LLMs aren’t lazy. They don’t cut corners because a simpler solution feels good enough. If they know how to solve something thoroughly, they will.
An LLM defaults to building when it should be buying. Not because it doesn’t know about existing libraries, it often mentions them, but because for an LLM, writing two hundred lines of implementation is the same cognitive effort as writing two lines of import. There’s no instinct to reach for the shortest path. The shortest path for the model is to implement it completely.
So reviewing AI-generated code has gotten more expensive. You’re reading code that’s technically correct but over-engineered, and you have to decide whether to accept the complexity or push back. That decision takes time. Making the case in review comments takes time. And because the same thing shows up repeatedly, you’re having the same conversation over and over.
On the other hand, rewriting is now cheap. If I identify code that’s more complex than it needs to be, in my own work or in someone else’s PR, I ask the AI to simplify it, use a library, cut a feature that isn’t required yet. The rewrite is often a quicker turnaround. The model that created the problem is also the fastest way to fix it.
The economics has changed. Reviewing is the expensive step now. Rewriting is not.
My workload has reorganized around this. I spend more time upfront in planning, deciding what should exist, what libraries we’re using, what the actual scope is, because that’s where I can head off complexity before it gets written. Then I implement, deploy to a test environment, look at what’s there, and identify what doesn’t need to exist or could be ten lines instead of a hundred. Then I rewrite that.
If something in review feels like too much, rewriting it later is not the sunk cost it used to be. That’s changed how aggressively I push back. The cost of flagging something and iterating is lower. The cost of letting it through is the same.