In the 1950s, “automatic programming” was the industry’s term for the compiler. It arrived with one prediction attached: machines would soon write the programs themselves, and the profession of programming would quietly disappear. The truth is that compilers did not replace programmers. They raised the level the programmer worked at, and the profession grew strong. Seventy years later the same prediction is being made about AI coding agents, and for much the same reason. However, a coding agent is a language model placed inside a loop. When given a workspace with permissions to read and write files and run system-level commands, it keeps working until it believes the work is finished or somebody or something stops it.
That loop is very useful, and engineers have noticed. In most engineering organizations, a serious inventory will find coding agents already in use, sanctioned or not, on corporate accounts or personal ones. Like every other productivity technology, the properties that provide the benefits are the same properties that create the risks. An agent that reads everything can also read your credentials and act on a hostile instruction without your permission. An agent that never gets bored can produce more change than your review process was built to absorb. And an agent that absorbs the routine work absorbs the work your junior engineers learn on, which is the capability risk here, and the one that takes years to become visible.
The decision in front of most engineering executives concerns how adoption should be designed and governed, since the adoption itself has already happened. The mistake most policies make is treating all of it as autocomplete. Above the tier where a person reads every line, a coding agent is not autocomplete: it is delegated execution inside your software delivery system, and it has to be governed like it. Understand the risks, regulate them with cybersecurity boundaries and review gates, and the organization can capture the velocity coding agents offer without accumulating the invisible debt that unmanaged adoption leaves behind.
1. The problem with how adoption is happening
The first step is to catalog what is happening now: inventory the tools engineers are using, and the accounts, data, and APIs those tools have access to. Then establish how that data is governed, which policy layer enforces it, and who owns the policies and the audit trail.
Organizations that ban adoption outright do not see the end of the usage, because usage moves to personal accounts, which moves control to personal devices, where no policy or audit log reaches. The usage simply stops being visible, which is worse, because a risk you can measure is a risk you can manage.
One possible response is a “paved road”: a small set of sanctioned tools with enterprise governance in place, with single sign-on, audit logging, and data governance. For that road to get used, though, the sanctioned version has to be at least as good as the shadow one. Engineers adopted these tools because they work, and no policy document will move a team to something slower. Coding agents have already earned a place at the desk for this generation of engineers.
2. “AI coding” is not one activity
Before the benefits or the risks can be discussed usefully, one distinction has to come first, and most AI policies miss it entirely. “AI coding” is not one activity, and writing a single policy for it guarantees the policy is wrong in both directions — suffocating the safe tiers while under-governing the risky one.
There are at least four different autonomy tiers, with different factors of risk.
The first tier is completion, where the model suggests code inline and the engineer accepts or rejects each suggestion at that moment; the risk is low and local to the developer’s IDE.
The second is pairing, where the engineer works conversationally with the model on code they are actively reading. This is the human-in-the-loop (HITL) tier: a person is reading every line as it arrives.
The third is delegation, where the agent takes a task-sized unit of work and produces a reviewable change set on its own; here the human moves from the loop to the gate, and review becomes the control rather than a formality. This is the tier today’s coding agents, such as Claude Code and Codex, are built around.
The fourth is autonomous operation, where agents run in the background against queues of work. This can be triggered by issues in Jira, kanban maintenance queues, set schedules, dependency alerts, L1/L2 monitoring alerts, or other agents. In this model, agents can open and execute changes without a human initiating each one. At that fourth tier you are operating an agent in production, and everything that applies to production agents generally applies to the one writing your code.
These tiers determine everything that follows: where the gains land, which risks are live, and which controls are worth what they cost.
3. Where the benefits are real
These agents are uneven performers, and knowing where they are strong and where they are weak is where the value lies. They excel at work that is well specified, documented, and tested. They can produce a usable map of an unfamiliar repository in a single pass, work that can take a newly onboarded engineer days or weeks.
They can migrate across large codebases, create useful test scaffolding, manage dependency upgrades, fix well-characterized bugs, and update issue trackers and source hosts directly through MCP servers. And an agent is fast, tireless, and checkable through test suites and human reviews.
However, if given ambiguous requirements, where the tests are weak or absent, where the domain knowledge lives in people’s heads and never reached the repository, or where the change touches systems whose failure modes are subtle, the agent produces “a best guess” that requires engineers to do a lot of refactoring. The specification, the tests, and the architectural context a team once carried in its head now have to exist in the repository, because the repository is the only place an agent can read them.
So agents are a strong answer to the delivery problem, and the risks they carry are the price of that answer.
4. Security risk: the blast radius
With every new technology, no matter how useful it might be, the risks tend to arrive alongside the benefits. Consider the office spreadsheet macro. In the early 1990s, the ability to script a spreadsheet was a genuine advance: finance teams could automate a week of manual work into a few button clicks.
That same scriptability, however, is exactly what made the macro virus possible. The industry spent the following decade building the controls — disabled-by-default execution, signed macros, protected view — to contain this. Those controls should have accompanied the feature from the start.
For coding agents, the equivalent controls are being built now, and organizations that build them early can mitigate the risks before they compound.
The risks themselves are real, and they scale with the tier. File reading and command execution begin at pairing; the blast radius widens sharply at delegation and above, where nobody is reading each line as it arrives. Most of these risks can be managed by setting agent boundaries.
- Agents can read files: credentials sitting in an environment file may get added to prompts, to logs, to repositories; secret hygiene stops being a best practice and becomes a precondition.
- Agents can run commands: a task that executes inside a developer’s own session can inherit that developer’s access to everything the developer can reach.
- Agents can fetch dependencies: models can hallucinate package names, and attackers can register the names that models tend to hallucinate. That unofficial dependency could become a supply-chain attack.
Most consequential of all is untrusted content. Issue text, pull-request comments, repository instructions, README files, source comments, dependency contents, retrieved web pages, and tool responses can all carry hostile instructions. An agent that acts on them as instructions becomes the attacker’s hands.
A single instruction planted in an issue comment can reach the agent and, from there, the repository, the build pipelines, the credentials the pipeline holds, and, if not caught in time, production. The same indirect prompt injection patterns that compromise retrieval assistants apply here with a considerably larger blast radius, because this agent has commit access.
5. Quality risk: review capacity and debt
The quality risks are a different executive concern. Security risk is about blast radius — how far a single bad instruction can travel. Quality risk is about capacity: whether the organization can still read what it ships. It is quieter, and over a long enough period more expensive.
An agent will happily produce a change too large for humans to inspect carefully, and volume is the mechanism. In the rollouts I review, a recurring pattern is change sets that are simply unnecessary — variable renames, or an “optimized” rewrite of a loop that was working and well tested. Each one is individually harmless and collectively expensive, because each one consumes review attention that the genuinely risky changes needed.
Over time, an agent can create a codebase nobody has actually read. That debt compounds quietly, and it does not announce itself until someone has to change something load-bearing under time pressure.
Both risk classes want the same response: engineering leaders need to treat them the way every other production risk is treated, at design time, with proper policies and governance in place.
6. Regulating the risky tiers
Not every tier needs the same controls. Completion and pairing need little beyond the data-handling boundary, since a person is reading every line as it arrives. Delegation and autonomous operation are where the following six controls earn their cost, and the fourth tier needs all six without exception.
- Disposable execution environments. From the delegation tier upward, each task should start in a clean workspace and end with that workspace destroyed, so no production credentials or inherited developer sessions persist from one task to the next.
- Default-deny network egress. Permit only the package registries, artifact stores, source hosts, and documentation domains the task requires. This is the single highest-value control on the list, because it converts an instruction into a physical limit. A prompt that says “do not touch production” is a sign on the door; an environment with no route and no credential is a lock. In household terms, it is the difference between telling a child not to touch the stove and installing the knob covers.
- Automated validation before a human ever looks. The agent workflow should run the same build, tests, and type checks required of human-authored changes, plus formatting and static analysis, e.g., Ruff for Python, so reviewers do not spend time on machine-detectable defects. Add security scanning for vulnerable code, newly introduced secrets, and unsafe patterns; image scanning for any containers the change produces, e.g., the Trivy scanner; and dependency and license policy covering provenance and approved registries. GitHub now applies CodeQL, dependency checks, and secret scanning to supported third-party coding-agent output; organizations running their own workflows would need to build something similar. A failed gate should return structured results to the agent for repair attempts, but repeated failures should stop the task and route it to a person.
- Human merge accountability. “The agent wrote it” is not a defense; whoever merges a change owns it, regardless of who or what wrote it. That accountability only works if change sets are sized for reviewers, which means constraining the agent to small, single-purpose changes with a stated plan, validation evidence, and an explicit description of the risk.
- Provenance recorded, not inferred. Tag agent-generated changes as such, in commit metadata or the change description, somewhere queryable — not to stigmatize them, but because every measurement in the next section depends on being able to compare agent-written and human-written changes, and provenance cannot be retrofitted onto history that did not capture it.
- Branch protection and sensitive-file ownership. The last gate belongs in the repository, not in an agent prompt: agent changes go on a feature branch and are accepted through a pull request only, and the agent cannot approve its own work or merge it. Changes to CI workflows, security policy, dependency manifests, and infrastructure provisioning deserve their own ownership rules, since those are the paths an attacker can use to bypass everything above.
Several of these are the same controls any agent with tool access needs, and they belong in a shared registration, approval, and change-review lifecycle that every team inherits. These controls look heavy on the page, so it is worth being honest about what they cost. Most of it is configuration written once: runner images, an egress allowlist, branch protection rules, a provenance tag. What recurs is real but bounded — small single-purpose change sets take longer to produce than one large one, and the egress allowlist needs maintenance as the work changes. The cost also lands where it should, since it is close to zero at the tiers where a person is already reading every line.
7. Measuring what moved
Most coding-agent rollouts are declared successful on activity metrics: suggestions accepted, lines generated, percentage of code that is AI-written. They measure usage, not value, and vendors favor them for exactly that reason. Even honest measurements of time saved need careful interpretation. A 2026 METR analysis of coding-agent transcripts found substantial apparent savings on selected tasks, but described them as a soft upper bound on productivity, given task selection, lower-value work, specialization, and limited validation. The question becomes not how fast the agent generated code, but how much accepted value moved through the whole delivery system.
Five dimensions answer that question:
- Throughput. The share of agent tasks that produce an accepted change without a human having to finish or rework it, plus cycle time per change measured end to end. Review time belongs inside that measure, because if generation got faster and review got slower, the result may have cost more velocity than it gained.
- Quality. Rework and reverts within thirty days of merge, and defect escape rates, each segmented between agent-written and human-written changes — the comparison that provenance tracking exists to make possible.
- Cost. Model, runner, tool, and review cost divided by changes that actually pass the gate. Count abandoned, timed-out, and killed tasks too, since repeated attempts against the same work item are a cost no dashboard reports by default.
- Attention. Review depth, measured as comments per change and time in review relative to diff size. A collapse in review depth alongside rising volume is the leading indicator of trouble, visible months before the defect data confirms it.
- Succession. Whether junior engineers are still getting the repetitions, tracked as the share of agent-suitable tasks deliberately routed to junior hands, the share of agent-generated change sets reviewed by a junior alongside a senior, and time-to-independence for a newly hired engineer, trended against the pre-agent baseline. The first two are leading indicators you can move next sprint; the third is the outcome, and it moves in years.
That last dimension has external support worth citing to a skeptical exec team. DORA’s 2026 analysis names the mechanism an expertise paradox: AI convenience bypasses the “productive struggle” that builds deep technical skill, and its recommended countermeasure is pairing junior engineers with senior mentors to review AI-generated work. That is a control like any other, and controls without metrics rarely survive a busy quarter.
It is also worth measuring where the gains concentrate, by task type and by seniority. The pattern is usually the one described earlier: large gains on well-specified, well-tested work and modest gains elsewhere. Knowing the distribution tells you where to push and where to hold, which is a more useful output than a single organization-wide percentage.
All of this should be tracked from the start of the rollout, since a baseline you did not capture is a comparison you cannot make. Measurement will tell you whether the velocity gain is real.
8. The generation that never gets the repetitions
The quiet long-term cost of agentic development is paid by the engineers who never get the practice. The work agents absorb first — small features, test scaffolding, routine fixes, the tedious migration — is precisely the work junior engineers have always learned on, because judgment comes from struggling with defects and long debug cycles rather than from reading someone else’s finished solution. Absorb all of it and the arithmetic is unforgiving: in three years the organization has senior engineers who can specify and verify, and a missing generation behind them who never built the judgment to do either. The seniors, meanwhile, are the only people qualified to review the agents, which means the review capacity of the organization is capped by a population that is not being replaced.
This does not resolve on its own, and it is not the junior engineers’ problem to solve. It is an organizational design decision, and it has three parts.
- Train specification and code reading as explicit skills, since specifying work precisely and verifying it are now the job itself.
- Reserve some agent-suitable work for human hands deliberately, accepting the cost as a development investment and defending it when someone proposes optimizing it away.
- Make review apprenticeship structured, with junior engineers reviewing alongside seniors, because review is where engineering judgment is learned. This pairing model has already been used successfully by the Agile XP methodology for software development.
All three are controls, which means all three need the succession metrics from the previous section attached to them. Teams that ignore this type of skills pipeline will discover, too late, that they automated themselves out of a succession plan.
What a defensible rollout looks like
Coding agents have already provided real benefits to engineering organizations, and they can provide more. For that to happen safely the risks need to be regulated, since neither a ban nor benign neglect survives contact with engineers who have already adopted the tools. Three things carry most of that weight: autonomy tiers governed separately instead of under one flat policy, hard boundaries from the delegation tier upward, and outcome measurement with a baseline captured before the rollout begins.
This is not free. At the delegation and autonomous tiers the gates cost real time, and a rollout that claims otherwise loses credibility the first time a team feels it. But the cost is bounded and mostly front-loaded, and done in this order it is what makes aggressive adoption defensible, to your security organizations, to your auditors, and to senior leaders asking whether that velocity was real.
One thing remains outstanding, and it belongs to a named leader rather than to a committee: a rollout spread across platform, security, and individual teams with nobody accountable for the whole is how organizations end up with all of the risk and half of the gains. It is the same accountability gap a board should be probing across every other AI system in the estate, and it has the same answer.
It is still too early to assess what this technology will finally do to the shape of the profession. The compiler did not end programming. It moved the programmer up a level, and the generation that came after argued about what the job had become. Coding agents are doing the same thing, faster, and with rather more of the codebase at stake while the argument is underway. Hopefully, in this version, we remember to bring the juniors up the level with us.
If your organization is adopting coding agents faster than its governance, review practices, or metrics can keep up, I work with engineering leaders to design rollouts that capture the velocity without accumulating invisible debt. Get in touch.