AI agents in software development: adopt with governance

An AI assistant waits for you to ask. An AI agent is given a goal and acts until it achieves it, or until it gets stuck trying.

This difference is the most important frontier in AI development today. Coding agents don't suggest snippets: they take a task, open the repository, change files, run the tests, read what failed, fix it and open a pull request for review.

The question for those who lead is not whether this capacity exists. It exists and it works. The question is how to adopt it without exchanging productivity for chaos.

What is a coding agent in practice

An agent works in a loop. He receives a goal, plans steps, executes an action, observes the result and decides the next step. Repeat this until you complete or give up.

What differentiates the agent from the assistant is the autonomy over actions. He doesn't just write the code: he runs the command, reads the terminal output, realizes that the test is broken and tries again. You're not stuck in the middle of each iteration.

This allows you to delegate entire tasks. "Migrate this service to the new library version and ensure the tests pass" stops being a script that you execute manually and becomes a request that the agent fulfills, with you reviewing the final result.

It's powerful. And it is precisely because it is powerful that it needs rules.

Where agents perform

Agents shine at well-defined, verifiable, and tedious tasks. The clearer the definition of ready, the better the result.

They pay off in writing tests for existing code, because the criteria is objective: the test passes or not, covers or not. They result in mechanical refactorings that are repeated across dozens of files, the type of change that tires humans and tempts them to lack attention. They result in dependency migrations, syntax updates and correction of errors that appear in the build.

They also benefit from exploring unknown bases. Asking an agent to map out how a feature works, or where a business rule is implemented, saves hours of reading time. The maintenance phase, always the most expensive in long-lasting systems, is where I see the greatest return with the least risk.

The common denominator is simple: task with verifiable success criteria. Where there is a test that says “it worked”, the agent has guidance.

Another characteristic of the tasks in which agents perform is quick feedback. When the agent runs a command and sees the result in seconds, it iterates and corrects it on its own. When the success signal is slow, vague or only appears in production, the loop breaks and the agent is left spinning. That's why it's worth preparing the ground: a base with good tests and fast build extracts much more value from an agent than a base without a safety net, where each error only appears late.

Where agents fail

They fail where the success criteria are ambiguous or non-existent. Architectural decisions, product choices, trade-offs that depend on the business context: none of this has a test that says whether it is right, and the agent will produce something plausible that could be completely wrong for your case.

They fail at tasks that require understanding the why, not just the how. An agent refactors a function to look cleaner, and along the way erases an edge handle that existed for a reason that isn't written anywhere.

They fail silently, and that is the most dangerous risk. The code comes back working, the tests pass, the pull request looks flawless, and the logic is subtly flawed. AI makes mistakes with confidence, and confidence contaminates those who review in a hurry.

And they fail at scale when you trust too much. An agent that opens ten pull requests a day generates ten reviews of dubious quality for a human who remains just one. Without governance, the bottleneck migrates to the exhausted reviewer.

The data that justifies caution

The number that supports this stance is worth repeating. In the 2025 Stack Overflow Survey, with over 49,000 respondents, distrust of the accuracy of AI tools outweighs trust, and only a very small fraction, 3%, strongly trust them.

This skepticism from developers themselves is not resistance to change. It is the experience of those who live with the tool and have seen where it stumbles. A leader who adopts agents needs to design the process based on this reality, not against it.

Trusting little and checking a lot is not a lack of ambition. It's the only responsible way to make the most of what agents have to offer.

How to adopt with governance

Governance here is not bureaucracy, it is the set of rules that let you use agents safely. It starts by defining what can be delegated and what cannot.

Delegate the verifiable and the reversible. Tasks with clear tests, isolated changes, work that a pull request can contain and reverse. Don't delegate the irreversible and critical things without a human in charge: migration from database to production, security configuration changes, changes that affect customer data.

Keep the agent within technical limits. Isolated environments, restricted permissions, no direct access to production, no ability to deploy alone. The agent proposes, the human decides what goes on air. For the detail of how to organize this, I wrote about AI agents in enterprise environments and about governance when adopting these tools in enterprises.

Treat every agent pull request like a pull request from someone new to the team: mandatory review, without exception, with extra attention to logic and not just syntax. And measure the results. If the defect rate goes up or the base becomes more difficult to maintain, the agent is not helping, even if it appears productive.

The human as responsible reviewer

Responsibility is not delegable. When the code goes into production, the person who approved it is the one who responds, not the tool that generated it.

This repositions the engineer. The value stops being in writing each line and becomes in defining the task well, judging the result well and making the decision. It's a more senior role, not less, and it requires more discretion, not less.

The responsible reviewer is the one who understands the code to the point of disagreeing with it. Who notices the erased edge, the wrong assumption, the dangerous shortcut. A team that delegates to agents but maintains strong reviewers gains speed without losing control. A team that delegates and relaxes review is just outsourcing its bugs.

If you're going to introduce agents, start small and verifiable: pick a task with clear tests, let the agent run it, and review it as if it were the work of a new hire. You build governance before you escalate, not after the first incident.

Source: Stack Overflow Survey 2025.