How CodeSky builds production software

The generation pipeline

Generation is staged rather than single-shot. Each stage produces an artefact the next one depends on, which is what keeps the schema, the API and the interface describing the same application instead of three plausible but incompatible versions of it.

1. 01

   Intent and planning

   Your prompt is expanded into a concrete build plan — the screens involved, the entities behind them, the operations each screen needs, and the order the work has to happen in. Planning runs before any code is written, so the schema and the API are designed against the same model rather than reconciled afterwards.

2. 02

   Schema and data model

   Entities, relationships, constraints and indexes are derived from the plan and expressed as migrations. Because the data model is generated first, the API layer and the UI are both written against a schema that already exists instead of one inferred from screens.

3. 03

   Code generation

   UI, API endpoints, authentication, authorization rules and background jobs are generated together as one coherent codebase — not as isolated snippets stitched together. Shared types flow from the schema through the API to the components that consume them.

4. 04

   Build and live preview

   Every change is compiled and served to a live preview immediately. You refine by clicking an element directly or by prompting, and each edit is analysed, applied and written to a clean, reviewable history rather than overwriting what came before.

5. 05

   Deploy

   One click provisions the infrastructure, runs outstanding migrations, issues SSL, wires your domain and serves the application from multiple regions. The same pipeline runs on every subsequent deploy, so the first ship and the hundredth are the same operation.

What CodeSky generates

Every layer below is generated for each project — not assembled from a fixed template you then have to grow out of. See the full feature set for how each layer behaves while you are building.

Model routing

No single model is best at every task. Scaffolding a component, reasoning about a schema migration and explaining a stack trace reward different strengths, so CodeSky benchmarks prompts across frontier models — Claude and GPT among them — and routes each task to whichever performs best on latency, cost and accuracy at that moment.

Routing is a default, not a constraint. Teams that need reproducibility, or that have approved a specific model for internal use, can pin one model for an entire workspace and opt out of routing altogether.

Your code, in your repository

CodeSky is GitHub-native. It synchronises in both directions with your repository, opens readable pull requests rather than opaque bulk commits, and leaves a git history you can review, blame and roll back like any other project. Work done in CodeSky and work done by your engineers land in the same place.

That also defines the exit. You can export the project or self-host it at any point, and the generated code carries no runtime dependency on the platform — an application built on CodeSky keeps running whether or not it stays on CodeSky.

Deployment and infrastructure

Deployment is one click and one pipeline: CodeSky provisions the infrastructure, runs any outstanding database migrations, issues and renews SSL certificates, wires your custom domain, and serves the application from multiple regions. Because migrations run as part of the release, the schema and the code that expects it move together rather than drifting.

The same pipeline runs on every deploy, so shipping a change on day two hundred is the identical operation to shipping on day one — there is no separate, more fragile production path to maintain. See the end-to-end walkthrough.

Security and access control

Authorization is generated as server-side enforcement. Role and permission checks live in the API layer, so hiding a control in the interface is a presentation decision rather than the security boundary — a request that should not be permitted is rejected by the server regardless of which client sends it.

Applications are generated with authentication, session handling and input validation in place from the start. Organisations with specific compliance, residency or review requirements can talk to us about enterprise deployments.

Arabic and right-to-left by default

Right-to-left support is part of generation rather than a retrofit. Generated applications handle Arabic content, full RTL layouts and multi-language interfaces as a normal case, which means mirrored layouts, correct text direction and localised content are handled when the code is written instead of being patched in after a redesign.

Local development with CodeSky Desktop

For engineers who would rather work on their own machine, CodeSky Desktop is a complete AI-powered IDE: inline editing over a selection, a visual debugger with real breakpoints, AI in the terminal, AI-written commit messages, and Model Context Protocol support for connecting your own tools and data sources.

It also runs local models through Ollama, with a hardware-aware picker that matches the model to what your machine can actually run — useful when code cannot leave your network. Repository conventions and a .codeskyrules file let you hold generated code to the standards your codebase already follows.

Frequently asked technical questions