AI Coding Agents in the Enterprise: What They Speed Up, What They Break and How to Govern Them

Most engineering leaders now have the same two reports on their desk. One says developers love their AI coding agents and feel much faster. The other says pull requests are bigger, review queues are longer and the incident count has not gone down. Both are accurate. Writing code has become cheap and abundant, and the scarce work has moved to checking it, merging it safely and paying for the tokens. This guide sets out what the measured evidence supports, where the risk has actually landed, and the operating model that lets an engineering organization keep the gain.

• 19%slower: experienced maintainers with AI in METR's trial, who believed they were about 20% faster¹
• +30%rise in releases, against about +240% in commits, across more than 500,000 developers using AI agents²
• 56%of AI-generated code passed Veracode's 2026 security tests, one point better than a year earlier⁴

What the trials and the telemetry actually measured

The randomized evidence splits by setting. Three field experiments at Microsoft, Accenture and a Fortune 100 company, covering 4,867 developers, found 26% more completed tasks with an AI assistant, with less experienced developers gaining most.¹⁰ Google's internal trial of 96 engineers found them about 21% faster on an enterprise task.¹¹ METR's 2025 trial put 16 experienced open-source maintainers on 246 real issues in repositories they knew well, and the tasks where AI was allowed took 19% longer. The developers had expected a 24% speedup, and afterwards still believed they had been sped up by about 20%.¹ METR's 2026 attempt to repeat the study could not produce a reliable estimate, partly because developers increasingly refused to work without AI.¹²

The large observational studies see something the trials cannot: the gain shrinks at every stage after the keyboard. An NBER working paper covering more than 500,000 GitHub developers found coding activity rising with each generation of tools, from autocomplete to interactive agents to autonomous agents, while commits rose about 240%, projects about 80% and releases about 30%. The authors conclude the task-level gains have translated only partially into shipped software so far.² Stanford's study of more than 100,000 engineers at over 600 companies finds gains of about 30 to 40% on simple tasks in new codebases and 0 to 10% on complex work in mature ones, and in one case study the team's effective output stayed flat after adopting AI while rework rose 2.6 times.¹³

Company figures look far larger and measure something else. Google's chief executive said in April 2026 that 75% of new code at Google is AI-generated and approved by engineers.¹⁴ A share of accepted lines counts code, and the NBER gap shows a large share of code can sit beside modest gains in releases. Benchmarks deserve even less weight: OpenAI stopped treating SWE-bench Verified as a measure of frontier coding ability after an audit found flawed tests and signs of contamination.¹⁵ The defensible expectation is narrow. Expect real gains of roughly 10 to 40% on well-scoped, greenfield or repetitive work in mainstream languages, expect little or nothing from senior engineers deep in large legacy systems, and expect the bottleneck to move downstream.

The bill arrives in review, stability and code health

Every large dataset that looks past the commit finds the cost landing later. Google's DORA research, built on nearly 5,000 respondents, found AI adoption now improves throughput while it "continues to have a negative relationship with software delivery stability", and its summary line is that AI amplifies what a team already is.³ Faros, whose 2026 report draws on two years of telemetry from 22,000 developers across 4,000 teams, finds pull requests 51% larger, bugs per pull request up 28%, median review time five times longer and incidents per pull request tripled.¹⁶ Faros sells engineering analytics, and the direction of its findings matches the independent studies.

Thoughtworks has placed complacency with AI-generated code in the Hold ring of its Technology Radar, citing GitClear's research showing duplicate code and churn rising while refactoring declines, and recommends reinforcing test-driven development and static analysis inside the coding workflow.¹⁷ Developers feel it too: 66% of Stack Overflow's 2025 respondents named answers that are almost right as their top frustration.¹⁸ There is a skills cost as well. In Anthropic's own randomized study, junior engineers learning a new library with AI scored 17% lower on a follow-up quiz, with the largest gap in debugging.¹⁹

DORA's research also names what protects a team. Its AI capabilities model lists a clear organizational stance on AI, healthy and AI-accessible internal data, strong version control, small batches, a focus on users and quality internal platforms, and finds that small batches amplify AI's benefit.²⁰ Whatever the foundation, review capacity and change safety have to be scaled on purpose, because a faster writer does nothing for the queue behind them.

Security: the code, the dependencies and the agent itself

Veracode's July 2026 report found generated code passing security checks 56% of the time on average, against 55% in its first report a year earlier, while it was syntactically correct almost every time. The best model scored 68%, more than half the models sat at 50 to 53%, and neither model size nor coding specialization made much difference. Weaknesses that follow a pattern improved, and those that need an understanding of data flow stayed poor.⁴ The finding sits on a long academic line: in 2021, about 40% of the programs an AI assistant wrote in security-relevant scenarios were vulnerable.²¹

Dependencies add a risk of their own. A USENIX Security 2025 study of 16 code models and 576,000 samples found that at least 5.2% of packages suggested by commercial models and 21.7% of those from open-source models did not exist, 205,474 unique invented names in all, and an attacker can register a name a model keeps inventing.²² Lockfiles, an internal registry or proxy, and a block on newly published packages close that gap. The larger shift is that the agent itself is now an attack surface. Simon Willison's rule of the lethal trifecta is the clearest guide: never give one agent access to private data, exposure to untrusted content and the ability to send data out at the same time.²³ Our AI agent security guide covers that threat model in depth.

Nine incidents and the control each one lacked

The public incident record falls into four patterns: destructive actions by agents with too much access, poisoned agent tooling, malware that drives installed AI tools, and prompt injection through repository content. Each maps to a control that already exists.

The pattern is consistent. The most damaging incidents happened because an agent could reach production or the backups, and cloning a repository has become a code-execution event because the repository itself can carry the payload. No measured study yet shows how much sandboxing or required review lowers incident rates, so the case for these controls rests on the incidents themselves, and the controls are cheap next to one lost database.

Seats became meters

Adoption is settled. Stack Overflow's figures show AI tool use among developers rising from 44% in 2023 to 79% in 2025, and agent use climbing from 31% to 59% by an April 2026 pulse survey, while positive sentiment fell.³¹ The money has changed shape with it. GitHub moved Copilot to token-based credits in June 2026, explaining that under seats a quick chat question and a multi-hour autonomous coding session could cost the same, and added budget caps at enterprise, cost-center and user level.⁷

Uber ran the whole cycle in public. It reportedly encouraged staff to use AI as much as possible, used its 2026 AI budget in about four months, then capped monthly spend per employee for each agentic coding tool, with exceptions by permission.⁸ Meta told engineers in September 2026 that it will not use AI adoption dashboards or token counts to evaluate impact.⁹ Gartner expects the pressure to grow: it predicts inference cost per agentic workflow will rise more than fivefold through 2028 even as unit prices fall, and recommends routing tasks to the right model tier.³² Our guide to inference cost covers those controls.

The cost drivers are tokens per task from long context, reasoning and retries, the default model tier, session length and autonomy, overlapping tools per engineer, and above all incentives. Budgeting becomes a consumption forecast with a long tail of heavy users, and usage can never be the success measure, because usage is exactly what the meter charges for.

The harness is the unit of control

The credible practitioner sources describe one operating model. Birgitta Böckeler's account of harness engineering defines the agent as the model plus its harness, and divides controls into guides that steer before the agent acts and sensors that check after, some deterministic like tests, linters and type checkers, others inferential like AI review.³³ Anthropic's guide for Claude Code makes verification its first practice, giving the agent a check it can run, and draws the line policy depends on: context-file instructions are advisory, while hooks are deterministic and always run.³⁴ GitHub builds separation of duties into its cloud agent, which pushes only to its own branch, opens pull requests that a human must review and merge, does not trigger workflows until review, and prevents the person who asked for the change from approving it.³⁵

Context files such as AGENTS.md, an open format now used by more than 60,000 projects, are useful guidance.³⁶ Governance belongs in permissions, sandboxes, hooks, branch protection and CI, which the agent cannot talk its way past. The table maps the clauses that appear in coding-agent policies to the control that enforces each one.

Measure delivery and cost together, never usage alone

METR's perception gap rules out self-reported time savings, and Meta's reversal rules out token counts. DORA's delivery metrics and DX's framework of utilization, impact and cost point to one scorecard that pairs throughput with stability, adds the review queue where the cost now lands, and sets spend against results.³³⁷ Baseline it before the rollout, because a team cannot tell an improvement from a dip it never measured.

Where to start

The best-documented enterprise wins share one shape: a bounded job, a mechanical check and a success threshold set in advance. Google set a goal of saving at least 50% of end-to-end time for its code-migration tool, and 80% of the landed changes in one migration were AI-authored.³⁸ Airbnb migrated about 3,500 test files in six weeks against a manual estimate of a year and a half, through a pipeline that refactored, tested, linted and compiled with retries.³⁹ Uber's AI code reviewer now analyzes more than 90% of about 65,000 weekly changes, and engineers rate 75% of its comments useful.⁴⁰ Upgrades of this kind are covered in our guide to AI-assisted .NET and Java modernization.

1. 1Lock down identity and containment Give agents identities with no production roles, short-lived scoped tokens, sandboxes with outbound allowlists, and backups they cannot reach. This needs no productivity evidence to justify.
2. 2Put agent output on existing rails Agent-only branches, draft pull requests, an approver who is not the requester, and hard gates for tests, security, dependencies and licenses. Write size limits into the review policy.
3. 3Choose work you can verify Start with migrations, framework upgrades, test backfills and AI-assisted review, set the success threshold first, and expect a dip in the first months.
4. 4Govern cost as consumption Budgets per user and per tool with an exception path, fewer overlapping tools, routine tasks routed to cheaper models, and token counts kept out of performance reviews.
5. 5Read the scorecard honestly If pull requests climb while deployments and change failure rate stay flat, the fix is in review, testing and release. Keep junior engineers debugging by hand often enough to learn.

The question has moved from whether AI writes code faster to whether the organization can absorb what it writes. Generation is abundant now. Verification, review and safe release are scarce, and the meter runs on every token whether or not the result ships. An engineering organization adopting agents is really buying a verification system, an identity model and a consumption budget, with the model as the most interchangeable part.

This is how we run custom software development. Our engineers work with coding agents inside a harness: agents contained and scoped, every change reviewed by an engineer other than the one who asked for it, hard gates on tests, security and dependencies, and delivery, stability and cost reported together, so clients get the speed and keep a codebase they can trust.