For years, AI in software development has been about assistance: autocomplete, code generation, refactoring suggestions, and tools that help developers work faster. The developer still makes the decisions, reviews the output, and moves the change through the delivery process.

That model is starting to change. Agentic coding for enterprise teams moves AI from generating suggestions to taking action. An agent can plan an implementation, write code, run tests, respond to failures, and create a pull request with limited human intervention.

And this isn’t just theoretical. Morgan Stanley, for example, built DevGen.AI to help engineers analyze and modernize legacy code. The system has reportedly reviewed around 9 million lines of code and saved more than 280,000 developer hours; not by replacing developers, but by taking repetitive analysis work off their plate.

The bigger shift is what happens when agents move beyond assistance and start operating across the software delivery workflow. If a human is no longer approving every transition, where does that control move?

For enterprises, the answer can’t simply be another human checkpoint. It has to be built into the engineering architecture: scoped permissions, automated verification, policies, observability, and controlled deployment.

That is what makes agentic coding an enterprise engineering problem, and not just a new way to write code.

Morgan Stanley Shows What Enterprise AI Coding Can Already Do

Enterprise AI coding does not begin with fully autonomous software delivery. Morgan Stanley’s use of DevGen.AI is a useful example of an earlier stage: AI-assisted analysis of legacy systems.

The internal tool was used to analyse legacy code and translate it into specifications that engineers could use during modernization. According to company-reported estimates cited by reporting on the tool, it analysed roughly 9 million lines of code and saved more than 280,000 developer hours in 2025.

DevGen.AI demonstrates how AI can absorb large volumes of repetitive analysis while engineers retain responsibility for modernization decisions and validation. It is therefore better understood as an example of AI-assisted engineering rather than autonomous production deployment.

Agentic coding takes that model further by allowing AI systems to execute more steps of the development workflow themselves.

Agentic Coding Is a Different Level of Autonomy

The difference between AI-assisted and agentic development isn’t simply how much code AI can generate. It is how much of the engineering process the system is allowed to execute on its own. That distinction becomes important when moving from experimentation to enterprise adoption.

Let’s understand the difference between agentic coding and AI-assisted coding:

AI-assisted coding keeps the developer in the execution loop

The developer remains responsible for moving the work forward:

• Prompt: Developer asks AI for code, a refactor, or debugging help.
• Generate: AI produces a suggestion or change.
• Review: Developer evaluates the output.
• Decide: Developer determines what gets accepted.
• Execute: Developer commits the change and moves it through CI/CD.

The key point: AI assists with individual tasks, but the developer controls what happens next.

Agentic coding delegates the execution loop

The agent can take responsibility for multiple steps in sequence:

• Understand: Interprets a ticket, task, or objective.
• Inspect: Examines the repository and identifies relevant files.
• Plan: Determines an implementation approach.
• Build: Modifies files and writes the required code.
• Test: Runs commands and executes tests.
• Iterate: Diagnoses failures and revises its own changes.
• Submit: Creates a pull request and, in some setups, can merge or trigger deployment.

The key point: The developer moves from executing every step to defining the objective, setting boundaries, and reviewing the outcome.

The real variable is autonomy

It helps to think of this as a spectrum rather than a binary: suggest, execute, test, create a pull request, merge, deploy. Each step to the right increases the consequences of a wrong decision, because the agent is acting with less human review standing between it and production.

The shift isn’t simply about generating more code faster. It’s about delegating more decisions and more actions, and every enterprise adopting it has to decide, deliberately, how far along that spectrum it’s comfortable operating.

What Changes When the Human Gate Disappears?

A human reviewer sitting in the approval loop does more than check whether code looks correct. That person validates intent, applies architectural judgment, catches security issues, checks the change against business context, assesses risk, and takes on accountability for the decision to ship.

When that gate is reduced or removed, those functions don’t disappear. They have to go somewhere else. Some become deterministic, automated controls; others still require a person, which is the core design question behind any agentic coding for enterprise rollout.

The point of this table isn’t that human judgment becomes unnecessary. It’s that enterprises need to work out, deliberately, which decisions can be converted into deterministic controls that a system enforces every time, and which decisions genuinely still require a person with context to make the call. Agent identity and execution logs provide traceability, but they do not replace ownership of the engineering decision.

Production Readiness for AI Coding Agents

Passing tests is necessary, but a green test suite alone does not make an autonomous agent’s output production-ready. An agent can produce working code while introducing security, architectural, or operational issues, especially when it touches production systems.

A production-ready change needs to pass four checks: it must work as intended, remain secure, fit the existing architecture, and behave reliably under real operating conditions.

Verification should also be independent of the agent that produced the change. If an agent can modify both the code and the tests or checks used to validate it, a green CI result may not provide enough evidence of correctness. Existing tests, security checks, approval policies, and CI/CD configurations should therefore be protected from unauthorised modification, with security-critical changes subject to additional review and independent validation.

1. Functional correctness

This is the layer most testing already covers: does the code do what the ticket asked for, verified through unit tests, integration tests, regression tests, and end-to-end tests.

2. Security correctness

Functional correctness says nothing about whether the change introduces a vulnerability, leaks a secret, pulls in an insecure dependency, opens an injection path, escalates privileges it shouldn’t have, or calls an API in an unsafe way. These require dedicated scanning, not just functional test coverage.

3. Architectural correctness

An agent can satisfy a ticket’s literal requirements while still making a poor system-level decision, like:

• Crossing a service boundary it shouldn’t touch
• Introducing unnecessary coupling between components
• Bypassing an established pattern the rest of the codebase follows
• Adding technical debt
• Creating a scalability problem that won’t surface until the system is under load.

4. Operational correctness

Code that passes its tests in isolation can still behave badly under real operating conditions: load, transient failures, retries, concurrency, unexpected input, or a partial outage of a dependency. Testing for these conditions is a different exercise than testing for functional correctness, and it matters more, not less, as agents take on a larger share of implementation work.

Managing the Risks of Autonomous Coding Agents

Autonomous coding agents risk isn’t well served by a generic list of “AI risks.” It’s better understood by asking a narrower question: what is this particular agent technically capable of affecting if it makes a mistake?

Low-risk changes, like documentation, formatting, test generation, routine maintenance, can reasonably run with higher autonomy, because a mistake in one of these areas is cheap to catch and cheap to reverse.

Medium-risk changes, such as business logic, internal APIs, refactoring, and dependency changes, need stronger automated verification before they’re allowed to progress unattended.

High-risk changes, like authentication, authorization, payments, database migrations, production infrastructure, security controls, and anything destructive, generally warrant explicit human approval regardless of how capable the agent is, because the cost of a mistake is high and often not easily reversible.

Sorting changes this way is really the practical core of managing autonomous coding agents risk: the categories rarely change, even as the agents themselves get more capable.

Autonomy should be proportional to blast radius, not model confidence.

That principle is worth treating as a design constraint rather than a slogan. A highly capable agent operating on a high-blast-radius change still needs the same controls a less capable agent would need, because the risk being managed is the size of the potential failure, not the likelihood the agent gets it right.

This is the kind of control-plane architecture Ariel Software Solutions can help engineering teams evaluate and design: defining where AI agents can operate autonomously, where controls need to intervene, and how those boundaries fit into the wider engineering environment.

The New Attack Surface: The Agent Can Read and Act on More Than Source Code

An autonomous coding agent doesn’t only process the source files it’s editing. It may also read README files, issue descriptions, documentation, configuration, scripts, third-party dependencies, and instruction files meant to guide its own behavior. Every one of those inputs is a potential vector for influencing what the agent does next.

1. Prompt injection becomes an engineering-security problem

Content the agent reads as context, rather than code it’s explicitly asked to write, can shape its behavior unintentionally.

A manipulated issue description, poisoned repository instructions, a compromised dependency, or a malicious script could, in principle, steer an agent’s actions if it treats that content as trustworthy input.

This deserves careful engineering attention rather than dismissal or exaggeration; the specific outcomes depend heavily on what tools and permissions the agent has been given.

2. Tool access determines the severity

There’s a meaningful difference between an agent that can only suggest code for a human to review and an agent that can execute shell commands, access credentials, modify repositories directly, and interact with deployment systems.

The more tools and permissions an agent holds, the larger the blast radius if any of those inputs successfully manipulates its behavior.

The security boundary here isn’t just the model itself; rather, it’s the entire environment the agent is permitted to act within, including every credential, tool, and system it can reach. Getting this boundary right is one of the less obvious but most consequential parts of any agentic coding for enterprise security review.

3. Protect source code, credentials, and model access

Enterprise controls also need to cover what the agent can send, read, and access during execution. Sensitive source code should only be exposed to approved model providers and within defined data-handling policies. Agents should receive task-scoped, short-lived credentials where possible, with unnecessary production secrets kept outside the runtime environment.

Network access should also be restricted to the systems required for the task, while logs and agent traces should redact credentials, tokens, and other sensitive information.

Don’t Put the Human Back in Every Loop. Move the Human Up the Stack.

Manual approval for every agent action would reduce much of the efficiency gained from delegation. A better division of responsibility is straightforward: humans define objectives, architecture, risk tolerance, permissions, and approval requirements; agents execute implementation, debugging, maintenance, and testing within those boundaries; automated systems enforce the rules.

Human oversight therefore shifts from approving individual actions to governing the system in which those actions take place

Build a Control Plane Around the Agent

This division of responsibility only works if it’s backed by real architecture, not just a policy document. A practical control plane, moving top to bottom, looks like this:

• Human intent defines the objective
• Agent orchestration breaks it into steps
• An isolated sandbox contains what the agent can touch
• The agent works against the repository and a defined set of approved tools
• Automated verification runs tests, security scanning, dependency scanning, and architecture checks against its output
• A risk and policy layer decides what happens next based on the type of change
• CI/CD enforces the rules for progression
• Staging and production apply environment-specific permissions
• Observability plus rollback sit underneath it all, ready to catch a bad outcome.

Each layer does a specific job, and together they mean the agent never operates without something checking its work. The key principle is that the agent should not be the control system, instead, the agent should operate inside the control system, with deterministic checks constraining what a fundamentally probabilistic system is allowed to do unsupervised.

This control plane, more than any single tool, is what makes governed agentic development possible.

CI/CD Becomes More Than a Delivery Pipeline

As agents take on more autonomous work, CI/CD stops being purely a mechanism for shipping software and starts functioning as a governance and enforcement layer. This is where those governance principles become operational.

1. Build deterministic gates around probabilistic systems

That layer typically includes automated tests, static application security testing, dependency scanning, secret detection, infrastructure policy checks, compliance checks, and deployment rules. None of these are new ideas in CI/CD. What changes is how load-bearing they become once an agent, not a person, is proposing the changes.

2. Separate agent freedom from production authority

Environment-based permissions are the mechanism that keeps this manageable: broad freedom in development, restricted actions with heavier verification in staging, and tightly controlled permissions in production. The agent can operate with real freedom in a sandbox while holding almost no direct authority over production systems.

3. Build recovery into the autonomy model

Autonomous workflows need tested recovery mechanisms, including version control discipline, immutable builds, canary releases, feature flags, and deployment rollback where reversal is possible. Some failures require separate recovery plans, particularly for database migrations, exposed data, or irreversible external actions.

The Goal Isn’t Fully Autonomous Software Development

The question worth asking isn’t whether AI agents will eventually do all the coding. It’s which engineering decisions genuinely require human judgment, and which can be safely handed to a system that enforces the same standard every time without fatigue or inconsistency.

The future this points toward isn’t humans or AI as competing alternatives. It’s a division of labor: humans define the boundaries, agents execute within them, and systems enforce them consistently. The enterprises that get agentic coding for enterprise adoption right won’t necessarily be the ones that hand AI the most autonomy. They’ll be the ones that build the strongest architecture around whatever autonomy they choose to give it.

Frequently Asked Questions

1. Can AI coding agents work with legacy enterprise systems?

Yes. In fact, legacy modernization is one of the more practical enterprise use cases for coding agents because agents can analyse large codebases, identify dependencies, generate documentation and assist with code transformation. However, legacy systems often contain undocumented business rules, so enterprises should validate agent-generated changes against functional requirements and existing system behaviour.

2. How much autonomy should an enterprise give an AI coding agent?

There is no universal autonomy level. It should depend on the risk and blast radius of the task. An agent might be allowed to autonomously update documentation or generate tests, while changes involving authentication, financial transactions, production infrastructure or sensitive data may require additional controls or human approval.

3. Can AI coding agents be trusted to make production changes?

They can be trusted with selected production workflows when the surrounding system provides strong controls. Trust should come from verification, restricted permissions, automated policies, observability and rollback mechanisms, rather than assuming the model will always make the right decision.

4. What infrastructure does an enterprise need before deploying coding agents?

Enterprises don’t necessarily need an entirely new technology stack. They do need a controlled environment around the agent, including secure repository access, identity and permission management, isolated execution environments, CI/CD pipelines, automated testing, security scanning, monitoring and rollback capabilities.

5. What happens when an AI coding agent makes a mistake?

The system should be designed so that a single agent error does not automatically become a production incident. Isolation, automated verification, permission boundaries, deployment policies, monitoring and rollback should limit the agent’s blast radius. For higher-risk workflows, the system should escalate the decision rather than allowing the agent to proceed.

6. Should enterprises build their own AI coding agents or use existing platforms?

It depends on the level of customisation and control required. Existing coding-agent platforms can accelerate adoption, while highly regulated or specialised environments may benefit from building additional orchestration, security, evaluation or governance layers around an existing model or agent. The important decision is not simply which model to use, but how much of the agent’s behaviour the enterprise needs to control.