The one-line version: AI is an amplifier; the organizations that invest in what it amplifies — architecture, feedback loops, disciplined review and judgment — will win, and the rest will discover that entropy has been automated too.

The key takeaways

  • The bottleneck moved. Writing code was the slowest, costliest step for fifty years, and the entire SDLC existed to aim that scarce act correctly. When agents make implementation nearly free, the constraint shifts to planning, review, deployment and — ultimately — deciding whether to build something at all.
  • Both the optimists and the skeptics are right. Uber doubled output; METR measured experienced developers going 19% slower. These aren’t contradictory findings about the model — they’re measurements of different systems. DORA’s “amplifier” framing reconciles them: AI magnifies existing strengths and weaknesses.
  • Changing the tools is not changing the work. Amazon ran the same tooling across 50 ordinary teams: half saw under 3× improvement, half a median of 4.5×. The discriminator was whether a team redesigned how it worked — and the teams that did got slower before they got faster.
  • The SDLC becomes a loop, not a line. Six stages bound together by committed artifacts (intent.md → spec.md → plan.md → diff → review → incident), with agents embedded at every stage and humans positioned above it — instigating, directing, governing.
  • Governance gets executed, not convened. Policy applied as skills while code is written, enforced as hooks while agents act, and evidenced as an artifact chain that doubles as the audit trail. The review board becomes a hook; the change ticket becomes an artifact.
  • Bad code is now the most expensive it has ever been. AI performs dramatically better in a clean codebase than a tangled one, and entropy compounds at agent speed — so “ignore the code and let it manage itself” is just vibe coding by another name.
  • The oldest ideas have the highest leverage. Brooks on conceptual integrity, Evans on ubiquitous language, Ousterhout on deep modules, Beck on daily design investment — principles written for humans coordinating with humans turn out to be the operating manual for humans coordinating with agents.

1. The bottleneck that moved

For half a century, the software development lifecycle was organized around a single economic fact: writing code was the slowest, most expensive thing a technology organization did.

Everything else — the PRDs, the estimation rituals, the review boards, the staged sign-offs — existed to make sure that the scarce, costly act of implementation was aimed at the right target. As Anthropic’s AI-Native SDLC Playbook puts it, the traditional SDLC “was designed to maximize efficiency in an era where the most time-consuming and expensive stage was writing and implementing code, which is no longer the case.”[1]

That era is over. When an agent can produce a working diff in minutes, the build phase collapses from weeks to hours, and the entire process architecture built around it becomes a friction machine. The playbook identifies three consequences: the bottleneck shifts left and right of build (to planning, review and deployment, which still run at human speed); the controls stop matching reality (line-by-line human review cannot keep pace with agent-generated diffs); and governance costs rise, because exceptions still route through committees that meet weekly.[1]

This is not a theoretical projection. On stage at a 2026 conference, Uber’s engineering leadership reported that more than 70% of their pull requests are now authored by local or cloud agents, that lines of code per engineer doubled year-over-year, and that over 250 automated migrations had touched 9 million lines of code — across an organization of a few thousand engineers at twelve global sites.[2] Whatever one thinks of lines-of-code as a metric, the directional claim is hard to dismiss: the constraint on software output is no longer typing.

And yet the honest empirical picture is more complicated, and it is worth holding both truths at once. In mid-2025, METR ran a randomized controlled trial with experienced open-source developers working on mature repositories and found that AI tools made them 19% slower — even though the developers themselves believed they had been sped up by 20%.[3] Google’s DORA program, surveying nearly 5,000 professionals for its 2025 State of AI-assisted Software Development report, reached a conclusion that reconciles the contradiction: AI is “an amplifier, magnifying an organization’s existing strengths and weaknesses.”[4] High-performing organizations accelerate; dysfunctional ones ship chaos faster. Uber’s numbers and METR’s numbers are both real — they are measurements of different socio-technical systems. The difference is not the model. It is the lifecycle wrapped around the model.

A third body of evidence sharpens the point rather than settling it. Clare Liguori, a senior principal engineer at AWS, reports that Amazon teams practising what the company calls frontier development — where agents write all but one or two percent of the code, run for hours without intervention, and several run at once — have shown a median productivity improvement of 4.5×, with some teams above 10×.[13][14] Her own gain from the earlier phases of AI assistance — completion, chat, vibe coding — she puts at 10 to 20%.[13] These are a vendor’s internal figures for its own tool, counted in commits and normalized deployment velocity rather than measured under controlled conditions, and they should be read as such. But they come with something neither METR nor DORA offers: a comparison drawn inside one company, with the tooling held constant.

That difference is what this essay is about.

2. From the line to the loop

The classical SDLC is a line: plan, design, build, test, deploy, maintain, with documents and tickets ferrying work between stages and ownership changing hands at each boundary. The AI-native SDLC, as Anthropic frames it, is a loop — the same six stages, but wired together by committed artifacts rather than meetings, with agents embedded at every point and humans positioned above the loop: instigating, directing, governing.[1]

The mechanism is deceptively simple: every stage ends by committing an artifact that the next stage begins by reading. An idea becomes an intent.md, written in the originator’s own words during a brainstorm with an agent. An accepted intent triggers a design pass that produces spec.md, with brand, security and compliance policies applied while the spec is written — encoded as reusable skills — rather than discovered in a review weeks later. An approved spec triggers plan mode, producing plan.md, which an engineer interrogates before any code exists. The diff and its tests follow, then layered agentic review, then deployment behind hooks that act as approval gates. And in the final stage, the loop closes: a deterministic monitor detects a control-band breach in production, invokes an agent with no human in the invocation path, and the agent’s diagnosis is written back into the pipeline as a new intent.md.[1]

Two design decisions in this architecture deserve emphasis, because they separate serious practice from theater.

The first is to keep detection deterministic and judgment agentic. The monitoring that decides whether to invoke an agent is a versioned, unit-tested script using statistical bands — no model involved. The agent is only summoned once a band is breached, and response tiers define what it may do: at one sigma, log; at two, diagnose read-only; at three, act — but only by opening a pull request into the review gate or triggering a pre-approved runbook.[1] Autonomy is rationed by evidence, not granted by enthusiasm.

The second is the artifact chain as audit trail. The sequence of intent.md → spec.md → plan.md → diff → review findings → incident record is simultaneously the working memory of the agents and the compliance record for auditors: who asked for what, what the agent produced, who approved it.[1] In the traditional SDLC, accountability and speed traded off against each other. In the artifact-chained loop, the same mechanism delivers both — which is precisely what regulated enterprises need before they can let agents touch production.

3. The platform underneath: lessons from Uber’s software factory

If Anthropic’s playbook is the process view, Uber’s talk is the infrastructure view of the same transformation — and the convergence between the two independent accounts is striking. Uber describes six building blocks, each of which answers a question the AI-native SDLC raises but does not itself solve:[2]

  • A model gateway so that every request — from any harness, to any frontier or open-source model — passes through one endpoint with PII redaction, safety guardrails under a strict latency budget, and per-user, per-team, per-project attribution. Over 800 internal projects route through it, handling more than 100 million model requests a day. Governance that cannot see the traffic cannot govern the traffic.
  • An MCP gateway that projects thousands of internal APIs and SaaS tools into agent-callable tools behind one entry point, with aggressive token optimization (a single discover-and-invoke “Omni MCP,” CLI projection, and a code-mode skill) that cut fleet-wide token consumption by more than 40%.
  • Agentified environments: pre-provisioned, pre-indexed cloud dev pods that let an agent start real work in seconds, and a “mega devpod” spanning all repositories — because agents, unlike specialized engineers, routinely work across repo boundaries.
  • A managed skills marketplace with lint checks, automated review and feedback loops: 2,500 skills, over 20,000 executions a day. Institutional knowledge becomes versioned, quality-gated and centrally improvable — the exact role Anthropic assigns to skills as “advisory controls.”[1][2]
  • A context graph: 150 node and edge types, 40 million entries, connecting services, owners, dependencies, design docs, Jira tickets and incidents — so agents stop burning tokens and latency rediscovering basic organizational context scattered across twenty or thirty systems.
  • A single assistant surface (Uber’s “Cortana”) through which every employee, engineer or not, reaches all of the above from Slack, CLI or web.

On top of these blocks, Uber’s end-to-end demo walks a feature — a World Cup stadium pickup flow — from a Slack brainstorm through business research, PRD, Figma variants, autonomous implementation by its cloud coding agent, simulator-based visual validation against the design mocks, self-healing CI, and a split code review (a fast model in the inner loop, a reasoning model in the outer loop), with a table of every automated check attached to the PR so the human reviewer inherits confidence rather than having to manufacture it.[2]

Notice what this stack is really doing: it is moving the control objectives of the old SDLC — accountability, review, policy enforcement, auditability — out of meetings and into middleware. The review board becomes a hook. The architecture guideline becomes a skill. The change ticket becomes a committed artifact. The on-call runbook becomes a pre-approved agent route. Uber’s closing slide named the new bottlenecks explicitly: CI capacity, experiment throughput and decision-making — “not can we build it, but should we build it.”[2] When implementation is nearly free, judgment becomes the scarce resource. The whole platform exists to concentrate human attention on exactly that.

4. The counterrevolution: code is not cheap

Against this optimism runs a necessary corrective, delivered in the second talk — a practitioner’s argument that begins with a confession. The speaker tried the “specs-to-code” workflow: write a specification, generate the code, and when something is wrong, fix the spec and regenerate — never reading the code. Each regeneration produced worse code than the last. “The idea that we can just ignore the code and let it manage itself,” he concluded, “is just vibe coding by another name.”[5]

The reference is to Andrej Karpathy’s February 2025 coinage — “fully give in to the vibes… forget that the code even exists” — a practice Karpathy himself framed as suitable for throwaway projects.[6] (It is telling that by early 2026 Karpathy was publicly declaring vibe coding passé in favor of “agentic engineering”: orchestrating agents, yes, but “without any compromise on the quality of the software.”)[7] The talk’s thesis inverts the movement’s founding assumption. If “code is cheap” were true, ignoring it would be rational. But code is not cheap: bad code is the most expensive it has ever been, because AI performs dramatically better in a good codebase than in a tangled one. Entropy — the Pragmatic Programmers’ old warning that systems decay whenever change is made without regard for the design of the whole — now compounds at agent speed.[5][8]

From that thesis come practical disciplines, each one an old software fundamental rediscovered as an AI technique:

  • Shared understanding before artifacts. The failure mode “the AI didn’t do what I wanted” is a requirements problem, not a model problem — Brooks’s “design concept” never formed between human and machine. The fix is adversarial elicitation: a skill that instructs the agent to interview the human relentlessly — forty, sixty, a hundred questions — until a shared understanding exists, and only then to write the PRD.[5][9]
  • A ubiquitous language. Domain-driven design’s shared vocabulary, compiled into a markdown glossary that both human and agent think with, measurably reduces verbose misalignment in planning and implementation.[5][10]
  • Feedback loops and small steps. “The rate of feedback is your speed limit.” Tests, types and browser access exist so the agent can verify its own work; test-driven development forces the small, deliberate steps that agents — left to themselves — are bad at taking.[5][8]
  • Deep modules. Ousterhout’s distinction between deep modules (rich functionality behind simple interfaces) and shallow ones turns out to be an agent-readability property: codebases of scattered shallow modules are hard for agents to navigate and reason about, while deep modules with well-designed interfaces give clean boundaries to test at and clean seams to delegate behind.[5][11]
  • Design the interface, delegate the implementation. The human’s attention goes to the boundaries — the module map, the interfaces, the design decisions that are expensive to reverse — while the agent fills in the interiors. Kent Beck’s “invest in the design of the system every day” stops being a virtue and becomes an operating procedure.[5]

Amazon’s field experience puts a price on that discipline. Nearly every team Liguori interviewed reported that its productivity fell while it adopted the new way of working. Before agents could run unattended, the teams had to write down the context that had lived in stand-ups and code review, rewrite error messages so that a model could act on a failure, build internal tools and MCP servers, and restructure repositories so that agents could navigate them; some went as far as changing language — away from untyped Python and JavaScript, toward TypeScript and Rust, where a compiler returns a precise, machine-readable complaint.[13] None of that is AI work. It is the ordinary engineering investment this section argues for, and it has to be paid before the curve turns upward.

The closing metaphor reframes the engineer’s role: the AI is a superb tactical programmer — a sergeant on the ground making changes — and the human must operate at the strategic level, which “requires software fundamental skills that we’ve been using for twenty years. For longer.”[5]

5. Synthesis: one transformation, three altitudes

Read together, the three sources are not in tension. They are the same transformation observed from three altitudes, and each supplies what the others lack.

The individual engineer’s craft (talk two) explains why the platform investments (talk one) pay off. Uber’s context graph is, at organizational scale, exactly the “ubiquitous language” and module-map problem: giving the agent the shared concepts and boundaries it needs to reason. The skills marketplace is the “grill me” and TDD disciplines industrialized — elicitation, verification and design review encoded once and applied fleet-wide. And the playbook’s CLAUDE.md — “the context a new joiner would need,” updated whenever the agent makes the same mistake twice — is simply the personal practice of maintaining a shared language with the agent, promoted to a team artifact.[1]

Conversely, the platform and process layers explain why individual heroics don’t scale. A single engineer’s careful TDD loop cannot govern a hundred million model requests a day; that requires gateways, attribution and hooks. And the DORA data supplies the unifying theory: AI amplifies the system it enters.[4] Good architecture, fast feedback loops and disciplined review were always the determinants of delivery performance; the AI era has merely raised the stakes, because amplification works in both directions. A deep-module codebase with strong tests becomes a compounding asset — every agent session is more effective inside it. A shallow, entangled codebase becomes a compounding liability — every agent session adds entropy faster than the last.

This synthesis also resolves the apparent paradox of the METR result. Sixteen experts in million-line repositories, working two-hour tasks with early-2025 tools and immature workflows, went 19% slower.[3] Uber, with six years of monorepo and build-system investment behind it and a purpose-built agent platform on top, doubled output.[2] The lesson is not that one of them is wrong. It is that the productivity of AI in software engineering is a property of the lifecycle, not the model. METR’s own follow-up work points the same way: by early 2026, developers were refusing to enroll in experiments that required working without AI — selection effects so severe the study design itself had to be abandoned.[12]

The closest thing to a controlled version of that comparison comes from inside Amazon Stores, which tracked roughly 50 ordinary teams — mixed seniority, existing systems, no handpicked experts — working their normal backlogs with the same tooling. The results split almost in half: one group landed under 3× improvement, the other reached the 4.5× median and in places went past 10×. What separated them was not which tools they used but whether they deliberately rebuilt their way of working around the tools, rather than adding the tools to the way they already worked.[13][14] Two other Amazon results are quoted more often — six engineers rebuilding a Bedrock inference data plane in 76 days against an estimate of 30 people over a year and a half, and a Prime Video sprint that cut a 90-week projection to 24 — but both carry conditions that resist generalization: the first team included two distinguished engineers working greenfield, and the second ran for ten days with no on-call, few meetings, and three weeks of pre-written, tightly scoped tasks waiting for it.[13] The unglamorous 50-team pilot is the more useful evidence precisely because it varies the practice while holding the tools, the company and the codebases fixed.

6. What it costs

Accounts of this transition usually stop at the throughput figures. The Amazon report is more candid than most, and the candour is worth borrowing.

The first cost is paid by people. Liguori describes engineers staying up late to craft the prompt that will keep an agent working through the night, so that a finished change is waiting in the morning — and names the risk plainly: burnout. Running several agents at once raises cognitive load rather than lowering it, as attention fragments across terminal tabs. And reviewing generated code is harder than writing it for engineers early in their careers, who have not yet spent years reading other people’s work.[13] That inversion deserves attention, because the frontier practice asks exactly this group to do more reviewing and less writing.

The second cost is organizational, and it falls on leadership. A team cannot slow down to speed up if the people above it read two quiet months as underperformance; Liguori counts herself among the leaders who have asked why a team with good models is not going faster.[13] Rolling the practice out too broadly, too early, has its own failure mode: no time to discover what actually works before everyone is required to do it.

The third cost is the one this essay has been circling. When implementation stops being the constraint, the constraint moves to decisions — and to the review and approval machinery wrapped around them. Amazon’s frontier teams, by Liguori’s account, now spend more time deciding than coding, and a two-month approval cycle that was rounding error against a twelve-month build becomes the long pole against a two-month one.[13] Uber arrived at the same place from a different direction.[2] Two organizations, different tools, different stacks, no shared incentive — and the same new bottleneck. That is about as close to corroboration as this field currently gets.

7. What the SDLC becomes

So what, concretely, is the SDLC in the AI era?

It is a loop, not a line — six stages bound by committed artifacts, where an accepted intent.md fires the design pass, an approved spec fires planning, a merged PR fires the pipeline, and a breached control band in production writes the next intent.[1]

It is a system in which governance is executed, not convened — policy applied as skills while code is written, enforced as hooks while agents act, and evidenced as an artifact chain that doubles as the audit trail.[1][2]

It is a system in which human attention is deliberately concentrated at the gates: on intent and risk in review, on interfaces and module boundaries in design, and above all on the question Uber ended with — should we build this at all.[2]

And it is a system in which the oldest knowledge in the field has the highest leverage. Brooks on conceptual integrity, the Pragmatic Programmers on entropy and feedback, Evans on ubiquitous language, Ousterhout on deep modules, Beck on daily design investment — these were written for humans coordinating with humans. They turn out to be, almost verbatim, the operating manual for humans coordinating with agents.[5]

The SDLC was never really about code. It was about aligning intent, managing complexity and keeping change safe. Code was simply the slowest part, so the process accreted around it. Now that the slow part is fast, the process is being rebuilt around what was always its true center of gravity: judgment. The organizations that understand this — that treat AI as an amplifier and invest in what it amplifies — will define the next decade of software. The rest will discover that entropy, too, has been automated.

References

  1. Anthropic. The AI-Native SDLC Playbook. Claude Blog. claude.com/blog/the-ai-native-sdlc-playbook
  2. Udai & Adam (Uber). Journey Towards a Managed Software Factory — conference talk. youtu.be/17-YSUHo6Lk
  3. Becker, J. et al. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR, July 2025. arxiv.org/abs/2507.09089
  4. DORA (Google Cloud). 2025 State of AI-assisted Software Development. dora.dev/dora-report-2025
  5. Software Fundamentals Matter Now More Than Ever — conference talk (“Claude Code for real engineers”; skills including “grill me,” ubiquitous language, deep modules). youtu.be/v4F1gFy-hqg
  6. Karpathy, A. Post on X coining “vibe coding,” February 2, 2025. x.com/karpathy/status/1886192184808149383
  7. The New Stack. Vibe coding is passé. Karpathy has a new name for the future of software (“agentic engineering”), February 2026. thenewstack.io/vibe-coding-is-passe
  8. Hunt, A. & Thomas, D. The Pragmatic Programmer (software entropy; “outrunning your headlights”). Addison-Wesley, 1999.
  9. Brooks, F. The Design of Design. Addison-Wesley, 2010.
  10. Evans, E. Domain-Driven Design (ubiquitous language). Addison-Wesley, 2003.
  11. Ousterhout, J. A Philosophy of Software Design (complexity; deep vs. shallow modules). Yaknyam Press, 2018.
  12. METR. We are Changing our Developer Productivity Experiment Design, February 2026. metr.org/blog/2026-02-24-uplift-update
  13. Liguori, C. (AWS). From AI-Assisted to AI-Native: Building a Frontier Development Team — AI Engineer talk. youtu.be/pqlWNihgdjI
  14. Sivasubramanian, S. How frontier teams are reinventing AI-native development. AWS Machine Learning Blog, June 2026. aws.amazon.com/blogs/machine-learning/how-frontier-teams-are-reinventing-ai-native-development