我为什么会拒绝 AI 写的代码,哪怕它能跑
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.
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.
I’ve been using coding agents for some time, and despite how impressive they are, they still need a great engineer guiding them to great solutions. Yes, coding agents can help you with this task with more than just writing code, but that doesn’t mean they can do it autonomously in a sustainable manner yet.
这篇还没有中文全文
该条目暂未提供中文翻译。标题/摘要已自动中译;本系统只对人工挑选的内容生成全文翻译。
挑中后 → markitdown 取正文 → 精翻 → 此处切换为译文