A sane team workflow for AI coding agents

The first time a teammate opened a 1,200 line pull request generated mostly by an agent, the whole review process seized up. Nobody wanted to read it. Nobody trusted it. And the person who opened it could not really explain half of it either. That is the failure mode most teams hit when they bolt AI coding agents onto an existing workflow without changing the workflow itself. The tooling got faster while the human parts stayed exactly as slow, and the gap is where things break.

I have spent enough time shipping with these tools across full-stack and Web3 work to have strong opinions about what a sane setup looks like. None of it is about the model you pick. It is about the guardrails around the model.

An ai coding agents workflow starts with small, scoped tasks

The single biggest lever is task size. Agents are very good at well-bounded work and very bad at sprawling, ambiguous work, which is exactly the opposite of what most people assume. If you hand an agent a vague ticket like improve the checkout flow, you get a mess. If you hand it implement this one function to match this signature and these three tests, you get something reviewable in two minutes.

So the workflow change is upstream of the agent. Break work down the same way you would for a junior engineer you do not fully trust yet. The smaller the diff, the more value you actually get, because review stays cheap and you can reject a bad attempt without losing an afternoon.

The human still owns the diff

This is the rule I will not bend on. Whoever opens the pull request owns every line in it, full stop. Generated does not mean exempt. If you cannot explain why a line is there, it does not go in. The moment a team accepts I do not know, the agent wrote it as an answer in review, the codebase starts rotting and nobody can debug it six months later.

In practice this means the agent is a drafting tool, not an author. The engineer reads the output, deletes what is wrong, tightens what is sloppy, and takes responsibility for the result. The pull request author field is a human name for a reason.

Tests and types are your cheapest defense

Agents will confidently write code that compiles and is also wrong. The fastest way to catch that without burning human attention is to make the machine prove its own work. A strong type system and a real test suite turn a lot of subtle agent mistakes into loud, immediate failures.

I lean hard on a few habits here:

• Write or sketch the test before the agent writes the implementation, so there is an objective target it has to hit
• Keep the type checker strict so hallucinated APIs and wrong shapes fail at compile time, not in production
• Run the full suite locally before the PR ever exists, not as a CI surprise
• Treat a green build as the start of review, never the end of it

Keep agents out of the parts that need judgment

There are zones where I do not let agents drive. Auth boundaries, money movement, anything touching user data deletion, schema migrations on a live table. Not because an agent cannot write that code, but because the cost of a subtle wrong assumption is enormous and the review burden is exactly the part you cannot shortcut. In those areas the agent can suggest, a human writes.

The flip side is where they earn their keep: boilerplate, test scaffolding, repetitive refactors across many files, first drafts of glue code, translating a clear spec into a clear implementation. That work is real, it is a big chunk of any week, and offloading it is a genuine speedup.

Make the agent context part of the repo

One thing teams skip: the agent is only as good as the context it gets, and that context should not live in one person's head. I put the project conventions, the architecture notes, the do-not-touch list, and the common patterns into files the agent reads automatically. That way every engineer on the team gets the same quality of output, and the rules are version controlled like everything else.

When a reviewer keeps catching the same mistake, the fix is not to nag people. It is to write the rule down where the agent will see it next time. The workflow gets better as a system, not as a pile of individual heroics.

The point is throughput you can trust

A team that uses agents well does not ship more code. It ships the same amount of code with less drudgery and more attention left over for the hard parts. If your agent setup is producing huge diffs nobody reads, you have made things worse, not better. Keep the tasks small, keep humans accountable, let the machine prove its work, and the speed shows up where it should.