How 102 Review Comments Taught Me to Treat Coding Agents Like Teammates

Coding agents are most useful when we stop treating them like tools that should magically produce perfect work, and start treating them like junior teammates: capable, fast, sometimes wrong, and much better with clear context, feedback, and review.

After working with coding agents for almost a year, I've watched them become more capable, more autonomous, and more deeply integrated into my workflow.

But the biggest improvement hasn't come from better models alone. It has come from changing how I work with them.

I get better results when I treat agents less like autocomplete and more like teammates.

1. Give them context like you would a teammate

Imagine a new colleague is joining your development team. You wouldn't just hand them a task and expect perfect results. You would prepare onboarding materials, explain how the team works, and give them the context they need to be effective.

That context might include company-level information, like working hours and team rituals, as well as project-level details: the tech stack, repositories, review process, communication style, and the parts of the system they should be careful with.

Coding agents need the same kind of context.

What are we trying to accomplish? And where can it find more about the task?
What constraints matter?
Where can it find more information about internal APIs?
How and where can it access other repos?
What files or systems are relevant?
What should they avoid changing?
What does "done" look like?

There is one difference, though: a teammate holds context in their head. An agent holds context in what you give it. So the best thing you can do is make your context an artifact.

I learned this with pyfr, a Python service template I had parked for two years. At my day job I had built templates like it, but I never had the time budget for a side-project version. When I finally picked it up with Claude Code, we didn't start with code. We brainstormed a plan for the whole project and its milestones, and we committed that plan to the repo. From then on, the plan was part of the agent's context in every session. I didn't have to re-explain anything.

Context that lives in the repo survives context windows, new sessions, and your own memory decaying over a weekend.

Example:

Don't just say: "Fix this bug."

Say: "This bug happens when a user refreshes the checkout page. The issue is likely in the cart hydration logic. Please inspect the relevant files first, explain the cause, then suggest a minimal fix."

Or: "Fix the bug, and get more information about it from this GitHub issue: https://www.github.com/EmadMokhtar/demo/issues/1"

2. Assign scoped work, not vague wishes

Agents do better with clear, bounded tasks. You wouldn't tell a new teammate "make the codebase better" on their first day. You'd give them a ticket with a boundary, because a boundary is also a definition of done — and without one, neither of you can tell whether the work finished or failed.

Good tasks:

"Refactor this function without changing behavior."
"Add tests for these three edge cases."
"Find where this API response is parsed."
"Draft a migration plan before touching code."

Risky tasks:

"Clean this up."
"Make it better."
"Fix the app."
"Implement the feature."

I've paid for vague tasks more than once. I once asked an agent, in two sentences, to build a dashboard that filters and tracks property states. It built a dashboard. It was not the dashboard I wanted. The vagueness didn't make the work faster; it just moved the cost — instead of five minutes of thinking up front, I spent a much longer loop of "no, like this, not like that."

3. Ask for plans before execution

This is the habit that changed the most for me.

Before letting an agent make changes, ask it to describe its plan. This helps you catch:

misunderstood requirements
risky assumptions
unnecessary rewrites
missing edge cases
changes outside the intended scope

Prompt pattern:

First inspect the code and propose a plan. Do not edit files yet.

The dashboard story above ended here: after the back-and-forth, I realized I had skipped Plan Mode and just told it to start building. That was the mistake. The agent did exactly what I asked — I had simply asked for a guess.

Contrast that with pyfr. Because we had brainstormed the whole plan up front, the actual build was smooth and fast — about three weeks, on a project I had been parking for two years. During execution, I could leave the agent working for hours without my input, because we had already thought through what we needed to build.

Yes, brainstorming with the agent takes time and energy. It feels like a tax. It is not a tax; it is the investment that buys the autonomy afterward. You pay the thinking cost once, up front, instead of paying the correction cost repeatedly, later.

4. Review their work like a pull request

Treat agent changes the same way you would treat a teammate's pull request.

Check for:

correctness
simplicity
unintended side effects
consistency with existing patterns
tests
security and privacy issues

Agents can move quickly, but speed does not remove the need for judgment.

Here is the uncomfortable truth I discovered: agent output that looks right is often not right. When I built email-mcp-go — a Go MCP server for email — I did it fast and without a plan, quick-and-dirty on purpose. GitHub Copilot's code reviewer left 102 comments on that first PR. Email identification bugs, transport security issues, authentication problems, documentation defects. A hundred and two. The code compiled, it ran, and it looked like a teammate's solid first draft. It wasn't.

This happens even on disciplined projects. On the first PR of pyfr — built with a plan and scoped milestones — the reviewer still caught things like domain invariant corruption, misclassified server errors, healthcheck drift, and incomplete logging.

The lesson is not "don't trust agents." It is that review is where trust is earned, for humans and agents alike.

5. Give feedback and iterate

If the first answer is wrong, don't just abandon the agent. Correct it.

Examples:

"This changes too much. Try a smaller patch."
"Use the existing pattern in X instead."
"You missed this edge case."
"Explain why this dependency is necessary."
"Keep the public API unchanged."

Like a teammate, an agent performs better when feedback is specific. "This is wrong" teaches it nothing. "This is wrong here, for this reason, do it like this" is a code review comment — and it works the same way with an agent as it does on a PR.

6. Don't outsource ownership

Treating agents like teammates does not mean trusting them blindly. It also doesn't mean the tooling can take the blame. When Copilot reviews my agent's PR and catches 102 defects, that's a machine reviewing a machine — useful, fast, tireless. But neither of them decided to merge, and neither of them will answer for it in production.

You are still responsible for:

the product decision
the architecture
the code that gets merged
the user impact
the final judgment

The agent can help you think and move faster, but it should not replace your responsibility.

7. Build team habits around agents

Teams should agree on norms for using agents.

At companies I've worked with, we used an RFC process for medium and large changes: write the proposal, review it together, then start the work. It's the same discipline as engineers reviewing the 2D plans of a building before construction starts — modifying the plans is cheap; modifying the built structure is not. The RFC process did two things at once: it spread context and knowledge across the team, and it let people catch gaps and issues before anyone wrote a single line. If you want a practical guide to running this process, Juan Pablo Buriticá's 6 lessons I learned while implementing technical RFCs as a management tool is the best I know — he treats RFCs as a decision-making tool that keeps teams aligned, async, and included, which mirrors exactly what we got from it.

Agents make this habit more valuable, not less. When an agent can implement a feature in an afternoon, the bottleneck is no longer building — it is deciding WHAT to build, and catching bad decisions early. That's exactly what a written, reviewed plan is for.

This is why I'm a fan of the Superpowers brainstorming skill: it makes the agent brainstorm with you, then write a design doc that you must read and approve before any implementation starts. It is, in effect, an RFC process between you and the agent — and the resulting doc doubles as shared context for the team.

Other norms worth writing down:

Agents can draft code, but humans review it.
Agent-generated code must follow the same testing standards.
Prompts and useful workflows should be shared.
Risky areas need extra human review.

These sound obvious written down, but they fail quietly in practice — someone merges a large agent diff without a review "because it was just scaffolding," and that's how the norms die. Write them down and hold each other to them.

Conclusion

Coding agents are not magic. They are also not just fancy autocomplete.

The most productive mental model I've found is to treat them like fast, eager teammates: give them context, assign scoped work, ask for a plan, review their output, and stay responsible for the result. Invest the thinking time up front, and the build becomes smooth and autonomous. Skip it, and you pay the cost later — in back-and-forth, in rework, in 102 review comments.

The future of software development may not be humans versus agents. It may be humans learning how to collaborate with them well.