I stopped reading my AI's code. I read its decisions instead

Since the end of December 2025 I haven’t written any code by hand. That used to be most of my job. A month or two ago I dropped the next thing: reviewing pull requests line by line. I still review. I review decisions, mostly architectural ones, and I don’t go into code specifics anymore.

When I tell other engineers that, the reaction sits somewhere between curious and horrified. So I want to write down what I actually do, and where I think it breaks.

What I read instead

The decisions. Where does this data live? What does this change touch? What happens when it fails halfway? Does the behaviour match what the product should do?

Those are the questions a diff hides. A diff shows you that a function changed. It doesn’t tell you that the change quietly moved a responsibility from one place to another, or that a retry now runs somewhere it shouldn’t. My guess is that an agent makes a locally sensible choice that’s wrong for the system more often than it writes a bad line. That’s the part I keep.

A small example from Relnk last week: if a save fails and you hit Back, should the app let you leave? The code that answers that is a few lines in the editor, and I don’t need to read them. The decision behind it is the one I care about: losing a paragraph of someone’s writing is worse than an annoying prompt. If that decision is right, the code can be rewritten as often as it likes and I won’t mind.

I think this is what engineering always was. Requirements, planning, docs, tickets, code, QA, monitoring, impact. Code was one step in that list and we treated it like the whole thing. AI is making that obvious, because it took the step most of us spent our days on and left the rest.

Where trust ends

I trust the agent a lot. I’m also not naive about it. Even if I trust it, I have to have my guardrails.

Production is read-only. It can query, investigate and debug there, which is most of what I need from it on a bad day. It can’t change anything. Staging is read and write: that’s where it runs things, breaks things, and where I do QA before anything ships. My card details go nowhere near it.

The guardrails are what make dropping the line-by-line review sane. They limit what a wrong piece of code can do before a person looks at the result.

Where I think this breaks

I work mostly alone on my side projects. On a team, a line-by-line review is also how people learn the codebase and each other’s habits. I don’t know what replaces that yet. Maybe reviewing decisions together does the same job. Maybe it doesn’t.

There’s also a kind of bug no decision review catches: the subtle one, three lines deep, that every test passes. That’s the bet I’m making, that the review and test passes catch more of those than my tired eyes would late at night. What would change my mind is simple. A bug that reaches users, that a line read would have caught, and that none of the passes did. When that happens, I’ll write about it.

Until then, I read plans and decisions, I QA on staging, and I let the agent own the lines.

Thanks for reading! Subscribe for free to receive new posts and support my work.