AI made individual coding much faster, but the gains at the level of the whole organization have been modest, because the work around the code (deciding what to build, reviewing it, coordinating people) didn't speed up, and often got more crowded. Cheap code doesn't make a company fast; it moves the constraint to that surrounding work. Running an AI-driven team well comes down to two decisions that move independently:
- How much of code review and release gating to automate, from a human signing off on every change to no human in the merge path. Let blast radius decide: the more a bad merge costs, the more you keep a human in the loop. This is the higher-stakes dial, so move it slowly.
- How to compose the team, from traditional specialists to a few senior generalists. This one is shifting more slowly, and most teams are still close to their current structure, so you can leave it largely alone and still get most of the value from the first decision.
Whatever you choose, the same things decide whether it pays off: give agents a shared context layer to work from (AI multiplies your existing practices, the good and the bad), plan for the coordination overhead and for pushback from some of your strongest engineers, and watch the predictable traps, spiky token bills, "it runs" mistaken for "it's ready," and cutting juniors and managers you'll want back.
If you run a software company, you've probably heard two versions of the same story.
In one, a solo founder builds a complete product in a few weekends, including auth, billing, the works, for the price of some API tokens.
In the other, a forty-person engineering team adopts the same tools, everyone's individually faster, and the company ships at roughly the same pace it did last year.
Both are true, and the gap between them is the whole point, because it tells you that adopting the tools is not the hard part.
Individual coding got faster. Turning that into faster delivery is a separate problem, and the two most substantial datasets published this year disagree about the size of the gain while agreeing about where it goes. DX tracked more than 400 organizations over the 16 months ending February 2026 and put the median gain in pull-request throughput at about 8% (published April 2026). Faros read two years of telemetry from 22,000 developers and found gains many times that: epics completed per developer up 66% (analysis as of March 2026). Most of that gap is method rather than a disagreement about reality. Faros contrasts each team's lowest-AI-adoption quarters against its highest, which selects the extremes and widens the contrast by construction; DX measures a fixed calendar window at the organization level. Neither is a causal estimate, and both say so. Both vendors also sell into this problem, which is worth keeping in mind in each direction.
What they agree on is more useful than what they don't. DX's read is that the time saved writing code gets consumed by increased review, validation, and remediation of what the AI produced. Faros measured that from the other side: as adoption rose, median time in pull-request review climbed 441%, nearly a third more pull requests merged with no review at all, and the rate of production incidents per pull request more than tripled. DX's July 2026 readout across 500+ organizations found the same pattern deepening: per-engineer throughput on its size-weighted measure kept climbing, up 37% over the year, though partly because pull requests nearly doubled in size, while its developer-experience index slipped from 67 to 65, review turnaround worsened, and the gains were "not yet translating into faster felt delivery" (DX Q2 report, July 2026). Faros's summary of its own data is the cleanest statement of the problem I've found: AI flooded a system built for human-paced development with more output than it was ever designed to absorb.
Here's why, in plain terms. Writing code was never most of the job. The rest is deciding what to build, reviewing what got built, coordinating across people, and integrating it all. AI sped up the coding. It did not speed up the deciding, reviewing, and coordinating, and in a lot of teams it made those slower by flooding them with more code to handle. Speed up one slice of the work dramatically, change nothing else, and single-digit gains for the whole organization are roughly what the arithmetic predicts.
The more people and handoffs sit between an idea and production, the more of the speedup you give back. A solo founder has no handoffs. She is author, reviewer, and decision-maker in one head, so she keeps almost all of the gain. A forty-person team gives it back at every step. As Laura Tacho, CTO of the developer-experience firm DX, put it in June 2026, the companies that pull ahead stop treating AI as a boost for individuals and start applying it to the system, redesigning the flow so there are fewer handoffs. Ryan Eade framed the same shift in April 2026: the first wave of AI was personal, but agents now operate inside the team, and the real question becomes whether the humans around that work can still see it, understand it, and coordinate around it.
So the real question isn't whether to adopt AI, but how to rebuild the team and its process around it. And that comes down to two decisions.
Decision one: how much of review and release gating do you automate?
This is the higher-stakes dial, because review is where the speedup goes to die. As Shannon Ryan of Veritas Automata put it in July 2026, the decision of where humans stay in the loop is the most important design decision your team will make this year. It runs from humans doing all the reviewing themselves to no human in the loop at all.
- Human-only review. People read and approve every change, backed by deterministic checks like tests and linters, but with no AI in the review itself. A lot of teams are still here, and it's the one spot you shouldn't stay: a first-pass AI reviewer is nearly free and better than nothing.
- AI-assisted, human-gated. AI does the first-pass review and catches the routine bulk, but a human still looks at what's left and approves every change before it ships. This is where Anthropic sits, and it's instructive because they're as deep into AI as anyone. Every pull request is auto-reviewed by Claude first, catching around 80% of bugs, alongside deterministic linters and parallel review agents. Yet a human still approves every change before production (Boris Cherny, Pragmatic Engineer podcast, early 2026). Not because the AI can't review it, but because their customers are enterprises and a bad merge is expensive. Cloudflare runs a comparable setup at scale, with humans still in the loop: an internal AI reviewer that handled more than 131,000 reviews in a single month (April 2026), and it's equally clear that this is "not a replacement for human code review, at least not yet with today's models." The review work is heavily automated; the human gate is the part they keep.
- Supervised-agentic. The AI reviews and approves routine changes with no human involved. People only step in on the changes categorized as risky or where AI is uncertain. PostHog's "StampHog" agent auto-approves low-risk pull requests outright, using deterministic checks (no conflicts, under 500 lines, blast-radius deny lists) and approving only when everything is clearly safe, so anything uncertain goes to a human. It ends up giving the final stamp on roughly one in three PRs, leaving people to spend their review time on the other two-thirds (PostHog, July 2026).
- Fully automated. No human in the merge path at all; tests and evals are the gate. StrongDM runs what it calls a software factory where, by its own rules, humans neither write nor review the code, leaning entirely on heavy automated testing (reported by Simon Willison, February 2026). This end stays rare in practice: across Faros's telemetry, fewer than 1% of pull requests are opened by an agent rather than a person (Faros, March 2026).
The clean line between the two middle positions is simple: does a human sign off on every change, or only on the exceptions? And what decides where you belong is blast radius. StrongDM can drop human review because it built an elaborate automated safety net and accepts probabilistic correctness. Anthropic keeps its gate because one bad merge is an enterprise liability. Same tools, opposite choices, because the cost of a mistake is different.
That line is cleaner on paper than in practice, though, and it's worth knowing how it blurs. Gergely Orosz reports hearing (July 2026) that when an AI reviewer comes back with nothing substantive, developers often just approve the change, and that the engineers who do still review carefully feel buried under the volume of AI-generated pull requests. He's explicit that this is anecdotal, but the mechanism is easy to believe, and Linus Torvalds named half of it in the same issue while arguing against banning AI-generated contributions to the Linux kernel: his own annoyance with the models was how "eager to please" they are, when what he wanted was "a more critical review of the code." A reviewer that seldom objects doesn't give a human much reason to look twice. Torvalds also cut the other way, which is worth holding onto before anyone idealizes the status quo: "AI reports are not always great, but neither are human reviews." The practical point is that a team can drift from human-gated to effectively automated without anyone deciding to. Where the dial actually sits may not be where your policy says it does, so if you're counting on the human gate, go find out whether it's real.
And wherever you land, review capacity is the constraint to manage, because it doesn't scale the way generation does. When agents produce three times the code, human review can't keep pace, and it's not a staffing problem. As Bryan Finster argued in March 2026, you can't hire your way out of a sampling-rate problem: a reviewer's ability to catch defects falls off sharply past a few hundred lines, and AI routinely produces changes well beyond it. So the teams handling this well automate everything a machine can check (linting, type checks, tests, security scans, a first-pass AI reviewer), reserve human review for what machines can't judge (architectural intent, cross-system effects, compliance), keep changes small, and build review capacity before scaling up generation, not after (Collin Wilkins, March 2026).
Decision two: how do you compose the team?
The second dial is who does the work, and it's independent of the first. This one shifts more slowly and is harder to see, but two kinds of data show it changing. The first is hiring. Over the past year, job postings for AI-engineering roles rose about 60% at top companies while general software-engineering postings grew 7%, and the frontend-only specialist is fading as full-stack becomes the default, a shift Gergely Orosz ties directly to AI: there's little reason a capable frontend engineer can't now work across the stack (Pragmatic Engineer, June 2026). Companies are hiring for broader engineers. The second is how existing teams organize. The formal org chart is mostly intact, engineering leaders at Microsoft and Atlassian both said in a mid-2026 panel that they hadn't restructured or redrawn any boxes, but the same leaders described smaller squads on new projects, shorter planning horizons, and non-engineers like designers starting to open their own pull requests (DX, May 2026). So read the positions below as the range of shapes on offer, with most teams still near the left end, not as a spectrum your peers have already spread across.
- Traditional specialists. Separate people for product, analysis, architecture, development, and QA, the org chart most companies already have. AI makes each specialist faster inside their lane.
- Blended roles. Fewer, broader roles. Rather than narrow specialists, engineers span more of the cycle, picking up more of the deciding, specifying, and reviewing that used to be split across separate people. In this shape, the extra review load AI creates rides on ordinary peer review, one engineer builds and another checks, rather than a dedicated review function.
- Product-minded senior generalists. A few people who each spec, orchestrate agents, and review, hiring for judgment and taste over headcount. This is the least-populated end of the dial, and the clearest examples are individuals and very small teams rather than restructured departments. At the far edge, a solo founder shipped a complete 38,000-line SaaS in about 55 days (February 2026), though that's the absence of a team more than a way of running one. Closer to a repeatable model, Ryan Eade describes (April 2026) working "above the code," writing strategy and detailed specs while agents build and other agents review against the spec. As he puts it, the spec is the system, and the code is just what comes out the other end.
Two things matter here that are easy to miss. First, specifying well is its own skill, and it becomes the scarce one. Deciding what to build and writing a spec precise enough for agents to execute is not a lighter version of coding; it's a different muscle. Get it wrong and the automation from the first dial just idles; as Magnus Hedemark put it in July 2026, a factory that can build anything but can only be fed by humans writing specs by hand runs at 20 percent utilization. That shift is already visible. At one mid-sized company, engineering kept getting held up waiting on product and design to decide what to build, so the team put its most senior engineers on that upstream work themselves: "We now have Staff+ engineers writing Product PRDs so we can move faster," the manager reported (Pragmatic Engineer, April 2026). This is where product management enters, and the hiring data bends the same way: there are about 15% more engineers per product manager than in 2020, so engineers are increasingly expected to bring product sense themselves (Pragmatic Engineer, June 2026). How the product-management role itself changes under AI is its own subject and beyond this piece; the point here is that the scarce skill is deciding what to build and specifying it, wherever that work sits. Second, review is demanding work, not a consolation prize. Judging AI-generated changes well takes context across the codebase and its architecture, so review needs people who understand the whole system, not your least-experienced hands. Faros's telemetry puts a name on why: the cost falls on senior engineers. AI-generated code is often superficially convincing, idiomatic and well-named, with its structural failures beneath the surface, so catching them means reading closely and reconstructing the intent behind the change rather than scanning for obvious errors (Faros, March 2026).
One more thing about the people, and it cuts across the whole dial: the engineers who do best here tend to be T-shaped, deep in one area, broad across many. AI is automating the narrow, well-defined execution, the vertical bar of deep expertise, while raising the premium on the horizontal: judgment, synthesis, and knowing what to build. That lines up with David Epstein's argument in Range that breadth is undervalued in complex, changing work (the messy, delayed-feedback domains he calls "wicked," as opposed to stable, clear-feedback ones like chess). Epstein overstates it in places, it's not that generalists always win, but the core holds, and AI sharpens it: when the deep, specialized execution gets cheap, the broad judgment around it is what's left to compete on.
Where teams land, and why the two dials aren't locked together
Here are a few positions worth naming:
| Position | Review automation | Team composition | Fits when |
|---|---|---|---|
| Guarded | AI-assisted, human-gated | Traditional specialists | Regulated, high-stakes, mature product |
| In transition | AI-assisted or supervised | Broader roles, review spread across the team | Mid-sized, review bottleneck biting, want more output without cutting |
| Lean | Supervised or fully automated | Senior generalists | Early-stage, greenfield, speed-first, risk-tolerant |
You could think of these as amplifying, restructuring, and compressing a team. But the important point is that the two dials move independently, and the interesting cases sit off that diagonal. A regulated fintech might automate review heavily while keeping specialists, because compliance needs specialists. A tiny regulated startup might run senior generalists while still human-gating everything, because the blast radius is high even though the team is small. Set each dial for your own situation. Don't assume one answer picks the other for you.
How to choose
For Decision one (automation), the driver is blast radius. Regulated, customer-facing, or safety-critical code keeps humans gating. Low-stakes, internal, or easily-reverted work lets you automate more. Start conservative and automate further only as your test and eval safety net proves it can carry the weight. This is the dial to move slowly.
For Decision two (composition), the drivers are talent and appetite for change. Do you have product-minded senior people who can work upstream? Can the team and the business absorb a change in who does what right now? If not, you can leave composition alone and still get value from the first dial. If yes, you can evolve it deliberately rather than all at once.
One note on measuring all this. Some of it is measurable and some isn't, and you should measure what you can, cost is measurable, and so are some delivery and quality signals like incident rates, escaped bugs, and cycle time on comparable work. Where you can measure, do, and treat it as one input. But don't force a single productivity number onto work that is lumpy and unpredictable, and don't let the metric become the target. The goal is to watch whether spend, quality, and delivered outcomes are moving together, not to win a dashboard.
Making your choice work
Whichever settings you land on, the same handful of things decide whether it pays off.
Build the foundation first
AI won't fix a broken engineering organization; it will speed one up. The teams that get the most out of AI already had automated testing and guardrails, written-down architecture decisions, and a reasonably clean codebase for agents to imitate (Pragmatic Engineer, May 2026). Shannon Ryan of Veritas Automata says it plainly (July 2026): AI doesn't fix broken teams, it amplifies them. Good practices get multiplied. So do the bad ones.
The practical prerequisite is a context layer: a consistent, current place in every repository that tells an agent what the project is, how it's built, what was decided and why, and what the traps are. In practice that's a lean instructions file (CLAUDE.md, AGENTS.md, or the equivalent) that holds your general rules and conventions and links out to your detailed technical docs, the architecture and the decisions behind it, and a running log of gotchas. Keep the instructions file small and let it point to the deeper docs, rather than cramming everything into one place. A CTO who ran four projects this way found the core skill wasn't prompting; it was structuring the knowledge the agents work from (Jayasagar, February 2026). Do it once, in one repo, and you get one power user's private setup. Do it the same way across every repo, and you've turned a personal trick into an organizational capability. That standardization is boring, and it is most of the game.
Manage the coordination cost
The bottleneck that surprises people isn't code; it's keeping humans and agents in sync when work is flying. This is the least-settled part of the whole shift, Eade himself says we don't yet know the right org chart for an AI-native company, so treat the confident recommendations as the two that hold up and the rest as emerging.
The two that hold up: make that context layer the shared source of truth, so the specs and decisions coordinating the work are the same ones the agents read. And reduce handoffs, which is really the second dial again, fewer people and roles between an idea and production means less to coordinate. Then the emerging tooling worth watching: making agent work visible (status trackers that gather updates from pull requests and chat), partitioning parallel work so agents don't collide (Anthropic's engineers split a large migration by file across dozens of agents, June 2026), and automating the coordination toil itself, which is what review-triage tools like StampHog and Uber's internal "Code Inbox" are for.
Roll it out without stalling, and expect resistance
Most AI coding rollouts don't fail because the tools don't work. They fail as change-management. Pilots succeed under ideal conditions, then the broader rollout hits messier work and inconsistent standards and stalls. As Ryan Eade put it in May 2026, most teams aren't scaling a workflow, they're trying to scale a moment.
A few things separate the rollouts that take hold. Spend to learn, then measure, then adjust: a sensible pattern, described by a dev-productivity lead at a mid-sized SaaS company, is to spend freely and experiment at first, measure outcomes and report spend monthly, and adjust when spend climbs but results don't follow (Pragmatic Engineer, April 2026). Reward outcomes, not usage: some companies now put AI usage in performance reviews or set targets like "75% of code written with AI," which just produces more slop, faster. Standardize the toolset and the operating model, or you get what one team lead bluntly called tooling chaos (Pragmatic Engineer, May 2026).
And be ready for the human side, because it's the hardest part. This is a change to how people work, not just what tools they open, and some of your strongest engineers will push back, out of craft, identity, or well-earned skepticism after a decade of overhyped tooling. Their resistance is often signal worth listening to, not just friction. You don't need an elaborate playbook for it. You do need to expect it, and to not mistake it for the rollout failing.
The traps
If you're going to lead your team through this, be the person in the room who names the downsides while everyone else is excited.
The bill is real and it's spiky. Token spend has jumped roughly 10x in six months at many companies (Pragmatic Engineer, April 2026). Uber burned through its entire annual AI budget in about four months (reported May 2026). Simple per-seat caps tend to break within days once people lean in. Budget for actual usage, expect power users to cost multiples of the average, and use model routing; defaulting to cheaper models for simple work cut one company's costs by about 30%.
"It runs" is not "it's ready." There's a honeymoon period. One tech leader shipped an AI-built site that worked fine on the surface but loaded 13MB of data and shipped its test files into production on every visit (Pragmatic Engineer, April 2026). The demo always looks done. Production-readiness is a separate question, and someone has to keep asking it.
Don't cut people you'll miss. Two groups are getting trimmed too fast. Juniors, because seniors now hand routine work to agents instead of to them, which feels efficient until you notice you've stopped growing your next seniors. And middle managers, who matter most precisely when everything is changing quickly. Both cuts are easy to make and hard to reverse.
Don't over-trust automated review on critical paths. AI-generated code with too little human review has already caused serious production incidents at large companies (Pragmatic Engineer, March 2026). The lesson from teams doing this well isn't "remove the human," it's "remove the human only where the blast radius is small."
Where this leaves you
Here's the through-line. Cheap code doesn't make a software company fast. It moves the constraint. The work that's left is the work that was always the hard part: deciding what to build, exercising judgment about whether it's right, and designing systems, of software and of people, that can absorb the new speed without drowning in it.
That's not a downgrade for your best people. It's the part of the job worth having. The companies that win the next few years won't be the ones that generate the most code. They'll be the ones that figured out where humans still add the most value, and pointed them at it.
None of this is settled. The tools shift every few months, and the patterns for running a team around them are still being worked out in real time, including by me. I've written down the best of what I can see right now, and I know it's incomplete. If you're running a team through this, I'd like to hear from you: what's working, where I'm wrong, and what's missing. Please reach out, and I'll keep updating this as the picture gets clearer.