别再误导我了——人工智能短期内不会取代人类开发者

我最近看到很多类似的讨论：

人工智能将构建你的整个软件产品，而你需要的人力将大幅减少。

每次读到这篇文章，我都感觉自己被误导了，而且担心这会让那些刚开始软件开发的人觉得这是一项糟糕的时间投资。

注： HN 上曾就此帖展开过长时间的讨论，您可以点击此处阅读。

我本人也是一名开发者（连续三年提交超过 2000 次代码），自从两年前 LLM（生命周期管理）技术流行起来以来，我一直在Trieve 公司大量使用 LLM。我了解几乎所有的“AI 工程”技巧，尤其是在检索方面。

让我来讲述一下最近一起公关事件：

Trieve 的代码库最初是为名为 Arguflow 的单租户应用程序设计的。因此，我们当时认为只有我们自己的应用程序会使用它，所以并没有花太多时间编写高质量的 API。

最终，我们转型为一家 API 优先的企业，情况也随之改变。我们为最常用的路由创建了 V2 响应类型，这些类型更加简洁，也更容易解析。

不幸的是，这导致我们的 OpenAPI 规范中包含大量枚举类型，使得通过该规范生成的 SDK（无论是否开源）都显得杂乱无章。我早就知道这是一个痛点，但最近yournextstore团队再次让我意识到这个问题，所以我决心要解决它！

多亏了hey-api（由
@mrlubos开发）的出色功能，它支持在生成的类型之上手动定义路由，这个问题才得以相当解决🙏。

法学硕士根本无法胜任这类工作！！

我需要打开lib.rs 文件，找到所有 V2 类型的路由，查看它们的响应类型定义，回忆起枚举中 V2 响应字段的名称，修改每个有问题的路由中的相应行，最后更新导入语句。虽然修改行不多，但需要大量的领域专业知识。

在我的 PR 获得批准后（请点击此处查看），我需要发布我们客户端的新版本，并向 yournextstore 提交 PR，以删除现在不必要的用于确定 V1 和 V2 类型之间的代码。

1. LLM 根本无法将 SDK 代码更新为 V2 响应类型。
2. LLM 无法成功配置 CI 操作，使我无需自行发布。
3. LLM 不了解修复问题后会产生的下游影响，即更新 yournextstore 的代码。

请不要再误导人类开发者，让他们以为人工智能会让他们失去专业知识。我们离那种情况还很远。