简介
Introduction
Summary
Andrew Ng introduces the Spec-Driven Development course with instructor Paul Everitt from JetBrains. Paul explains three main benefits of SDD: controlling large code changes with small spec modifications, eliminating context decay between sessions, and improving intent fidelity.
Key Takeaways
- Small spec changes amplify downstream: one sentence like “use SQLite with Prisma ORM” can affect hundreds of lines of code
- Specs eliminate context decay: agents are stateless, so loading them with high-quality context on boot is critical
- Specs improve intent fidelity: defining the problem, success criteria, and constraints before coding leads to better alignment
Video: Introduction
English Script
Welcome to this course on Spec-Driven Development built in partnership with JetBrains. Spec-Driven Development is currently the best type of workflow for building serious applications with agentic coding assistance. Give your coding agent a markdown file or a long prompt, explaining exactly what to build and it implements that spec. Rather than writing code by hand, you focus on writing down the context that the agent doesn’t already have. I’m delighted that our instructor for this course is Paul Everett, who’s developer advocate at JetBrains.
Thank you Andrew and wait, I didn’t know you wore spectacles, You’re right. I don’t actually need these. Okay, that’s what I thought. Anyway, Spec-Driven Development has three main benefits that you’ll start to see right away. First, you can control large code changes with small changes to the spec. One sentence like, use SQLite with Prisma ORM, might affect hundreds of lines of code. Change that to MongoDB for the same downstream amplification. This makes writing specs really efficient, far more so than writing code. Second, specs help eliminate context decay between sessions, preserving the non-negotiable. Agents are stateless, so loading them with the highest quality context right when they boot up is important. And finally, specs improve your intent fidelity. You define the problem, success criteria, constraints, and so on, and the agent can elaborate to create a fuller plan.
One way I often write a spec is by having a conversation with an agent like Claude Code or Gemini or ChatGPT Codex, to make the key architectural choices using my knowledge of how I want to make different trade-offs. Then have the agent summarize the key decisions in a markdown file. Writing a spec requires thinking, and this is hard work. You have to decide what product you want to build, what is its features, its technical architecture. And without a spec, you’ll be leaving these important decisions up to the whims of the coding agent, which might be okay if you want to move really fast and just roll the dice, but certainly leads to less maintainable code and sometimes pretty weird products. For example, I’ve seen teams working on a complex software product where there was no clear spec, and this led to many downstream headaches from these different coding agents under the direction of different developers, building quickly, building in contradictory ways.
Spec-Driven Development involves developing a constitution at the project level to define the immutable standards. Then iterating through feature development loops. These loops isolate each feature on its own branch with plan, implement, and verify steps that leave a clean slate between features and reduce headaches and context switching. This same workflow supports both greenfield and brownfield projects. In greenfield projects, you start from scratch. You’ll develop the constitution in a conversation with the agent. In Brownfield, existing code bases, you’ll generate the project constitution based on the existing code base. In both cases, you’ll then iterate through these feature development loops, managing versioning in small steps. In this course, you’ll also see how to write your own agent skills to automate your spec-driven workflow.
You know, if you can accomplish what you need in just one short prompt, that’s great. I’m definitely an advocate of lazy prompting when it works. But the great developers I know out there almost always will write detailed specs for projects with any significant complexity, because they have unique context and an opinion on what or how to build that’ll be superior to letting the LLM, which is missing that context, pick randomly. If a coding agent is going to go off and write code for 20 or 30 minutes, which may correspond to several hours of traditional developer work, you’re often better off sitting down for three or four minutes and writing really clear instructions. Many people have contributed to this course, including Konstantin Chaika and Zina Smirnova from JetBrains and Isabel Zaro from DeepLearning.AI. Let’s go on to the next video and let’s write some specs.
简介
摘要
吴恩达介绍规格驱动开发课程，讲师为 JetBrains 开发者布道师 Paul Everitt。Paul 讲解了 SDD 的三大主要优势：通过微小的规格修改控制大规模代码变更、消除不同会话之间的上下文衰减、提高意图还原度。
关键要点
- 规格修改的下游放大效应：一句话如”使用带 Prisma ORM 的 SQLite”可能影响数百行代码
- 消除上下文衰减：智能体是无状态的，因此在启动时为其加载最高质量的上下文非常重要
- 提高意图还原度：在编码前定义问题、成功标准和约束条件能使智能体产出更符合目标的代码
视频：简介
视频脚本（中文翻译）
欢迎来到这门由 DeepLearning.AI 与 JetBrains 合作开发的”规格驱动开发（Spec-Driven Development）“课程。规格驱动开发是目前在使用智能体编程助手构建严肃应用程序时最好的工作流。你只需给你的编程智能体提供一个 Markdown 文件或一段长提示词，准确说明要构建的内容，它就会去实现这个规格说明。你不再需要手动编写代码，而是将注意力集中在写下智能体尚不具备的上下文信息上。我很高兴我们这门课的讲师是 Paul Everett，他是 JetBrains 的开发者布道师。
谢谢你，吴恩达（Andrew）。等等，我都不知道你还戴眼镜呢。你说得对，我其实不需要戴这个。好吧，我就知道。言归正传，规格驱动开发有三个主要优势，你很快就会体会到。首先，你可以通过对规格说明进行微小修改来控制大规模的代码变更。像”使用带 Prisma ORM 的 SQLite”这样一句话，可能会影响数百行代码。将其改为”MongoDB”，同样会产生巨大的下游放大效应。这使得编写规格说明非常高效，远比直接写代码高效得多。其次，规格说明有助于消除不同会话之间的上下文衰减（context decay），保留那些不可协商的硬性要求。智能体是无状态的，因此在它们启动时为其加载最高质量的上下文非常重要。最后，规格说明能提高你的”意图还原度（intent fidelity）“。你定义了问题、成功标准、约束条件等，然后智能体可以进一步展开，制定出更完整的计划。
我经常使用的一种编写规格说明的方法是：与 Claude Code、Gemini 或 ChatGPT Codex 这样的智能体进行对话，利用我自己在各种权衡取舍上的专业知识，来做出关键的架构选择。然后让智能体在一个 Markdown 文件中总结这些关键决策。编写规格说明需要思考，这是一项艰苦的工作。你必须决定你要构建什么样的产品，它有哪些功能，技术架构是什么。如果没有规格说明，你就会把这些重要决策留给编程智能体凭感觉来定。如果你只想快速推进、碰碰运气，那或许没问题，但这肯定会导致代码难以维护，有时还会产出非常奇怪的产品。例如，我见过一些团队在开发复杂的软件产品时没有明确的规格说明，这就导致了后续许多令人头疼的问题——在不同开发者的指导下，不同的编程智能体快速编写代码，结果却产生了自相矛盾的构建。
规格驱动开发包括在项目层面制定一个”项目章程（constitution）“，以定义不可变的各项标准。然后通过”功能开发循环”进行迭代。这些循环将每个功能隔离在自己的分支上，通过”计划”、“实现”和”验证”这些步骤，在不同功能之间留出干净的状态，从而减少令人头疼的问题和上下文切换。这套工作流同时支持全新项目（greenfield）和已有代码的传统项目（brownfield）。在全新项目中，你从零开始，你将通过与智能体的对话来制定项目章程。在传统项目中（已有代码库），你将基于现有的代码库生成项目章程。在这两种情况下，你都将在此后迭代进行这些功能开发循环，以小步快跑的方式管理版本控制。在本课程中，你还将看到如何编写自己的智能体”技能（skills）“来自动化你的规格驱动工作流。
你要知道，如果你能用一个简短的提示词就完成你所需要的任务，那当然很好。当”偷懒提示（lazy prompting）“有效时，我绝对是它的拥趸。但我认识的那些优秀开发者在面对任何具有一定复杂度的项目时，几乎总是会编写详细的规格说明。因为他们拥有独特的上下文背景，对要构建什么以及如何构建有自己的主见，这远比让缺乏这些上下文的 LLM 随机盲目选择要好得多。如果一个编程智能体要花 20 或 30 分钟去编写代码（这可能相当于传统开发者几个小时的工作量），你通常最好还是坐下来花三四分钟，写下非常清晰的指令。许多人为本课程做出了贡献，包括来自 JetBrains 的 Konstantin Chaika 和 Zina Smirnova，以及来自 DeepLearning.AI 的 Isabel Zaro。让我们进入下一个视频，开始编写一些规格说明吧。