Blog

An OpenAPI spec is a second copy of your API, written by hand or scraped from decorators, and it drifts from the code the moment either one moves. But a Sky app's endpoints and their request and response shapes are already known to the compiler, statically and completely. So Sky derives the whole OpenAPI 3.1 document from the typed source — no annotations, no drift — with real JSON Schema for every payload and the CSRF scheme on the endpoints that need it. It validates clean and imports straight into Swagger UI or a gateway. One command, `sky doc --api openapi`.

An LLM agent is a loop that spends money and takes real actions across minutes or hours, on infrastructure that restarts. Sky's new Std.Ai layer treats that honestly. The agent runs as a durable workflow, so a crash mid-run resumes from the last step and never pays for the same model call twice. And the model never authorises an action — it proposes a typed one, a pure policy decides, and only an allowed decision runs the effect. The whole thing is testable offline with no key and no network. The capstone is a Slack bot in one file.

Every architecture diagram I have ever drawn was out of date the week after I drew it, because it lived in a different file from the code and nothing kept them honest. So Sky generates them from the compiler's own view of the program — and I have since made them good enough to submit. Four diagrams — a C4 container map, a behaviour-and-data-flow diagram with real trust boundaries and confidential-data markers, an API call-path table, and a data-egress inventory — read straight from the typed IR, as PlantUML or a self-drawn SVG. One `--diagram audit` command writes the whole pack — every diagram, a data inventory, a named sub-processor register, and an index that maps each artefact to a SOC2 or ISO control. It is the folder you hand an auditor.

"If it compiles, it works" was always half a promise. The compiler catches the errors it can see in the types. It cannot see a dropped field in an RPC that still type-checks, or a handler that panics on an input a user can actually send. Those you find in production, or you find them with tests you have to write by hand. This is the story of the tests Sky now writes for you — one `sky fuzz` command that folds random messages through your update and adds a differential split oracle when you target a client, mocks derived from your own effect boundary, and a command that scaffolds the fixtures from the types.

Sky.Live put the whole web app on the server — one language, no separate frontend. But some apps want the loop on the client: offline, native, low-latency. So the same Model / update / view you write for Sky.Live now compiles to wasm and runs on the client, and ships from one source to web, desktop, iOS and Android. This is the story of Sky.Spa — the auto-split that shares types without symlinks, the native APIs you can extend yourself, and the honest line about what wasm is not.

Four days ago I wrote that Sky had shipped embedded PostgreSQL instead of a database I would have had to maintain. Today the blog you are reading runs on it — on a 969 MB machine, the whole app plus its own PostgreSQL sitting in about 106 MB. This is the production story: what the migration actually took, the one typed config that now drives the whole app, and the honest numbers on memory, security, and the tradeoff I made.

Three days ago I wrote about BlueDB, a data layer I was building for Sky, and said most of the gates that would tell me it worked had not been run. They have been run. Then a build-versus-buy review asked whether a custom engine was justified at all, and the answer was no. What shipped instead is embedded PostgreSQL — a real one, bundled and supervised by the toolchain, across four tiers, arranged so the app never knows which tier it is in.

This post is about two things that do not exist yet. BlueDB, a data layer built for the way Sky apps actually hold state, and a deployment platform meant to give the whole stack one honest end-to-end story. Neither has a date. Here is what they are, why the language needs them, and the parts of Sky that are still maturing in the meantime.

Sky's compiler was written in Haskell, and Haskell got it a very long way. Then one 24,000-line module, held together with global mutable state I spent a whole release trying to remove, told me the architecture had hit its ceiling. This is the story of the rewrite. Why Rust, why now, and the one decision that made replacing a working compiler feel safe rather than reckless.

"If it compiles, it works" is a slogan a dozen languages have used. In Sky Lang it's a contract — defined precisely, enforced by three release gates, and load-bearing for every decision the language makes. Here's what the contract says, how it's enforced, and the bug class that proved removing a single line of CSS can close five filed bugs.

Twelve weeks ago I started building a new language. Today it's at v0.15.55 with 1,232 commits, 35 examples, and 485 compiler specs. Here's the bet, the principles that held, and why I believe Sky Lang is the language AI builds production apps in.