2026-08-14 · AI is removing the middle class of software engineering

Transcript

Transcript. Paraphrased; sources in notes.md.

HostIt is August 14th, 2026. Welcome to the show. Today, we are wading into the messy intersection of AI-inflated codebases, the self-hosting movement for distributed primitives, and the sheer audacity required to write a DirectX 11 driver for QEMU. Fred, I feel like you have been waiting all week to drop some cynicism on these.

GuestI have been vibrating with a very specific, calm, professional rage, Daniel. I am particularly looking forward to the software engineering piece. It is essentially a confession booth for the industry admitting that they have successfully automated the "thought" part of the process, and now they are shocked, shocked that the resulting code is a labyrinthine monument to technical debt.

HostLet us start there then. Over on Lobsters, there is a fascinating write-up about how AI is eroding the middle class of software engineering. The author argues that LLMs remove the speed limit on bad engineering, allowing teams to generate and merge massive, unmaintainable features without ever stopping to discuss architecture or the "why" behind their choices.

GuestIt is the dream, is it not? Every middle manager from 1994 to the present has wanted a button that turns "human labor" into "feature completion" without the pesky overhead of, you know, people who know how a database works. A Lobsters user called bediger4000 nails it in the thread, pointing out that this has been the management pitch for decades. They want a factory floor where you can swap out the workers like cheap fuses. The problem is that software isn't a bolt-tightening operation. When you have an AI spitting out 24,000 lines of code for a single PR, you have effectively turned your codebase into a write-only medium. You aren't building software anymore; you are building an archeological site for the next guy to suffer through.

HostIt is a dark view, but is the underlying premise actually changing? The author thinks we are hitting a debt trap because nobody is doing the deep work anymore.

GuestThe debt was always there. The difference now is that we have scaled up the velocity of the debt accumulation to a level where the "senior" person is just a glorified janitor who spends all day shoveling AI-generated sludge. The irony is that the people pushing for this think they are gaining efficiency, when in reality, they are just losing their ability to understand their own system.

HostLet us pivot to something that takes a more granular approach to infrastructure. There is a project called celld, which is an open-source implementation of the Durable Objects model. For the uninitiated, Durable Objects is a serverless primitive that provides a single-threaded object with its own storage, mapped to a specific name. The folks behind celld are self-hosting this in Rust and SQLite, moving the state into user-controlled storage buckets. The claim is that by doing this, you make the failure domains explicit and inspectable.

GuestFinally, some sanity. I am a fan of any project that moves state away from a vendor's "magic black box" and onto a filesystem I can actually grep. The author is essentially saying, "I like the model, but I don't trust your proprietary scheduler." My only hesitation here, and looking at the Lobsters thread, danderson points out the, let us say, heavy use of em-dashes in their documentation. Which, honestly? That is a red flag for a certain kind of over-engineered "thought leadership" copy. And then rileylabrecque points out the, ah, generous amount of AI-generated comments in the source code.

HostDoes the use of AI in the comments or documentation invalidate the architectural approach?

GuestIt makes me wonder if they actually understand the memory management here. If you are going to roll your own distributed object store, I want to see the benchmarks and the failure injection tests, not a bunch of boilerplate comments generated by a model that hasn't the faintest clue what a race condition looks like in Rust. However, the move to decouple the programming model from the vendor is exactly the right instinct. If I were building a system that relied on object leases, I would want my state in a SQLite file on a disk I control, not trapped in an opaque API response from a cloud provider.

HostOur last topic involves the UTM team and their new project, Triton. UTM is a system for running virtual machines on Apple Silicon hardware using QEMU, which is a widely used open-source machine emulator and virtualizer. Triton is a Windows driver that enables native Direct3D 11 acceleration for those virtual machines by implementing the complex Windows Device Driver Interface.

GuestNow, this is impressive. Writing a Windows driver is a special kind of hell. It is a world of opaque interfaces and absolute, unforgiving hardware-level contracts. The fact that they are doing this to get decent performance on a virtualized Windows guest on macOS is, well, it is proper systems work. It is not just prompting a model to write a Python script. This is reverse-engineering the DDI and making it actually work.

HostThe Lobsters discussion took an interesting turn here. A user called mdaniel noted that even here, in a highly technical project, the authors felt the need to include a preamble about how AI tools amplify their work.

GuestIt is the current cultural tax, isn't it? You can't release a piece of open-source software without performing a little ritual of fealty to the AI gods in the blog post. A Lobsters user called hoistbypetard put it perfectly, saying they skipped reading that part because they wanted to see the, and I quote, "just how cursed this must be." That is the right attitude. If you are building a D3D11 driver for QEMU, you are deep in the trenches. No LLM is going to save you when you hit a kernel panic because your shader state is misaligned.

HostIt sounds like you approve of the technical ambition, even if you are tired of the marketing.

GuestI approve of anyone brave enough to touch the Windows kernel. It is a brutal, unloved corner of the stack. Triton is, at the very least, a real project with a real purpose. That is a refreshing change of pace from the "AI will write my app" crowd we started with today.

HostI think that is a fair place to leave it. A day of code-generated chaos and some actual, hard-won systems engineering.

GuestExactly. I think I am going to spend my weekend auditing some old C headers just to cleanse the palate. It is the only way to be sure I am still dealing with reality.

HostI appreciate the honesty, Fred. And thanks to everyone for tuning in. All the stories we talked about today can be found, along with those lively discussions, over on Lobsters. We will be back tomorrow. Take care, everyone.