一位资深开发者对AI编程的看法

去年，我和一位拥有大约十二年后台经验的同事一起调试一个Rust服务。

我们在排查一个内存问题，它已经悄悄地在生产环境中造成了两个星期的麻烦。没什么戏剧性的。只是细微的、令人烦躁的那种bug，会让你开始质疑自己对系统的理解。

在某个时刻，他停下来，看着代码，说了一句我至今一直在思考的话。

"现在每个人都在用AI写代码的问题在于，没有人再犯错了。而如果你不犯错，你就学不到任何东西。"

他不是带着怨气说的。他说这话的方式，像是一个人把某件事想了很久，终于找到了合适的措辞。

从那以后，我一直在想这句话。

1、过去一年我亲眼目睹的事情

我不反对AI工具。我用它们。我认识的大多数工程师都用。这不是我们要讨论的。

我们要讨论的是，当一个工具开始替你思考，而不是帮助你思考得更快时，会发生什么。

以下是我实际观察到的。在过去十八个月入职的初级工程师写的代码看起来很干净，在测试中也运行良好。但当生产环境中出了问题——一些真正出乎意料的问题——他们的反应是僵住，这在几年前入行的工程师身上不会出现。不是因为他们能力差。而是因为他们从未培养出那种来自被一个问题困住三个小时、无法甩手不管的本能。

我说的这种本能很难命名。它大概是：当一切看起来都正确，而系统仍然表现异常时，你往哪里看？你首先怀疑什么？当证据确实模糊不清时，你如何形成假设？

这种本能来自迷失。具体来说，来自迷失后不得不自己找到出路。

如果你从事后台开发，你早就知道困难的问题很少是语法问题。

一个看起来正确但性能极差的数据库查询。一个处理了98%输入、却悄悄破坏了其余2%的Rust服务。一个在本地环境和生产环境中行为不同的Docker容器，追溯原因花了两天，最终发现是一个环境变量。

这些问题不会屈服于提示词。它们只会屈服于理解。而理解来自曾经把事情做错、看着它们失败、不得不从日志、指标和有根据的猜测中重建实际发生的事情。

一旦你有了那种理解，AI工具可以帮助你走得更快。但它不能给你那种理解。

说出来的时候这很明显。但看看行业现在的谈论方式，你会以为我们已经忘了这一点。

他们担心的是更安静的事情。

他们正在看着培养出他们的那条管道停止运转。曾经存在的初级岗位——那些你写出不完美的代码、被人审查、从审查中学习的岗位——正在消失。公司在精简运营。以前分给三个初级工程师的工作，现在给了一个拥有更好AI工具的中级工程师。

季度数据看起来很好。知识传递看起来很好。代码库看起来很好，至少目前如此。

但是五年后，那些足够深入理解系统以正确监督AI输出的工程师在哪里？如果培养那种理解的路径不再存在，他们从哪里来？

我尊敬的一位工程师把它描述为吃掉种子粮。你在这个收获季节省了钱。但明年春天你无物可种。

我不会告诉你避免使用AI工具。那会是糟糕的建议。

但我会告诉你，我注意到是什么区分了真正在进步的工程师和只是变得舒适的工程师。

那些在进步的人，用AI加速他们已经理解的部分，并且刻意自己完成困难的部分。他们在寻求帮助之前先阅读错误信息。他们在验证自己是否正确之前先形成关于问题所在的假设。他们在不舒服的地方多待一会儿，比感觉必要的更久。

那些变得舒适的人，把不适感完全外包了。代码能工作。PR被合并了。从每个可见的指标来看，他们都是高效的。而且他们悄悄地在自己的理解中制造了一个缺口，这个缺口在它突然变得非常重要之前不会显现。

那个缺口会在最糟糕的时候出现在生产环境中。它会出现在他们非常想要的职位的系统设计面试中。它会出现在资深工程师要求他们讲讲自己的推理过程，而他们意识到自己没有推理，只有输出的时候。

AI不会取代好的工程师。这很可能是真的。

但它可能会造就一代非常擅长看起来像好工程师、但实际上并不是好工程师的工程师。在某个时刻，这些工程师将会运行重要的系统。做出难以撤销的架构决策。在没有人完全理解的代码库上监督AI输出。

那天和我一起调试的资深开发者，在大约四分钟的对话中就能判断一个人是真正理解自己在做什么，还是在不理解的情况下进行模式匹配。他从多年观察系统以只有在深入理解时才有意义的方式失败中，培养了那种本能。

他正在考虑离开这个行业的人之一。

不是因为AI威胁了他的工作。而是因为他不确定这个行业还会不会重视他擅长的事情。

这比任何我读过的关于模型能力的基准测试都更让我困扰。

汇智网翻译整理，转载请标明出处