规格说明即代码的幻觉与软件熵的代价
Matt Pocock 开启了一个充满挑衅性的话题：在这个 AI 席卷行业的时代，许多人认为传统的软件工程技能已经贬值，但他坚信 软件基础（Software Fundamentals）现在比以往任何时候都更加重要。他特别提到了当前流行的 规格说明即代码（Specs to Code: 通过编写需求规格，让 AI 生成并维护代码）运动。这种模式主张开发者只需修改规格说明，然后像运行编译器一样重新运行 AI 生成代码，而无需查看代码本身。然而，Matt 在实践中发现，这种方式会导致代码质量迅速退化。每次“编译”生成的代码往往比前一次更糟，最终演变成一堆无法维护的垃圾。
这种现象被称为 软件熵（Software Entropy: 软件系统随着时间推移趋向于混乱和崩溃的倾向）。《程序员修炼之道》中曾系统阐述过这一概念：如果你在修改代码时只关注眼前的变更，而不考虑整个系统的设计，代码库就会不断恶化。Matt 尖锐地指出，认为“代码是廉价的”这一观点是完全错误的。事实上，糟糕的代码比以往任何时候都更加昂贵，因为它阻碍了你利用 AI 带来的红利。AI 在一个设计良好的代码库中表现极佳，但在混乱的系统中则会举步维艰。
Original English Source
I have a message for you that I hope will be a comforting message for folks who believe that their skill set is no longer worth anything in this new age, which is I believe that software fundamentals matter now more than they actually ever have.
There's a kind of movement that has come up around this, which is the specs to code movement. And the specs to code movement says that okay you can write a specification about how an application is supposed to work then you can use AI to turn it into code. If there's a problem with the application you then go back to the spec. You don't really look at the code. You just change the spec. You run the compiler again and you end up with more code.
And what I noticed was I realized I would get code out first of all and then I would run it I would get worse code and then I would get even worse code. I kept running the compiler and I would just end up with garbage. The idea that we can just ignore the code and just have the code let it manage itself is just sort of v-coding by another name.
Entropy is the idea that things tend towards disaster and collapse. And this is exactly how most software systems behave too is that every time you make a change to a codebase, if you're only thinking about that change, not thinking about the design of the whole system, your codebase is going to get worse and worse and worse. Bad code is the most expensive it's ever been. Because if you have a codebase that's hard to change, you're not able to take all of the bounty that AI can offer because AI in a good codebase actually does really, really well.
设计概念的对齐：通过“Grill Me”技能达成共识
当 AI 无法生成你想要的结果时，本质上是遇到了 沟通障碍。Matt 引用了弗雷德里克·布鲁克斯（Frederick P. Brooks）在《设计的设计》中提出的 设计概念（Design Concept: 存在于设计者之间的一种关于所构建事物的无形、共有的理论）。当你与 AI 协同工作时，如果双方没有共享这个设计概念，产出必然会产生偏差。
为了解决这个问题，Matt 开发了一个名为 Grill Me 的技能。其核心指令是：“就此计划的每一个方面对我进行无情的追问，直到我们达成共识。沿着设计树的每一个分支向下探索，逐一解决决策之间的依赖关系。”这种方法强制 AI 扮演一个“反面角色”，通过提出 40 个、甚至 100 个问题来榨取开发者脑中的隐性知识。这种深度互动生成的对话可以转化为 产品需求文档（Product Requirements Document: 详细描述产品功能和目标的文档），确保在进入代码实施阶段前，人类与 AI 已经建立了稳固的逻辑共识。
Original English Source
The first [failure mode] is that the AI didn't do what I wanted. No one knows exactly what they want. You and the AI, there is a communication barrier there. Frederick P. Brooks talks about this idea called the design concept. It is the invisible sort of theory of what you're building. Me and the AI don't share a design concept.
So I came up with a skill called "grill me". Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree resolving dependencies between decisions one by one. This skill went viral. These couple of lines means the AI asks you like 40 questions, 60 questions, a hundred questions before it's satisfied they've reached a shared understanding. It turns the AI into a kind of adversary where it's just continually pinging you ideas.
通用语言：消除 AI 的冗余并提升对齐度
另一个常见的失败模式是 AI 输出过于冗长或与业务逻辑脱节。Matt 认为这反映了开发者与 领域专家（Domain Expert: 对特定行业或业务领域有深刻理解的人）之间常见的语言鸿沟。为了消除这种隔阂，他借鉴了 领域驱动设计（Domain-Driven Design: 一种通过将实现连接到持续进化的模型来处理复杂软件设计的编程思想）中的 通用语言（Ubiquitous Language）概念。
通用语言 要求开发者、代码表达和领域专家在对话中都使用同一套从领域模型导出的术语。Matt 创建了一个自动化技能，它会扫描代码库，提取核心术语，并生成一个 Markdown 格式的词汇表。在与 AI 进行后续的规划或代码生成时，始终参考这个词汇表。实践证明，这不仅能显著减少 AI 的冗余输出（Thinking Traces），还能让代码实现与业务意图保持高度一致，使 AI 的思维过程更加高效。
Original English Source
Failure mode number two is that the AI is just way too verbose. You need to establish some kind of shared language. I went back to Domain-Driven Design (DDD). DDD has a concept of a ubiquitous language. Conversations among developers and expressions of the code and conversations with domain experts are all derived from the same domain model.
It's essentially a markdown file full of a list of terms that you and the AI have in common. I made a skill that scans your codebase and creates the ubiquitous language markdown file. I actually have it open all the time when I'm grilling with the AI. It not only improves the planning, but it allows the AI to think in a less verbose way and actually means that the implementation is more aligned with what you actually planned.
速度限制与 TDD：防止 AI “跑得比车灯还快”
即使逻辑对齐，AI 编写的代码有时仍无法运行。Matt 指出，LLM 往往缺乏资深开发者的克制力，倾向于一次性生成海量代码而不进行中间验证。这在《程序员修炼之道》中被描述为 跑得比车灯还快（Outrunning your headlights: 因反馈速度跟不上行驶速度而导致失控）。他强调，反馈频率就是你的速度限制。
解决这一问题的终极武器是 测试驱动开发（Test-Driven Development: TDD）。TDD 强制 AI 采取小步快跑的策略：先写测试，验证失败，编写实现，最后重构。虽然测试本身很难编写（涉及 Mock 对象、单元大小、行为定义等复杂决策），但 可测试的代码库通常也是优秀的代码库。通过建立紧密的反馈循环，开发者可以有效地约束 AI 的行为，确保系统的稳健性。
Original English Source
The AI has built the right thing, but it doesn't work. The LLM doesn't use feedback loops very well. It will produce like huge amounts of code and then think, "Oh, I should probably check a test on that." They describe this as outrunning your headlights as essentially driving too fast because the rate of feedback is your speed limit.
Skill number three is TDD. TDD forces the LLM to really take small steps. You create a test first. You make that test pass and then you refactor. Better your codebase is, the better your feedback loops are. Because you're able to give better feedback to the LM, it produces better code.
战略架构：通过“深层模块”解放人类大脑
针对 AI 容易产生大量碎片化、难以理解的微小代码块（浅层模块）的问题，Matt 引用了约翰·奥斯特豪特（John Ousterhout）的理论，提倡构建 深层模块（Deep Modules: 将复杂功能隐藏在简单接口背后的模块化策略）。
- 深层模块：接口极其简单，但背后隐藏了大量的复杂实现。
- 浅层模块：功能单薄，却有着复杂的接口。
AI 非常擅长制造浅层模块，这会迫使人类大脑去记忆海量的依赖关系，导致认知超载。Matt 建议开发者应当 设计接口，委托实现。将非核心模块视为“灰盒”，开发者只需精心设计其边界和接口，并利用 TDD 进行外部验证，而将内部复杂的实现细节交给 AI 处理。这种战略性的分工——人负责战略架构，AI 负责战术编码——是应对 AI 时代开发疲劳的关键。他最后引用肯特·贝克（Kent Beck）的名言：每天都要对系统设计进行投资。
Original English Source
Good codebases look like John Ousterhout's "deep modules". Deep modules: lots of functionality hidden behind a simple interface. Shallow modules: not much functionality, complex interface. AI is really good at creating shallow modules that are hard for the AI to explore and understand.
How do you turn a codebase into deep modules? I've got a skill for that: "improve codebase architecture". You wrap related code in a deep module. This is a codebase that rewards TDD. It also means you can treat these modules as gray boxes. You design the interface, but you don't worry too much about the implementation as long as you have a testable boundary. Design the interface, delegate the implementation.
If we think about AI as a tactical programmer, a sergeant on the ground, you need someone above that thinking on the strategic level and that's you. Invest in the design of the system every day. Code is not cheap. Code is important.