AI coding has moved the engineering bottleneck

I am bullish on AI code generation. It has already dramatically changed how software gets built. But we need to be honest about what it accelerates. AI can generate code quickly. It does not automatically make that code reliable, maintainable, or valuable to customers.

Meta learned this at a significant scale. According to a Reuters investigation, changes to Meta's internal software platforms and infrastructure increased 220% year over year. But new and improved features reaching users increased only 36%. At the same time, major technical and security incidents increased 40%. The time employees spent firefighting those incidents increased 70%. More code was being produced. But the increase in code activity did not translate into the same increase in customer value. It also created more operational work.

A Carnegie Mellon study of 806 open-source repositories found a similar pattern. Projects adopting Cursor experienced a three-to-five-times increase in lines added during the first month. That speed advantage disappeared after about two months. Static-analysis warnings increased around 30%, while code complexity increased around 41%. The initial speed was temporary. The complexity remained. Fieldway's analysis provides a useful summary of the research and its limitations.

The impact is also showing up in QA. In a survey of 300 QA practitioners, 52% said bug volume had increased since their development teams began using AI. Fifty-eight percent said their testing workload had increased. Not one respondent gave AI-generated code a full trust score. Fieldway summarized the survey here.

The important takeaway from all of this is that code generation is accelerating faster than the systems responsible for reviewing, testing, and operating that code.

The engineering constraint is moving downstream

For years, the industry's bottleneck was coding velocity. Today, that constraint has shifted downstream to operational reliability and incident management. Tests can verify expected behavior. Code review can catch visible problems. Neither can reproduce every dependency, traffic pattern, infrastructure condition, feature-flag combination, or edge case that exists in production.

There is a second-order effect worth naming. When most of a codebase was written by people, the people who wrote it carried the operational knowledge: which service depends on which, what changed last week, what the runbook said before it drifted. When most changes are generated, that knowledge stops accumulating in anyone's head. The Meta numbers are what happens when the volume of change outgrows the memory of the organization operating it.

What production operations needs now

The reflex is to add another agent: an on-call bot, an assistant in the incident channel, a coding agent pointed at the alert queue. Each of these is a consumer of production context. None of them is a source of it. Pointed at a raw alert stream, a smart agent chases the noise faster. Five of them, each with its own credentials into the observability stack and its own model calls, chase it in five directions with no shared record of what any of them concluded.

What the downstream bottleneck actually calls for is a center, not another consumer. I would hold any approach, ours included, to three requirements.

One governed connection to telemetry and models. Investigation should query logs, metrics, traces, and topology where they already live, across the tools the team already runs, without copying telemetry into yet another platform. Model access should run through one metered path, so tokens are spent once and spend is attributable by team, agent, and service. No rip and replace, and no new data lake.

A memory of every investigation. Every root cause, every piece of evidence, every approval, recorded and cited inside your own perimeter. The memory holds conclusions, not telemetry. NeuBird stores zero telemetry. That memory has to include a dependency map discovered from real traffic, code, and config and refreshed after every deploy, and runbooks checked against reality after every change. The second occurrence of an incident should be faster than the first. In an environment shipping 220% more changes, this is the only thing that compounds in the team's favor.

Delivery to everyone doing the work. On-call engineers get a root-caused incident with a staged fix in the tool they are already in. Team leads get one view of all agentic activity touching production. And the team's own agents, including the coding agents that generated the change, connect over MCP and inherit the same context, memory, guardrails, and audit trail. The policy spectrum is Suggest, Recommend, Act, and it applies to every actor, including NeuBird itself.

This is the Agentic Operations Center, and it is what we built NeuBird to be. The NOC watched. The SOC investigated. The AOC acts and governs. Out of the box, NeuBird investigates and resolves incidents alongside the engineers who own them: it assembles the relevant context for an incident, runs a hypothesis-driven investigation, identifies the most likely root cause, presents the evidence, assesses impact, and recommends the next action. In customer production environments it reaches root cause in under five minutes with 94% RCA accuracy, and it runs in your VPC or air-gapped, SOC 2 Type II, with human approval on every action.

Two things it is not. It is not a replacement for testing, observability, change management, or incident process. And it is not a replacement for experienced SREs. NeuBird does the investigation work that no longer fits in the hours the team has, and hands back a decision with the evidence attached.

The coding agents are not the problem

I want to be clear about the tools that started this essay. Cursor, Claude, and homegrown agents are excellent, and they are exactly as good as the context they are given. The Meta and CMU data are not an argument against using them. They are an argument for giving them, and everyone else on the team, a shared and governed view of what production actually is and what has already been learned about it. The clients will change every year. The context layer is the asset you keep.

The next generation of engineering excellence will not be defined by who can generate code the fastest. It will be defined by who can safely operate the most complex systems at scale.