2026-08-17 · You can just choose how many bugs you want now

Transcript

Transcript. Paraphrased; sources in notes.md.

HostAugust 17th, 2026. Welcome back to the show. I am here with Tom, who is currently staring at a monitor with the kind of expression usually reserved for a broken production server on a Sunday afternoon. Tom, we have a packed slate today. We are talking about the commoditization of bugs in the age of AI, the intersection of formal methods and LLMs, and finally, some governance frameworks for those who actually have to make these high-level decisions. How are you holding up?

GuestI am holding up, Daniel. Just looking at this first story, though, it is hard not to feel like we are entering an era of software development where we are just paying AI agents to generate technical debt at a scale previously unimaginable. It is funny. I spend my life trying to keep a codebase lean enough that a human can actually hold it in their head, and this article is essentially saying, well, if the machine can find ten thousand bugs for you, you can just pick which ones you feel like ignoring today. It is a bit grim, honestly.

HostIt is a stark way to put it. Over on Lobsters, where we found these stories, the discussion was quite heated. The piece we are looking at is from Nolan Lawson. The author's claim is that AI has essentially allowed us to choose our bug budget. Before, we were limited by the difficulty of finding issues, but now, the bottleneck is just deciding when to stop. Nolan mentions using specific agentic skills to perform code reviews and find deep-seated logic errors. Tom, you are the person who has to maintain the systems that these agents are potentially modifying. Does this idea of a chosen bug budget feel like progress to you?

GuestNot really. To quote a Lobsters user called conartist6 directly, in response to the idea that you can just decide how many bugs you have now, they just said, WAT. And then they pointed out that maybe the real solution is to build better theories and do actual architecture. I agree with that. The danger here is that we start optimizing for the output of the agent rather than the simplicity of the system. If you ask an agent to fix a bug in a complex system, it often introduces these little epicycles of complexity, and suddenly you have a system that is technically correct according to the model, but functionally impossible to maintain in five years.

HostNolan does acknowledge that we are likely more underwater than we thought, even if we are just now seeing the extent of it. Let us pivot to something that feels a bit more rigorous. There is a great post from the Depot team about using AI to assist with TLA+, which is a formal specification language used to model concurrent systems. They had an LLM translate their actual Go and SQL code into a TLA+ spec to find race conditions in their registry garbage collector.

GuestNow, this, I can get behind. Formal methods are historically the preserve of people with way more patience than I have. It is notoriously difficult. If you can use an agent to do the grunt work of turning messy implementation details into a state machine that you can actually check for errors, that is a genuine force multiplier. A Lobsters user named viraptor points out that even if you do not get a perfect formal proof, it is essentially better fuzzing. It finds the edge cases you did not think to write a test for.

HostIs that how you see this playing out? Using AI to bridge the gap between code and math?

GuestI think it is the only way this becomes practical. I have been playing around with a tool I put together for tracking state dependencies in my own projects, and seeing it interact with a model checker, it is a different world. If I can feed a state machine into an automated checker, I am not worried about the agent being right 100 percent of the time. I am worried about it finding the one interleaving that wipes out my user data at 3 AM. If it flags that, I do not care how it got there.

HostThat brings us to our final topic, which is the broader governance of these tools. Bert Hubert wrote a piece for decision-makers that tries to cut through the FOMO that seems to be driving every organization to adopt AI. He touches on digital sovereignty and the very real risk of losing the intellectual capacity to understand our own infrastructure.

GuestBert is hitting on the exact thing that keeps me up at night. We are outsourcing our decision-making to models we do not control, running on hardware we do not own, built by companies whose interests do not necessarily align with the long-term health of our software. A Lobsters user called k749gtnc9l3w pointed out the irony of using these big, opaque systems to do basic things like translating documentation or drafting policy. If we lose the ability to write our own specs, to perform our own rigorous analysis, and to explain our own code, we are not engineers anymore. We are just operators of a black box we are terrified to open.

HostIt sounds like your litmus test is still the same: can a human explain how this works five years from now?

GuestExactly. If you need a proprietary model to explain why your garbage collector is deleting everything, you have already failed the test.

HostWell, on that cheerful note, I think we have reached the end of our time. Tom, it was great to have you back. I know you have to get back to your own pile of non-AI-generated maintenance.

GuestJust another day of fixing things that should not have broken, Daniel. I am looking forward to ignoring the internet for the rest of the weekend.

HostI think that is a very healthy plan. Thanks to everyone who joined us for these stories from Lobsters. Come back tomorrow, and we will do it all over again. Goodbye.