# The State of Software Development AI made code cheap and left the real constraint standing — deciding what is true, and revising it safely. The new paradigms are engines in search of a substrate: structured meaning, deterministic execution, human authority at the boundary. ## Code just became cheap Something genuinely new has happened in software. For the first time in the history of the trade, producing working code is cheap. A developer today describes intent in natural language and watches a model produce working code in seconds. Agents complete multi-step tasks with less and less supervision. Whole categories of programming work — boilerplate, migrations, test scaffolding, glue — are collapsing in cost. Whatever else is true about the AI moment, this much is real, and it is not going back. The industry has concluded that software development is being transformed. The conclusion is correct — but not in the way most of the industry means it. To see why, look closely at what the new tools change, and at what they leave exactly where it was. ## The reinvention underway The new paradigms arrive weekly, but they form a recognizable family. Vibe coding: describe what you want, iterate by feel, let the model type. Agentic development: give the model tools and a goal, and let it work the task end to end. Multi-agent systems: let several models check and extend each other's work. Spec-driven development: write the specification first, and generate the implementation from it. Retrieval brings an organization's documents into the model's context. Protocols give models structured access to tools and systems. Structured output constrains what a model may emit. Evaluation harnesses measure whether any of it can be trusted. Each of these answers a real limitation, and each earns its adoption. But the family resemblance matters more than the members. Every one of them increases what a probabilistic system can be trusted to produce, reach and coordinate — some by extending its reach, some by fencing it in — and applied to software development as it stands, they feed the same pipeline, and the pipeline ends where it always ended: more code, faster. ## The nature of the instrument The honest scorecard is this: the new tools are extraordinary at producing plausible artifacts, and poor at guaranteeing that those artifacts preserve an institution's authoritative meaning. A generative model does not, by itself, carry a durable, governed account of a system's invariants, and it does not guarantee that the same situation will produce the same decision. Every output remains a probabilistic inference from whatever context and state the system around it supplies. That system can supply a great deal. Conversation state persists. Retrieval feeds in an organization's documents. Schemas constrain the shape of what a model emits; contracted tools bound what it can touch; evaluations catch classes of failure. These harnesses genuinely help — but they are the system around the model, not properties of the model. They constrain generation. They do not turn generation into an authoritative execution substrate. Nor is this a limitation to wait out. Better models will reduce error — and leave the deeper question standing, because it is a question of authority, not capability: what an institution treats as true must have a governed identity outside any individual generation. The model remains probabilistic where governed execution needs deterministic commitments, context-bound where institutions need durable authority, and fluent where systems need enforceable contracts. What is missing underneath the whole wave is a governed home for accepted meaning — one that is not reinterpreted, probabilistically, each time it runs. ## Prose is not the artifact There is a deeper issue than reliability, and it is older than the models: what prose is asked to do. The standard loop — describe intent in natural language, receive code — reproduces, at machine speed, exactly the translation that has failed institutions for decades. The first paper in this series traced that failure: an interpretation of the work, translated into a mechanism at a distance from the work, separated from its reasoning, frozen. The prompt is a specification document. Shorter, faster, more conversational — but the same artifact, with the same fate: interpretation loss on the way in, and a mechanism with no memory of why on the way out. Prose is where knowledge begins — descriptions, evidence, reasons — and nothing here argues against it as input; it is how experts will always first say what is true. The failure is prose as the terminal form: the last shape meaning takes before it disappears into mechanism. Much of what an organization knows is first said in natural language, and natural language is ambiguous, context-dependent and drifting; feeding it to a probabilistic machine compounds all three. The answer is not better prose. It is a structured language for meaning itself: a domain language an organization can author, version, review and validate — that a machine can check, and a system can run. ## The spec is not the model The industry has begun to notice the prose problem. Its best current answer is spec-driven development: write the specification first, treat it as the durable artifact, and let AI generate the implementation from it. The instinct is right. It demotes code from master to output, and it promotes the description of the work to the thing worth keeping. It is the closest the mainstream has come to the conclusion this series argues for. But look at what the spec is, and at what happens to it. It can be carefully structured — templated sections, acceptance criteria, even machine-checked consistency across its artifacts. What stays natural language is its domain semantics: the meaning of the specification is not formally typed, and nothing guarantees, by construction, that the generated implementation preserves the accepted meaning. The spec still becomes code through a probabilistic engine — the same lossy translation, now automated, repeated on every regeneration as a fresh interpretation of the same words. The specification guides generation. The implementation still runs. Practitioners will answer that acceptance criteria compile to tests, and tests run. True, and worth having. But tests check the points someone thought to check; they are not the meaning itself, running. The spec-driven shop now maintains three renderings of the same meaning — spec, tests, code — and hopes they agree. So the two can still diverge — not necessarily because the document is neglected, but because every generation is another interpretation, and semantic equivalence is not guaranteed by construction. The rule from the first paper reaches specifications in a softened but real form: knowledge that nothing runs on must be kept correct by discipline alone. Spec-driven development has half of the answer: the durable artifact should be the description of the work. The other half is the harder one, and it is where the rest of this paper goes: that artifact must be structured enough to validate, and it must be the thing that actually runs. ## Faster code, same freeze The first paper warned that adding AI that writes code faster does not bend the curve that matters — it produces frozen interpretations at higher speed. It is worth being precise about why. The cost of a system was never mainly the typing. It was deciding what is true: which concepts exist, which rules apply, what an exception means, who may do what, and when. That is interpretation, and in the conventional model it is embedded in code at the moment of writing. Making the writing faster makes the embedding faster — and the volume of encoded decisions can now grow faster than the organization's capacity to review the assumptions they contain. Be precise about the danger, too, because it is not code volume — and not every artifact carries meaning equally. Boilerplate may carry little. Tests, mappings and integration glue can carry a great deal: they encode business assumptions, and tests are often the clearest frozen statements of intended behavior a system has. The danger is the number of independently maintained places where domain meaning is embedded. Every cheaply generated application, workflow, integration and customization can become another point-in-time implementation of the same concepts and rules — unless it is derived from a governed source. When the domain changes, each copy must be found, understood, reconciled and revised, separately. Generative tooling does not only accelerate the freeze; under the conventional architecture, it multiplies the frozen copies. The semantic surface area an organization must later govern, explain and revise keeps growing. An organization that adopts generative tooling on top of the conventional architecture gets exactly this: tickets close faster while the system accumulates embedded decisions that are harder to trace — authored partly by a process that can produce a rationale, but cannot guarantee that the rationale is the reason the encoded decision is correct. The queue shortens. The audit gap widens. The shadow systems remain. The constraint was never code production — and it does not disappear when code production accelerates. It is exposed. ## The bottleneck moved The price of producing code is collapsing. What stands exposed is everything that cost used to hide: knowing what should be built, whether it is right, whether it may run, and who decides. These were always the real costs — the interviews, the workshops, the review meetings, the compliance checks, the arguments about what a rule actually means. In the conventional model they were bundled invisibly into development and paid through the queue. Now they stand alone. What will be scarce in the next decade of software, and therefore what will differentiate, is not code generation. It is judgment, review and governance: the human authority to decide what is true for this organization, and the machinery to hold that decision accountable once it runs. Engineers remain essential — but their highest-value work moves from repeatedly encoding domain decisions to building the machinery that makes governed decisions executable. Too often, the industry spends that scarce judgment reviewing machine-written code, line by line — at the furthest possible distance from the knowledge being encoded. That is the state of software development in one sentence: the profession acquired an engine of unprecedented generative power, and pointed it at the wrong artifact. ## Not a new idea — a new economics Structured, executable models of the work are not a new idea. Expert systems, rules engines, model-driven engineering and the low-code platforms that followed them each pursued a piece of this for decades, and business-facing formalization kept hitting the same two walls. The first was the economics of authoring: formalization demanded specialists translating the domain by hand, so the formal model became one more expensive artifact standing at a distance from the people who actually knew the work. The second was reach — where a tool did get close to the expert, it bought that closeness by narrowing what could be expressed, and the real work escaped through the gaps into code and spreadsheets. AI changes the first wall directly. The second is a language problem, and it is why the artifact this paper argues for has to be a domain language with a type system, not a form with fields. That is the constraint AI changes — and this, more than code generation, is its structural gift to software. A model can propose a formal domain model from descriptions and evidence, fast enough for the experts themselves to review, correct and re-propose, continuously. Formalization stops being a specialist bottleneck and becomes a conversation. What was missing was never the idea of an executable model of the work. It was an authoring economics that let the people who hold the domain govern one. ## The right artifact Point the engine at a different artifact, then, and the picture changes entirely. Instead of asking a model to write the application, ask it to propose the model of the work — in a structured domain language with a type system, validation rules and versions. Structure constrains generation: the language's grammar defines what can be expressed at all, and validation rejects the structurally invalid — the malformed, the inconsistent, the unresolvable — before a person ever sees it. What validation cannot judge is whether a rule is true to the work. That judgment belongs to the people who hold the domain — and the artifact is finally in a language where they can exercise it, instead of reviewing someone else's code line by line. This is the inversion, stated for software development: humans describe the domain and bring evidence; AI proposes the interpretation, in a structured form; authorized experts review and decide; only the accepted version executes. Generation is probabilistic — and is allowed to be, because nothing generated runs unreviewed. Execution is deterministic — and has to be, because that is where accountability lives. ## The platform they run on Seen this way, the paradigm wave is not a threat to be resisted or a religion to be joined. It is a set of engines in search of a substrate. Agents become safer and more governable when they act through capability surfaces with explicit contracts, rather than with unrestricted reach into open-ended codebases. Retrieval needs governed, versioned knowledge to retrieve — not document soup. Structured output needs a target language worth constraining to. Evaluation needs stable, governed reference behavior to evaluate against — not one probabilistic system grading another. Follow any serious AI-native pattern into governed work — work where meaning, authority and accountability matter — and it arrives at the same requirements: structure for meaning, determinism for execution, human authority at the boundary, and a trace for everything. That substrate is what Fluid is: one governed home for the domain's meaning, a deterministic runtime that executes only what was accepted, and an authoring boundary where AI proposes and humans decide. Fluid does not need to adopt the new paradigms. It needs to be the platform they run on. ## What this looks like when built Concretely: in Fluid, an organization's domain — its concepts, rules, processes, decisions — is authored as a structured, versioned artifact. Not free-form prose, and not general-purpose application code. AI participates on the authoring side: it drafts models from descriptions and evidence, proposes revisions when the domain moves, and works inside the language's type system, so that what it produces is validated before it is even considered. Authorized experts review the proposal in the domain's own terms and accept, correct or reject it, according to the organization's governance. Accepted knowledge assembles into a runtime that is immutable once built: the same domain version, the same input, the same configuration, the same result. Applications — the screens, the workflows, the portals — are projections of the domain, derived from it rather than written beside it. Every execution leaves a trace back to the version of the knowledge that produced it. Nothing generative sits inside the execution boundary. And because organizations are running while their domains move, evolution is built into the artifact rather than bolted on: domains are versioned, every piece of recorded work is stamped with the model version it was created under, and when the model moves, existing data either migrates forward under an explicit rule or fails loudly — never silently reinterpreted. Past results stay traceable to the version that governed them. Richer coexistence — effective dates, parallel versions in force — is a design requirement this architecture is built to carry, not an afterthought to retrofit. This is running today; we are building the first systems on it now. It is not another paradigm added to the pile. It is the layer that was missing underneath the pile. ## One rule changes Watch the whole argument in a single change. A professional describes a changed rule in their own words, with the evidence behind it. AI proposes the structured revision; validation rejects anything malformed before anyone reads it. The people the organization authorizes review it in the domain's own terms and accept it, and Fluid assembles a new immutable domain version. The screens, decisions and workflows that depend on the rule now follow that version — and every result produced under the old rule remains exactly as it was, traceable to the version that governed it. No ticket. No translation into someone else's code. No archaeology through frozen copies. The change is the size of the change. ## The choice The state of software development, then: an industry mid-upheaval, holding an engine that makes its old bottleneck cheap and its real bottleneck visible — and deciding, mostly by default, to use that engine to accelerate the architecture that was already failing. Said plainly: AI makes it cheap to multiply independently frozen implementations of domain meaning — unless meaning is first given a governed form outside the code. There is a choice available that is not the default. Stop making separately maintained application code the authoritative home of domain meaning. Give meaning one governed home. Use AI to make drafting and revision continuous; keep authority human; keep execution deterministic. The commitment, here as everywhere in this series, is the same: the work changes, and the software follows. ## Next in the argument The third paper is about the people who know: what the translation took from them, and what Fluid returns. - [Next: Liberating Domain Knowledge](https://fluid.nu/en/liberating-domain-knowledge) - [Download this paper as PDF](../papers/state-of-software-development.pdf)