May & June 2026 Link Roundup

Published: June 03, 2026

I found this article recently when doing a search for the origin of the aphorism "code is a liability". It's a very relevant warning for any team that works with any significant quantity of LLM generated code.

A good engineering culture with emphasis on strong fundamentals and good design is as important now as ever. I recently, briefly, inherited maintenance of a codebase that demonstrated firsthand what incautiously accepting LLM suggestions (and merging them) can result in - things like a 13,500 line service class that wasn't even a year old. Much of this code base ended up very difficult to understand, extend or maintain. And to the inevitable "let the LLM maintain it" apologists, that literally did not work; Claude may have written most of the code in that 13,500 line file, but as soon as I asked it to suggest any changes, it would consistently crash the conversation with out of context errors. (Going back a message to try again hardly helps if it was your first message!)

All that to say, while LLMs can be useful, they certainly still require oversight and human judgement to write actually useful - and usable - code that will enable you to ship features at a good velocity, with low errors, over time.

On the flip side, one of the earlier projects I was involved in in my career had a very strong focus on good engineering principles. That codebase, while still containing a variety of sections and moving parts, was incredibly easy to extend and pivot on features. We did such a great job that the client extended our contract in order to train up junior developers to continue the trend; the project as a whole was a major success story for the client.

Shipping lines of code as fast as possible is a really poor metric.

Normalization of Deviance in AI

This video demonstrates a much more mature approach to using an LLM to write code than what we often seen thrown around. Pocock highlights how important it still is to have good fundamentals and architecture in your project, because failing to do so will leave the LLM lost and confused as much as it does human developers.

This article got recommended to me on LinkedIn recently. The author goes into detail at length about how the design of LLMs predisposes them to behaviors such as always finding errors (whether there are any there to find or not), and discusses how to avoid falling for the trap. Great read.

One of my favorite quotes: "The core issue is that LLMs are trained to produce plausible text, not to produce correct text. Plausibility and correctness are highly correlated in many domains, which is why LLMs are so impressive in general use. But in domains where correctness has a precise, objective definition, such as code, mathematics, or formal logic, the gap between plausibility and correctness can be significant and consequential."

The Infinite Bug Factory: Why Large Language Models Never Run Out of Errors to Find, and What You Can Do About It

Wonderful talk by Brandon Sanderson about what art really is and what it means. I love his conclusion that WE are the art, the end result is just proof of the work that was done.

This post is tagged: