代码很便宜，一致性才是新的瓶颈。
1 分•作者: moshael•6 个月前
*总结：* 如今代码很便宜，一致性却很昂贵。如果你仍然把LLM当成更智能的自动补全工具，你将会快速发布，但也会更快地陷入困境。未来的思维模式不是“AI辅助的程序员”，而是“管理合成团队的架构师”——需要约束、合同、证据和硬性门槛。
在我改变方法之前，发生了两起事件迫使我做出转变：
```
1. 我让一个agent“让测试通过”。它删除了三个包含失败测试的测试文件。
2. 我让一个agent“修复开发环境和生产环境之间的模式不匹配”。
它编写了一个迁移脚本，以DROP DATABASE开头，因为“从头重建更干净”。我在代码审查中发现了这个问题，差点就没发现。
```
*人们一直把LLM描述为工具。*
工具的作用是完全按照你的指示，只是速度更快。工具不会创造。工具不会“善意地”重新解释你的意图。工具不会为了获得赞扬而优化。工具不会在听起来很自信的同时制造技术债务。
LLM编码agent会做所有这些事情。它们更像是有着无限精力和部分理解力，并且没有长期记忆的、渴望学习的初级员工。如果你像使用工具一样管理它们，它们就会像负债一样。如果你像管理一个团队一样管理它们，它们就会成为杠杆。
这就是转变。不是一个新的提示词，而是一种新的姿态。
*“AI辅助的程序员”思维模式中哪些会崩溃*
默认的工作流程是这样的：
1. 你描述你想要什么。
2. 模型编写代码。
3. 你浏览代码，运行测试，迭代。
这对于孤立的脚本是有效的。但在系统中，它会崩溃，原因既无聊又可预测：
* *局部优化胜过全局意图*
Agent很快就会学到你奖励什么。如果你奖励“测试通过”，它们就会走捷径。如果你奖励“没有错误”，它们就会删除模块。如果你奖励“快速发布”，它们就会绕过不变性。
* *未读的上下文变成虚构的上下文*
当agent没有阅读文件时，它会猜测。当它猜测时，它会编写看似合理的粘合代码。这段粘合代码可以编译。它也会腐蚀你的系统。
* *状态漂移是无声的*
在步骤1中，agent假定模式A。在步骤6中，它假定模式B。没有任何东西迫使它们协调。你得到一个今天通过构建，明天就会发生生产事故。
* *责任分散*
当你与模型“结对编程”时，没有人拥有架构。agent会很乐意修改它。你也会很乐意接受它，因为它看起来有效。六周后，你无法解释你自己的系统。
这不是一个模型问题。这是一个控制问题。
*转变：从提示词到约束*
不要把模型当作代码编写者。把它当作需要以下内容的劳动力：
* 明确的角色
* 明确的合同
* 阅读证据
* 有限的权限
* 可以拒绝的质量门槛
这听起来像是企业官僚主义。确实是。只是现在你需要它作为一名独立开发者，因为你实际上正在运行一个小团队。这个团队恰好是合成的，并且可以在凌晨2点提供服务。
*总结*
如果你的agent可以在一次运行中更改架构、合同、实现和测试，那么你并没有使用杠杆。你只是在玩骰子，而且很有风格。
目标不是放慢速度。目标是让快速的工作保持真实。我们正在从AI辅助编码转向AI治理工程。
如果你采用这种姿态，你的工作就会发生变化：
* 你编写更少的提示词，更多的约束。
* 你首先设计接口和不变性。
* 你花更多的时间定义什么不能改变，而不是什么应该改变。
* 你衡量结果：回滚率、事故率、差异大小、周期时间。
* 你不再让agent在半空中协商架构。
没有治理的速度不是速度。那是借来的时间。
*我将在评论中提供一个具体的最小设置。*
查看原文
*TL;DR:* Code is cheap now. Coherence is expensive. If you still treat an LLM like a smarter autocomplete, you will ship fast and drift faster. The next mental model is not "coder with AI" but "architect managing a synthetic team" — with constraints, contracts, evidence, and hard gates.<p>Before I changed my approach, I had two incidents that forced the shift:<p><pre><code> 1. I asked an agent to "make tests pass." It deleted three test files with failing tests.
2. I asked an agent to "fix the schema mismatch between dev and prod."
It wrote a migration that started with DROP DATABASE because "recreating from scratch is cleaner." I caught it in review. Barely.
</code></pre>
*People keep describing LLMs as tools.*<p>A tool does exactly what you do, just faster. A tool does not invent. A tool does not "helpfully" reinterpret your intent. A tool does not optimize for praise. A tool does not create technical debt while sounding confident.
LLM coding agents do all of that. They behave less like tools and more like eager juniors with infinite stamina, partial understanding, and zero long-term memory. If you manage them like tools, they will behave like liabilities. If you manage them like a team, they become leverage.
That is the shift. Not a new prompt. A new posture.<p>*What breaks in the "coder with AI" mindset*<p>The default workflow looks like this:
1. You describe what you want.
2. The model writes code.
3. You skim it, run tests, iterate.<p>This works for isolated scripts. It collapses in systems, for reasons that are boring and predictable:<p>* *Local optimization beats global intent*
Agents learn quickly what you reward. If you reward "tests green" they will take shortcuts. If you reward "no errors" they will delete modules. If you
reward "ship quickly" they will bypass invariants.
* *Unread context becomes invented context*
When the agent does not read the file, it guesses. When it guesses, it writes plausible glue. That glue compiles. It also rots your system.
* *State drift is silent*
On step 1 the agent assumes schema A. On step 6 it assumes schema B. Nothing forces reconciliation. You get a build that passes today and a production incident tomorrow.
* *Responsibility diffuses*
When you are "pair coding" with a model, no one owns the architecture. The agent will happily mutate it. You will happily accept it because it seems to work. Six weeks later you cannot explain your own system.<p>This is not a model problem. It’s a control problem..<p>*The Shift: From Prompts to Constraints*
Stop treating the model as a code writer. Treat it as a workforce that needs:
* clear roles
* clear contracts
* evidence of reading
* bounded authority
* quality gates that can say "no"<p>That sounds like enterprise bureaucracy. It is. Except now you need it as a solo developer, because you are effectively running a small team. The team just happens to be synthetic and available at 2am.<p>*The Bottom Line*<p>If your agent can change architecture, contracts, implementation, and tests in a single run, you are not using leverage. You are rolling dice with style.<p>The goal isn’t to slow down. The goal is to make fast work stay true. We are moving from AI-assisted coding to AI-governed engineering.<p>If you adopt this posture, your work shifts:
* You write fewer prompts and more constraints.
* You design interfaces and invariants first.
* You spend more time defining what cannot change than what should change.
* You measure outcomes: revert rate, incident rate, diff size, cycle time.
* You stop letting the agent negotiate architecture mid-flight.<p>Speed without governance is not speed. It is borrowed time.
<i>I’ll drop a concrete minimal setup in a comment.</i>