The Practitioner Reality

Executive Summary

Almost every developer now works with AI, and almost every organization paying for it is finding that faster typing did not become faster delivery. Adoption is effectively universal; the 2026 Stack Overflow survey puts it at 84 percent. Yet the year's largest engineering-telemetry study found individual throughput rising while organizational delivery stayed flat and defects climbed. That gap is not a tooling problem. It is a coordination, review, and accountability problem the tools created and cannot solve.

The constraint on enterprise delivery has moved. It used to be how fast people could write correct code; it is now whether an organization can review, reconcile, and stand behind code that arrives faster than anyone can check it. Speed at the keyboard was the old bottleneck. Trust at the system boundary is the new one.

The stakes are real money and real risk. Gartner expects more than 40 percent of agentic AI projects to be cancelled by the end of 2027, and the teams that stall are rarely the ones whose AI wrote too little code; they are the ones that never built the discipline to govern what it wrote. This is the “I recognize this” paper: what building with agents actually feels like, backed by the best evidence available, with the weak evidence labeled as weak.

01The Experience Nobody Put in the Demo

This series traces back to what our own teams observed, not to a whiteboard.

Over the last twelve months, Technossus teams built with LLMs across a range of frameworks and working styles: vibe coding, spec-driven development, and several agent orchestration patterns in between. The work spanned different domains and different scales, and the same challenges surfaced in all of it. Working software arrived faster than expected, and that part of the hype is true.

Here is the part that was not in anyone's demo. Managing the AI's context consumed more time than any other single activity. By the end, four separate sessions were running: one had become the architecture authority, one the domain expert, and each feature had its own session and context window, with the developer as the glue between them, hand-copying markdown files and prompts so the architecture session's decisions actually reached the feature sessions. Sessions got heavy in under an hour and forced a restart: new session, re-upload the files, write a handoff summary, hope nothing critical dropped. Some context files grew past 1,500 lines. What was happening, unnamed at the time, was governance by hand: deciding which agent knew what, which agent was allowed to decide what, and when something had to escalate to a human.

For one person on one small project, it worked. The question that started this series is what happens next: two developers on the same codebase, a twelve-month enterprise build, or a system carrying ten years of embedded decisions. The manual model breaks the instant a second person, codebase, or set of constraints enters the picture.

Seven failure modes anyone who has built with agents will recognize

Context burnout. The session degrades as its window fills. Early answers are sharp; later ones drift, forget constraints, or contradict decisions made an hour earlier. A fresh session recovers quality but charges a reconstruction tax to get back up to speed.

Session fragmentation. Real work spans more context than one session holds, so it splinters across several, and no single session holds the whole truth. Keeping them consistent becomes a manual job that scales with the square of how many are running.

Prompt inconsistency. The same request phrased two ways produces two different architectures. Output quality tracks prompt craft as much as problem difficulty, so the system's behavior depends on who is driving and how they worded it that day.

The review bottleneck. Generation is nearly free; understanding is not. Verifying a thousand lines someone else wrote is harder than writing a hundred by hand. Review time, not coding time, becomes what the whole team waits on.

Architectural drift. Each agent makes locally reasonable choices — a data structure here, a dependency there, a pattern somewhere else — and no one watches whether those choices stay globally coherent. The system loses its shape invisibly, until integration surfaces the damage.

The instruction that isn't a guarantee. Telling an agent to never touch the auth module, or to always validate an input, feels like setting a rule. It is closer to a request. The model usually complies and sometimes does not, and nothing in the tooling stops it from crossing a line it was told to respect. Teams meet this the first time an agent edits a file it was instructed to leave alone: the boundary was advisory all along. The gap between an instruction and a guarantee is invisible in a demo and expensive in production, and later papers return to it as the difference between governance that prevents and governance that merely asks.

The “works for me” scaling problem. Everything an individual produces passes its own tests in isolation. The contradictions appear only when the pieces meet: modules that each work alone and fail together.

None of these are exotic. They are the ordinary texture of agentic development, and the rest of this paper is what the published evidence says about them.

02Speed Is Not Delivery

The perception gap (Tier 1). In a mid-2025 randomized controlled trial, METR had 16 experienced open-source developers work 246 tasks on mature repositories they knew well, with and without AI. They predicted AI would make them about 24 percent faster and believed afterward they had been roughly 20 percent faster. They were actually about 19 percent slower. The direction of their own perception was wrong.

That number was cited everywhere, including in this series' earlier draft, so its standing deserves precision. METR revisited it in February 2026 and is redesigning the experiment, partly because it can no longer recruit experienced developers willing to work without AI at all, and partly because a late-2025 re-run shrank the slowdown to something statistically indistinguishable from zero. METR now says the original figure very likely understates how much AI helps today. Cite the 19 percent for what it is, a point-in-time finding about experts on codebases they already understood, not a standing fact about AI and productivity. The durable lesson is not the slowdown but the perception gap: developers systematically believe AI helped more than it did, exactly the wrong instinct to build a delivery estimate on.

The counterweight (Tier 1). Pointing only at METR would be dishonest, because the strongest measured evidence points the other way. A pre-registered randomized trial by Demirer and colleagues, spanning roughly 4,867 developers across Microsoft, Accenture, and an anonymized Fortune 100 firm, found GitHub Copilot raised weekly completed pull requests by about 26 percent, with the largest gains among junior and shorter-tenure engineers and no measured drop in quality. Both studies are real and do not contradict each other. METR measured experts on mature code they knew cold, where AI mostly adds review overhead; Demirer measured typical enterprise developers on their own codebases, where autocomplete removes real friction. The truth is contextual, and “it depends on the work” is not a dodge. It is the finding.

The organizational paradox (Tier 2). Now the number that matters most for anyone funding this. Faros AI's 2026 report, The Acceleration Whiplash, analyzed causal telemetry from about 22,000 developers across more than 4,000 teams over two years. AI is now the primary author on most teams, and acceptance rates roughly tripled. Task throughput rose about 34 percent and epics delivered per developer about 66 percent. Underneath that acceleration, the defect rate rose from about 9 percent in the 2025 data to about 54 percent in 2026, the ratio of production incidents to pull requests rose about 243 percent, code churn under high adoption rose several-fold, and median code-review time rose roughly fourfold while the share of pull requests merged with no review at all rose about 31 percent.

The acceleration and the instability are the same event seen from two ends — and the organization absorbs both.

This reconciles the whole picture. Individuals genuinely get faster; Demirer measured it, Anthropic's engineers report it, the restaurant-app experiment showed it in three weeks. But the faster each individual goes, the more unreviewed, unreconciled, faster-changing code the organization must metabolize, and that metabolic work — review and integration and incident response and rework — is where the individual gains quietly go to die. More output, no better delivery: the spine of this paper.

03The Review Bottleneck and the Quality It Hides

The review bottleneck is not a feeling. It is measured, surveyed, and named, and 2026 was the year the industry stopped pretending otherwise.

Developers do not trust the code, and they are right not to. Sonar's 2026 survey found 96 percent do not fully trust the functional accuracy of AI-generated code. The 2026 Stack Overflow survey, with tens of thousands of respondents, found that against 84 percent adoption only about 3 percent “highly trust” AI output while roughly 46 percent actively distrust it, two-thirds name “almost right, but not quite” as their leading frustration, and nearly half say debugging AI code takes longer than writing it themselves. The “almost right” failure mode is the expensive one: obviously wrong code gets thrown away, while plausibly wrong code gets reviewed, merged, and found in production.

The maintainability signal is worse, because it compounds. GitClear's 2026 analysis of hundreds of millions of code changes found copy-pasted and duplicated blocks at record highs, duplication up roughly 80 percent against a 2023 baseline, while refactoring — the work that keeps a codebase habitable — fell sharply. AI is very good at adding code and, left ungoverned, disinclined to consolidate it. For a system meant to run five or ten years, that is not a style complaint. It is a future maintenance bill run up silently today, on a codebase with no human thought process to reverse-engineer when someone finally has to understand it.

Google's DORA program framed the mechanism honestly in its 2026 work: AI does not automatically improve delivery performance. It is a multiplier that rewards teams with strong review, testing, and architectural discipline and punishes teams without it, and adopting it typically means riding a J-curve — an initial dip as verification overhead lands before the gains show up, if they show up. The tool is neutral. The governance around it decides whether an organization reaches the far side of the curve.

04How the Work Itself Changes Shape

When generation stops being the bottleneck, effort does not vanish. It moves.

Anthropic's own engineering study — 132 engineers, 53 interviews, and around 200,000 Claude Code transcripts, a Tier 3 self-report rather than external measurement — captured the shift cleanly. Engineers reported using Claude for roughly 59 percent of daily work, up from about 28 percent a year earlier, with self-reported productivity gains near 50 percent. But more than half could fully delegate only 0 to 20 percent of their actual tasks. Human turns per session fell about a third while AI tool calls more than doubled. The work moved from writing toward directing, evaluating, and correcting. Less typing, more judgment. The effort did not leave; it changed form.

That carries a staffing consequence many organizations still resist. Multiple 2026 analyses (Tier 3/4, an emerging pattern rather than a validated one) describe the same inversion of the traditional team pyramid: fewer hands overall, weighted toward senior architects who design and review, away from large benches of juniors whose main historical job, producing volume, is exactly what the tools now do. This deserves caution, because the data is soft and the second-order effect is troubling. If juniors were how the industry grew seniors, a model that stops hiring juniors is quietly eating its own future supply of the people it most depends on. No one has a good answer to that yet.

05Where the Enormous Numbers Actually Come From

The claims are familiar: 3 to 5 times faster, 100 times on a task, ten times the speed at half the cost. Some are real. Almost all describe work that is nothing like a greenfield enterprise build, and the extrapolation is where leaders get hurt.

Consider the three most-cited compression cases. Amazon used its own tooling to migrate tens of thousands of Java applications to Java 17, dropping the average per-application upgrade from about 50 developer-days to a few hours (Tier 3). Fujitsu used agents to automate regulatory modifications on existing medical and government software and reported a single change request done in four hours against a vendor-estimated three person-months — its “100x,” which Fujitsu attaches to one narrow task rather than a project (Tier 3). And the closest thing to a greenfield signal, McKinsey's April 2026 account of a global bank standing up an “agent factory” of nearly a hundred concurrent agent instances to build a cross-border payments system with a handful of human reviewers, reported roughly 10 times the speed at half the cost — with no lines of code, no baseline, no methodology appendix, and no independent verification (Tier 3, and thin even at that tier).

Every well-documented case shares one feature: the AI worked against known constraints. An existing codebase to read, an existing architecture to obey, a fully specified target such as Java 17 compatibility or a defined regulatory change. That is pattern-based transformation, precisely where AI delivers maximum compression.

Greenfield work is the opposite. There is no codebase to analyze because it is being created; architecture is being formed, not followed; domain models are being designed, not inherited; requirements are being discovered, not applied. Those are the activities that demand human judgment, and the ones AI compresses least. Taking Amazon's migration ratio or Fujitsu's single-task 100x and applying it to a new enterprise build is a category error, and the specific category error that turns into a cancelled project eighteen months later.

06What Nobody Has Measured Yet

It is more honest to name what is missing than to paper over it. As of this writing, there is no high-quality, project-level evidence for what enterprise leaders most want a number on: how long a greenfield enterprise system built by governed agents actually takes, end to end, and what it truly costs. The McKinsey bank is a signal, not a benchmark. There is no clean public comparison of greenfield versus brownfield outcomes under any methodology, no validated cost model combining inference, governance overhead, and human orchestration, and no causal evidence that any specific governance architecture produces measurably better delivery than doing it loosely. The frameworks on offer, including the one this series builds toward, are principled and awaiting real empirical stress-testing. Much of what follows in later papers is careful inference, and where it is inference, the papers say so.

07Naming the Shift: The Governed Agentic SDLC

There is a deeper reason the review bottleneck bites. The traditional software lifecycle paces its controls to human authorship: review boards, change-advisory meetings, sign-off documents, quarterly audits, all built on the assumption that the volume of change is small enough for ceremony to inspect. Agentic volume breaks that assumption. When an agent produces in an afternoon what a team used to produce in a sprint, the old ceremony has two failure modes and no third. It either slows the agents to the speed of its meetings and becomes the bottleneck, or it waves the work through and supplies the governance on paper and becomes theater. Neither is governance. The way out is not more ceremony, or less of it, but a different lifecycle — one where control runs at the speed of the work rather than alongside it.

That lifecycle needs a name, and here the industry has a problem: there is no settled one. Vendors and analysts circle it with different labels — AWS ships an “AI-Driven Development Lifecycle,” Forrester writes about “agentic software development,” and a scatter of firms use “ADLC” to mean at least six incompatible things, some actually about operating AI products in production rather than transforming how software gets built. When a concept has six definitions, teams talk past each other and buy the wrong thing.

The older model assumed humans do the work with tools assisting; the Governed Agentic SDLC inverts that assumption, so agents do the work and humans govern it. The middle word, agentic, names who is now doing the building. The first word, governed, names what this series argues cannot be skipped. On scope: this concerns transforming how any kind of software gets built. It is not the separate discipline of building and monitoring AI products — a different lifecycle with different concerns, and conflating the two is one of the more common and expensive confusions in the market right now.

Everything in Paper 1 is the “before.” The practitioner pain, the flat delivery, the review bottleneck, the quality debt: that is what an ungoverned agentic SDLC produces. The rest of the series is the “governed” half — how to decide how much control a project needs, what that control costs, who is accountable when it fails, and what an architecture that enforces it actually looks like.

Questions Worth Sitting With

References

Connecting to the Series

This paper described what building with agents actually feels like and what the evidence shows. The next three papers turn that reality into decisions.

Technossus has developed a governance framework, the Agent OS, that implements the concepts this series describes. Papers 1 through 3 are written to stand on their own regardless of whether an organization ever adopts it.