What Do We Do When We Read The Code?

2026-08-11T00:00:00Z

Last Friday, I wasted over an hour arguing with an LLM. I was reviewing a pull request I asked it to generate, and realized that three of the tests it wrote were either not useful or literally could never fail.

I hate reading tests. Reading tests is hard and boring, but I always try to read them carefully. They’re your guardrails. They don’t always do a good job of capturing the nature of the behaviour or feature that you’re trying to achieve, but at least they try to guarantee that things won’t change in unpredictable ways in the future without you noticing.

They take time and effort to read, and eventually I realized these tests were useless.¹ When I asked the LLM about it, it got bashful. Rather than reasoning about it like I had, it impressively wrote a mutation test to indeed show the test was useless, and then wasted more time trying to find ways to preserve the spirit of the tests, which I simply deleted.

Afterwards, I sat back and thought about this interaction. What am I doing here?

Am I really enhancing shareholder value by caring about these tests?

Before, I could’ve said: oh, i’m training a junior to not make these mistakes – but that’s gone now, that doesn’t matter. These tests will be executed over and over again and so they’re a waste of electricity – but that’ll cost, what, pennies?

To not care about these tests means not reading them. When I think about not reading code, I feel like two things are true:

When I ask myself, is there a world where I will NEVER read ANY of the code? I think the answer is no. I will always have to debug something, or derive a real understanding of what the app is doing.

In the future, we will never read 0% of the code.
However, we already live in a world where sometimes there is no point in reading some or most of the code.² The proportion of code that’s not worth reading will only grow.

In the future, we will never read 100% of the code.

I’ve been adapting my workflow to LLMs. Today, I still spend a lot of time editing LLM output because when I publish a PR I feel like I should apply the same level of care and attention to details – the same level of… let’s say professionalism – that I would’ve expected from a staff engineer a mere twelve months ago.³

Yet, I feel a lot of pressure to stop reading code. There’s too much of it. We just don’t have any of the affordances, none of the tooling, and none of the culture has really caught up.

I feel stuck between two extremes: I either try to hold on to my sense of professionalism and aesthetic sensibilities, or I go bug fuck nuts and hands off the wheel yolo agent swarm – and neither option seems sustainable to me.

So, why do these empty tests matter?

I have a metaphor that I keep coming back to. Back in the day, back when I got started in this industry, if you wanted a chair to sit on first you had to go down to the swamp and pick some reeds. Once you collected enough grass you then carefully weaved the chair into being. We used to spend a lot of time thinking about what kind of straw is best, and how to fold it properly, and how to make your wicker handsome.

Since then, we’ve invented injection molding. Now, if you want a chair you carve a mold that gets filled with plastic.

I feel like if we lean in to this shift – if we stop reading the code – we will still need to retain some kind of control over whatever the fuck is happening. Because… my job isn’t to prompt the machine, it’s to deliver business value. So, how do I know that the slop is delivering business value – or we don’t break the existing value we already built?

How do I keep the shape of the chair in sight?

I’m starting to think about how I can stop worrying, and write more expressive and comprehensive end to end tests. I’m weary of confirming my pre-existing biases; I’ve always thought that one good integration test is worth a hundred unit tests.

I feel like the question we need to be asking is “how do i retain control over the integrity of the business value we are delivering?” because… if your codebase is littered with tests that don’t do anything, how do you know if something broke?

You might not find out until your revenue drops.

The only assertions made concerned the behaviour of the test mock, which would never change. ↩
A friend told me “I don’t review front-end code anymore”. He was never a React-ninja to begin with, and you refresh the page and it either looks right or it’s wrong. In some domains, it’s very easy and quick and cheap to see if the app is working – or your audience has a high tolerance for flakiness. ↩
Certainly, none of my company’s policies wrt code quality, review, etc have changed. ↩

okayfail.com (feed for #llm)

What Do We Do When We Read The Code?