# The AI-native SDLC: when typing code stops being the bottleneck By Muthukrishnan (Muthu) Bommiah · AI-native SDLC · Jul 28, 2026 > AI has made writing code cheap. Verification, trusted context and human judgment are now the scarce resources, and teams that redesign their lifecycle around them will pull away from teams that only add assistants. **We have commoditized typing code, and that is the least interesting thing about the AI-native software lifecycle.** A few years ago enterprises were debating whether a model could write a working function. Now coding agents, background repair bots and AI help in every phase of delivery are routine on strong teams. The question has moved from whether AI can produce code to whether the organization can absorb it safely. My view, after watching this play out in large regulated enterprises, is that the winners will not be the teams with the best assistant. They will be the teams that rebuilt the lifecycle around the new scarcities: verification, trusted context and human judgment. Six shifts separate those teams from the ones bolting AI onto the old process. ## The evidence is more awkward than the demos Start with what the data says, because it is not the story vendors tell. [DORA's 2024 research](https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report) found that a 25% increase in AI adoption was associated with better documentation, code quality and review speed, but also with an estimated 1.5% drop in delivery throughput and a 7.2% drop in delivery stability. Individual output went up. The system did not keep pace. A year later, [the 2025 DORA report](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report) found 90% of respondents using AI at work and, this time, a positive link to throughput. Stability was still the casualty. DORA's framing is the one I quote most often to executives: AI does not fix a team, it amplifies what is already there. Then there is perception. In [METR's randomized study](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) of 16 experienced open-source developers working on 246 real issues, the developers took 19% longer when AI was allowed, yet afterwards still believed it had sped them up by 20%. METR has since marked those results as dated and published newer data, so I do not treat the number as permanent. The lesson I take is about measurement: if experienced engineers cannot feel the difference, self-reported productivity is not evidence. *Figure: Flow from spec or intent to a coding agent, then a highlighted verification harness of tests, policy checks and security scans, then human review and production. Failures loop back to the coding agent to fix and retry. In an AI-native lifecycle the bottleneck moves from writing code to verifying it. The harness decides what reaches a human, and what reaches production.* ## Spend the saved time on better problems When syntax speed stops being the constraint, the bottleneck becomes creative problem solving: framing the right problem, choosing between designs, deciding what not to build. The best teams I have seen reinvest the time AI saves into better solutions. Weaker ones simply produce more code, which means more to review, more to secure and more to run. A simple test works here. Ask each team where its saved hours went. If the answer is "more tickets closed", you have bought volume. If the answer is "we prototyped three approaches before committing" or "we finally paid down that brittle integration", you have bought quality. There is a failure mode hiding in that test. When generation is cheap, teams stop throwing work away. A prototype that took a week used to die quietly if it was wrong; one that took an afternoon gets polished and shipped because it already exists. I now ask teams to treat agent output as disposable by default, and to judge a spike by whether the design deserves to survive. ## A lifecycle that remembers Static knowledge management is giving way to a lifecycle that learns. Every fixed bug, review comment and agreed pattern should update the context the next agent works from, so the organization gets smarter with every commit instead of repeating the same mistakes at machine speed. The trap is assuming more context is better. [Anthropic's engineers describe context](https://anthropic.com/engineering/effective-context-engineering-for-ai-agents) as a finite attention budget and argue for the smallest possible set of high-signal tokens. That matches what I see in practice. An agent fed a thousand stale wiki pages does worse than one fed twenty current, owned ones. Compounded learning needs pruning and ownership as much as capture. Context has a half-life, and someone has to be accountable for it. ## Architecture that agents can execute Stale diagrams on a wiki are finished as a control. Architecture defined as code, machine-readable, version-controlled and testable, can be checked by an agent before a human ever opens the pull request. I built a small public [Architecture-as-Code prototype](https://aac.muthub.org) to test this idea, and the most useful thing it showed me was that a decision only becomes enforceable once it carries its rationale with it. The *what* of implementation finally links to the *why* of business intent. This is also how the inner and outer loops start to merge. When an agent can pull production signals, architecture rules and past incident lessons into the editor, defects get caught while the developer is still in context. We stop shifting left in stages and start collapsing feedback from days to minutes. ## Verification becomes the senior job As the cost of generating code approaches zero, verification becomes the most expensive resource in the lifecycle. Senior engineers move from builder to auditor: confirming that the flood of agent-written changes matches business intent, security standards and the architecture the firm actually approved. Here is where I disagree with a common assumption. Many leaders plan AI capacity by counting generation: seats, tokens, agents. The binding constraint is review capacity, and it does not scale with licenses. If agents triple the number of pull requests and your review practice stays the same, you have not tripled throughput. You have built a queue, or worse, a rubber stamp. Plan verification the way you plan production capacity, with automated tests, policy checks and evidence capture first, and human judgment reserved for the decisions that need it. The decision rule I use for how closely a human must look comes down to two questions: how far can this change reach, and how quickly can we undo it? A test fixture or an internal report query is narrow and reversible, so automated checks and a light human pass are enough. A change to an entitlement rule, a payment path or a shared library is wide and hard to unwind, so it gets a named senior reviewer no matter who or what wrote it. Notice that the author does not appear in that rule. Treating agent code as uniquely suspect wastes review time on trivial changes. Treating it like a trusted colleague's work lets wide changes through on reputation that the agent never earned. Rubber-stamping deserves its own warning. When one reviewer approves forty agent pull requests in an afternoon, the approval record looks perfect and means very little. I would rather see fewer approvals with comments that show real reasoning. Sample a handful each month and ask the reviewer to walk a peer through one of them. You find out quickly whether your maker/checker control still works. > Code fast, verify hard, and keep the humans in the loop. ## Measure flow and trust, not output Velocity metrics are table stakes but incomplete. DORA's four keys remain essential for stability, and I would watch change failure rate more closely than ever, since that is where AI risk shows up first. Developer experience measures such as SPACE and simple satisfaction scores matter more, not less, because automated output can hide a team that is worn out from reviewing machine work. I would add two measures most dashboards lack: how long it takes to verify a change, and how often accepted AI changes are reworked within a month. Both tell you whether the speed is real or borrowed. ## The foundation is trusted knowledge The quality of an AI-native lifecycle will not be decided by how well an agent writes code. It will be decided by the chain around the code: intent, requirements, design, plan, code, tests, approvals and production learnings, versioned and traceable so people and agents work from the same context. DORA's 2025 AI capabilities model points the same way, naming healthy data ecosystems, AI-accessible internal data and strong version control among the practices that magnify AI's benefit. **What to do Monday** - Ask each delivery lead to state, in one sentence, where their team's AI-saved hours went last quarter, then compare the answers side by side. - Add time-to-verify and 30-day rework rate for accepted AI changes to your engineering dashboard, next to change failure rate. - Sample ten recently approved agent pull requests and have each reviewer explain the change to a peer. - Pick the most used context source your agents read and assign it a named **owner** and a review date. That raises the harder question. When the knowledge guiding an agent is outdated, conflicting or unowned, AI helps us make the wrong decision faster. Enterprise scale needs current engineering knowledge with clear owners, policies agents can read and apply, guardrails that cannot be bypassed, evidence captured at each important step, and people accountable for judgment and risk. That is a platform investment, not a tooling purchase. If you audited the context your agents used last week, how much of it would have a named owner? **Bottom line:** Code fast, verify hard, and keep the humans in the loop. The real investment is trusted knowledge and controls that live inside the engineering flow, not an approval step bolted on at the end. *Adapted from my LinkedIn writing on the AI-native SDLC, 2026.* --- Muthukrishnan (Muthu) Bommiah · https://muthub.org · Views are my own and do not represent my employer.