When I reject AI code even if it works — Vinicius Brasil<br>With implementation getting faster and faster, the real bottleneck moves to<br>reviewing the volume of code generated by AI. I’m not even talking about<br>your coworkers’ (and their agents’) PRs, but your own git diff after your<br>coding agent has finished its job.
Even when I follow good practices – like starting with the plan mode, dividing<br>big tasks into phases, and shipping small changes – I still feel cognitive<br>overload when reviewing something I haven’t actually thought through myself.
GENERATED BETTER FIT
Before coding agents, when given a task, I would explore the codebase, think of<br>different solutions, experiment, and only then implement. That could take<br>days of consolidating all that context. When I finally submitted that PR,<br>confidence was higher, and explaining each of my changes to my coworkers was<br>easier.
I have to admit that with AI, completing big tasks still takes me days. More<br>often than not, I reject all changes made by AI and start over. The<br>difference between the first session and the second is not the LLM model, but<br>the person behind the screen. With more time to consolidate the problem I’m<br>trying to solve, I can drive the agent to a better solution instead<br>of being driven by it.
FIG. Can you trust the diff?<br>More and more, I reject AI code for the same reasons:
I reject AI code when I can’t explain the approach in my own words.
I reject AI code when the diff is bigger than the problem.
I reject AI code when it introduces abstractions before proving they’re needed.
I reject AI code when it works locally but makes the system harder to reason about.
I reject AI code when I’m trusting the output more than my understanding.
It’s not uncommon to see engineers accept AI-generated changes too quickly, and that is<br>why I advocate for required human review in conjunction with AI reviews.<br>The reality is that code that runs and makes the CI green can still be a bad<br>solution, and engineering has always been about implementing adequate,<br>scalable, and extensible solutions.
I’ve been using coding agents for some time, and despite how<br>impressive they are, they still need a great engineer guiding them to great<br>solutions. Yes, coding agents can help you with this task with more than just<br>writing code, but that doesn’t mean they can do it autonomously in a<br>sustainable manner yet.