Zum Inhalt springen

I stopped defending my code in review. I didn’t decide to.

Dieser Artikel ist auf Englisch.

When an agent writes the code, nobody in the review has enough skin in it to say no.

Last week I got a review comment that would have ruined my afternoon in 2023.

You know the type. Small PR, focused, you actually thought about it, and then: „why is there an interface here, there’s only one implementation.“ In the old world something in my chest would tighten, because that interface wasn’t an accident. I read the book. I sat through the talk. I decided the seam was worth the indirection, and now someone with three minutes of context was calling it noise.

This time I copied the comment into Claude Code, said „address this,“ skimmed the diff, and hit reply. Ninety seconds. No defense, no counterargument, no thread. I didn’t even disagree, because to disagree I would have needed an opinion, and somewhere along the way I stopped having one.

The review got faster. Something else broke.

That hour I used to spend was doing a job nobody assigned it. It forced a question: is this reviewer actually right, and do I care enough to find out. Now the comment goes into the agent, the diff comes back, the thread resolves, and nobody ever answers it. The argument was the quality gate. Nobody designed it that way, and we deleted it by accident while making everything else better.

the sculpture problem

Here’s how it used to work, and I don’t think this was unique to me.

You spend your first few years absorbing patterns. You find ports and adapters and it rewires how you see a codebase, because for the first time the domain logic isn’t tangled up with the database driver. You try CQRS on something that probably didn’t need CQRS. Every new pattern you learn goes into the next PR, because how else do you learn it.

And the code that comes out the other end is yours. Not in a legal sense. In the sense that the shape of it is a record of what you believe about software. Somebody looking at your service layer could reconstruct your opinions from the file structure alone.

So when a reviewer says „there’s too much abstraction here,“ they are not saying something about the code. They are saying something about your taste. You built a sculpture and someone walked into the studio and said the arms are too long.

The stupid part is that this made us better. All that ego produced real arguments. Long, tedious, occasionally insufferable arguments about whether the repository interface earns its keep, and those arguments were how a team actually converged on a shared idea of what good looks like. You cannot get to a house style through a linter. You get there by two people who both care too much fighting it out in a comment thread until one of them produces a better reason.

Painful. Slow. Load-bearing.

the architect doesn’t bleed

Then the work changed shape.

I’m not typing much anymore. I describe what I want, I set the constraints, I define what the edges have to look like, and something else produces the code. And I’m happy with the results, because the results are what I envisioned. That part works.

But look at what happened to the review dynamic. The code in the PR is no longer a record of my beliefs. It’s an output. When a reviewer says the abstraction is wrong, they’re critiquing a first draft written by a machine that has no opinion and will cheerfully write the opposite tomorrow. My identity isn’t in there. There’s nothing to defend, because there’s nothing of me in the thing they’re attacking.

So I don’t defend it. I fix it. Instantly, without friction, because the cost of changing it is now approximately zero.

This is a real improvement and I want to be honest about that. Comments that used to sit for days get addressed in minutes. Nobody is stonewalling a reviewer to protect their pride. The reviewer’s suggestion wins by default, and often the reviewer is right, and in the old world their being right would have cost us three days and a passive-aggressive Slack thread.

Ego was a tax on velocity, and we stopped paying it.

except we didn’t pay that tax for nothing

When the cost of changing code drops to zero, the value of arguing about it also drops to zero. Those two things are not the same. They feel the same in the moment, and so nobody argues anymore.

Watch what actually happens now. A reviewer leaves a comment. It might be a great comment. It might also be a stylistic preference they picked up at a previous job, or a misreading of what the code does, or advice that was correct in 2019. In the old world I would have had to evaluate it, because implementing it meant an hour of my life. Now there is no filter, and the PR gets approved. The code is now shaped by whichever reviewer happened to be assigned, filtered through whatever the model felt like doing that afternoon. That’s not consensus. That’s just the path of least resistance with a green checkmark on it.

The goal quietly moved, too. It used to be „produce the best version of this code.“ It’s now „get this merged.“ Those overlap most of the time. Most of the time is doing a lot of work in that sentence.

the agent will argue both sides and mean neither

The detachment isn’t only on my side, which is what makes it compound. An agent will happily rewrite the architecture it proposed forty minutes ago. Tell it the abstraction is too heavy and it strips it out. Tell it five minutes later that the code is too coupled and it puts it back, cheerfully, with a nice explanation of why layering is important. It has no memory of why it chose the first approach and no stake in defending it.

So you have a reviewer who spends thirty seconds on the comment, an author who spends ninety seconds on the fix, and an implementer with no opinions at all. Nobody in that loop is invested in the outcome. The old system had a mechanism nobody designed on purpose: somebody in the thread cared enough to push back. That was the quality gate. Not the approval button. The willingness to say „no, and here’s why.“

I can’t point to a specific PR where this went wrong, and that’s the part that unsettles me. Nothing looks broken. The dashboards are fine, the tests pass, the reviews close faster than they ever have. If we merged something worse last quarter because nobody stopped to ask, there’s no artifact that would tell us.

don’t reattach. the sculpture isn’t coming back.

The obvious reaction is to say we should care about our code again, and I think that’s wrong. It’s nostalgia dressed up as principle.

Going back means going back to the guy who spent three days defending a factory nobody needed. It means slower merges and more thesis-defense reviews and a team where the loudest person’s taste wins because they had the most stamina. I’ve worked on that team. I’ve been the problem on that team. It wasn’t better, it was just differently broken.

The attachment was never actually to the code. It was to the judgment behind the code. Writing it by hand was just the delivery mechanism, and losing the delivery mechanism shouldn’t mean losing the judgment.

put the argument somewhere on purpose

So the thing to rebuild isn’t emotional investment in a diff. It’s a place to put the argument, deliberately, since it no longer shows up on its own.

Before you paste a comment into the agent, decide out loud whether the reviewer is right. Ten seconds, in the thread: „agreed, that interface was pointless“ or „I don’t think so, here’s what it’s for.“ That one sentence restores the filter you lost, and it costs you nothing.

Push back when you actually disagree, and accept that it now takes deliberate effort instead of arriving for free with your wounded pride.

And be honest when a comment genuinely isn’t worth the argument, because plenty of them aren’t, and the old world wasted enormous energy pretending otherwise.

None of that requires you to be precious about a pull request. It requires you to still have a position.

the twenty percent was never the job

If I had to guess, writing code was twenty or thirty percent of this job even at its peak. The rest was figuring out what to build, deciding what not to build, understanding what the customer actually meant instead of what they said, and choosing which failure modes we could live with. Craft is where a lot of us stored our professional identity, and it was stored in the smallest slice of the work.

So the loss is smaller than it feels. The slice we’re mourning was never where the value was, and the judgment that used to ride along inside it can be spent somewhere better. Or it can not be spent at all, in which case you coast on the throughput and become someone who ships a great deal of software they have no opinions about. That’s an available option too, and I think a lot of people are going to take it without ever deciding to.

Keep giving a damn. Just stop storing it in the diff.

DSGVO Cookie Consent mit Real Cookie Banner