AI coding tools have moved quickly from autocomplete to something much closer to delegation.

A few years ago, an AI coding assistant might suggest the next few lines of code or help explain an error. Today, coding agents can inspect a repository, modify multiple files, run tests, investigate failures, and return a pull request for review.

OpenAI's Codex, for example, can handle features, refactors, migrations, code review, and other engineering tasks, while supporting multiple agents working in parallel. GitHub has taken a similar approach with its coding agent, which can work on issues, make changes, run tests, and open pull requests.

That changes the conversation around AI-assisted development.

The interesting question is no longer whether AI can write code. It clearly can.

The more useful question is what can a coding agent actually take responsibility for, and where does the engineer still need to be involved?

From assistant to agent

The difference between an AI assistant and an AI coding agent is largely about how much of the workflow the system can handle on its own.

An assistant usually waits for an engineer to ask for something: write a function, explain an error, generate a test, suggest a refactor.

An agent can be given a broader objective and work through several steps to get there.

Imagine an engineer opening an issue because an API is returning inconsistent results. A traditional coding assistant can help investigate the problem once the engineer starts asking questions.

A coding agent can potentially inspect the relevant code, trace the request through the application, identify a likely source of the problem, make a change, run the relevant tests, and return the result for review.

That distinction matters because the agent is operating across a workflow rather than answering isolated prompts.

It is part of a broader shift toward agentic systems. Our article on Artificial Intelligence and the evolution toward agentic systems looks at this progression, from systems that primarily generate content toward systems capable of taking actions and working through multi-step tasks.

Software development happens to be a particularly good environment for this evolution. Codebases provide a defined environment, development tools provide ways to interact with it, and tests provide at least some way of checking whether the work produced the expected result.

That makes coding a natural place for AI agents to move from suggestion toward execution.

The strongest use cases today tend to be tasks where the agent has enough context to work independently and where the result can be verified.

Routine changes are a good example. An agent can update a dependency across a codebase, make the corresponding changes, run tests, and prepare a pull request. It can add tests to an existing function, fix straightforward bugs, clean up repetitive code, or help with a framework migration.

More complex work is possible too. OpenAI describes Codex being used for features, complex refactors, migrations, and longer-running engineering tasks.

That doesn't mean an agent should be handed an entire project and left alone.

A well-scoped change inside a familiar codebase is much easier to delegate than a problem involving undocumented business rules, unclear requirements, or architectural decisions that affect multiple systems.

The quality of the result still depends heavily on the context available to the agent.

A coding agent doesn't automatically understand why a system was designed the way it was. It can inspect the repository, but important decisions may exist in documentation, customer requirements, team knowledge, or years of accumulated technical history.

That is where engineering judgment still matters.

The engineer becomes the supervisor

As agents become more capable, the engineer's role starts to change.

Instead of manually executing every step, the engineer increasingly defines the task, provides context, sets constraints, reviews the work, and decides what happens next.

That introduces a different kind of engineering problem.

What should the agent be allowed to access?

Which actions can happen automatically?

When should a human approval be required?

How do you know what the agent actually changed?

What happens when it gets stuck?

What happens when it confidently makes the wrong decision?

These questions become more important as agents move beyond local development and into shared repositories, CI/CD pipelines, cloud environments, and eventually production systems.

This is where coding agents start to overlap with the concerns of AgentOps. Once an AI system is acting rather than simply generating an answer, teams need ways to observe, govern, and troubleshoot those actions. Our article on AgentOps explores that operational layer in more detail.

The same principle applies to the broader engineering system around the agent.

DORA's 2025 research describes AI as an amplifier of an organization's existing strengths and weaknesses. Teams with strong internal platforms, clear workflows, good version control, and healthy testing practices are better positioned to capture the benefits of AI.

That is an important distinction. An agent can make an engineer faster, but it cannot fix an unclear requirement or a fragile deployment process simply by generating more code.

In fact, faster generation can create a new bottleneck.

DORA's research has found that AI can increase software delivery throughput while also increasing instability when teams generate larger changes that take longer to review. Its research suggests that the gains from faster development need to be supported by practices such as small batch sizes and strong testing.

This is why the quality of the engineering environment matters so much.

What coding agents can actually change

The biggest shift may not be that engineers write less code. It is that the unit of work they delegate can become larger.

For a long time, the basic unit of software work was a ticket, a bug, a feature, or a pull request. An engineer would take that task, work through it, and eventually submit the result.

With agents, an engineer can increasingly delegate an objective.

Investigate this issue. Update this dependency across the repository. Add coverage for this part of the application. Migrate this component. Find why this service is failing and propose a fix.

The agent can research, implement, test, and iterate before returning something for human evaluation.

That doesn't remove the engineer from the process. It changes where their attention goes.

More time can go toward defining the problem, providing context, evaluating the result, and deciding what should happen next. Less time may be spent on repetitive implementation work.

This is also where the idea of an AI Software Factory starts to become interesting. Coding agents are one component of a broader shift in how software can be planned, built, tested, and maintained. The technology is moving from individual productivity tools toward engineering workflows designed around AI from the beginning.

The organizations that benefit most won't necessarily be the ones that give engineers access to the most agents.

They will be the ones that figure out where autonomy actually helps, where human judgment is still essential, and how the two can work together without creating a new layer of complexity.

Coding agents are getting very good at doing software work.

The harder part is deciding which work to give them, how much autonomy to allow, and how to know when the result is good enough to ship.