Originally published on tamiz.pro.
I spent twelve years reviewing code. I developed a rhythm—spotting logic errors, questioning edge cases, recommending refactors—and it made me a better engineer. When AI coding agents first became viable last year, I assumed my superpower would transfer directly: I'd simply review what the agent produced, flag issues, and iterate. Thirty days into treating AI-generated code as my primary workflow, I've learned that assumption was dangerously wrong.
Code review assumes an autonomous author. Agent management assumes you are the author, and the AI is your increasingly competent but occasionally catastrophic pair programmer. The mental shift from reviewer to manager is steeper than most engineers are admitting publicly.
The Reviewer Mindset Doesn't Transfer
When you review human-written code, you evaluate decisions someone else made. You bring context, intent, and domain knowledge to bear on choices you didn't make. This is a receptive, analytical mode.
When you manage an AI agent writing code, you're doing something fundamentally different: you are making decisions before the code exists, and then verifying that the output matches your intent. The work has moved upstream. Your primary skill is no longer spotting bugs in others' code—it's articulating precisely what you want before the agent writes a single line.
I found myself repeatedly slipping back into reviewer mode: pasting the agent's output into a diff view, hunting for problems, feeling satisfied when I found and fixed a couple of issues. Meanwhile, the real work—specifying the problem correctly, designing the interface contracts, deciding which abstractions to introduce—was either under-specified or handled entirely by the agent, often inadequately.
The shift isn't minor. It's the difference between editing and writing, between proofreading and composing. Treating AI agents like junior developers you review will leave you with code that looks fine at the surface but has architectural debt you'll spend months paying down.
What Actually Changed in My Workflow
Three things reshaped my daily practice immediately.
Prompt design replaced code reading as my primary skill
I used to judge code quality by reading it. Now I judge prompt quality by how well it precludes bad outcomes. A good prompt doesn't just describe what to build—it defines constraints, naming conventions, error handling boundaries, test requirements, and the specific interfaces the generated code must satisfy. I've started treating prompts like API contracts: the more precisely you specify inputs and outputs, the less surprising the behavior.
The pattern I keep returning to: define the interface first, then the agent fills in the implementation. This isn't new software engineering wisdom—it's the same principle applied at a higher level of abstraction. But the consequence is more acute because the agent operates faster than a human collaborator, and faster mistakes are harder to trace back.
Context window management became a real engineering problem
Human code review works because the reviewer has the whole file in front of them. AI agents work inside a context window, and that window has hard limits that reshape how you structure work. I've moved from monolithic features to smaller, agent-managed units where each iteration has everything it needs to succeed without requiring the agent to reconstruct the entire codebase mentally.
This has led to a practice I didn't anticipate: I now maintain a living CONTEXT.md in every project directory that summarizes architecture decisions, established patterns, and known constraints. It's not documentation in the traditional sense—it's operational context specifically engineered for an LLM to consume efficiently. I update it religiously after every significant decision.
Verification replaced trust as my default posture
In code review, you read and decide whether something is correct. With AI agents, "reading" is not verification. The agent can produce code that looks correct, passes some tests, but still encodes a fundamental misunderstanding of the domain or the system architecture. I've started treating every piece of generated code as requiring two levels of scrutiny: does it match my specification, and does it fit coherently into the system I'm building?
The second question is the one most people miss. Individual functions might be perfect; the integration with the surrounding codebase might be wrong. I've developed a habit of reading generated code top-down through its dependencies, not bottom-up line by line. The lens changed.
The Hidden Cost: Agent Orchestration
Nobody talks about this enough: managing AI agents is expensive in a way that goes beyond token costs. There's a cognitive tax, a time tax, and a reliability tax.
The cognitive tax is the mental overhead of maintaining accurate mental models of what the agent knows, what it's about to do, and what it has already done. Every interaction requires you to reset and re-establish context. After eight hours of this, my ability to do deep analytical work on my own code deteriorated noticeably.
The time tax is the gap between how long an agent takes to generate code and how long a human takes to write it. For trivial operations—boilerplate, straightforward CRUD, simple utility functions—the agent is genuinely faster. For anything involving non-obvious design decisions, the agent is often slower than me writing it myself plus reviewing it. The math flips when the agent gets the design wrong and you spend an hour untangling it.
The reliability tax is the most insidious. Agents are probabilistic. The same prompt, run twice, can produce meaningfully different outputs. This means you cannot treat AI-generated code as deterministic like human-written code. You need to verify correctness consistently, and that consistency requirement is something most engineering teams haven't adapted to yet.
What I Wish I'd Known Before Starting
Here are the lessons that would have saved me two weeks of painful recalibration.
Your review skills are necessary but insufficient. Being able to spot bugs in AI-generated code is the floor, not the ceiling. The real value is in shaping what gets generated in the first place.
Write the spec the way you wish the agent could read it. If you can't articulate a requirement precisely enough to encode it as a prompt, the agent won't be able to execute it correctly. Vague requirements don't become clearer through better prompting—they become confidently wrong code.
Test generation, not just output. I've started writing tests against generated functions before I even read the generated code. This catches hallucinated APIs, incorrect signatures, and silent behavior changes faster than any review process.
Keep humans in the loop for design, not just review. The agents that work best in my experience are the ones that handle implementation while a human owns architectural decisions. Flip that relationship and you get elegant solutions to the wrong problems.
Document agent interactions, not just code. When you're generating significant amounts of code, the record of why certain decisions were made lives in your prompt history and agent conversation logs, not in your codebase. I now treat these artifacts as first-class engineering documentation.
The Bigger Picture
What I experienced in thirty days is part of a much larger shift happening across software engineering. The role of the engineer is moving upstream—from writing code to specifying systems, from reviewing implementation to managing intelligent tools that implement. This is analogous to what happened when compilers replaced assembly programmers, or when garbage collection relieved engineers of manual memory management. Each transition displaced a layer of skill while raising the ceiling on what was possible.
The engineers who will thrive in this shift aren't the ones who kept treating AI like a faster human writer. They're the ones who learned to think about system design, specification, verification, and orchestration—skills that were always valuable but were previously exercised primarily on paper and in conversation, not encoded into prompts and validated through test suites.
Code review was my craft for over a decade. It served me well. But the craft that's replacing it is different enough that pretending they're the same thing is how you end up managing a tool you don't understand rather than wielding one you do.
Frequently Asked Questions
Q: Should I stop reviewing code altogether and focus only on prompting?
No. Reviewing AI-generated code is still essential—just not your primary skill. The review mindset is a necessary defensive layer, but the offensive work happens in specification and design. Treat review as quality assurance, not as your main contribution.
Q: How do I know when an AI agent has made a good architectural decision versus a plausible-looking bad one?
This is one of the hardest problems in agent management. Start by requiring agents to justify non-obvious design choices before they implement them. Ask for alternatives considered. If the agent can't explain its reasoning, the decision is likely shallow. Human judgment on architecture should remain the gatekeeper, not the afterthought.
Q: What's the practical takeaway for someone whose day job is code review today?
Begin practicing prompt-as-specification now. Take a feature you'd normally write a ticket for and try to encode the ticket as a prompt that produces working, tested code. The gap between your natural code review instincts and what's actually required will show you exactly where to invest your learning.
Top comments (0)