Skill Issue logo

Skill Issue

Archives
Subscribe
December 19, 2025

Dystopian Code Review

This is the final Skill Issue of the year. Thanks y'all for reading. I'll be back at it on Jan 9th. In between now and then I'll be enjoying some time with my family, doing some surfing, and relaxing in Tofino with some friends.

Here's a question for y'all: have any of you worked through Crafting Interpreters? I'm tempted to give it a shot. Looks fun. I've been playing with some language development stuff, but don't have the foundations to make anything more serious.

Snark

I might have got a little snarky this week when discussing reviewing AI-generated PRs. The thoughtbot article that spurred me to write this was rather dystopian, as Dave put it. My friend Isaac had and interesting take.

This only addresses the immediate short-term purpose of code review to check the quality of the specific code being reviewed. Over the longer term, code review has another purpose: to negotiate norms of code structure across the team.

When there's more than one good way to do something, having everybody pick a different way creates unnecessary complexity that will gradually make everything harder. Code review needs to discover these different approaches and help the team reduce them. It's not just about the code you've written, it's about the code you're going to write in future.

If code is written by an LLM that has no model of the decisions your team has already made, the longer-term purpose of code review is undermined. Instead of gradually building consensus on how to move together, you're wasting time on the same discussions over and over with a bot that's not listening.

Code review isn't just a quality gate. I'd argue it's not even mainly a quality gate. Code review creates an outlet for all kinds of team discussions that many modern software development processes don't adequately make time for.

These conversations help align teams in concrete ways ("Let's use the same HTTP client everywhere.") and more subtle ways, like their mental model for boundaries and where complexity should live.

Yes, I've seen teams ship features quickly by leveraging these tools. But, I keep seeing teams dig themselves into difficult holes with it too. Months ago I saw a post claiming that we shouldn't worry about any of this, that in a few months LLMs would be able to clean up and refactor all the shit code they were pumping out at the time.

I'm still waiting.

Howling Giant – Crucible Ruin

I'm currently working through the long backlog of albums I've meant to listen to. It goes all the way back to February. Part of why I'm so behind is that good albums keep coming out. Basically, I blame Howling Giant.

I don't know too much about the psych/stoner act. They're energetic, the vocal harmonies are cool, and the songwriting is reasonably complex, but not inaccessible. Good pick me up for this grey, rainy season.

And look at them.

image.png

Howling GiantCrucible & Ruin
Don't miss what's next. Subscribe to Skill Issue:
Share this email:
Share on LinkedIn Share on Mastodon Share on Bluesky
https://ruby.so...
Bluesky
https://jardo.d...
GitHub
Twitter
LinkedIn
Powered by Buttondown, the easiest way to start and grow your newsletter.