AI Coding Agents Can Write the Code. But Who Controls What Happens Next?

When Agents Can Change Code, the Real Problems Begin

As AI coding agents grow more capable, many teams are moving past the question of "can an agent modify a codebase" and into a deeper one: once an agent has made a change, who should actually control what happens next?

A developer building infrastructure for autonomous coding agents raised this topic on Reddit. Their core observation is telling — the technical conversation has shifted away from whether agents can write code, and toward how the entire engineering process should handle the risks and uncertainty that follow once a change has already been made.

Six Ways Autonomous Agents Can Spiral Out of Control

The original poster outlined several failure modes that autonomous agents can fall into during real-world operation — each one exposing the fragility of relying purely on agent autonomy:

• Infinite retries: The agent loops endlessly, consuming resources without actually resolving the problem.
• Technically correct but business-wrong changes: Code that compiles and passes syntax checks, but is logically wrong from a business perspective.
• Over-permissioning: The agent runs with more access than the task actually requires, expanding the blast radius of any mistake.
• Partial validation passes: Passing one validation step while failing another — single-point checks can't guarantee end-to-end correctness.
• Decision points that require human judgment: Some critical choices simply shouldn't be delegated to an agent.

What these scenarios share is this: the problem usually isn't in the code-writing step itself — it's in everything that happens after the code is written. An agent that can autonomously retry and autonomously commit, without external constraints, can easily carry a plausible-looking mistake all the way into shared or production environments.

Should an Agent Have the Power to Push to Production?

This is the sharpest question the original post raises: should an AI coding agent have the authority to carry a change all the way to shared or production state?

From an engineering governance perspective, the answer leans toward no. Changes to production environments involve stability, security, and accountability. Handing the final "ship it" authority entirely to an automated system that can make technically correct but business-wrong mistakes carries obvious risk. This is why more and more practitioners are arriving at the same conclusion: an agent's capabilities and its authority should be separated. It can generate, modify, and verify code — but the authorization to push to production should be managed independently.

"Technically correct but business-wrong" is one of the hardest failure modes for AI coding agents to detect automatically. Traditional CI/CD pipelines cover formalizable rules well — syntax compliance, unit test passes, code style — but business logic correctness depends on contextual understanding and domain knowledge that test suites can't fully capture. For example, an agent might change a billing module's precision from floating point to integer to eliminate a compiler warning. The code is perfectly valid, all existing tests pass — but the change silently breaks the precision requirements of financial calculations. In a manual code review, an experienced engineer would typically catch this. In an agent-driven commit workflow, without a mandatory human approval gate, such a change can reach production unnoticed. This is precisely why "technical validation" and "business validation" need to be treated as two separate gates by design.

Designing an "Engineering Control Plane" for Agents

The original poster noted that as they built out their infrastructure, the architecture kept pushing them toward a single concept: an engineering control plane for agents. This is a dedicated governance layer — not responsible for writing code, but for managing the boundaries and oversight of agent behavior. It covers:

Identity and Permissions

Establish clear identity and capability/permission boundaries for each agent, ensuring it can only access and operate on resources the task genuinely requires — preventing over-permissioning.

Task Boundaries and Verification

Use task boundaries to constrain an agent's scope of action, and replace single-point checks with comprehensive verification mechanisms to prevent "passes one step, fails another" failure modes.

Retry and Recovery Controls

Centrally manage retries and recovery to prevent agents from getting stuck in infinite loops, with safe rollback paths when failures occur.

Auditability and Human Approval

All agent actions should be auditable, with human approval gates inserted at critical decision points — returning final authority to the engineers.

The essence of this control plane is to layer engineering authority on top of an agent's autonomous execution capability. The agent handles the "doing"; the control plane governs "how far the doing is allowed to go."

The concept of a "control plane" originates in network engineering and cloud computing. In software-defined networking (SDN), the control plane handles routing decisions and policy, while the data plane handles actual packet forwarding. The design philosophy behind separating the two: keep the execution layer efficient, keep the governance layer authoritative. Modern container orchestration systems like Kubernetes follow the same architecture — the control plane (API Server, Scheduler, Controller Manager) manages cluster state and scheduling decisions, while worker nodes simply run containers. Applying this pattern to AI agent governance means explicitly decoupling an agent's "execution capability" from its "action authorization." An agent can have powerful code generation and modification abilities — but every action that affects shared state must pass through the control plane's policy checks and authorization confirmation. This design grants agents autonomy while preserving observability and the ability to intervene.

Where Does the Line Between Autonomy and Engineering Authority Fall?

The question the original post leaves for the community is one of the most representative open questions in the field right now: where do you draw the line between agent autonomy and engineering authority?

This remains an open question without a consensus answer in AI-assisted software engineering. One pragmatic approach is tiered authorization based on blast radius: give agents a high degree of autonomy in personal branches and sandbox environments, letting them fail freely; but as changes move closer to shared codebases and production, the bar for human approval and verification should rise accordingly.

What's worth noting is that this conversation marks a shift in the industry's mindset — from asking "how capable is the agent" to thinking about "how do we safely harness that capability." As code generation itself becomes a solved problem, the truly scarce skill may be the governance, constraint, and accountability systems built around agents.

Conclusion

AI coding agents can already handle the work of writing code. But integrating them safely into real engineering workflows requires far more than a stronger model. Identity, permissions, task boundaries, verification, recovery, auditability, human approval — these seemingly traditional engineering governance elements are being rediscovered as critical in the era of autonomous agents. Who controls the fate of code after it's written will become the central question determining whether AI can truly scale across software engineering.