Post

HN
Hacker News

When I reject AI code even if it works

With implementation getting faster and faster, the real bottleneck moves to reviewing the volume of code generated by AI. Iโ€™m not even talking about your coworkersโ€™ (and their agentsโ€™) PRs, but your own git diff after your coding agent has finished its job.

Even when I follow good practices โ€“ like starting with the plan mode, dividing big tasks into phases, and shipping small changes โ€“ I still feel cognitive overload when reviewing something I havenโ€™t actually thought through myself.

Before coding agents, when given a task, I would explore the codebase, think of different solutions, experiment, and only then implement. That could take days of consolidating all that context. When I finally submitted that PR, confidence was higher, and explaining each of my changes to my coworkers was easier.

I have to admit that with AI, completing big tasks still takes me days. More often than not, I reject all changes made by AI and start over. The difference between the first session and the second is not the LLM model, but the person behind the screen. With more time to consolidate the problem Iโ€™m trying to solve , I can drive the agent to a better solution instead of being driven by it.

More and more, I reject AI code for the same reasons:

Itโ€™s not uncommon to see engineers accept AI-generated changes too quickly, and that is why I advocate for required human review in conjunction with AI reviews. The reality is that code that runs and makes the CI green can still be a bad solution, and engineering has always been about implementing adequate, scalable, and extensible solutions.