默认情况下,我反对阅读 AI 生成的代码。如果每一行生成的代码都需要我审查,那么我的阅读速度就会成为整个流程的上限。对于一段有问题的实现,我通常宁愿把它应该做什么说清楚,然后让它重写,也不愿花更多时间去弄明白它为什么写错了。在例外情况下我仍然会检查代码,尤其是高风险的逻辑,或者那些我无法用其他方式解释的失败。

我也仍然喜欢手写代码。有些东西我会仅仅为了亲手做出来的满足感而去写。但当优先级是快速交付生产软件时,这种偏好并不足以成为手动实现的理由。

那么,开发者应该把时间花在哪里?

首先,是决定哪些东西可以不用构建。一个可以砍掉的功能,一个不需要的抽象,一个不必单独拆分的服务。AI 让我更愿意尝试复杂的东西,但事后我仍然要为这些复杂性负责。

然后是理解系统。我需要一张精确的心智地图:什么调用什么 ,状态存在哪里,哪个服务负责哪项职责,失败如何在工作流中传播。没有这些,我怎么能给 AI 有用的指令?我会在不理解影响范围的情况下要求修改。目前,我认为这些决定是我的责任。

最需要解释的部分是验证。如果我不逐行阅读,我就需要另一种方式来确定实现的行为是否正确。我想要一个模块化的系统、大量的集成测试、聚焦的单元测试,以及针对重要流程的端到端测试。我宁愿从一开始就为此设计,而不是事后补救。

这些测试还需要一个能让我在不同层级运行它们的执行环境。我应该能够在不启动整个系统的情况下测试单个服务,并单独测试那些协调多个服务的编排器。例如,对于一个在超时后重试的工作流,我想验证这次重试是否会重复执行一个本应只发生一次的操作。决定测试必须证明什么,仍然是我需要做的工作。

我还需要区分明天就能改变的决定,和那些会把我困住的决定。替换一个小函数和把整个系统迁移到另一种编程语言,是截然不同的承诺。后者值得在实现开始之前就认真对待,无论 AI 能多快把它生成出来。

有时我还需要停下开发。下一个功能可以等一等,先修复那些正在变得脆弱或难以测试的部分。向 PM 解释这一点,光说”技术债”是不够的。哪些改动已经变得有风险?什么在反复出问题?整合现有系统究竟能改善什么?

这就是为什么我认为沟通会成为这份工作中更重要的部分。把系统装在脑子里有助于我给 LLM 写提示词,但其他开发者和 PM 也需要理解我的推理。当我认为我们应该简化某个东西、改变方向或停止添加功能时,我需要用我们正在构建的系统中的具体细节来解释原因。