Andrew Ng's New Course: Spec-Driven Development Reshapes the AI Programming Workflow

As AI coding assistants grow increasingly powerful, learning how to harness these agents — capable of completing in 20–30 minutes what traditionally takes developers hours — has become an essential new skill. The Spec-Driven Development (SDD) course, launched by Andrew Ng in collaboration with JetBrains, offers a systematic answer. This article distills the core concepts and practical workflows of SDD based on the course content.

What Is Spec-Driven Development (SDD)?

Spec-Driven Development is one of the best workflows currently available for building serious applications with agentic coding assistants. These agentic assistants are AI coding tools with autonomous planning, tool invocation, and multi-step reasoning capabilities — distinct from earlier Copilot-style products that merely offered code completion. Representative products include Claude Code, Cursor Agent, and GitHub Copilot Agent. They can understand high-level requirements, autonomously decompose tasks, read and write files, run tests, and debug errors, forming a complete development loop. The rise of these tools stems from breakthroughs in large language model (LLM) code generation capabilities and the maturation of agent frameworks like ReAct (Reasoning + Acting), which transformed AI from passive responder to active executor.

The core idea of SDD is straightforward: instead of writing code by hand, give the coding agent a Markdown file or a detailed prompt that clearly specifies what to build, and let the agent implement that spec. The choice of Markdown as the spec medium is no accident — Markdown is a lightweight markup language that is highly human-readable, version-control-friendly, and natively supported by virtually all development tools. More critically, current mainstream LLMs have been exposed to vast amounts of Markdown-formatted documents during training, so their ability to parse and follow Markdown structure far exceeds that of other formats. Writing specs as .md files makes it easy for developers to track changes in code reviews while enabling agents to efficiently parse them as executable context instructions.

Paul Everitt, course instructor and JetBrains Developer Advocate, notes that this approach shifts the developer's focus from "writing code" to "writing down the context the agent doesn't yet know." In other words, you define the problem, success criteria, and constraints; the agent fills in the details, generates a complete solution, and implements it.

Andrew Ng emphasizes that writing a spec is itself a demanding intellectual exercise. You must decide what product to build, what features it should have, and what technical architecture to adopt. If you skip this step, these critical decisions get left to the coding agent to determine on the fly — which might work when you're prioritizing speed and willing to "roll the dice," but often leads to decreased code maintainability or even rather bizarre products.

Three Core Advantages of SDD

The course explicitly identifies three immediate benefits of Spec-Driven Development.

Control Large-Scale Code Changes with Small Edits

The leverage effect of specs is remarkably powerful. A single sentence — such as "use SQLite with Prisma ORM" — can influence hundreds of lines of code; changing it to "MongoDB" produces an equally massive downstream amplification effect.

To understand the magnitude of this leverage, it's worth explaining the differences between these two technology choices. SQLite is an embedded relational database that requires no separate server process, stores data in a single file, and is particularly suited for prototyping and small-to-medium-scale applications. Prisma is one of the most popular ORM (Object-Relational Mapping) tools in the Node.js/TypeScript ecosystem, automatically generating type-safe database client code through declarative schema definitions. When the spec changes the database from SQLite to MongoDB (a document-oriented NoSQL database), not only does the schema definition approach change entirely, but the data modeling paradigm, query syntax, and relationship handling logic all undergo fundamental transformations — resulting in downstream code changes that can reach hundreds of lines. This means writing and modifying specs is far more efficient than writing code by hand — a single sentence can pivot an entire tech stack.

Eliminate Context Decay Between Sessions

Agents are fundamentally stateless — every session is an amnesiac fresh start. This characteristic is rooted in how LLMs operate: each API call is essentially an independent inference process, and the model does not automatically "remember" the content of previous sessions. Although modern LLMs have expanded their context windows to 128K or even millions of tokens, attention allocation in long contexts suffers from the "Lost in the Middle" phenomenon, where the model's ability to retrieve information from the middle of the context drops significantly. Moreover, information across sessions is completely lost.

The role of a spec file is to load the highest-quality context into the agent from the very start, preserving non-negotiable core constraints and preventing context decay across multiple sessions. It front-loads critical context, ensuring every session begins from the highest-quality information baseline.

Improve Intent Fidelity

Through specs, you can clearly define problems, success criteria, constraints, and more, while the agent can further refine these into a more complete execution plan. This ensures the final output is highly aligned with your true intent, rather than being a random guess by a model lacking context.

Andrew Ng shared a cautionary example: he once observed teams developing complex software products without clear specs. Multiple coding agents directed by different developers were all producing rapidly, but building code in mutually contradictory ways, ultimately causing a cascade of downstream problems.

How to Write a Good Spec

Andrew Ng described his typical approach to writing specs: start a conversation with agents like Claude Code, Gemini, or ChatGPT Codex, apply your own judgment about various trade-offs to make key architectural decisions, then have the agent summarize the core design, and finally commit those decisions to a Markdown file.

He specifically noted that while he's an advocate of "lazy prompting" — if a short prompt can get the job done, that's obviously ideal — the best developers he knows almost always write detailed specs for any project of meaningful complexity. The reason: these developers possess unique context and clear opinions about what to build and how to build it, and that judgment far surpasses what a context-deprived LLM would randomly choose.

A simple cost-benefit calculation: if a coding agent will spend 20–30 minutes autonomously writing code (equivalent to several hours of traditional development), then spending three or four minutes sitting down to write clear instructions is usually an extremely worthwhile investment.

The Complete SDD Workflow

The Spec-Driven Development workflow operates at two levels.

Project Level: Establishing the "Constitution"

First, at the project level, you establish a "constitution" that defines immutable standards. This serves as the project's foundation, constraining all subsequent development activities. The constitution typically includes tech stack choices, code style guidelines, directory structure conventions, security policies, performance requirements, and other global constraints. Its role is similar to Architecture Decision Records (ADR) in software engineering, but presented in a format that agents can directly consume.

Feature Level: The Iterative Development Loop

On top of the constitution, developers advance the project through individual "feature development loops." Each feature is isolated on an independent branch, following three steps: plan → implement → verify, then returning to a clean initial state. This isolation design reduces interference between features and the headaches caused by context switching.

Interestingly, this workflow applies equally to two types of projects:

• Greenfield (brand-new projects): Built from scratch, with the project constitution defined through conversations with the agent.
• Brownfield (existing codebases): The project constitution is auto-generated based on the existing codebase.

Greenfield and Brownfield are classic software engineering terms borrowed from urban planning. A Greenfield project means building from zero without historical baggage — developers enjoy complete freedom in technology choices but face the challenge of dense architectural decisions. A Brownfield project means developing on top of an existing codebase, requiring consideration of legacy system technical debt, existing architectural constraints, and team conventions. In real-world enterprise development, Brownfield scenarios far outnumber Greenfield ones. The fact that SDD covers both scenarios carries significant practical value — for Brownfield projects, the agent can automatically generate a project constitution by analyzing existing code structure, dependencies, and coding conventions, which is traditionally one of the most time-consuming reverse engineering tasks.

In both scenarios, iteration continues through feature development loops, with versions managed in small batches. Additionally, the course teaches you how to write your own agent skills to automate the entire spec-driven workflow. Agent skills are predefined, reusable instruction sets or workflow templates that guide AI coding assistants in executing specific types of tasks. Within JetBrains' AI assistant ecosystem, developers can encapsulate common development patterns (such as "create a REST API endpoint," "write unit tests," or "execute database migration") into standardized skills. These skills are essentially structured prompt engineering artifacts that include task descriptions, input/output formats, quality standards, and verification steps. By writing custom skills, teams can codify best practices, ensuring consistent output quality across team members when using agents, while reducing the cost of repeatedly writing complex prompts.

Final Thoughts

As AI coding assistant capabilities leap forward, developers' core competitive advantage is shifting from "coding ability" to "the ability to articulate intent and design architecture." The value of Spec-Driven Development lies precisely in its structured approach to capturing developers' unique judgment and domain knowledge, transforming them into the "authoritative document" that directs the agent.

This course, jointly created by Andrew Ng and JetBrains, features contributors including JetBrains' Konstantin Czajkur and Zina Smirnova, as well as DeepLearning.ai's Isabel Zarro. For developers looking to establish a standardized AI programming workflow and avoid common pitfalls, SDD offers a methodology well worth serious study. As Andrew Ng puts it: let's start writing specs.