自动化的陷阱：何时值得自动化

维护者的眼光萎缩

几年前我写过一篇关于抽象化的文章。在考虑到 AI 辅助编码的背景下，我在这里重新审视它，因为我看到类似的问题正在出现。LLM 让生成代码比以往任何时候都更容易，但当我们看看接下来会发生什么时，情况就变得不那么清楚了。

当你构建一个供他人使用的抽象层或自动化系统时，你做出了一个决策——决定哪些信息对用户而言是重要的，哪些则不是。在编程中这极其困难。我们经常不小心隐藏了用户实际上需要或想要了解的信息。而且这可能会随时间变化，因为在软件中，上下文对我们如何以及构建什么有着巨大影响。

API 的世界由导入他人编写的代码的能力而繁荣发展——我们能够专注于自身问题和解决方案的独特方面。但选择使用一个依赖项有着我们往往没有认真对待的后果。这是一种权衡，我希望我们在与 AI 相关的讨论中更明确地谈论它。

⚠️ 我应该指出，我不认为 LLM 提示词是编程抽象，而是代码生成自动化，原因我在最近的演讲中一直在探索。

渐进式披露？

管理这种权衡的一种方法是提供某种逃生舱口，如果你愿意，你可以看到并配置底层实现，如果你不需要知道下面发生了什么，也可以忽略它。

这是我对自称赋权的代码平台持怀疑态度的地方。我不会说出公司的名字，但我最近尝试从一个面向没有编码经验的人的服务生成一个简单的静态网站。我将应用导出到 VS Code。实现不合理地过度设计了，有大量的 TypeScript 文件，但零文档。没有代码注释，没有 README，什么都没有。输出实际上是混淆的。即使作为一个经验丰富的开发者，我也很难使用这个代码库。

也许你在想这是否是一个边界情况，假设这些代码库不需要直接处理。我密切关注使用这些服务的人的账户，这不是我发现的情况。压倒性地，它们让你达到原型阶段，但为了将你的应用提升到下一个水平，你确实需要与代码进行交互。即使这些平台本身也微妙地改变了他们的信息传递来反映这一点。

界面不是 LLM

我提到的这些平台与例如在你的 IDE 中使用助手或 agent 有些不同。底层提示词和 LLM 脚手架对用户来说是部分或完全隐藏的。它们可以轻易指示模型优先考虑人类可读的实现并提供充分的文档——生成针对用户学习优化的程序，并作为构建的基础。那才是赋权。

这是拼图的另一个尴尬部分。为了向模型请求这样一个赋权的起点，你已经需要了解一些关于软件如何构建的东西。所以这排除了没有先前开发经验的任何人。

让我们谈谈权衡因素

以下是我认为在设计或使用代码生成自动化时有价值的一些考虑：

用户隐藏了哪些细节？

实现的决策是什么？这些决策是意外的还是故意的，什么在驱动它们？

这些决策是意外的还是故意的，什么在驱动它们？

这些决策如何能被改变？

用户现在不知道，但之后可能需要了解什么？

花一时刻回答这些问题可能会帮助我们对我们构建的抽象层以及我们选择采用的抽象层做出更好的选择。

赋权是什么样的？

有时我想象一个像 Glitch 这样的平台，但它从提示词生成应用，同时优先考虑扩展的易用性和后续的学习——Glitch Hello 应用精心设计的目的。这样的东西在技术上是绝对可行的。但现实是软件公司的决策由经济动力决定。它们被激励优先考虑参与度而不是赋权——在许多情况下，这看起来像是平台锁定。

我确实看到人们在使用 LLM 构建软件时被赋予权力，通常在他们工作场所或社区中其他人类的支持下。这项技术在为开发者技能打开大门方面拥有巨大的潜力，但这不会偶然发生，我们应该审视那些表面下经不起推敲的赋权声称。

责任制是什么样的？

即使是专业开发者也在经历一个平行的问题，因为 AI 生成的代码更难维护，随着时间的推移增加了维护负担。使用 LLM 生成代码正在减少我们构建对代码库的强大心智模型的能力。再次说，我不相信这必须是这样的情况，我们可以使用这些自动化，同时仍然保留代理权和理解。

对于在职开发者来说，责任制的问题在这里起着巨大作用。当事情出错时，谁要对此负责，后果是什么？理解你正在提交给代码库的东西有着我认为我们尚未完全解决的含义。

随着我们开始发现使用 LLM 生成代码的长期后果，我希望看到更多诚实的谈话，谈论在短期和长期都真正涉及赋权的内容。因为如果我们想要的话，我们可以为此构建。

一些评论可能仅对已登录的访问者可见。登录以查看所有评论。

如需后续行动，你可以考虑屏蔽此人和/或举报滥用。