当我拒绝AI生成的代码时,即使它能运行
When I reject AI code even if it works

原始链接: https://vinibrasil.com/when-i-reject-ai-code-even-if-it-works/

随着人工智能加速代码生成,主要的工程瓶颈已从编写代码转向代码审查。即使能够高效使用 AI 智能体,审查海量机器生成的差异(diff)也会导致严重的认知超载。 作者认为,当工程师对解决方案保持深度思维掌控时,AI 辅助编程的效果最为显著。如果工程师在不完全理解逻辑的情况下盲目接受 AI 输出,生成的代码往往缺乏可维护性、引入不必要的抽象,或产生难以推敲的系统复杂性。 归根结底,速度并非软件工程的首要目标,设计出适宜、可扩展且具备延伸性的解决方案才是。作者提醒人们警惕那种仅仅因为代码通过了 CI 测试就全盘接受的陷阱。相反,工程师必须作为严格的把关者,拒绝那些自己无法解释或捍卫的 AI 方案。编程智能体虽然是强大的工具,但它们尚无法取代工程师在架构决策中的角色。为了确保成果的可持续性,深度的人工监督依然必不可少;输出质量的好坏,更多取决于工程师整合问题背景的能力,而非大语言模型的复杂程度。

这篇 Hacker News 讨论探讨了人工智能生成的代码与专业工程标准之间的张力。许多参与者认为,虽然 AI 工具擅长快速原型设计,但“能运行”的代码并不等同于“优秀”或“易于维护”的代码。 一个反复出现的主题是,AI 往往会提出过于复杂的抽象方案,优先考虑即时功能而非长期稳定性。虽然参与者普遍认为 AI 适用于低风险任务、个人爱好项目或内部便捷工具,但他们警告不要将其用于生产关键系统。 主要的担忧在于技术自主权的丧失。工程师们认为,发布他们无法完全理解或掌控的代码会产生巨大的“技术债务”。职场中存在一种令人担忧的“中间地带”,即开发人员可能利用 AI 完成工单,却不去审查其背后的逻辑。最终,大家的共识是,人工监督至关重要;如果工程师无法解释或维护 AI 提供的逻辑,那么无论这些代码是否通过了初步测试,它在本质上都是不合格的。
相关文章

原文

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.

Can you trust the diff?
FIG. Can you trust the diff?

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 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.

联系我们 contact @ memedata.com