Scaling AI Coding Agents From Pilot to Production

AI coding agents are already running in production at a wide range of organizations, taking a ticket, reading a codebase, planning a set of changes, writing the code, running the tests, and opening a pull request without a human at the keyboard. The problem showing up across the industry in 2026 is not whether agents can do real work, but why so many teams that prove the concept in a pilot cannot get the same workflow to hold up at scale. Gartner predicts that more than 40% of agentic AI projects will be canceled by the end of 2027, and the stated reasons are escalating costs, unclear business value, and inadequate risk controls, not weak models. The pattern in failed deployments backs this up: the controls missing most often are single sign-on left unconfigured, audit logs that never reach the SIEM, pull request gates that exist on paper but aren't enforced, and no sandbox isolation around what the agent is allowed to touch. None of those are modeling problems. They are governance and architecture problems, and they are the actual subject of this piece.

Scaling From a Handful of Files to Dozens

A pilot looks clean because the scope is small. A single agent task in a pilot usually touches a handful of files in a part of the codebase the team already understands well, and a developer reviewing the output can hold the whole change in their head while reading it. Production work does not stay that small. A single prompt at production scale can span dozens of files and produce thousands of lines of diff in one pass, and at that point the diff stops being a usable way to understand what the agent actually built. The scale ceiling for this kind of work was demonstrated publicly when a team ported 535,496 lines of Zig to Rust using up to 64 Claude agents running in parallel, generating more than a million lines of code. The achievement was real, but the harder problem it exposed was verification: once code is produced at that volume, no person is reading all of it line by line, and the question of whether it's correct has to be answered a different way. Agents also carry documented limits as codebases grow. Files above a certain size often get excluded from indexing altogether, multi-file refactors in enterprise environments land well short of what benchmark demonstrations suggest, and legacy codebases perform worse than clean test repositories in almost every case. Part of the reason is a known effect in long-context models: as the amount of context grows, agents tend to lose track of information sitting in the middle of it, which makes a single globally consistent decision less and less likely the wider the task spans. Agents are also built to finish the task in front of them, not to preserve the shape of the system around it. Each decision can be locally sensible and still be wrong for the codebase as a whole. As a result, the code on disk slowly stops matching the design the team agreed on, and no single diff is where you'd catch the drift happening.

Architecture drift as the silent failure mode of agent-assisted codebases

Architecture drift has always existed in software teams, but the usual defenses against it, code review, documentation, the occasional deliberate refactor, were built for a pace of change that agents have already outrun. A human engineer builds up an intuitive sense of a system's design over months of working inside it. An agent starting a new task has no such memory. It only knows what it can read in the current context window, so it has no way to notice that the change it's about to make conflicts with a design decision made three tasks earlier. One response to this has been to have agents review each other's output, but that pattern carries its own blind spot: a model reviewing work from a closely related model tends to miss the same things the generating model missed, especially within the same model family. Meanwhile the review queue itself is already strained. Senior engineers are spending more time reviewing pull requests than designing systems, and deployment frequency hasn't kept pace with how fast code is now being generated. Security is where this becomes most expensive. Findings across multiple 2026 assessments point to a higher rate of security vulnerabilities in AI-generated code that goes unreviewed, even though results on overall bug density are mixed from study to study. An agent implementing the obvious version of a feature correctly while missing a constraint that only exists as unwritten domain knowledge appears across these cases, so the code looks right in isolation and is wrong in context. The scale of the compounding effect is visible in one 2026 agentic case study where 189 files were modified in the course of unwinding a single core architectural invariant. Each of those changes made the next review slightly harder and the next agent task slightly less coherent, and by the end the codebase no longer matched the design anyone had actually agreed to. The honest conclusion from that case is that the fix cannot be "review more carefully," because review capacity was already running out.

Making architecture machine-readable so agents cannot violate it

If review can't scale to catch drift, the rules the codebase depends on have to be enforced before the code is written. A developer with years inside a codebase carries an architectural model in their head without ever writing it down. Agents have no equivalent, so that model has to be made explicit and put somewhere an agent can read it to exist for the agent's purposes. The working principle is constraint-by-construction: non-negotiable structural rules, like which layers can depend on which, no circular dependencies, which modules are isolated from which, get embedded at the specification layer, so generated code has to comply by the time it's produced. IBM's agentic development platform, IBM Bob, shows one version of this in production. As of its July 2026 update, subagents handle exploratory work (reading files, running searches, tracing functions) inside an isolated context, and its Java modernization workflows, including migration to Java 25, large-scale refactoring, and dependency analysis, are delivered in a structured, repeatable way. The architectural model itself needs to live inside the repository and change version by version with the code. A diagram drawn once in a planning meeting and never updated is a historical artifact, not a structural model an agent can use.

Planning agent work against an explicit structural model before writing a line

Giving an agent a structural model to work from changes what it produces, because the model narrows the space of acceptable answers before the agent generates a single line. The architecture now standard across leading agents, including Claude Code and Windsurf's Cascade, separates planning from execution: a planning stage reasons about the structure of the codebase and produces an implementation plan, and only after that plan exists does an execution agent start writing code. This is usually called the Plan mode / Act mode pattern. Pointing an agent at a shared structural model, so it can see what already exists, where the boundaries sit, and what the proposed change will actually touch, cuts down on the number of changes that are locally correct but wrong for the system as a whole. For multi-file refactors or features that cross several modules, having that structure visible before the agent starts lets a developer see which boundaries the change will cross and decide whether crossing them is intended, turning what used to be a problem caught after the fact into a decision made before any code exists. In this kind of workflow, the specification itself becomes the most valuable thing a developer produces, more valuable than a detailed prompt, because a spec that references the structural model gives the agent stable ground to reason from across a task that might run for hours. Teams that get this right tend to put one person in charge of deciding which agents, which models, and which use cases are approved for production work. That's an organizational admission that agent work needs direction, not just access.

Verifying agent output against the structural model, not against the diff

A diff was never built to answer the question that matters once an agent's changes span dozens of files: does the result still match the architecture the team intended? Answering that question requires checking the output against the structural model directly, not reading every line of the change. The review backlog this creates is already visible: pull request queues are growing, senior engineers are spending more hours reviewing than designing, and deployment frequency hasn't moved in proportion to how much faster code is now being produced. Having the same agent that generated the code also review it doesn't solve this, because the model is too close to its own output to see the architectural inconsistency it just introduced; that inconsistency was invisible to it while it was writing the code, and it stays invisible on a second pass. The pattern practitioners point to as most useful at scale is cross-provider review, having a model from a different family check the output of the model that generated it, which closes the blind spot that same-family review leaves open. Structural verification can catch things a line-by-line read cannot: a change that breaks an API contract another service depends on, a regression that only shows up across service boundaries, a new component that duplicates logic that already exists somewhere else in the system. These are architectural observations that appear only across multiple files, so no amount of careful diff reading surfaces them. The Bun rewrite's own verification approach is a useful model of what holds up at real volume: a test suite with a million assertions, written independently of the implementation language so it doesn't care whether the underlying code is Zig or Rust, the compiler itself acting as a hard constraint, and adversarial agent review applied to every change. That combination is the oracle principle, an independent source of truth the generated code has to satisfy, applied at a scale most teams will never approach but should still take as the design pattern worth copying in smaller form.

Enforcing architectural constraints in CI so violations cannot merge

A rule written into documentation or typed into a prompt is a suggestion. A rule that fails a build and blocks a merge is a boundary, and only the boundary survives contact with a production agent workflow. Practitioners working on this problem keep arriving at the same conclusion: security and architecture enforcement belongs in CI, not in prompts. Telling an agent to "always verify ownership" is advice it can ignore under pressure or forget three tasks later. A failing test in the build pipeline is a gate the code cannot pass through. Architecture tests wired into CI are deterministic in a way instructions never are: if a violation physically stops the build from passing, whether the rule holds no longer depends on the agent's judgment or a developer's discipline that day. It depends on the pipeline. The same logic applies to deployment itself. If agents are able to trigger deployments on their own, constraints like "never deploy without passing integration tests" and "require human approval before a production release" have to be enforced at the platform level, because asking for that behavior in a prompt gives no guarantee it happens. In regulated environments, the production pattern that has emerged is the ephemeral workspace: agent execution runs in isolation, with audit logging, sandbox isolation, and role-based access control all enforced at the infrastructure layer, which is what makes running many agents in parallel both auditable and repeatable. Governance has to live where every process inherits the same policy automatically, in the workspace infrastructure itself, not inside a particular tool and not inside a particular prompt. A check like gr check, run in CI and set to exit with a non-zero status the moment it finds an architectural violation, is what turns the idea of the architecture graph as a source of truth from an aspiration into something operational. When that check runs on every pull request, the architectural model stored in the repository changes from documentation into a live gate the code has to clear.

The practical path from pilot to production: what the governance layer requires

Teams that get an agent workflow into durable production use do it in a specific order, with architectural enforcement at the center of that sequence, running in four phases: a pilot on a single team with mature security practices, a phase of infrastructure hardening that covers audit logging into the SIEM, sandbox isolation, secret scanning on every agent pull request, and license governance, a controlled expansion to two or three more teams, and only then general availability, with a documented list of approved agents, approved models, approved use cases, and a clear escalation path when something goes wrong. That sequence requires seven controls to be in place before general availability, not after. Every agent session has to map to a named human identity through single sign-on, because without that mapping, access reviews and offboarding simply don't function. Every file access, shell command, pull request, and API call an agent makes has to flow into the enterprise SIEM with retention that matches the compliance framework the organization answers to. Secret scanning on agent pull requests has to run as a pre-receive hook or a required status check that blocks a merge the moment it finds a secret, enforced at the infrastructure level. Agent pull requests have to go through the same review gates as human pull requests, with no pilot exemptions, and each one should carry a label identifying the tool and session that produced it, so a security team can trace a pull request back to the exact agent run that created it. Agent execution needs sandbox isolation, with microVM isolation and a dedicated kernel per workload as the baseline for any deployment touching proprietary code. A license policy needs to specify what's acceptable in agent-generated code, with a scanning step before merge and a defined process for fixing violations. And incident response runbooks need escalation paths written specifically for agent-originated incidents, not borrowed from a generic security playbook. Architectural enforcement runs through all four phases rather than showing up only at the end: a structural model gets established at the start of the pilot, agent work gets directed and checked against that model through the expansion phase, and a CI check enforces it automatically once the system reaches general availability, versioning with the code so it never becomes a separate thing someone has to remember to maintain. The teams that fail to get past pilot are rarely the ones that picked the wrong model. They're the ones that treated the choice of tool as the whole decision and skipped the governance and architecture work that keeps the system holding together once it's run at scale.