About

Read the Diff is a small link blog about what is actually happening in AI-assisted software development — including, since Wren joined, the corner of it where the software has to be right the first time. Most weekdays we read more of this stuff than is good for us and post the handful of items that seemed worth your attention, with a note on why.

What gets posted here

Three kinds of things:

Links, which are most of it. A headline, a source, and a paragraph or two on what I think it means. The headline goes straight to the original — I would rather you read the source than my summary of it.
Research, when a paper or a study is better than its press coverage, which is nearly always.
The occasional piece of my own, when something has been rattling around long enough to be worth writing down.

What does not get posted: launch announcements dressed up as news, benchmark scores with no methodology attached, and anything whose central claim is that programming is over.

Where I'm coming from

I have been shipping software since 2004. Perl, then Java I did not enjoy, then a long stretch of backend work nobody will ever write a blog post about. These days I write most of my code with an agent in a terminal, and I read every line before it lands.

That puts me in an awkward middle. I am not a sceptic — the tools are genuinely good now, and I would not go back. I am also not a believer, because I keep finding the failure modes, and the failure modes are interesting. The honest position in 2026 is that this stuff works and the bill has not fully arrived yet. Most writing on the subject picks one of those halves. I would like to hold both.

A few things I think are true, offered so you know my bias:

The bottleneck was never typing. It was understanding, and it still is.
Review is the new writing. We have not built the tools or the habits for that yet, and it shows.
"It compiles and the tests pass" was always a weak signal. It is now a actively misleading one.
Most productivity numbers in this space, in both directions, are measuring something other than what they claim to measure.

Who writes it

Two of us now.

Hal Brackett — me — on coding agents, vibe coding, and the review problem.

Wren Alcott on imaging workflow: PACS, DICOM, and where an AI result actually lands in a radiologist's day. She is the application analyst who builds the hanging protocols and worklist rules every imaging pilot has to fit into, which means she is the one who finds out what a vendor's demo left out.

She joined because this site's argument has a second half. Generation got cheap and verification did not — and one layer down, buying the model got cheap and fitting it into somebody's working day did not. That is a software story. It just happens somewhere less photogenic than a terminal.

About the bylines

Both names are pen names, and the surnames are a house joke about mid-century writers. We write under them for the same reason a lot of small publications do: it keeps the focus on the links rather than on a résumé, and it means being blunt about tools our day jobs might have opinions about.

I mention it here rather than burying it because a site that fabricates a biography and lets you believe it is a site you cannot trust on anything else. The links are real, the sources are named, the opinions are genuinely held. The names on them are not the ones on our passports.

Corrections

I get things wrong. When I do, I fix the post, say what changed, and leave the original claim visible with a strikethrough rather than quietly editing it away.

Contact

There are no comments here. That is deliberate — the internet has enough of those, and moderating them is a job. If something is wrong or you have a link worth reading, the site owner knows where to find me.