2026-07-19 · Reviewing AI Code Is Not A Viable Argument

Transcript

Transcript. Paraphrased; sources in notes.md.

HostIt is July 19th, 2026. Welcome back. I am Daniel, joined as always by Fred, our resident skeptic who manages to find a dark cloud behind every silver lining in the tech world. Fred, I was reading through some discussions today about the state of AI in the development lifecycle, and I have a feeling you might have some thoughts.

GuestI have enough thoughts to fill a garbage collector, Daniel. And honestly, it is getting harder to keep up. Everyone is rushing to shove these LLMs into their IDEs, and the arguments for why we should trust them are becoming increasingly circular.

HostWell, you are going to love our first topic. There is a piece making the rounds on Lobsters arguing that we need to stop pretending reviewing AI-generated code is a sustainable way to work. The author claims that the cognitive load of verifying LLM output is actually higher than writing it yourself, and that we are misapplying developer productivity metrics to something that is fundamentally different.

GuestFinally, someone says it out loud. It is the intern problem. If you ask a junior developer to write a complex system, you check their work because you assume they do not know what they are doing yet. But with these models, you are essentially letting a hallucinogenic intern write code at light speed, and then you are expected to play detective to find the subtle logic errors that might have been hidden in that slurry.

HostOver on Lobsters, there is a fascinating pushback. A user called sunshowers points out that speed might be the wrong metric entirely. They argue that if you use these tools for things like property-based testing or better type structures, you are actually raising your standard of rigor, not just trying to type faster.

GuestThat is a clever framing, but it assumes the human operator is diligent enough to use the AI as a scaffolding tool rather than a crutch. To quote sunshowers directly, the value you get out of these tools mirrors the values you bring to them. That is the polite way of saying most people are just using them to generate more technical debt faster. Jamii makes a good point in that same thread, too, noting that we did not wait for a peer-reviewed study before adopting Rust or Git. We just saw they were better. But here is the kicker, Daniel: we knew *why* those tools were better. We can trace the memory safety or the version control history. With an LLM, you are just gambling on whether the next prompt will be the one that introduces a security hole.

HostSpeaking of productivity, our second story is about a study from METR. METR, for the uninitiated, is an organization focused on evaluating the safety and capabilities of advanced AI systems. They are admitting that their latest developer productivity experiment failed because they could not account for the fact that developers are now fundamentally unwilling to work without AI.

GuestIt is the ultimate confirmation bias. If you tell a developer they have to work with one hand tied behind their back, they are going to opt out. And of course, the productivity metrics are skewed. If the task scope changes from a one-day chore to a two-week project that only exists because the agent makes it possible, how do you even measure the delta?

HostA user called viraptor notes on the Lobsters thread that the experiment fails by design because it cannot account for tasks that simply would not be attempted without AI help.

GuestExactly. Viraptor is right to be fascinated by the estimation side of this. We are trying to use 2024-era benchmarking on 2026-era workflows. It is like trying to measure the speed of a jet engine with a stopwatch from a horse race. The disconnect is total. You cannot quantify productivity when the baseline of what is "possible" is shifting every single month.

HostLet us pivot to something that feels a bit more grounded. Freya 0.4 was released recently. Freya is a native GUI library for Rust that renders its own interface rather than wrapping platform-specific widgets. The author just did a massive rewrite, ditching their dependency on Dioxus to build a custom reactive model.

GuestNow, this I can actually get behind. Moving away from a massive framework towards a type-safe builder pattern? That sounds like someone finally decided they were tired of fighting a framework's macro-heavy DSL and wanted to see the actual logic. If you are going to build a UI in Rust, you should want to see the compiler breathing down your neck to make sure your state transitions are valid.

HostYou sound almost happy, Fred. Is there a catch?

GuestThe catch is that every time someone rolls their own reactive model, the surface area for bugs changes. But honestly? I would take a custom, type-safe implementation over a opaque macro-magic black box any day of the week. It is a bold move to cut ties with Dioxus, but if it gives you better IDE feedback and real compile-time checks, it is a win for the long-term maintainability of the library.

HostIt is certainly a refreshing change from the "add more agents" philosophy we were talking about earlier.

GuestIt is the difference between writing software and writing prompts. I know which one I prefer to debug at three in the morning.

HostI think that is a wrap on our dive into the latest from Lobsters. Are you planning to spend your weekend debugging someone else's AI-generated code or building your own GUI, Fred?

GuestI have a few things in my own codebase I have been refactoring that would make a great case study for why manual, type-safe work still beats a prompt, but I think I will spare you the lecture until next week.

HostI will hold you to that. Thank you, Fred. And thanks to everyone listening. All these stories were sourced from the discussions over on Lobsters. We will see you back here tomorrow.