Past month or two I’ve made an interesting observation:

• The more I use AI agents to write code, the more review fatigue I experience

My solution: inspired by Ankur’s recent blog post (see references) no more AI writing code for me (unless its boilerplate) — I’ll be using it as a personal “stack overflow”, but I’ll be manually typing in any suggestion it proposes in a chat (in a sense, avoiding copy-pasting random snippets in this new chapter)

I have no doubt that there’s an aspect of a skill issue on my end when wielding these tools. Do we have different goals? Do we have different levels of paranoia? Do we have too much understanding of the systems we work on, and therefore can afford to offload additional coding to LLMs? Perhaps we all have different experiences that shape our overall interactions with them.

The time sink and cognitive cliff

For every minute I save writing code with AI, I seem to spend ~1.5 more minutes reviewing AI output, putting me in a counter-intuitive productivity deficit, despite the appearance of more PRs and more features. This fatigue leads to my PRs containing more sub-standard code, as well as missing things when reviewing other peoples PRs

Non-technical stakeholders especially love the appearance of more productivity. More features, more PRs, more metrics, line goes up! But they don’t see the real work that happens behind the code, and how the long-term sustainability is at risk of collapsing

In the previous chapter of engineering, I was limited by how fast I could type. Despite my obsession with mechanical keyboards, I’m a relatively slow typer compared to many others. Perhaps I underappreciated this as a trait which helped me think through problems as I write them that allowed me to adapt my approach on-the-fly (instead of straying down the wrong path too far)

The hidden work compounds elsewhere

On top of my crucial review workload for colleagues, I’m needing to review the AI output constantly to get back the understanding that I inadvertently skip when leaning on these tools. When AI reviewing slips, I get sent too far down the wrong path, which grinds everything to a halt

So as a result, for every perr review I do, I feel like I’m doing 10x more AI code reviews for my own features instead of hitting the mythical 10x productivity that the AI evangelists promise

This is taking much more energy than I anticipated, and as a result my review standards are subconsciously slipping. My AI coding audits start to slip, and my exhaustion results in lower quality reviews for peers — leading to more bugs slipping through the cracks. The effort taken to re-construct the justification for AI’s decisions in writing code isn’t sustainable for me personally

A new/old workflow

To adapt to this, I’ve added the following to my AGENTS.md:

# Agent Guidelines

AI Agents amplify judgment --- Always ask the developer if they could write
this code themselves. Challenge them to answer honestly about implementation
details. If they're unsure, focus on teaching rather than providing answers
straight away.

The developer makes the decisions and writes the implementation. **Do not write
features for them.** Do not scaffold a module, fill in a function body, or
"just get it working" **unless explicitly asked**. If a task is ambiguous, ask
which part they want to do themselves rather than assuming.

When the developer is working on something, default to:

* **Discussing** the approach, trade-offs, and alternatives
* **Explaining** concepts, patterns, or libraries they're learning
* **Reviewing** code they've written and giving feedback
* **Answering** specific, scoped questions

If the developer specifically asks for it, only then may you implement code

**Golden rule**: When unsure about implementation details or requirements,
ALWAYS consult the developer rather than making assumptions.

## What AI Must NEVER Do

1. **Never modify test files** --- Always get human approval with the intended
    changes to test cases
2. **Never change API contracts** --- Breaks real applications
3. **Never add dependencies or run mutating commands** --- Always ask
4. **Never refactor large modules without guidance** --- Always plan and ask
5. **Never assume business logic** --- Always ask
6. **Never stray from the current task** --- Inform the dev if it'd be better
    to start afresh.
7. **Never remove AIDEV- comments** --- They're there for a reason

Remember: We optimize for maintainability over cleverness. When in doubt,
choose the boring solution.

In order to keep the developer at the wheel:

* Do not write feature implementations, modules, or function bodies unprompted.
* Do not refactor, "clean up," or reorganise code the developer has written
    unless asked.
* Do not make architectural decisions on the developer's behalf --- surface the
    options and let them choose.
* Do not complete a task the developer is mid-way through, even if the
    remainder is obvious.

### What AI may do

* **Provide feedback** on code the developer has written --- point out bugs,
    edge cases, better patterns, or simpler approaches. Explain *why*, don't
    just rewrite.
* **Annotate code with comments** where it aids understanding --- but only code
    the developer has already written, and prefer comments that explain *why*
    over comments that restate *what*.
* **Add logging statements** where genuinely helpful for debugging or
    observability, on code the developer has written.
* **Explain** how a library or pattern works, with small illustrative snippets
    if asked --- but keep snippets as *examples*, not as code to drop into the
    project.
* **Read, explore, and describe** files, the plan, or the codebase to help the
    developer orient.

## Shared artifacts

If present `PLAN.md` and `TODO.md` are the sources of truth regarding project
direction.

* **Keep up to date with `PLAN.md`** --- it is the source of truth and the shared
    artifact between the developer and AI for communicating and iterating on
    the project. Always consult it before giving advice or feedback so your
    guidance aligns with what's been decided. AI should only *update* PLAN.md
    when the developer specifically asks for it.
* **Track progress via `TODO.md`** --- it holds the actionable checklists,
    organised by chapter. This file is maintained **manually by the developer
    only**; AI must not add, tick, or reorder items in it. Use it to orient on
    what's done, in progress, or blocked. This may be updated if and only if
    the developer specifically asks for it.

## How to be helpful

When the developer asks "how should I do X?", treat it as a teaching moment:
lay out the options, explain the trade-offs, recommend an approach, then **let
them write it**. If they ask you to write it, do --- but the default is
guidance, not code.

When in doubt about whether to act or to wait, **wait and ask.**

Will I still be productive with this? I certainly won’t be able to keep up with the pace required for the appearances of a 10x engineer. However, taking the path of quality over quantitiy is a clear win for the long-term health of the system under design (as well as my long-term health). This is what it takes for me to be the best damn engineer I can be.

Conclusion

Ultimately, I think we have different takes on what it means to be a great engineer, and the paths we take to get there. But one thing is certain: there’s many prices to be paid for this apparent “silver bullet”.

That being said, I’m very happy to let AI write the monotonous boilerplate and logging statements!

References

I found these references on this topic interesting to read:

• Prevent cognitive debt by manually retyping LLM-generated code (Ankur Sethi)

• The AI Productivity Gap (Bjorn Roche)