AI Coding Agents for Software Teams: Where Humans Still Matter

What agents are genuinely good at

Stripped of hype, current agents are strong at bounded, well-described work in a codebase they can read: reproducing a described defect, making a mechanical change consistently across many files, writing the missing test, following conventions that are documented in the repository, and summarising what they did.

They are correspondingly weak at anything requiring context that is not written down. Business rules that live in someone's head, the reason a strange workaround exists, a client relationship that makes one approach politically impossible. An agent will produce a confident answer to those too, which is exactly the risk.

One job per agent beats one agent doing everything

A single agent asked to "fix this ticket" makes its plan, its implementation and its assessment of its own work in one continuous stream, which means the review is performed by the party with the strongest incentive to declare success. Splitting the work into stages with different responsibilities gives you checkpoints a human can inspect.

The planner stage earns its keep more than people expect. Most agent failures are not bad code, they are correct code for the wrong problem, and a plan on the ticket catches that for the price of a cheap model call. Suporta's planner works exactly this way, read-only by design.

Why an agent should not press merge

This is the one constraint worth being inflexible about, and the reasons are practical rather than philosophical.

• Accountability does not transfer. Your contract with the client says you are responsible for the code you ship. "The agent approved it" is not a defence anyone will accept, including your own insurer.
• Green tests are not the same as correct. A passing suite proves the things you already thought to check still work. Most expensive defects are in the space nobody wrote a test for.
• Self-approval is not review. If the thing that wrote the change also decides it is good, there is no second opinion anywhere in the process.
• The blast radius is asymmetric. A missed review costs a code review. An unreviewed merge to a client's production system costs the relationship.

The cost of keeping a human at the merge is one code review per change, which you were doing anyway. The cost of removing them is unbounded, and payable at the worst possible moment.

What the review agent should hand you

An approval with no evidence is just an opinion. A useful reviewer states what it did, so a human can decide how much of the change still needs their attention.

It also matters that the reviewer approves under its own identity rather than as the author, so nothing in your history shows a change approving itself. That is a small implementation detail with a large audit consequence.

The guardrails worth setting before you start

Autonomy is only safe in proportion to the controls around it. Every item here should be a setting you own, not a promise from a vendor.

1. 1A switch per agent. Turn any stage off for the whole organisation, and have that switch respected regardless of who or what started the run.
2. 2A model per agent. A capable model for planning, a cheap one for documentation review. Cost and quality are not the same dial for every stage.
3. 3A monthly budget. A ceiling in your own currency with a warning before it and a hard stop at it. See controlling AI development costs per client.
4. 4Explicit command permissions. An agent should run the commands you approved and nothing else.
5. 5Scoped write access. Reading the whole codebase is useful. Writing to all of it is not necessary.
6. 6A needs-a-human queue. Everything ambiguous ends up in one place instead of stalling silently.

Where to start, realistically

The instinct is to point agents at the hardest ticket to see what happens. That produces a good story and a bad decision. Start where checking the output is cheap.

• Well-described defects with reproduction steps, in a codebase with tests. The archetype of a checkable task.
• Mechanical changes across many files: a renamed field, a deprecated call, a version bump with consequences.
• Test coverage for code that already exists. Low risk, visible benefit.
• Documentation drift. Cheap, constant, and nobody enjoys doing it.

Hold back on anything touching money, authentication, permissions or data migration until you have seen enough runs to know the failure modes. Those are the areas where a plausible-looking wrong answer is most expensive.

What actually changes for the team

Not headcount. The work shifts rather than disappears: less time typing implementations of well-understood changes, more time specifying problems precisely and reviewing changes carefully. Ticket quality becomes the bottleneck, which is why the intake step matters so much — see turning client emails into developer-ready tickets.

Two habits are worth protecting deliberately. Junior developers still need to write code that an agent could have written, because that is how judgement is built. And reviews must stay real: an agent-authored pull request that gets a rubber stamp is strictly worse than no agent at all, because the appearance of review has been added to an unreviewed change.