When Code Gets Cheap, Coordination Gets Expensive

TL;DR. AI is making code cheaper to produce. That does not make software organizations automatically faster. The bottleneck is moving from writing code to absorbing code: deciding what should be built, reviewing what was generated, integrating it safely, assigning ownership, and getting value into production. Engineering management now has a different job. It is no longer enough to manage people and roadmaps. Managers have to design the system through which human and AI-generated work becomes reliable product change.

The old constraint was writing

For years, engineering management was organized around a simple assumption: software was expensive because building it was slow.

That assumption shaped almost everything.

Teams were staffed around implementation capacity. Roadmaps were negotiated around developer availability. Planning rituals existed to protect scarce engineering time. Managers asked how many engineers were needed, how many sprints a feature would take, and how much work could fit into a quarter.

Then AI changed the economics of the first draft.

The shift is now visible in the data. Stack Overflow’s 2025 Developer Survey found that 84% of respondents either use or plan to use AI tools in their development process, and 50.6% of professional developers use them daily. GitHub’s 2025 Octoverse reports more than 180 million developers on GitHub, more than 1.1 million public repositories importing an LLM SDK, and 518.7 million pull requests merged over the measurement year. AI-assisted development is no longer a side experiment. It is becoming part of the default engineering environment. (Stack Overflow Developer Survey 2025, GitHub Octoverse 2025)

That does not mean software delivery has become easy.

It means the constraint has moved.

The important question is no longer only: how quickly can a developer produce code?

It is: how quickly can the organization turn a useful change into safe production behavior?

Those are not the same question.

The productivity gain is real, but local

There is credible evidence that AI can make developers faster in bounded tasks.

A controlled experiment on GitHub Copilot found that developers using the tool completed a JavaScript HTTP server task 55.8% faster than the control group. That result matters. It explains why developers adopt these tools quickly and why executives now treat AI coding as a strategic issue rather than an engineering curiosity. (Peng et al., 2023)

But a coding task is not a product.

A pull request is not a customer outcome.

A generated implementation is not a system someone can safely operate for the next five years.

This is where engineering management enters the picture. AI improves local production, but software delivery is a system of dependencies: product decisions, architectural constraints, security review, testing, deployment, observability, customer impact, and operational accountability. Speeding up one step does not speed up the whole system if the rest of the system cannot absorb the new volume.

A recent study of Copilot in collaborative open-source development makes this visible. It found a 6.5% increase in project-level productivity, but also a 41.6% increase in integration time, plausibly due to higher coordination costs. That is the whole problem in miniature: more contribution, more participation, more code — and more time spent integrating the work into a shared system. (arXiv:2410.02091)

AI does not remove coordination.

It raises the price of weak coordination.

“Almost right” becomes a management problem

The biggest risk in AI-assisted software is not that the model is always wrong.

It is that the model is often close enough to be convincing.

Stack Overflow’s 2025 survey found that more developers distrust the accuracy of AI tools than trust them: 46% distrust the output, while only 33% trust it, and just 3.1% highly trust it. The same survey shows that developers are especially reluctant to use AI for high-responsibility workflow stages: 76% do not plan to use AI for deployment and monitoring, and 69% do not plan to use it for project planning. (Stack Overflow Developer Survey 2025)

That is rational.

Deployment, monitoring, planning, and review are not typing problems. They are accountability problems. They require context, judgment, and responsibility for consequences.

This is where the role of engineering managers changes. In the old model, managers asked whether the team had enough capacity to produce the work. In the AI-assisted model, the better question is whether the team has enough capacity to verify, integrate, and own the work.

If a team generates twice as many changes but review capacity stays flat, the team is not twice as fast. It is simply building a review queue.

If juniors generate more code but seniors carry the verification burden, the organization has not automated engineering. It has shifted work from implementation to judgment.

If AI creates more prototypes than product leadership can prioritize, the bottleneck becomes decision rights.

The constraint moved from hands to architecture.

The expert slowdown is a warning, not a verdict

The strongest version of the argument must handle uncomfortable evidence honestly.

In 2025, METR ran a randomized controlled trial with 16 experienced open-source developers working on mature repositories they knew well. Developers expected AI tools to make them 24% faster. After the study, they still believed AI had helped them. The measured result was the opposite: with early-2025 AI tools, tasks took 19% longer. (METR, 2025)

This does not prove that AI slows all developers. The study was small, the context was specific, and the tools will improve.

But it does prove something useful for managers: perceived productivity and system productivity can diverge.

A developer can feel faster while spending more time prompting, checking, revising, and untangling generated output. A team can produce more pull requests while increasing integration time. An organization can see more activity in GitHub while not delivering more value to customers.

The dashboard gets noisier.

The system does not necessarily get better.

Engineering management has to become more empirical because intuition is now less reliable. The question is not whether people feel more productive. The question is whether cycle time, review time, change failure rate, incident recovery, and customer outcomes improve.

The first companies are already redesigning around this

Some companies are beginning to treat AI not as a tooling rollout, but as an operating-model change.

GitLab is the clearest recent example. In May 2026, CEO Bill Staples described a restructuring for the “agentic era.” The plan included removing up to three layers of management in some functions, reorganizing R&D into roughly 60 smaller empowered teams with end-to-end ownership, and embedding AI agents into internal processes to automate reviews, approvals, and handoffs. On June 2, 2026, GitLab confirmed it would cut about 14% of its workforce as part of this AI pivot. (Business Insider, May 2026)

The difficult human reality of layoffs should not be softened. AI restructuring can become a cover for cost-cutting, and flattening can overload the people who remain.

But the management logic is still important: GitLab is not only saying “developers will use AI.” It is saying the organization around software development has to become flatter, smaller, more ownership-driven, and more automated at the handoff layer.

Shopify made a different but related move. In April 2025, CEO Tobi Lütke told employees that AI usage was now a baseline expectation, that teams must demonstrate why they cannot get work done with AI before asking for more headcount, and that AI usage would be added to performance and peer review questionnaires. (The Verge, April 2025)

Duolingo’s April 2025 memo was even more explicit about operating-model change. CEO Luis von Ahn wrote that being “AI-first” meant the company would need to rethink much of how it works, not merely make minor tweaks to systems designed for humans. The memo tied AI to contractor usage, hiring, performance reviews, headcount allocation, and function-level redesign. (The Verge, April 2025)

Coinbase pushed the idea into team topology. In May 2026, CEO Brian Armstrong said engineers were using AI to ship in days what previously took teams weeks, and that Coinbase would experiment with “one-person teams,” reduce management layers, and concentrate around AI-native talent capable of managing fleets of agents. (Business Insider, May 2026)

These examples are imperfect. They mix strategy, cost pressure, labor reduction, and genuine organizational experimentation. But they point in the same direction: AI adoption is becoming a management architecture question.

The companies taking it seriously are not only buying tools.

They are changing how teams are shaped, how work is approved, how headcount is justified, and how responsibility is assigned.

The new engineering manager is a systems designer

This is the uncomfortable part for managers.

If code gets cheaper, coordination becomes more expensive.

That does not mean managers disappear. It means management work changes.

The old engineering manager often acted as a translator between business priorities and engineering capacity. The new engineering manager has to design the operating system of the team.

That operating system has several parts.

First: decision rights. A team using AI can generate options faster than leadership can arbitrate them. Managers have to clarify who can decide what, at what level of risk, and under which constraints. Without that, AI simply creates more proposals waiting for approval.

Second: ownership. AI can produce a patch, but it cannot be accountable for the service six months later. Every AI-assisted change needs a human or team owner. Ownership is not a line in Jira. It is the obligation to understand, maintain, monitor, and improve the behavior after it ships.

Third: review design. More generated work means review systems must become smarter, not just busier. Some checks should move left into automated tests, static analysis, policy-as-code, and security scanning. Human review should be reserved for architectural judgment, user impact, risk, and maintainability. If every AI-generated change requires the same senior-review path, AI will turn senior engineers into bottlenecks.

Fourth: platform maturity. AI magnifies inconsistency. If every team deploys differently, documents differently, monitors differently, and secures differently, AI has no stable path to follow. Platform engineering becomes the way management encodes standards into the default workflow. Backstage describes this kind of developer platform as a centralized software catalog and portal that unifies infrastructure tooling, services, templates, and documentation while preserving team autonomy. That is exactly the kind of paved road AI-assisted teams need. (Backstage documentation)

Fifth: measurement. Activity metrics become dangerous in an AI environment. Pull requests, commits, tickets closed, and generated lines of code are increasingly cheap. Managers need flow metrics instead: lead time, review latency, rework rate, escaped defects, change failure rate, incident recovery time, and customer impact.

The job is not to make people type faster.

The job is to make the system absorb useful change faster.

The review bottleneck is where theory becomes pain

Review is the first place most organizations will feel the shift.

A pull request is no longer a reliable proxy for human effort. It may contain code the author barely wrote. It may be correct, but poorly understood. It may pass tests while violating architectural intent. It may solve the local issue while increasing global complexity.

That changes the social contract of code review.

Reviewers are not just checking another engineer’s reasoning. They are often reconstructing reasoning that happened between a human and a model. That is harder.

This is why AI review tools will matter, but only if they are embedded into a management system. A 2025 study of DeputyDev, an AI-assisted code review system at TATA 1mg, reported a 23.09% reduction in average pull-request review duration and a 40.13% reduction in per-line review duration in a controlled A/B experiment involving more than 200 engineers. (arXiv:2508.09676)

That is promising because it attacks the actual bottleneck, not only the coding step.

But the lesson is not “replace review with AI.” The lesson is “redesign review around risk.” Low-risk changes can move through automated checks. Medium-risk changes can get AI-assisted review with human confirmation. High-risk changes still need deliberate human judgment.

The system should not treat a typo fix, a dependency upgrade, a payment-flow change, and an authentication refactor as the same kind of work.

AI makes that distinction more important, not less.

The best case is not full automation

The strongest evidence for the future is not pure autonomy. It is structured human-AI collaboration.

A 2025 paper on WhatsCode, an internal GenAI system deployed at WhatsApp, describes a 25-month production deployment across compliance-relevant software work. The system increased automated privacy-verification coverage from 15% to 53%, generated more than 3,000 accepted code changes, and identified two stable collaboration patterns: “one-click rollout” for high-confidence changes and “commandeer-revise” for complex decisions. The authors explicitly conclude that organizational factors such as ownership models, adoption dynamics, and risk management were as decisive as technical capability. (arXiv:2512.05314)

That is probably the right model.

Not “AI replaces engineers.”

Not “humans approve everything manually.”

A tiered operating model.

Let machines handle bounded, repeatable, well-instrumented work. Let humans own intent, context, tradeoffs, exceptions, and accountability. Move as much policy as possible into platforms and pipelines. Keep irreversible decisions close to people who understand the business and the system.

This is engineering management in the agentic era.

What has to change

The practical shift is simple to state and hard to execute.

Stop managing engineering as if implementation is the only scarce resource.

Manage it as a flow of decisions, context, risk, and ownership.

That means smaller teams with clearer missions.

Fewer handoffs.

More explicit ownership boundaries.

Better internal platforms.

More automated guardrails.

Review systems designed around risk.

Managers who remove coordination tax instead of adding status meetings to observe it.

And incentives that reward shipped, reliable customer value rather than visible activity.

DORA’s 2025 AI-assisted software development report frames successful AI adoption as a systems problem, not a tooling problem, and highlights value-stream management as a way to convert local productivity gains into product performance instead of downstream chaos. (DORA / Google Cloud State of DevOps)

That is the management challenge.

AI creates local acceleration.

Engineering management must create organizational absorption.

Without that, AI will produce more code than the company can understand, more pull requests than it can review, more prototypes than it can prioritize, and more changes than the platform can safely deploy.

What it comes down to

Code is becoming cheaper.

Coordination is not.

The companies that understand this will not simply ask every developer to use AI. They will redesign how engineering work moves: from idea to decision, from decision to implementation, from implementation to review, from review to production, and from production to learning.

The companies that miss it will confuse motion with progress. They will see more commits, more pull requests, more generated tests, more dashboards, and more AI usage in performance reviews. They will feel faster.

But the customer will not feel the difference.

The next advantage in software will not come from AI alone.

It will come from engineering organizations that know how to manage at AI speed without losing human judgment.

That is why engineering management has to change.