Individual tasks that used to take days now take minutes. Engineers ship pull requests faster than reviewers can read them. When McKinsey surveyed nearly 300 publicly traded companies about how AI is reshaping software development, it found a 15-percentage-point performance gap between the best and worst performers. Top performers reported 16 to 30 percent gains in team productivity, customer experience, and time to market, and 31 to 45 percent gains in software quality^[1]. Most companies land well below that top tier. The difference between faster tasks and better organizational performance comes down to the operating model around the technology.

Recent McKinsey research into AI-driven software organizations identifies a common constraint: most companies have added AI coding tools onto an operating model built twenty years ago for a completely different constraint: human beings who write, review, and test code at human speed^[1][2]. Two-week sprints, eight-to-ten person squads, story points, and long written requirements documents all exist to manage that constraint. AI changes the pace of production and exposes bottlenecks elsewhere in the delivery system.

Why task-level speed does not guarantee system-level output

McKinsey's research is candid about where the gains are actually landing. Top performers are six to seven times more likely than their peers to scale AI use cases across four or more stages of the development lifecycle, including design, coding, testing, deployment, and adoption tracking, rather than limiting themselves to one or two isolated tools^[1]. Nearly two-thirds of top performers combine at least three of five key practices (end-to-end use-case coverage, AI-native roles, intensive upskilling, outcome-based measurement, and aligned incentives); only 10 percent of bottom performers do the same^[1].

The change-management gap shows up starkly in how companies handle incentives. Nearly eight in ten top performers tie generative-AI goals directly to both product manager and developer performance reviews. Among bottom performers, that figure is 10 percent for developers and effectively zero for product managers^[1]. Adoption without accountability rarely turns into impact.

The bottlenecks follow from the operating model. AI agents can now run increasingly complex, multistep workflows, but they still can't infer business intent. They need structured requirements, clear user stories, and unambiguous acceptance criteria, or the work they hand back doesn't match what was actually needed^[2]. And a Carnegie Mellon University study of hundreds of GitHub repositories that adopted the Cursor coding agent found a large but transient boost in development velocity, paired with a substantial and persistent rise in static-analysis warnings and code complexity. That complexity did not fade after the initial adoption period and measurably slowed future velocity^[13]. Faster code generation without a faster review and quality process doesn't remove the bottleneck. It just relocates it.

Agile's ceremonies were built to manage a known, human-paced constraint: people who write and review code at a roughly fixed rate. AI removes that constraint but replaces it with a different one: non-deterministic, probabilistic output that needs a tighter, more continuous feedback loop than a two-week sprint box was ever designed to provide.

Specs, agent factories, and continuous cadence

One of the clearest published examples of the new model comes from McKinsey's account of an "agent factory" built inside a large global systemically important bank. The bank restructured around a two-shift rhythm: humans work the day shift, converting intent into agent-ready specifications, setting architectural boundaries, and reviewing overnight output; a coordinated fleet of AI agents works the night shift, coding, testing, reviewing, and documenting inside a controlled workflow, with an orchestrator agent managing handoffs between them^[2]. The bank adopted a daily sprint cadence in place of the two-week cycle and reported ten times the speed at half the cost^[2].

That agent-factory model isn't unique to one bank. McKinsey reports a separate large financial-services firm used the same approach to build a greenfield payment system and improved productivity 40 to 70 percent, while LATAM Airlines applied a version of it and delivered 50 percent productivity increases with smaller teams^[2]. LATAM credits two foundations for making this possible: a robust engineering platform that gives agents the tools and environments they need, and a product-oriented operating model where cross-functional teams already understood modern software engineering before the AI layer was added^[2]. IBM took a slower, more deliberate route. After an initial rollout of AI tooling saw patchy adoption, the company built a six-month enablement program that assigned a coach to every team for at least two sprints, ran "bring your code in" office hours, and cultivated an internal community of AI-fluent champions. More than 8,000 developers went through the program. McKinsey reports that individual productivity increased during that period^[2].

Inside this new model, the unit of work shifts from the user story toward the executable specification, and planning shifts from quarterly roadmaps toward a continuous cadence. Cursor's own engineering organization, studied directly by McKinsey researchers, shows what this looks like day to day: traditional boundaries between front end, back end, and QA have merged into broader full-stack responsibility, each release has one directly responsible individual, product managers test features themselves, and designers prototype directly in code rather than handing off static mockups^[1]. Within Cursor's ML, infrastructure, and product functions, pods are deliberately kept small and projects often span across teams rather than sitting inside one^[1]. Cursor ships new releases roughly every two to four weeks with a team of around 50 engineers^[3]. McKinsey argues that this cadence would typically require a much larger, layered organization under a conventional Agile structure.

Traditional Agile and AI-native operating models

Published restructuring examples

Anthropic provides one of the clearest public examples. As of May 2026, more than 80 percent of the code merged into Anthropic's own codebase was authored by Claude, up from low single digits before Claude Code's early 2025 preview, and the typical engineer was merging roughly eight times as much code per day in the second quarter of 2026 as in 2024^[4]. Review, not code generation, is now the bottleneck. A small team can produce far more than a similarly sized team could review under the old model.

Coinbase announced in May 2026 that it is moving to "AI-native pods," experimenting with reduced pod sizes including single-person teams that combine engineering, design, and product into one role, flattening its management structure to five layers below the CEO and COO, and eliminating pure management roles in favor of "player-coaches" with large spans of direct reports^[5]. The announcement came alongside a roughly 14 percent workforce reduction^[6], and it's worth flagging that these pod structures are described as experimental intentions rather than something with reported before-and-after performance numbers yet.

Klarna provides an important counterexample. The company's OpenAI-powered support assistant handled 2.3 million conversations in its first month, work Klarna said was equivalent to roughly 700 human agents, and total headcount fell by around 40 percent under a hiring freeze. But by May 2025, CEO Sebastian Siemiatkowski told Bloomberg that Klarna had gone too far: an overemphasis on cost had produced "lower quality" support, and the company began recruiting human agents again in a flexible, remote setup^[7]. Klarna has not abandoned AI. It says the assistant still handles roughly two-thirds of inbound conversations, but the reversal signals that restructuring around AI ahead of proven quality and service outcomes carries real brand risk^[8].

Other companies have stated similar intentions without publishing comparable operating results. Amazon CEO Andy Jassy told employees in June 2025 that generative AI and agents would "reduce our total corporate workforce" over the coming years and urged teams to find ways to "get more done with scrappier teams"^[9]. Shopify CEO Tobi Lütke told staff in April 2025 that "reflexive AI usage is now a baseline expectation" and that teams must demonstrate why they can't get something done with AI before requesting headcount^[10]. The policy coincided with Shopify's employee count falling from about 11,600 in 2022 to roughly 8,100 by the end of 2024 while revenue kept growing^[11]. Duolingo's CEO drew significant backlash for an "AI-first" memo in April 2025 before clarifying that the company was not planning full-time layoffs, only reducing reliance on contractors for AI-suited work^[12].

Roles emerging inside AI-native teams

The role most visibly changing is the software engineer's. McKinsey's research describes engineers shifting toward full-stack fluency, structured communication of specifications, and a deeper understanding of architectural and systems trade-offs. This places more emphasis on systems thinking and precise specification-writing than on raw code production^[1].

Product managers are moving closer to implementation. Rather than writing a requirements document and waiting weeks for a prototype, PMs at AI-native companies increasingly spend more of their time on design, prototyping, quality assurance, and responsible-AI implementation practices instead of pure feature-delivery coordination^[1].

It's worth resisting the temptation to romanticize this as a clean handoff from "writing code" to "managing agents." In practice it means debugging non-deterministic output, writing sharper specifications than most engineers were ever trained to write, and knowing a codebase deeply enough to catch an agent that is confidently wrong. That's a slower, harder transition for most organizations than the label suggests.

Matching the operating model to the work

Not every kind of engineering work should be organized the same way. McKinsey's agent-factory model, with high context, clear specs, and minimal human intervention during execution, fits legacy modernization and well-defined build-outs particularly well, as the bank, the financial-services firm, and LATAM Airlines all demonstrate^[2]. Exploratory, greenfield feature work tends to need more human steering throughout, with agents acting more like co-creators generating variations for rapid feedback rather than an unattended overnight shift.

Underneath either model, platform investment matters more than it used to, not less. Google Cloud's 2025 DORA report, based on nearly 5,000 survey responses, found that AI doesn't fix a struggling team; it amplifies whatever is already there. Strong technical practices and clear internal platforms turn AI into a multiplier; weak ones turn it into a faster way to generate problems^[15]. LATAM's own experience backs this up: the foundation that made its agent-factory experiment work was a robust engineering platform built before the agentic layer was added, not after^[2].

Company size and starting culture matter a great deal too. Lean startups adopt AI-native patterns almost by necessity because small teams already own a full slice of the product, so the transition to smaller pods and spec-driven work is a smaller jump. Large enterprises with years of ticket-tracker-shaped process and clearly separated specialties tend to stall somewhere in the middle of the transition, as IBM's own experience shows: its first rollout attempt, without dedicated coaching, produced patchy adoption that didn't stick until the company invested in a slower, much more hands-on enablement program^[2].

Risks and counterevidence

It would be easy to read all of this as a straightforward "move fast or fall behind" narrative. Independent studies and developer surveys point to material trade-offs that leaders should evaluate before restructuring a team.

Start with code quality. The Carnegie Mellon study of Cursor-adopting repositories found the velocity gains were real but transient, while the increase in code complexity and static-analysis warnings was persistent. The study's own modeling found that rising complexity in one period predicted slower velocity in the next, creating a feedback loop that can quietly erode the very speed advantage teams adopted AI to capture^[13]. A follow-up analysis of the same research found that even after controlling for the simple fact that more code tends to be more complex, Cursor adoption still produced a meaningfully higher baseline complexity. The additional code was also harder to understand^[14].

Developer trust is heading the wrong direction, too. Stack Overflow's 2025 Developer Survey of more than 49,000 developers found that while 84 percent now use or plan to use AI tools, trust in the accuracy of AI output fell to 29 percent, down from 40 percent the year before. This is counterintuitive because trust in most new technology tends to rise with familiarity, not fall^[16]. Two-thirds of developers cited AI output that's "almost right, but not quite" as their top frustration, and nearly half said debugging AI-generated code takes longer than writing it themselves^[16]. DORA's 2025 findings echo this: roughly 30 percent of respondents reported little or no trust in AI-generated code even as adoption climbed to 90 percent^[15].

At the business level, MIT's Project NANDA found that despite an estimated $30–40 billion in enterprise generative AI investment, roughly 95 percent of organizations were seeing no measurable financial return from their AI pilots, with just 5 percent extracting meaningful, sustained value^[17]. And a survey of more than 1,100 senior business leaders by Orgvue found that 39 percent had made employees redundant as a direct result of deploying AI. Of those, 55 percent admitted the redundancy decisions were mistakes^[18]. Klarna's reversal, described above, is the highest-profile example of exactly this pattern playing out in public.

There's also a reasonable case that the "Agile is dead" framing overstates things. A widely shared rebuttal argues that AI isn't killing Agile so much as illuminating constraints that were already sitting in the value stream: if coding gets dramatically faster but overall lead time doesn't improve, the real bottleneck was probably never engineering output in the first place. It was prioritization, dependencies, validation, or decision latency further up the chain^[19]. Shrinking a team's headcount doesn't shrink the work that still needs covering; it just rebundles who covers it, and rebundling badly can create new single points of failure.

A practical sequence for engineering leaders

The evidence supports deliberate change. The productivity gap McKinsey documented is real, but the operating model should change before headcount policy does.

Measure before you restructure. Instrument cycle time, code quality, mean time to resolve priority bugs, and developer sentiment before touching team shape, not just AI tool adoption rates. If adoption is climbing but end-to-end lead time is flat, the constraint is probably upstream of engineering, and no amount of pod restructuring will fix it.

Fix specs and review capacity before you shrink teams. The first bottlenecks to solve are unclear acceptance criteria and manual review that cannot keep pace. A smaller team layered on top of the same unclear specs and slow review process just moves the traffic jam.

Pilot on a bounded workflow before rolling out org-wide. Pick one well-scoped workflow, run a small cross-functional pod against it, and hold that pod to the same quality bar as before. Reorganizing squads by work type, such as one for well-defined bug fixes and one for exploratory greenfield work, is a lower-risk first step than a company-wide reorganization.

Invest disproportionately in hands-on enablement. IBM's own experience is a useful proof point: its first AI rollout stalled with patchy adoption, and only a deliberate, months-long program of embedded coaching, office hours, and peer champions got individual productivity to actually move^[2]. The gap between companies that see large delivery gains and those stuck at marginal improvement is largely a change-management gap, not a tooling gap.

Watch for the warning signs before you cut. Rising bug or incident rates per pull request, falling developer trust scores, and growing code-complexity metrics are all signals that you're borrowing speed from the future. Klarna and the Orgvue data both point to the same lesson: restructuring headcount ahead of proven quality outcomes is a decision a meaningful share of leaders end up regretting.

Rethinking how your engineering organization works in an AI-native world? Let's discuss how Aliac can help you sequence the shift from Agile ceremonies to AI-native workflows without borrowing speed from tomorrow's quality.

Sources & References