The Bottleneck Did Not Disappear. It Moved.

The afternoon the code stopped being the hard part

A few weeks ago I shipped a release of a Rust tool I maintain on the side. Fourteen files changed. A new subsystem, its tests, its docs, and a migration for the config format. I typed almost none of it. I wrote a page of intent: what the subsystem does, what it must never do, what an acceptable test looks like, which crates it may not pull in. Then I let the agent run.

The generation took the length of a coffee. What took the rest of the afternoon was everything after. I read the diff and found a design decision I had not asked for and would not have made. I read the tests and found two that could not fail. I found a dependency I had never heard of, went to look at who maintains it, and came back less sure than when I left. Then I sat with a question I had never needed to ask about my own code. Do I trust this enough to ship it?

I shipped it. But the ratio stayed with me. Ten minutes producing, four hours deciding whether what was produced was right, safe, and mine.

That afternoon is now every afternoon, in every engineering organization I talk to. The code is no longer the hard part. The hard part is knowing whether the code is right. We have spent forty years optimizing the wrong phase.

The assumption nobody wrote down

Every version of the software development life cycle shared a premise so obvious it never made it into the diagram. A human typed the code.

That premise did quiet work everywhere. Code review was sized for human output, a few hundred lines a day per engineer, so a reviewer could read all of it. Security scanning ran on a cadence set by how fast people could produce things to scan. QA planned test cycles around sprints because sprints were how fast humans shipped. Governance lived at the release gate because releases were rare enough for a gate to be a reasonable place to stand. Staffing ratios, one reviewer per few engineers, one security person per few dozen, were tuned to the same throughput.

None of these were principles. They were calibrations. Settings tuned to a specific input rate.

Now the input rate is not human. An agent produces in an hour what a team produced in a week, then produces it again with a different design when you change one sentence of the prompt. The calibrations did not break loudly. They stopped meaning anything. Review queues grew until reviewers started skimming. Scan results grew faster than anyone could triage, so triage became sampling. Governance gates became either a formality that waves everything through or a wall the organization routes around.

The bottleneck did not disappear when the code got cheap. It moved.

Where it moved to

I think about the new lifecycle as six phases arranged as a loop. The names are ordinary on purpose. What matters is where the weight sits and what you would measure at each step.

• Intent. What happens: Goal, constraints, acceptance criteria. What changed: The highest-leverage human work. What I would measure: Share of generated work traceable to a written intent.
• Generate. What happens: Agents produce code, tests, docs, infra. What changed: Cheap, parallel, non-deterministic. What I would measure: Cost and time to first candidate, not much else.
• Validate. What happens: Correct, secure, what was asked for. What changed: The new bottleneck. What I would measure: Share of validation signal independent of the generator.
• Govern. What happens: Policy, license, provenance, audit. What changed: Continuous, not a gate. What I would measure: Drift between policy as written and what shipped.
• Deploy. What happens: Ship it. What changed: Mechanically familiar, higher volume. What I would measure: Unchanged.
• Observe. What happens: Runtime behavior back into Intent. What changed: Turns the pipeline into a loop. What I would measure: Latency from production signal to a changed intent.

I call the category the Agentic Development Life Cycle, and the model itself Intent to Evidence, because that is the arc. Intent enters at one end. Evidence that the intent was met, and that nothing else happened along the way, comes out the other. Everything between is machinery for turning one into the other.

In the old lifecycle the weight sat on phase two. Hiring, tooling, process, and culture were all organized around getting more and better code out of people. In the new one, phase two is the cheap part. The weight moved to phases one, three, and four. Intent, Validate, Govern. Those are where the queues form now, where the risk concentrates, and where almost nobody has rebuilt their organization.

The objections, and why they do not hold

This is the part that does not fit in a LinkedIn edition. Four objections come up every time I present this. They deserve real answers.

Agents will get good enough to validate themselves. Capability is not the problem. Incentive is. A system that grades its own work optimizes for the grade, and a more capable system finds a better shortcut to it, not a worse one. This is the independence thesis I keep returning to: the generator cannot be its own auditor. It started as a security argument and it is now an organizational design argument. Independence has to be structural. Separate tooling, separate signals, and in the places that matter, separate people. Better models make this more urgent, not less.

This is DevSecOps with a new name. We already shifted left. Shift-left assumed a human author to shift toward. Put the security feedback in the developer's editor, in the pull request, in the sprint. In the new lifecycle there is no human author at the point of generation to shift toward. The shift goes further upstream, into the intent that bounds what the agent may produce, and further downstream, into observation of what it did produce. The middle, where DevSecOps did its work, is now the phase that carries the least weight.

Cheaper code means we will just write less of it. Every previous drop in the cost of computing produced more computing, not less. Cheaper code will produce more code. More services, more variants, more experiments, more of everything that needs to be validated and governed. Organizations planning for the same volume at lower cost are planning for the one scenario that will not happen.

Skip the review and trust the tests. The tests were generated by the same process that generated the code. Two of mine could not fail. A passing test suite written by the generator tells you the generator is consistent with itself. It does not tell you the code is right.

What it changed for me as a builder

I build alone in the evenings, and the shift showed up in my own habits before I had a name for it.

I write intent files now. Not prompts. A document per subsystem stating what it does, what it must never do, what an acceptable test proves, and which dependencies are off limits. They live in the repo. They are the part I still author, and they are the artifact everything else is bounded by. When something goes wrong, the first question is whether the intent was wrong or the generation was, and the file makes that answerable.

I use a second, different model as the reviewer. Not because it is smarter. Because it did not write the code, and it does not share the first model's blind spots. It reads the diff against the intent file and reports what does not match. It catches things I would have missed at the end of a long day, and it never gets tired of reading.

I keep a manifest of what I have not read. Every release, the list of files I merged without reading line by line. It is uncomfortable and it is honest, and it tells me exactly where my observation phase has to be sharpest.

None of this is sophisticated. It is what one person does when the ratio flips. An organization has to do the same thing at a scale where habits are not enough and structure is required.

What it changes for the organization

If you lead product or engineering, the practical consequence is a reallocation. Not a new tool. A different answer to where the people, the budget, and the attention go.

• Hiring for output. To: Hiring for judgment: intent authors, validators, people who can say no.
• Review sized to read everything. To: Review that samples, plus signals independent of the generator.
• Security as a scan cadence. To: Security as constraints before generation and observation after.
• Governance at the release gate. To: Governance expressed in intent, enforced in production.
• Product writes the PRD and waits. To: Product owns intent, builds in the repo, breaks the circuit when needed.
• Pipeline from ticket to release. To: Loop from production evidence to the next intent.

The last row is the one most organizations skip. Observation got cheap along with generation. Telemetry, incident data, usage, drift, all of it is available in a form an agent can read and a human can act on. Organizations still running the lifecycle as a straight line are throwing away the one signal that tells them whether their intent was right.

Where the series goes

This is the first of a set. Each phase that now carries the weight gets its own piece: why intent is the new source code, what independent validation looks like in practice, how governance moves from gate to phase, and what closing the loop requires. Alongside them, one on what the product role becomes when the codebase is the single source of truth. I call that role the Full Stack PM, and it deserves more than a paragraph.

Part of my day job is running an organization through this shift. Part of my evenings is living it alone, at a pace I could not have imagined three years ago. The two views agree on one thing. The hard problem of software was never producing it. It was knowing what you had produced. We are about to find out how many of our institutions were built on the assumption that producing it was the hard part.

Intent goes in. Evidence comes out. Everything else is the machinery. Rebuild the machinery.