The Engineer's Dilemma in the Age of AI Coding: When Nobody Reads Code Anymore

An Anonymous Rant From Someone Who's Had Enough

An engineer who had been at a large company for just two weeks posted this complaint online: spec documents, code, tests, PRDs, tickets, ticket resolutions, reports — everything generated by Claude Code. Nobody on the team is happy about it, yet they're all being pushed to ship as much as possible.

The picture he painted was deeply unsettling: management keeps saying "pushing code isn't the bottleneck, so why are we still slow," and engineers end up working 12 to 13 hours a day just to press Enter. From L1 to L7, everyone is doing the same thing — talking to Claude. Nobody is reading anything, nobody is fixing bugs, and "nobody is thinking anymore." He described the experience as soul-sucking.

This rant resonated so widely because it struck a nerve running through the entire software industry right now: when AI can generate everything, where does an engineer's value lie? Prominent streamer ThePrimeagen spent a significant portion of a recent video responding to this topic, and his perspective is worth serious consideration by anyone in the field.

The Whiteboard Defense: A Standard for Responsible AI Use

ThePrimeagen referenced a concept put forward by Mitchell Hashimoto (co-founder of HashiCorp) called the "whiteboard defense," calling it the baseline for responsible AI use:

I should be able to pull you aside at any time and have you explain any customer-facing system you've delivered. You should be able to clearly articulate how it works and defend the decisions you made.

Crucially, Hashimoto doesn't require line-by-line familiarity with the code, or even knowledge of exactly which functions were called. What he cares about are more fundamental questions: Why X instead of Y? What happens when there's a malicious actor? What data structures were used here, and why? Where does this system fail?

This is precisely the opposite of what the rant described. It demonstrates that understanding what you built — and why you built it that way — still has value. If you're delivering a product to customers and you're ultimately accountable for it, you should at least slow down enough to understand some of the mechanics under the hood. ThePrimeagen believes that people who can answer these questions not only build better products, but are also far less likely to fall into that soul-emptying state of "full Claude, nobody reads the code."

Mitchell Hashimoto is the co-founder of HashiCorp, the company behind infrastructure-as-code tools like Terraform and Vault. With his deep, long-standing involvement in engineering practice and toolchain design, his views carry significant authority in the engineering community. The essence of the "whiteboard defense" concept lies in separating the ability to deliver from the act of understanding — in the AI era, these two things are decoupling at an unprecedented pace. Traditionally, shipping code and understanding it were nearly the same thing, because the cost of production itself forced engineers to work through the logic. But when the cost of generation approaches zero, engineers can potentially deliver complex systems without understanding them at all. This makes "understanding" something that needs to be explicitly required and evaluated, rather than treated as a natural byproduct.

This Has Actually Never Changed

ThePrimeagen's core argument might come as a surprise: what's happening now is not fundamentally new.

He quoted Uncle Bob (Robert C. Martin): "What is happening has always been happening. The irony is that nothing has changed. Management is still asking why everything takes so long."

He recalled his first professional job in 2007: needing to ship a feature while calculating "how many corners to cut and how fast to get it live." From 2007 through his decade at Netflix and up to his departure in 2024, that conversation never changed: we need to ship features — which corners do we cut? What can wait until after launch? What has to be handled now?

The only thing that's changed is that people feel more distant from the code. The kind of thinking that considers "what this means for the future codebase" is quietly slipping away from people's minds. The problems didn't appear out of nowhere because of AI. Anyone who's taken the time to review that kind of "Schrödinger's code" knows exactly what this means — the code runs fine, everything seems normal, but the moment you open it, you're horrified: how on earth is this thing actually working?

Learn to Say No — Don't Be a "Yes Engineer"

In ThePrimeagen's view, the antidote to many of these problems is relearning how to say "no" — refusing to be the kind of "yes engineer" who just pulls features on demand.

Before AI, engineers had the leverage to say "things take time." Now, saying yes has essentially zero cost. Any good programmer knows that if you don't set guardrails, if you don't think things through, if you don't ask the right questions, if you don't genuinely engage with the development process, and if you can't answer those fundamental questions — what you produce is complete garbage. Working in a bad codebase is miserable, whether that code was written by a robot or whether you're the one stuck rewriting it.

A Fractured Software World

ThePrimeagen proposed a "behind-the-curtain theory" to explain why people's experiences with AI coding are so polarized: we live in a divided world.

On one side is a large group of people who are essentially building "one website connected to one server, with data in a remote database and a remote login system." In this world, duct-taping things together magically works, because the problem space is fairly straightforward: there's a server, there's a client, and from the outside it's a "solved" domain. When these people use AI, they come to believe that all problems are solved.

On the other side are people dealing with multiple servers and far more complex interactions. Once you enter that world, the complexity and chaos make it impossible to "let Dario drive and just steer toward product success." That approach doesn't work for anything beyond the simplest software — eventually the debt comes due: you've chosen the wrong abstractions in a few places, and unwinding them will be a hellish experience.

The Dario mentioned here is Dario Amodei, co-founder and CEO of Anthropic — the company behind Claude. The phrase "let Dario drive" is a metaphor for handing all decisions over to AI autopilot. On a simple, straight road, this might be fine — but the moment you encounter compounding system complexity or architectural forks in the road, an autopilot without human engineering judgment will lose control. This metaphor also echoes the broader ongoing debate about the boundary between AI autonomy and human oversight: the limits of a tool's capabilities often only become clear after something goes wrong.

The Most Worrying Question: How Do Junior Engineers Actually Grow?

If there's something in this discussion that genuinely troubles ThePrimeagen, it's the question of how newcomers develop.

He admitted honestly: if he were placed in an environment where "everything is written for you," he's not sure he would have been able to actually learn. He needed a difficult environment — one that forced him to really dig into things.

He cited the author of Clay (an immediate-mode GUI library) to articulate this Catch-22: senior engineers can explain systems because they once built them by hand. Junior engineers, meanwhile, are expected to "generate" code rather than write it themselves. The problem is — how can someone truly understand what good system architecture looks like if they've never sat down and built a system from scratch?

The "whiteboard defense" is easy for people who've spent years accumulating hands-on experience. For those who have never really learned properly and can't code very well, it's nearly impossible. ThePrimeagen says he still practices what he preaches: opening a text editor, writing code by hand, personally implementing specific libraries and major architectural decisions — because he needs to feel them, needs to understand whether they're actually good. He even jokes self-deprecatingly that maybe he's just too slow, and reading documentation alone isn't enough for him to understand things — he has to sit down and write it out.

The Clay mentioned here is an immediate-mode GUI library developed by Ryan Fleury. Immediate-mode GUI stands in contrast to "retained mode" frameworks like Qt or WinForms: retained-mode frameworks maintain a persistent tree of UI components in memory, with the framework managing state and redraws; immediate mode, by contrast, re-describes the entire UI from scratch on every frame, with all state managed by the caller and no UI objects retained by the framework. Immediate mode is popular among game developers and tool builders for its clear control flow and ease of debugging, but designing a truly usable immediate-mode API requires deep understanding of rendering pipelines, memory layout, and calling conventions. Ryan Fleury himself is known precisely for his style of "deriving architecture from first principles, without relying on existing frameworks" — which gives his argument that "you must build it yourself to truly understand it" direct, lived-in credibility.

Closing Thoughts: We Should Be Living in a Better Era

ThePrimeagen's final reflection is striking: we should be living in an era where we can build software faster and more robustly than we could five years ago — this should be an exciting time. Yet the reality is that everyone seems to be suffering.

Technological progress hasn't automatically brought happiness. The problem was never AI itself — it's whether we've retained the capacity to understand, to think, and to refuse. When shipping speed becomes the only goal, when nobody reads the code anymore, what gets hollowed out isn't just the engineer's soul. It's the entire industry's ability to cultivate the next generation.