AI Writes Code Faster Than You Can Read It — Here's How to Keep Up

I've been writing code with AI for over two years now, and recently I've become increasingly aware of a problem: it's not that the AI writes poorly, but that I myself seem unable to keep up.

At the beginning, it was genuinely exhilarating. Throw a requirement at it, and within minutes a pile of code would appear, accompanied by a lengthy explanation of the changes. It was written quite seriously, and the logic made sense. Back then, I really enjoyed that feeling, thinking my efficiency had multiplied several times over.

But as time went on, the problem emerged. The AI would give me a change description, often hundreds of words long, sometimes even longer. I'd open it, my eyes scanning over it, but my brain just couldn't absorb it. It's not that I didn't want to read it; I genuinely couldn't take it in—that feeling is a bit like reading a particularly long expository essay back in school: you recognize every word, but strung together you can't grasp the main point, and after reading it you feel like you haven't read anything at all. The code is the same: a huge chunk of changes laid out before me, bits here and there, and I find it very hard to string them together in my mind into a coherent thread, to figure out "why was this step changed this way" or "will changing this function affect something else."

To put it bluntly, the speed at which AI writes code has long since outpaced my speed at understanding code.

A while ago, I seriously mulled this over. It wasn't about finding some magic bullet; I just wanted to figure out exactly where the problem lay, and then try adjusting my habits a bit. It felt slightly better, so I'm recording it here.

Don't Read the Explanation First, Read the Diff

I realized I used to have a bad habit: after the AI finished modifying the code, I would first go read that long block of text explanation, trying to understand the changes by "comprehending the explanation." But later I figured out that this order is backwards. Text explanations are the most mentally taxing form of input, especially those laced with a bunch of technical jargon and context, which are more tiring to read than looking directly at the code changes.

Now I've switched to reading the diff first—that is, which lines were added, which were deleted, which were modified. This information density is actually lower and easier to digest, because it's "concrete," not "abstract." I now just glance at the text explanation to see if there are any major architectural-level decisions, like switching a library or changing a data structure. I judge the remaining details entirely by reading the diff myself.

Don't Give Too Large a Task at Once

This is the biggest pitfall I've fallen into. Before, for the sake of convenience, I liked to throw a complete requirement at the AI in one go, like "help me change this module from Plan A to Plan B," and then it would spew out hundreds of lines of changes, plus a mini-essay. I simply couldn't review it seriously; basically, I'd just scan it, think "looks fine," and merge it.

Now it's much more reasonable—I break things down first. For example, change the data layer first, run it through, then change the interface, and once the interface is fine, change the UI. Each step is a small, readable change that I can go through honestly, and I can even offer some specific feedback. Small-step commits have always been advocated in engineering; I just used to think that working with AI meant I could skip this step. The facts prove it cannot be skipped.

Set the Rules in Advance, So the AI Doesn't Need to Ramble in Explanations

I later discovered that many long explanations are long because the AI is "explaining the implicit decisions it made"—which library it used, why it named things a certain way, how errors are handled, what code style was adopted. Having to re-explain these things every time makes it seem particularly verbose.

Later, I simply decided to nail these things down in advance and write them into the project's conventions, such as naming standards, directory structure, and error handling approaches. This way, the AI doesn't have to spend large paragraphs each time explaining these "background settings," and the output naturally slims down a lot. What's left is basically pure business logic changes, which are much easier to read.

Review from a Different Angle, Don't Read Line by Line

I led a team for a few years before, and when helping colleagues review code, I actually never read it line by line. Instead, I'd first look at which interfaces were changed, who calls these interfaces, whether there could be side effects, and whether the test coverage was adequate. I later realized this set of habits can be completely transferred to reading AI code—focus attention on the "boundaries," rather than nitpicking the "implementation details." As long as the interfaces are reliable and the tests can act as a safety net, you can appropriately delegate the specifics of the internal implementation, without needing to be strict about every single line.

This mental shift helped me a lot, because reading code line by line is inherently manual labor, and it's very easy to lose focus while reading. In contrast, key nodes like boundaries and interfaces make it easier to grasp the main points.

Let Tests Verify for Me, Instead of Relying on "Understanding" to Verify

Previously, my confidence that the code was "fine" came almost entirely from "I understood it." Thinking about it now, this logic is quite fragile, because understanding doesn't mean there are no bugs, especially with AI-written code where the logic might be correct but pitfalls are hidden in the details.

Now I require every change to come with a set of tests, whether unit tests or integration tests, making "tests passing" the main source of my confidence, rather than obsessing over "whether I understood every single line." This way, the purpose of reading code changes—it's no longer to verify if it's right, but to understand its design thinking. The pressure is much lower, and reading becomes more relaxed.

Directly Ask the AI to Speak Plainly

The last change is actually the simplest, and also the most easily overlooked: I started directly stating requirements in my prompts, telling it not to write mini-essays, and instead to "explain what was changed in one sentence, list 3-5 key decision points, and separately mention any risk points if they exist."

The effect was immediate; the length shrank right away. That previous style of overwhelming explanatory text was, in the end, the AI "trying its best to show how diligent it is," but for me, the information density was too low. Clearly requiring it to be concise and structured is something it's fully capable of; I just hadn't made that request before.

---

Looking back as I write this, none of these adjustments are actually novel tricks. To put it plainly, they are all old rules that have long existed in software engineering—small-step commits, focusing on interfaces, using tests as a safety net, convention over configuration. It's just that when collaborating with AI before, I always felt, "the AI has done it all for me, maybe I can slack off a bit." In the end, I found that not a single one of these rules can be skipped, and because AI writes code so fast, these rules are even more important than before.

My current state is that the amount of code written hasn't decreased, but I read it much more easily, and I'm more confident saying "I truly understand this code," rather than "the AI said it's fine so I trust it." This shift is quite important to me.