过去十年中，计算机用户常被迫执行无意义的任务，如创建账户、确认邮件等，如今随着AI生成代码的普及，开发者也开始被迫适应AI对API设计的“意见”。例如，某些公司因AI频繁建议而添加了原本不存在的功能或方法。这种现象既有助于标准化开发，也带来了一种独特的测试方式，但整体上仍让人感到奇怪。

文章标题：Gaslight-driven development（煤气灯驱动的开发）

主要内容总结：

在过去十年中，使用计算机的人都知道，执行无意义的任务是计算机体验的一部分。数以百万计的人创建账户、确认电子邮件、关闭通知、解决验证码、拒绝Cookie、接受条款和条件，并不是因为他们特别想要或需要这样做，而是因为计算机告诉他们这样做。我们已经在为机器服务。

现在，有一种新的方式来服务我们的硅基霸主。大型语言模型（LLMs）开始对API的外观提出意见，而且由于90%的代码将由AI编写（预计从2025年9月开始），我们别无选择，只能遵从。

例如，Soundslice因为ChatGPT不断告诉人们某个功能存在而添加了该功能。在Instant中，我们原本使用tx.update来插入和更新实体，但LLMs却一直写tx.create。最终，我们也不得不添加了tx.create。

这种行为是好是坏？感觉确实有些奇怪。从某种意义上说，这是有帮助的：LLMs已经看过数百万个其他API，并建议最明显的事情，这也是每个开发者首先会想到的。

这也是一种独特的测试设备：如果开发者错误地使用你的API，他们会责怪自己，阅读文档并修复代码。最终，你可能永远不会知道他们遇到了问题。但有了ChatGPT，你可以随时体验“新手的视角”。

当然，如果你试图做一些新颖和独特的事情，这种方法就不起作用了。LLMs只是“无法理解”。但有多少人正在做新颖和独特的事情呢？也许，API并不是展示聪明才智的地方？也许，在大多数情况下，做最明显的事情确实是最好的？

欢迎来到新时代。AI不仅仅是在使用我们给它的工具，它现在对这些工具应该如何制作有自己的看法。而且，它不是在礼貌地询问，而是通过“煤气灯效应”让每个人都认为事情一直都是这样的。

图片标记：无

主要观点总结：

1. LLM对代码设计的影响

   • 观点1：LLM开始影响API设计，开发者可能被迫接受其建议，甚至无法反驳。
     • 引用1：“LLMs started to have opinions on how your API should look. Just submit to the wishes of the overlord, resistance is futile.”
     • 引用2：“We see the same at Instant: for example, we used tx.update for both inserting and updating entities, but LLMs kept writing tx.create instead. Guess what: we now have tx.create, too.”
   • 观点2：LLM的建议可能误导开发，甚至导致不必要的功能添加。
     • 引用1：“If it were somehow a human that was consistently and confidently handing out made up programming advice about one's products, would companies still respond by just adding whatever imagined feature?”
     • 引用2：“I feel offended I even need to point out how bonkers it is to alter a single line of code simply because some LLM extruded incorrect synthetic text.”

2. LLM的局限性

   • 观点1：LLM本质上是高级自动补全工具，不应被过度神化。
     • 引用1：“It’s just a really, really, really good autocomplete and sometimes I find thinking of it that way cleans up my whole mental model for its use.”
     • 引用2：“To those that still believe that a bunch of data loaded into memory can represent anything intelligence, I have some bad news for you.”
   • 观点2：LLM无法真正理解语义，其建议可能基于错误的前提。
     • 引用1：“If a function can both insert and update, it should be called 'put'. Using 'update' is misleading.”
     • 引用2：“These were design choices made by humans, not computers.”

3. 未来编程原则的变化

   • 观点1：未来的编程原则可能更关注代码的可索引性和上下文适应性，而非传统的最佳实践。
     • 引用1：“Future coding principles would be around whether your agentic IDE can index it well to become context aware.”
     • 引用2：“We will index on maintainability of the code, as code will become disposable as rate of change will increase dramatically.”
   • 观点2：LLM可能帮助统一命名规范，减少开发中的认知负担。
     • 引用1：“It’s great whenever some weight / synapse strength bits can be reallocated from idiosyncratic API naming / behavior towards real semantics.”
     • 引用2：“I guess it’s the same for the LLMs, just on a massive scale.”

4. 用户体验问题

   • 观点1：页面设计中的动态元素（如实时用户栏）可能干扰阅读体验。
     • 引用1：“The constant jostling of users coming and going made it hard to read the post.”
     • 引用2：“I ain’t reading all this with the animated live user bar at the bottom.”
   • 观点2：某些页面设计需要改进，例如提供阅读模式以提升可读性。
     • 引用1：“I had to use the reader mode to be able to read this article.”

总结：

评论中既有对LLM在代码设计中的积极影响的认可，也有对其局限性和误导性的批评。未来的编程原则可能因LLM而改变，但开发者仍需保持批判性思维，避免盲目接受其建议。同时，用户体验设计中的动态元素可能对阅读造成干扰，需要进一步优化。