Clean Code, Broken Architecture: Why Review Can’t Catch a Bad Design Decision

AI can now produce code that looks great. Clean, follows best practice, passes every standard, sails through review. And the architecture underneath can still be broken.

It’s tempting to treat this as a new AI risk that needs a new kind of review. It isn’t, really. This happens all the time with human programmers too. Both humans and AI tend to stay at the abstraction level the task is formulated at. Ask for a thing, get exactly that thing, no questions asked about whether it should exist in the first place.

Say someone asks for a feature to download all the sensitive data. A programmer, or an AI, can just build that. It’ll work. It might even be well-written. Nobody stopped to ask if that’s a good feature to design in the first place, because that question sits one level above the task as stated, and nobody’s job was to ask it.

This is why code review won’t save you here. Review checks whether the code does what it was asked to do, cleanly. It doesn’t check whether it was the right thing to ask for. By the time something reaches review, the framing has already happened.

So the fix isn’t a sharper reviewer. It’s better instruction. If you want AI to be critical of design and architecture, you have to explicitly ask it to check for that, every time, before coding — not trust that it’ll surface on its own once the code exists.