Ask a team what they would grab if the building were on fire, and for seventy years the answer was the source code. Losing it meant losing the company’s accumulated decisions, the thousands of small judgments that make a system fit its business. That answer is quietly changing. When agents can regenerate a working implementation from a precise statement of what the system must do, the code stops being the crown jewels. The statement is. We call the practice that follows from taking this seriously intent-driven development: the discipline of making the intent — not the code — the artifact your team writes, reviews, versions and owns.
The claim in the title needs immediate qualification. “Writing code becomes optional” does not mean nobody reads code, or that generated code doesn’t matter, or that engineering skill is obsolete. It means something narrower and more interesting: for a growing class of work, hand-typing the implementation is now a choice rather than a necessity — and teams should decide deliberately where they still make that choice, instead of making it everywhere out of habit.
Intent is not vibes
The word “intent” invites abuse. It sounds like something you could satisfy with a mission statement and a mood board. In practice, intent that can drive development is a set of verifiable statements about behaviour — statements a machine or a colleague can check a system against and answer pass or fail. “Customers should have a smooth checkout” is a sentiment. “A returning customer completes checkout in three steps; a failed payment preserves the cart and explains the failure in the customer’s language; no double charge is possible even if the confirm button is clicked twice” is intent. The difference is checkability, and it is the entire difference.
Intent stacks in three layers. At the top sits product intent: what outcome the system exists to produce, for whom, measured how. Below it live system invariants: the properties that must hold regardless of implementation — money conserves, audit trails append, personal data stays inside the boundary, deletes are recoverable. At the bottom sit acceptance tests and evals: the executable form, the layer a pipeline can actually run. Each layer justifies the one below it; each layer below makes the one above checkable. A team that maintains all three can hand implementation to an agent the way a client hands construction to a contractor — against drawings, not adjectives.
If that sounds like a close cousin of writing contracts for AI agents, it is. Spec-driven development is the per-task discipline: one piece of work, one contract, one verification loop. Intent-driven development is what the codebase looks like when that discipline compounds — when the accumulated contracts, invariants and evals become the system’s real description, and any given implementation is just the current compilation of it.
Code as a build product
The practical consequence is a shift in what “the source” means. In a compiled language nobody patches the binary; they change the source and rebuild. Intent-driven teams start treating implementation code the same way: when behaviour must change, the first edit lands in the intent layer — a new acceptance test, a changed invariant, a sharpened product statement — and the implementation is regenerated or reworked to satisfy it. The code remains readable, reviewed and load-bearing. What changes is its status: it is derived, and the thing it derives from is the thing you argue about.
Review changes target accordingly. Reviewing three thousand generated lines at reading speed is theatre; the reviewer approves what they cannot actually hold in their head. Reviewing the intent diff is tractable: what new behaviour was promised, which invariants were touched, do the new tests actually pin down the promise, and does anything in the implementation diff exceed what the intent explains? The senior engineer’s attention moves up a level — from “is this loop correct” to “is this the right promise, and is it enforced.” That is not a demotion of engineering judgment. It is engineering judgment applied where it now pays most.
The code is derived. The intent is the source. Teams that argue about the source ship faster than teams that argue about the compilation.
Where hand-written code still wins
Honesty about the boundary keeps this from becoming ideology. Some code should still be written by hand, and the categories are consistent. The hot core— the pricing engine, the matching algorithm, the risk model — where every branch embodies a business decision and the team’s comprehension of the code is itself an asset. Novel algorithmic work, where the intent cannot be stated more precisely than the implementation because discovering the implementation is the work. Safety-critical boundaries— authentication, cryptography, payment initiation — where review depth matters more than production speed and you want a human’s fingerprints on every line. And the intent layer itself: tests, invariants, evals and schemas deserve human authorship precisely because everything else is checked against them.
The useful question for any given piece of work is not “can an agent write this?” — increasingly it can — but “what do we lose if no human writes it?” Where the answer is “nothing, provided the intent is enforced,” generation is the rational default. Where the answer is “our understanding of the thing that makes us money,” type it yourself.
How it rots
Intent rotis the first failure mode. The intent layer is only the source of truth while it is maintained like source. The moment a team starts patching behaviour directly — a hotfix here, a quick manual edit there — without back-propagating the change into tests and invariants, the intent begins describing a system that no longer exists. Then the next regeneration, faithfully compiled from stale intent, erases the undocumented fixes. The rule that prevents it is the same one that keeps schemas honest: behaviour changes land as intent changes first, in the same pull request, or they don’t land.
Regenerating without re-verifyingis the second. Regeneration is not idempotent: two runs against the same intent produce different code with different incidental behaviour, and anything the intent layer doesn’t pin down is free to change. Teams get burned when they assume yesterday’s green pipeline vouches for today’s regeneration. It doesn’t. Every regeneration is a new implementation and earns the full verification pass — tests, evals, invariant checks — every time. If that is too expensive to run per regeneration, the fix is to make verification cheaper, not rarer.
Treating generated code as disposable when it is load-bearingis the third and subtlest. A team internalises “the code is just a build product” and stops reading it entirely — no review, no profiling, no operational familiarity. Then an incident arrives at 2 a.m., and the people on call are debugging a system nobody has ever read, guided only by the intent it was meant to satisfy. Derived does not mean ignorable. Production code demands operational ownership regardless of who typed it; the intent layer tells you what the system should do, but incident response still happens in what it actually does. The teams that handle this well designate an owner for every generated component the same way they would for a hand-written one — someone who has read it, profiled it and can page through it under pressure.
A pragmatic adoption path
None of this requires a revolution, and teams that attempt one usually produce a manifesto and no change. The working path is incremental. Start by making intent explicit for the system you already have: write down the invariants you believe hold, turn the tribal knowledge into acceptance tests, and get honest about where the tests and the system disagree. This step pays for itself even if no agent ever touches the codebase — it is simply the documentation and test coverage you owed yourselves anyway.
Then pick one bounded, well-understood component and run the full loop on it: intent written and reviewed, implementation generated against it, verification mechanical, human review aimed at the intent diff. Measure honestly — cycle time, defect rate, review effort — against the hand-written baseline. Expand along the boundaries where the loop wins; keep typing where it doesn’t. Within a few quarters the codebase sorts itself into a hand-written core with a generated periphery, and the team’s scarce senior attention concentrates on the layer where it compounds: deciding, precisely and checkably, what the software must do.
The industry has been here before. Nobody mourns writing assembly by hand; we kept the ability and dropped the habit, because a higher-level source plus a trustworthy compiler was simply a better deal. Intent plus agents plus verification is shaping into the same deal, one level up. Writing code is becoming optional. Knowing exactly what the code must do — and being able to prove it does — is becoming the job.