Back in 2008, when Robert C. Martin published Clean Code, the software world looked completely different. There was no GitHub Copilot, no Claude writing entire functions while you go grab a coffee, and most conversations about code quality revolved around human teams trying not to kill each other during code review. Almost two decades later, the book is still sitting on every dev's shelf, right next to The Pragmatic Programmer and Design Patterns. But a few years ago an uncomfortable question started popping up in forums and on Twitter (X now, though nobody's really adjusted to the name) — what if Uncle Bob's principles are, in practice, making software slower and more convoluted than it needed to be? The spark came from Casey Muratori, back in 2023, with a video called "Clean Code, Horrible Performance." He took an actual example straight out of the book, applied the principles to the letter — polymorphism, Single Responsibility Principle pushed to its limit, short functions stacked on top of each other — and showed that the "clean" version ran dozens of times slower than a more direct, almost ugly version written like it was 1995. Casey's underlying critique wasn't new to anyone who follows him: he'd been saying for years that most modern software runs at less than a twentieth of the efficiency the hardware would allow, and that this isn't fate, it's an architectural choice. The video blew up. Uncle Bob responded, and the interesting part is the conversation didn't stay on social media — the two of them ended up on GitHub, in a long and fairly technical document, going point by point through where they agreed and where they didn't. And here's the part that usually gets lost when someone sums this whole thing up in three LinkedIn lines: Uncle Bob didn't deny the problem. His response was roughly this — if you're squeezing every nanosecond out of a bank of GPUs, clean code might not be for you, at least in the tightest inner loops; but if you're trying to squeeze productivity out of a thirty-person team over five years, clean code might be exactly the right strategy. That's not a surrender, it's drawing a boundary around the context. And honestly, this is where most posts on the topic fall apart — they treat it like a boxing match with a winner, when really it's two different problems fighting over the same name. It's also worth showing the emotional side of this, because that's what actually makes a senior dev stop scrolling. A while back there was a post on dev.to, half ironic, half exhausted, telling the story of a senior engineer who spent three days refactoring a feature that worked perfectly fine — just because the functions were over ten lines long. The result: two new bugs, and code that was harder to follow than before. Anyone who's worked on a large team has lived through something like that, or been that person during a more dogmatic phase of their career. That doesn't make the book wrong, but it shows how certain rules turned into ceremony instead of tools. What changes everything now, in 2026, is a factor that didn't exist when this debate started — the person writing the code isn't always a person anymore. Some AI labs have forecast that AI could be responsible for up to 90% of all new code written by the end of 2025, a number worth questioning on its own but useful for sensing the direction things are heading. There's also a study from Cambridge and Microsoft on how developers actually use Copilot day to day that found something telling: roughly half of "coding" time isn't writing anymore, it's reviewing what the AI suggested, and 35% of that time is spent just double-checking whether the suggestion is even correct. If most of your day has quietly turned into reading instead of writing, the question changes shape — it's no longer just "is this code pleasant to write cleanly," it's "can this be audited fast, under pressure, by someone who didn't write it." On the quality side, there's harder data now too, not just opinions. A recent study compared over 500,000 code samples, some written by humans, some generated by ChatGPT, DeepSeek-Coder, and Qwen-Coder, measuring defects, security vulnerabilities, and structural complexity. You don't need every number to get the point — the comparison exists now, which means the conversation about AI-generated code can finally lean on data instead of vibes. And that shifts what "clean code" even means, from "what looks elegant" to "what's auditable, testable, and secure when half your team is a model." Maybe the right question was never "is Clean Code outdated," but "who does it still make sense for, exactly as written in the book." It still makes sense for people leading large teams with high turnover. It makes a lot less sense for someone working solo on a game engine trying to squeeze one more frame out of the GPU. And it makes even less sense, or maybe sense in a completely different way, for someone spending their day reviewing pull requests an AI agent generated at three in the morning. Uncle Bob wrote a book for the world of 2008. The world shifted again, and maybe the next chapter of this argument won't even be about performance versus readability — it'll be about what "readability" even means once the first reader isn't human anymore. If you found this post helpful, I invite you to participate by commenting or voting. Help us make sure our work reaches more people.