我曾以为仪表盘在向我传递好消息。
我的团队迅速采用了人工智能辅助编程，有一段时间，情况看起来正如所有人承诺的那样。关闭的工单更多了。周期时间缩短了。更多的拉取请求得以推进。同样的团队，产出更高，阻力更小。
我对此感觉良好。
但这正是我出错的地方。
对我而言发生转变的时刻
让我发生转变的时刻并非某种大规模的服务中断或戏剧性的失败。它比那更安静，说实话，这也让情况变得更糟。
我们发布了一项变更，它通过了所有测试， cleared 代码审查，并顺利部署。两周后，我们发现它在我们的测试环境未能复现的负载条件下，正在逐渐降低某条重试路径的性能。
当我请那位工程师向我讲解这项变更时，他们做到了。代码合乎逻辑。他们理解每个部分的作用。
但是，当我问如果下游服务变慢（不是宕机，只是变慢）会发生什么时，出现了一阵停顿。
这并不是因为他们能力不足。
而是因为他们从未需要问过这个问题。
人工智能编写了处理代码，测试通过，整个问题在有人提出疑问之前就已向前推进。
就在那一刻，仪表盘不再向我展示真相。
并不是因为它在撒谎。事情确实进展得更快了。
只是它没有向我展示那些至关重要的部分。
我没预料到的情况
我没预料到的是，人工智能会让团队在实际变得更强之前，看起来显得更有能力。
我过去是通过陷入困境来学习的。不是那种有趣的困境。而是那种晚上十一点的困境。那种你盯着堆栈跟踪信息看几个小时，三次追逐错误的理论，并慢慢建立起一种直觉的困境，这种直觉会告诉你，某些东西在技术上可行，但仍然不安全。
这种直觉并非来自完美的答案。它来自摩擦。来自吃亏上当。来自目睹在压力下失败的情形。
我认为这部分是我们尚未真正替代的。
当初稿免费生成时，许多早期的学习过程就被跳过了。你仍然能得到产出。你仍然能看到进展。但你不会自动获得那种曾在挣扎中建立起来的判断力。
也许这种判断力会在其他地方重建。也许是我忽略了它。但我尚未看到它自然发生。
差距不会一次性全部显现
第一个差距通常出现在代码审查环节。
现在，一名工程师就能生成过去需要几个人才能完成的拉取请求量。审查者不堪重负。每个人开始更快地阅读代码。如果测试通过且没有明显的问题，它很可能就会获得批准。
我开始看到一些拉取请求，其中的测试虽然存在、整洁，却与实际的故障模式完全脱节。这是一种非常特定的问题。它看起来像是严谨。但它并非严谨。
下一个差距出现在调试环节。
如果每一个错误都可以粘贴到聊天窗口中，并在三十秒内转化为一个看似合理的修复方案，你就会停止追问它为何出错。症状得到了修补。教训却没有被吸收。然后，下一次类似的故障会以稍有不同的形式出现，而团队花费的时间比应有的更长，因为没有人真正从第一次故障中吸取教训。
接着，第一次真正的事故发生了，这时你才会发现哪些能力已经建立，哪些没有。
我有一位工程师，几个月来交付表现良好。扎实的拉取请求。快速的交付。良好的反馈。然而，他遭遇的第一次真正事故却很艰难。并非恐慌。只是他没有在故障系统中投入足够的时间，以至于当答案不明显时，不知道如何缩小问题范围。
这需要反复练习。我不知道还能怎么表达这一点。
我们实际尝试的做法
我们
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
