Reading code is the bottleneck now

For most of my career, the slow part of programming was typing. You knew roughly what you wanted; the question was how many hours of glue, boilerplate, and yak-shaving stood between you and the working version. The job rewarded people who could hold a lot of detail in their head and translate it into syntax quickly.

That's over. With a competent coding agent, the diff lands in seconds. The slow part is now reading it.

What changed

I noticed it first on a small refactor — a Worker endpoint, maybe 200 lines. I asked the agent to add validation, a rate limit, and a captcha check. It came back in under a minute with a working patch. The patch was fine. But verifying it was fine took me twenty minutes: tracing the request path, confirming the rate-limit binding wasn't double-counted, checking that the captcha verification failed closed instead of open.

Twenty minutes to read sixty lines I didn't write. That ratio used to be inverted.

Why this is harder than writing

When you write code, you build the model as you go. Every variable name, every early return, every type — they're decisions you made and remember the reason for. The mental model is a free byproduct of authorship.

When you read code someone else wrote (and an agent counts as someone else), you have to reconstruct that model from scratch. You're reverse-engineering intent from syntax. And unlike a human collaborator, the agent can't tell you why it chose Map over Record, or why the catch block swallows the error — it just did the thing that pattern-matched. Half the time the choice is load-bearing; half the time it's arbitrary. You can't tell which without reading it.

The skill that compounds

The engineers getting the most out of AI agents are not the ones who can prompt cleverly. They're the ones who can read a 300-line diff, spot the one place the agent confidently invented an API, and reject it without ceremony. They have strong opinions about what good looks like in their codebase, and they hold the agent's output to that bar instead of grading on a curve.

That skill — taste, applied at speed, on code you didn't write — is what I'm trying to get better at. It used to be a senior-engineer luxury. Now it's the price of entry.

What I do differently now

A few things that have helped:

• Read the diff before running it. The agent's confidence is uncorrelated with correctness. If I let "the tests pass" be my acceptance criterion, subtly wrong code ships.
• Push back early. If the first response goes in a direction I don't like, I stop and redirect instead of patching it after. Bad foundations get expensive fast.
• Keep the codebase legible to myself. Consistent patterns, short files, obvious names. Future-me reading an agent's diff is the primary user of the codebase now.
• Accept that I'll write less code by hand. That's fine. The leverage is real. But the responsibility for what ships is still mine, and pretending otherwise is how bugs get in production.

The work didn't get easier. It got different. The valuable thing I do has moved one level up the stack — from producing code to judging it. I'm still figuring out what that means for how I spend my day.