Agent-based development greatly raises individual engineering productivity, but if the existing organization remains unchanged, company-wide improvement usually struggles to exceed 50 percent. Breaking through requires changing the relationship between product and engineering, team composition, decision authority, management structure, and even how non-engineering functions work. The task is not merely adopting faster tools, but moving to an operating model designed for their speed.

1. The 50-Percent Barrier Between Individual and Organizational Speed

The infrastructure and workforce changes discussed earlier make individual engineers dramatically faster. They do not automatically make the whole organization move at the same speed. The central problem is the gap between fast individual execution and actual organization-wide output.

One leading company in the study had practiced agent-centered development for over a year and agents generated 85–90 percent of production code. Its infrastructure was strong. Yet even with code generation almost ten times faster, end-to-end productivity from intent to deployed value improved by no more than 50 percent and usually only 25–30 percent.

"Code generation became almost ten times faster. But real end-to-end productivity from intent to deployed value improved by no more than 50 percent. Most of the time it was closer to 25 or 30 percent."

— Engineering leader at a late-stage company

The article calls this a Ferrari stopping at every traffic light. Replacing an old sedan with a sports car improves the vehicle, but red lights every two hundred meters barely change arrival time. Faster developers cannot deliver the benefit while product reviews, PM handoffs, code-review queues, monthly planning, human status reporting, and legacy ownership boundaries remain intact.

External data shows the same pattern. Across more than four hundred companies measured by DX, AI adoption rose 65 percent while median pull-request throughput increased only 7.76 percent. Much of the local acceleration disappeared into organizational bottlenecks.

This does not mean removing every safeguard. Quality and security controls remain necessary. But unnecessary stops designed for slow historical development should go, and automatable controls should be redesigned to operate at machine speed. 🚦

"The cars got faster. Now redesign the roads."

2. People Trained to Wait for Permission

Removing approval processes does not make people move quickly overnight. One engineer was explicitly authorized to work in an AI-native way and the approval gates were removed, but he still sought permission whenever he faced a meaningful architectural, scope, or product-priority decision.

"The traffic lights were off, but he still stopped at every intersection."

Traditional product and software management usually followed define, align, review, approve, implement. This made sense when code was expensive and rework slow. It also trained engineers to ask permission rather than decide, defend code already written, and treat discarded work as waste.

The agentic era rewards more reversible decisions, rapid experiments in software, and willingness to discard work when evidence changes. Organizational change must go beyond removing procedure; people must learn to judge and act without waiting for approval.

Delay creates competitive risk. Given the 46-fold concentration of capability discussed in Part I, a fifty-person R&D organization late to AI could lose on throughput to two AI-fluent engineers at a competitor. Those two face little friction from management layers, PM handoffs, or cross-team queues. With domain knowledge and sound architecture, they operate like founders.

An existing codebase remains a defense, but not a permanent moat. A good codebase can serve competitors as an excellent specification. A few exceptional engineers may rapidly reconstruct parity and then move ahead. Companies must make those people want to work inside their own organization, not a competitor's.

3. Reversing the Relationship Between PM and Engineer

Traditional software organizations commonly employed roughly one PM per six engineers. Engineering was slower, so PMs could continuously define and feed work into development.

When a feature takes a day rather than a sprint, requirements definition and product judgment become the bottleneck. The PM-to-engineer ratio then moves in one of two directions based on proximity to customers.

Engineers Absorb the Product Role

For developer tools or infrastructure, where engineers are the customers or know the domain deeply, the ratio may expand beyond 1:10. Product work does not disappear; it moves into engineering.

Each engineer becomes a mini-founder responsible for a product area, staying close to customers, deciding what to build, shipping it, and learning from usage. Remaining PMs manage a broader portfolio rather than transmitting requirements to one team.

PMs Become Hybrid Builders

Sometimes engineers cannot understand customers sufficiently because of distance in geography, demographics, or expertise. PMs cannot simply be removed. Instead, PMs use coding tools to build clickable prototypes and working features, while engineers strengthen architecture, quality, security, and operational reliability rather than translating a specification mechanically.

One late-stage software company is moving from a 1:6 ratio toward 1:2 on this logic and requires every PM to use Claude Code.

"I have excess capacity to build. If you define it, I will build it. I want to build faster than you can define."

— CTO of a late-stage software company

Working Betas and PRs Replace Specifications

Documents once formed the interface between functions; now working software itself becomes the interface. Designers submit functional screens, PMs submit implemented prototypes, and people who did not know Git a year ago open pull requests.

"The beta is the specification, and the PR is the handoff."

Handoffs do not vanish, but the translation from reading a document to interpreting and implementing it shrinks. Everyone can react to the real beta instead of debating an interpretation. Engineering remains responsible for architecture, quality, security, and production approval, but starts from a working change.

Cat Wu, product lead for Claude Code, describes the convergence:

"Our roles are blending. Designers ship code, engineers make product decisions, and product managers build prototypes and evaluation tools."

One engineering leader in the study put the hiring implication more directly:

"It is easier to teach product-management skills to a developer than to teach a product manager to think like an architect."

Planning Cycles Shrink

Faster shipping also breaks old planning. Quarterly OKRs, six-month roadmaps, and two-week sprints arose when one feature took a month. If a feature takes a day, a detailed six-month plan may assume constraints that disappear before launch.

Anthropic's internal benchmarks show that from Sonnet 3.5 to Opus 4.6, over sixteen months, the task duration a frontier model could handle without human intervention rose roughly 41-fold. Planning cycles longer than capability-change intervals risk planning for a world that no longer exists. Organizations should make fewer long-term commitments and run and discard more experiments quickly.

4. Autonomous Squads as the Basic Unit of Shipping

The core execution unit becomes a small squad of individual contributors with product judgment. Each directs agents and ships independently. Companies in the study varied, but generally converged on teams of one to five, most commonly two or three.

One AI-native company assigns about five people to each product vertical: two backend engineers, two AI engineers, and one architect-like role. Even with agents, two humans often solve difficult problems better than one, and agent-assisted pair programming can create healthier collaboration than complete isolation.

The Extreme of a One-Person Squad

A one-person squad is the extreme of the small-squad model, not an entirely different form, and opinions remain divided. One AI-native startup in the study considers it romanticized rather than practical.

"It is a romantic story. It is not good enough yet."

— AI-native startup

Another late-stage company runs five or six one-person squads in production. One engineer owns a product end to end and directs a team of agents working almost around the clock. The engineer also performs the PM role, understands customers and product, and decides what to build. It works especially well where engineers can represent customers and produced a reported sevenfold speedup after reorganization.

Junior Engineers Have Not Disappeared

Contrary to claims that AI ends junior engineering, several companies reported the opposite under certain conditions. The important hiring criteria are AI fluency and product judgment, not tenure, supported by a strong architectural spine.

"A junior with product sense paired with an architect is more powerful than yesterday's veteran programmer."

— CEO of an AI-native startup

Scale changes the picture. A mid-sized SaaS company measuring its engineering organization found that L2 engineers close to graduation struggled most with AI, while staff and principal engineers used it most aggressively. Its CPTO attributed this to experience and taste: making fast decisions from broader context.

In a small AI-native company, a nearby architect can bear more of the judgment burden. In a large organization with less proximity, individual judgment matters much more. Tenure alone is not the criterion, but at scale the value of judgment formed through experience compounds.

5. Four Chiefs Align Autonomy

Small autonomous squads reduce handoffs and accelerate shipping, but locally sensible decisions may pull the company in different directions. As hierarchy thins, alignment previously supplied by architects, senior managers, product reviews, design critiques, and security gates disappears too.

The article proposes Four Chiefs who maintain company-wide context:

1. Chief Architect

   Maintains architectural consistency across projects and updates technology choices as external technology changes.

2. Chief Product

   Aligns autonomous teams around one product strategy and important customer needs.

3. Chief Designer

   Creates a consistent, distinctive visual and product voice across every touchpoint.

4. Chief Security

   Maintains a single security boundary spanning models, agents, squads, and risks introduced by AI adoption.

They should be the most experienced and AI-capable people in their fields. Squads use agents within a project; chiefs use them across projects. Because agents handle research, search, comparison, and repetitive communication, a chief's organization can remain one person or a very small team rather than a large department.

Divergence from Freedom of Models and Teams

Autonomous squads can choose databases, authentication, API patterns, UI components, state management, testing, observability, and external libraries. Using several models is good practice because strengths differ, independent opinions improve important decisions, and the company avoids total dependence on one provider.

Models also carry default biases. A 2026 ACL Findings paper, A Study of Library and Programming Language Preferences in Large Language Models, compared eight models and found a preference for familiar, popular languages and libraries over suitability. Models may guide teams toward the common choice rather than the company's best choice.

Even when every squad decides reasonably, incompatible stacks and duplicate infrastructure can accumulate. Model diversity improves judgment, but combined with team autonomy it can widen divergence.

The Problem of Everything Looking Alike

In design, the problem is more visible. Models trained on similar product data converge on safe defaults: familiar component libraries, rounded cards, and predictable layouts. Without a distinct visual language, the model fills the gap with the statistical average.

"AI design is derivative. It is trained on Tailwind and Bootstrap, so everything ends up looking the same."

— Shared observation from three companies in the study

The Chief Designer must set a proprietary language spanning typography, color, composition, imagery, motion, and conventions the company deliberately rejects. Agents can apply it consistently across hundreds of screens and generate variations, but cannot originate the brand's human point of view.

Traffic Control Without Stopping Traffic

A squad's local context centers on requirements, repositories, tests, and an immediate customer problem. Chiefs must remember shared architecture, stack, product strategy, security policy, design systems, customer commitments, reusable code, data, prompts, design assets, and historical exceptions. This is company-wide memory.

Chiefs use several models to search history and compare external alternatives. On important questions they expose inter-model disagreement and examine hidden assumptions and biases. Models broaden the view; accumulated human experience makes the final judgment.

To remove traffic lights without causing chaos, chiefs cannot wait for teams to escalate problems. Their agents continuously inspect plans, code, dependencies, design changes, security exceptions, and customer promises across projects. Comparing them with standards and historical decisions, they alert the chief when a small team's choice begins becoming a company-wide issue. Routine decisions stay with squads; consequential ones surface early and asynchronously.

"Control the traffic without traffic lights."

At one AI-native company, the CEO built a personal agent connected to Slack, production, meeting transcripts, and monitoring. Employees talk to it before approaching the CEO. Another leading organization gives each product a bot aware of conversations, code, and customer calls; the product lead uses it as the first review before release approval. Agents answer routine questions, and only matters requiring real judgment reach people.

6. Management Layers Shorten and Spans Widen

When product-minded individual contributors direct agents, small squads ship independently, and Four Chiefs preserve company direction, the surrounding management structure can compress. Agents absorb status gathering, work coordination, and routine handoffs, letting managers cover more engineers and squads.

Management does not disappear; its density and purpose change. The chart becomes shorter and wider: fewer managers per engineer, fewer steps from frontline builder to executive, and broader scope per manager.

At a twenty-five-person startup, team-level managers may disappear. In a five-hundred-engineer organization, one layer may vanish, spans may broaden, and remaining managers may focus less on coordination and more on people, portfolios, and cross-team judgment.

Engineering management traditionally combined people leadership with workflow coordination: status meetings, sprint planning, capacity allocation, blocker removal, and cross-team negotiation. Agents reduce much of that coordination but do not eliminate coaching, performance management, hiring, governance, or product-and-platform judgment.

Roles that mainly translate status between layers and coordinate handoffs shrink first. Remaining management roles are broader and require more judgment.

Automation Enables Broader Spans

Automatic transcription and summaries, agents that detect risk in team activity and draft status reports, and assistants that turn managerial intent into follow-up reduce time spent manufacturing visibility.

Where four to six direct reports was once common, some organizations now consider fifteen to twenty-five. AI does not replace managerial judgment; it reduces repetitive work such as attending meetings, writing reports, preparing one-on-ones, tracking blockers, and connecting workflows.

Ramp runs agents in shared multi-user sessions so teammates see one another's work in real time without waiting for status meetings. Transcripts become searchable company memory. Like the CEO agent above, leadership context can be queried when needed. Continuous visibility and queryable leadership context enable wider spans.

Three Career Paths for Managers

The equation of a larger team with a higher title weakens as spans widen and layers compress. Managers can move in three directions:

1. Wider management scope

   Own several squads or product areas rather than one small team. AI supports visibility and follow-through; the manager owns people, priorities, performance, and cross-team choices.

2. Return to hands-on engineering

   A former manager of four becomes a senior individual contributor directing a squad of several agents. The scope of influence remains, but the form of work changes.

3. Cross-squad leadership

   Take a company-wide role preserving context and judgment that one project cannot, such as architecture, platform, product domain, or security.

All three require managers to become deeply fluent in AI. Supervising people who use AI is insufficient. Leaders must operate agents themselves, understand the new work firsthand, and distinguish strong agent-based outcomes.

What matters is not team size but leverage. Middle management remains in large companies, but roles existing only to relay status between layers will decline.

7. Building Capability Spreads Beyond Engineering

The agentic transition began in engineering, but revenue operations, finance, HR, support, and legal are moving the same way. They are not becoming software engineers. Each function gains agents and custom internal applications operating inside systems it already uses.

People previously moved among CRM, billing, email, spreadsheets, and support queues to assemble context and perform repeated work. Agents assemble the context, execute routine steps, and return only decisions requiring human judgment. As these systems mature, manual procedures and thin SaaS features begin yielding to agentic internal tools adapted to company data and operations.

The study already observed:

• A RevOps team building sales-cycle analysis and deal-scoring software with coding agents and automation tools
• A five-person GTM AI team building systems such as call briefings for sales and marketing
• Companies building HR candidate-screening tools, internal pricing applications, and helpdesk and meeting-intelligence systems
• Dashboards combining revenue, engineering, finance, and HR data

These are not employees developing side projects after their main jobs. Functions are directly rebuilding how their own work gets done.

Business Software Will Move Beyond Its IDE Stage

Engineering began by placing AI assistance in existing IDEs. The larger change came when agents received outcome goals and operated the whole toolchain.

Business software is similar. A better CRM sidebar or AI extension for Excel helps but remains in the "IDE stage," with a person operating the application. The true agentic transition begins when an agent reads customer history, updates CRM records, triggers the next action, and works independently across CRM, email, billing, and support.

Strategy and Marketing Gain One Living Context

The Four Chiefs' method of maintaining architectural, product, design, and security consistency extends to strategy and marketing. Agents actively collect signals from customer conversations, sales activity, support, finance, product usage, competitors, and public material. They preserve not only what happened but why a decision was made.

Leadership and marketing then operate from one living context for roadmaps, positioning, and corporate strategy instead of a pile of fragmented reports.

Anthropic's Cat Wu observed the same phenomenon across the company:

"Data science, finance, marketing, legal, and design teams began using these tools themselves. Now the whole organization moves at the same speed without waiting for handoffs."

AI Ops and the New Boundary Between Buy and Build

In this transition, AI Ops becomes a company-wide function rather than engineering support. It provides every department with tools, training, reusable patterns, and common security and data foundations. It also tracks what functions build, which models and data they use, and where choices diverge.

Without it, a faster company may accumulate shadow software, inconsistent controls, and ten databases solving the same problem.

As custom development becomes cheaper, the build-versus-buy boundary moves. Trusted systems of record, regulated core systems, and products with strong network effects are still better purchased. Rigid point solutions and thin interfaces become easier to replace.

The likely pattern is to buy trustworthy core systems while building differentiating workflows and an agent layer that uses proprietary data. API quality, MCP support, and agent accessibility consequently become new purchasing criteria.

8. Where the Organization Stands Today

The transition sequence is simple: first an infrastructure problem, then a people problem, and finally an organization problem. Many companies stop before the final stage, even though it contains the greatest leverage.

Position can be judged on two axes: tool maturity and workforce transition.

AI-Adapted Organizations Past the Turning Point

These include AI-native companies and incumbents that moved decisively beyond AI-assisted IDEs to autonomous agent development in Q4 2025. Having passed tool adoption and workforce transition, they are in the difficult stage of redesigning and tuning organization structure from measured results.

Through training, hiring, and replacement, most employees have moved into a group that believes in and uses the AI transition. Obstacles created by defenders of old ways have largely been removed.

Cautious Organizations Approaching the Turning Point

Most organizations are likely here. They run some agent projects in new products or embedded AI features, while most of the company remains IDE-centered. They are building infrastructure to expand agent development.

They are not ready for a decisive turn. People remain attached to or defending old methods, legacy architecture constrains them, and they fear losing control.

Holdout Organizations That Have Not Transitioned

These have added a few IDE tools, but every change still requires human review by choice or regulation. They are earliest in both tools and people, with the farthest distance to catch up and the least time.

9. First-Mover Advantage and the Choices Facing Late Movers

AI-assisted IDEs became common in 2023–2024, but humans still drove every line of code. The article places the true inflection in Q4 2025, when Claude Code 2.0 arrived in September and Opus 4.5 in November, making agents dependable work tools rather than demos.

An early-2025 randomized METR experiment found experienced developers were actually 19 percent slower with AI. Participants believed they were 20 percent faster, but the data showed the opposite. When the same developers were measured later in 2025, the direction reversed, although researchers warned that the new result was weak evidence because many participants refused to work without AI.

The case shows how rapidly tool performance and experience changed within months. First-mover advantage is real and cumulative. Late companies, however, inherit better tools, lessons from earlier mistakes, and validated operating practices.

"Timing created the lead. But the operating-model choice determines the slope from here."

Late movers have two paths:

• Introduce AI cautiously while preserving the existing operating model. Individuals improve meaningfully, but the gap keeps accumulating.
• Redraw infrastructure, workflows, roles, and decision rights for agent-based work. Move onto a steeper curve and close the lead.

"For followers, the moment of choice is now."

10. The Next Transition Will Arrive Faster

Q4 2025 began a continuous sequence, not a final transition. An agent working for an hour without intervention and one working for a day are not merely the same tool run longer; they require different teams, review, and organizational structures.

People plan linearly, assuming next quarter resembles this one plus a little. AI capability does not move that slowly. A structure designed for a 5x world may already lag in a 20x world that arrives while hiring for the old plan.

Imagine one year ahead. Instead of opening an editor Monday morning, you brief hundreds of agents handling features, bug fixes, tests, migrations, research, and review. They work nights and weekends. The human job becomes deciding what to build and whether returned results are correct.

The moat of an existing codebase becomes shallower each quarter as rebuilding an equivalent system from scratch takes less time. This scenario assumes no unseen breakthrough; it merely extends the visible curve twelve months.

Agents also become faster, not only more numerous. Build, test, and rework cycles that take minutes compress toward immediacy. Short iterations needing human input finish in seconds and feel like real-time conversation rather than serial handoffs. Long tasks continue for hours or days without recalling a human.

One thing does not accelerate: human judgment about what to build and whether the result is right. That becomes the most important human work.

The change spreads beyond engineering into revenue operations, finance, HR, support, and legal. R&D moved first because of longer tool experience and stronger automation incentives, but other functions need not rediscover the path. Tool adoption, workforce transition, cross-functional context management, and organizational change transfer directly.

11. Closing

The agentic era does not call for one perfect reorganization. Continuous changes in technical capability will repeatedly demand new team structures, review methods, authority allocation, and management roles.

The essential organizational capability is to remain near the frontier, recognize the next transition early, and keep reassembling accordingly. 💡

"The agentic awakening is already moving through the industry. Those who see it early will define the next era of software. Everyone else will wake up inside it."