Andrew Ng's New Course Explained: Using Spec-Driven Development to Tame AI Coding Agents

Andrew Ng has teamed up with JetBrains to release a beginner-friendly, hands-on course featuring JetBrains Developer Advocate Paul Everett. The course centers on Spec-Driven Development — a workflow widely regarded as the best approach for building serious applications with AI coding agents today. This article breaks down the course's core ideas to help you understand why writing specs beats hand-coding line by line.

What Is Spec-Driven Development

The core idea behind Spec-Driven Development is straightforward: instead of writing code line by line, focus your energy on providing the context that the AI agent doesn't already have. You hand the coding agent a Markdown file or a detailed, long-form prompt describing what you want to build, and the agent implements the entire spec from there.

In other words, the developer's role shifts from "code worker" to "intent designer." You decide what product to build, what features it needs, and what tech stack and architecture to use — then the agent translates those decisions into working code. The course emphasizes that these critical decisions should never be left entirely to the agent's discretion. Doing so may be fast, but it tends to produce hard-to-maintain code and products that feel off.

Three Key Benefits of Spec-Driven Development

The course highlights three immediate benefits you'll experience by adopting this workflow.

Control Large Changes with Small Edits

The first benefit is the ability to trigger sweeping code changes through minimal edits to the spec. A single line like "use SQLite with Prisma ORM" might affect hundreds of lines of code; changing it to "switch to MongoDB" triggers an equally large refactor — all from one line. Editing a spec is far more efficient than rewriting code by hand.

Eliminate Context Decay Across Sessions

The second benefit is that specs prevent context decay between sessions by preserving non-negotiable principles. AI agents are fundamentally stateless — they need their context reloaded every time they start up, which makes it critical to feed them the highest-quality context at the beginning of each session. Spec files serve exactly this role as persistent memory.

Understanding the "stateless" nature of LLMs is key to grasping the value of specs. At the start of every new session, the model has zero memory of prior conversations, decisions, or code — it relies entirely on whatever context is provided in the current input. This stands in sharp contrast to human developers, who accumulate project knowledge over time, remember past mistakes, and understand the origins of technical debt. A spec file essentially externalizes and structures that "project knowledge" so that every new session starts from an equally informed baseline. Without this kind of persistent context, agents may make contradictory architectural decisions across sessions — using REST API in one session, switching to GraphQL in the next, then reverting back — gradually eroding the codebase's consistency.

Improve Intent Fidelity

The third benefit is improved intent fidelity. You define the problem, success criteria, and constraints; the agent then expands those into a more complete execution plan. Andrew Ng shared his own approach: he starts by conversing with agents like Claude Code, Gemini, or ChatGPT Codex, uses his own understanding of trade-offs to make key architectural decisions, and then asks the agent to summarize those decisions into a Markdown file.

Why Writing Specs Is Worth the Effort

Writing a spec requires genuine thinking — it's real work. You have to decide what product you're building, what features it includes, what technology to use, and how to architect it. The course is candid: without a clear spec, you're essentially handing those important decisions over to the coding agent's whims.

Andrew Ng cited a real-world cautionary tale: some teams building complex software products lacked clear specs, causing different developers to direct different coding agents to build quickly but without shared context — ultimately leading to a cascade of downstream headaches.

He offers a practical rule of thumb: if your coding agent is going to run independently for 20 to 30 minutes writing code — potentially equivalent to hours of traditional development work — then spending 3 to 4 minutes upfront to write clear instructions is almost always the better investment. He's also a proponent of "lazy prompting" — if a short prompt gets the job done, great. But for any project with meaningful complexity, skilled developers almost always write detailed specs, because they possess unique context and a clear vision for what they're building — and that beats letting a context-starved LLM make random choices.

The Workflow: Constitution and Feature Development Loops

At the project level, Spec-Driven Development calls for establishing a "constitution" — a document that defines the project's immutable standards — followed by iterative progress through feature development loops.

Each loop isolates a single feature on its own branch and consists of three steps: plan, implement, and verify. This leaves a clean state between features and reduces the friction of context switching.

The workflow supports both greenfield and brownfield projects:

• Greenfield projects: Start from scratch by conversing with an agent to draft the project constitution.
• Brownfield projects: Generate a project constitution based on an existing codebase.

In both cases, you iterate through these feature development loops, managing versions in small steps. The course also teaches you how to write your own agent skills to automate the entire spec-driven workflow.

The "constitution" concept draws inspiration from Architecture Decision Records (ADRs) in software engineering, but is oriented toward AI agent consumption rather than human readers. A well-crafted project constitution typically includes: tech stack choices and their rationale, code style and directory structure conventions, core business rules and constraints, and explicit prohibitions (e.g., "no global state," "all API calls must include error handling"). The greenfield vs. brownfield distinction is a common one in software engineering: greenfield projects start from zero with full freedom but require all decisions to be made from scratch; brownfield projects require working within existing code constraints, meaning the agent must first understand the existing codebase's style and structure before generating a corresponding constitution document — ensuring new features remain consistent with the historical code.

Summary

The course's central message is this: in the age of agentic coding, writing good specs is a high-leverage activity. Small spec changes that drive large code transformations, consistent cross-session context, improved intent fidelity — combined with the structured "constitution + feature loop" process — allow developers to harness the speed of AI agents without sacrificing code maintainability. For beginners who want to build applications seriously with coding agents, this is a clear and immediately actionable path forward.