软件工程师正日益发现自己处于一种交付并非由其编写且未完全理解的代码的境地。Meta 的工程师 Ali Hamie 在最近的一篇帖子中强调了这一转变,他将与 AI 生成的代码共事描述为感觉像是一个“黑盒”。这种紧张局势的核心在于 AI 的速度:由于模型可以在几秒钟内生成数千行代码,传统的逐行验证做法变成了一个瓶颈,甚至可能破坏 AI 本应提供的速度。这造成了一个两难境地:工程师必须在放慢速度以审计每一个细节,或者为了保持动力而对代码块进行“橡皮图章式”的快速审批之间做出选择。

关于使用 AI 交付代码并失去代码理解力的 LinkedIn 帖子标题。
Ali Hamie 的帖子突出了 AI 驱动的速度与失去深度代码理解力之间日益增长的紧张关系。www.linkedin.com

这张图片代表了 Ali Hamie 描述的关于 AI 生成代码的“黑盒”困境的来源。

为了应对这一转变,一些开发者提倡向“架构式”工程转型。与其让 AI 模型设计整个系统,一些人建议先建立严格的抽象层级和参与者——在高层级上决定组件如何交互——然后再利用 AI 来填补实现上的空白。这种方法允许工程师即使不熟悉每一个内部逻辑门,也能保持对系统职责的心理地图。另一些人认为,工程师的角色正默认演变为“首席工程师”:人类提供设计和约束,而 AI 则充当负责实现细节的初级开发人员。在这种范式下,主要责任从编写代码转向设计系统并通过严格测试来验证输出。

然而,这种转变在长期稳定性和技能保留方面引入了重大风险。对于“氛围编程”(vibe coding)趋势——即在没有深度验证的情况下基于高层意图交付代码——的批评者警告称存在“责任缺失”。如果系统在凌晨 3 点的高峰负载下崩溃,概率模型无法承担责任;交付它的人类必须能够对其进行调试。此外,还有关于“技能退化”的担忧,即新一代工程师可能会因为缺乏从第一原理构建的基础而失去进行深度代码审查的能力。为了减轻这些风险,许多从业者强调“信任但验证”的模型,其中重点转向详尽的测试套件、自动化关卡,并专门利用 AI 来可视化和解释它帮助构建的系统,确保“黑盒”保持足够的透明度以供安全管理。