reading the diff is the whole job

why working exclusively with ai agents turns code review into the primary bottleneck, how diff literacy replaces typing, and why domain mastery is still required to spot bad changes.

thesis

less than a year ago, ai assisted around the edges while i still hand-wrote most of my code. today, working completely solo, my workflow has flipped entirely. i rarely write code by hand anymore. instead, i interact almost continuously with an ai chatbot and spend my time reading the diffs produced by agents. this shift arrived exactly as predicted, and it exposes the real constraint of modern software engineering which is that generation costs have dropped to near zero, so reading the diff has become the whole job, the human reviewer is the only remaining bottleneck, and deep domain mastery is the only thing standing between acceleration and production failure.

context

a year ago, writing code was still a manual process where an ai tool helped auto-complete a function, generate boilerplate, or suggest a regex. the mental model was simple: i wrote the code, and the tool accelerated my typing.

today, my daily interaction model is almost exclusively conversational and review-driven. i state intent to an agent, evaluate the proposed file changes in a diff viewer, and accept or reject the output. what used to be a future prediction about how engineering workflows would evolve inside a single year is now my everyday reality.

this shift changes where leverage lives. when you no longer spend hours typing out logic, you do not automatically ship features faster. you simply reach the review step sooner. as i wrote in the missing memory of generated code, generation time has shrunk to near zero, but verification time remains constrained by human limits.

argument

the human reviewer is the sole bottleneck

an ai agent can edit five files, refactor three joins, and rewrite a test suite in twenty seconds. but a human brain reads, evaluates, and comprehends code at the exact same speed today that it did twenty years ago.

this asymmetry creates a stark reality: if you want to accelerate your engineering output today, prompting faster or asking for larger code dumps yields diminishing returns. diff literacy, the speed and accuracy with which you can read, parse, and evaluate proposed code changes, is the primary skill that unlocks actual delivery speed. if your diff review is slow or superficial, your delivery speed drops to match your reading speed, or worse, drops to zero when you spend the afternoon debugging an unread change.

reading the diff is a proxy for code memory

when you hand-write code line by line, you acquire a mental map of the implementation for free. you remember wrestling with a specific edge case, handling a null value, or choosing one join condition over another.

when an agent writes the code, that cache does not exist. the code arrives fully formed. reading the diff line by line is not a bureaucratic formality, it is the minimal investment required to build working memory for code you did not write yourself. if you accept an edit without reading it carefully, you are operating code you do not understand, leaving you helpless when it breaks later in production.

the reject and re-prompt loop

working exclusively with agents requires normalizing rejection. it is extremely common in my daily workflow to read a diff, reject the changes entirely, and send the agent back with specific feedback.

a prompt loop usually looks like this:

1. issue a clear intent or task to the agent
2. inspect the resulting diff line by line
3. spot a subtle defect, missing constraint, or bad assumption
4. reject the edit and issue supplemental instructions explaining exactly why the first attempt failed

re-prompting effectively depends on diff literacy. if you cannot spot why the first diff was wrong, you cannot give the supplemental instructions needed to guide the second attempt.

why domain mastery still matters

some people assume that if agents write all the code, domain expertise is no longer necessary. but the opposite is true.

as i argued in ai only makes sense if you have already been through the cognitive struggle yourself, if you have not paid your dues through years of hands-on problem solving, you cannot evaluate what the agent produces. an agent will confidently generate syntactically valid code that satisfies an underdeveloped prompt while violating business rules, grain constraints, or edge-case logic.

without earned domain mastery, you cannot spot those subtle errors in a diff. you end up approving plausible-looking breaking changes, borrowing speed today against troubleshooting debt tomorrow.

tension or counterpoint

a common objection is that reading diffs carefully takes too much time and defeats the purpose of using ai for speed. why not trust the agent's test suite or rely on automated linting?

automated checks are necessary, but they only test for what you explicitly wrote checks for. they do not validate unstated business intent or subtle domain shifts. skipping diff review to save three minutes on approval usually costs three hours of reverse engineering when an unread edge case corrupts downstream data.

closing

i no longer measure productivity by how much code i write. i measure it by how quickly and accurately i can evaluate the code my agents propose. the shift to agentic coding does not eliminate human responsibility, it means reviewing is the primary engineering discipline.

master your domain, sit with the diff, and treat every line of proposed code as something you will personally have to explain and maintain when it runs in production.