Spec-Driven Development: Critically Important in Any Task

# "Forget About Spec-Driven Development": Harmful Advice That Multiplies Rework

## Harmful Advice from the Lecture

Sheyko says:

> "For startups or startup initiatives within a company, forget about Spec-Driven Development. Spend time first to understand what you need. You can even build a frontend without a backend, create an in-memory database, click around, and understand what you need from the interface."

Sounds reasonable. Sounds like "don't plan in a vacuum, understand the product first." The audience nods.

This is **harmful advice**. Because it conflates two different concepts. It confuses "planning in a vacuum without understanding the product" with "using AI to formalize your understanding of the product." These are **different things**. And the second one is not bureaucracy. It saves hours and days of rework.

---

## Why This Advice Is Harmful

Here's what happens when you "forget about the spec" and build a prototype without one:

1. You tell the agent: "Build an interface for X." No criteria. No constraints. No data model. No understanding of which edge cases matter.

2. The agent builds **its own way**. By default. On average. Because it has no contract.

3. You look at the result and say: "That's not it. That's not what I needed."

4. You redo it. The agent redoes it. Still not it. Because you **never formalized** what "right" means.

5. The cycle repeats 3–5 times. Each time — tokens, time, context loss after compaction.

In the end, you spent **more time on rework** than writing a 1-page spec would have taken. And got a **worse result** than if you'd spent 30 minutes formalizing requirements.

Sheyko himself says in the lecture: "Every 10 minutes of planning saves hours of execution." And then immediately advises forgetting about planning for prototypes. This is a **contradiction**. A prototype is also a task that requires planning. Maybe even more than a mature product, because uncertainty is at its **highest** in a prototype.

---

## Spec ≠ Bureaucracy. Spec = Contract with the Agent

When people hear "Spec-Driven Development," they imagine a 50-page requirements document that takes three weeks to write and nobody reads. This is the **old model**. It's dead.

A spec in the AI era is not a 50-page document. It's a **1–2 page contract between a human and an agent**:

- What we're building (1 paragraph)

- Completion criteria (5–10 items)

- Constraints (3–5 items)

- Data model / architecture (if applicable, 1 paragraph or a diagram)

- What we're NOT building (3–5 items)

This is not bureaucracy. This is **an instruction for the agent** that guarantees it will build what you need, not what it guessed.

Without a spec, the agent **guesses**. Guessing = rework. Rework = wasted time, tokens, context.

With a spec, the agent **executes a contract**. Executing a contract = minimal rework.

---

## AI Helps Write the Spec. This Is Not "Human in a Vacuum"

This is what Sheyko misses. In the AI era, a spec is **not written by a human alone, sitting in a vacuum**. The spec is written by a human **in dialogue with AI**.

It looks like this:

**Human:** "I want to build a service for managing content on Google Sites."

**AI:** "Great. Let's formalize it. Questions:

1. What content operations are needed? (create, edit, delete, move)

2. Are there access permission constraints?

3. What content volume do we expect? (10 pages or 10,000)

4. Do we need change history?

5. What integrations are needed? (Google Sites only or something else too)

6. What should NOT be done in the first version?"

**Human answers the questions.** AI forms the spec. 20–30 minutes.

This is not "planning in a vacuum for a long time." This is a **structured dialogue** that surfaces hidden requirements, contradictions, and edge cases. AI asks questions you wouldn't think to ask yourself. And you end up with a spec that **precisely describes** what needs to be done.

Sheyko advises "click through a prototype and understand what's needed." But **clicking through a prototype without a spec** means spending hours iterating with an agent that builds the wrong thing. While **writing a spec with AI in 30 minutes** gives the agent a clear contract upfront and delivers results in a single iteration.

---

## Minimal Spec vs No Spec: Comparison

| Parameter | Without Spec | With Minimal Spec (1 page) |

|---|---|---|

| Time to formulate | 5 minutes ("build X") | 30 minutes (dialogue with AI) |

| Iterations with agent | 3–5 (rework) | 1–2 (clarifications) |

| Tokens per task | 150k–300k (rework) | 40k–80k |

| Rework | 40–60% | 5–10% |

| Quality of result | Medium (agent guessed) | High (agent executed contract) |

| Time from start to result | Hours/days (with rework) | Hours (without rework) |

A minimal spec **pays for itself in the first 30 minutes** because it saves hours of rework.

---

## Architectural Specs Reduce the Cost of Mistakes

Sheyko himself says in the lecture:

> "Any mistake at the architecture stage drags on for months and years. Mistakes are expensive."

And then immediately advises forgetting about specs for prototypes. But a prototype **often becomes the foundation of the product**. What you build in the prototype becomes production architecture. If you didn't formalize the architecture in the prototype, you've embedded mistakes that will haunt you for months.

A 1-page architectural spec for a prototype:

- What modules exist

- How they connect

- What contracts exist between them

- What can be changed and what cannot

- What decisions we make now vs. defer

This is **not bureaucracy**. This is insurance against your prototype turning into an unmanageable mess of code that cannot be scaled.

---

## Practice: How to Write a Spec in 30 Minutes with AI

**Step 1: State your intent (1 minute).**

"I want to build X for Y so that Z."

**Step 2: Ask AI to ask you questions (5 minutes).**

Prompt:

```

I want to build [intent]. Ask me 10 questions

that will help formalize the requirements. Include:

- functional requirements

- constraints

- edge cases

- what NOT to build

- data model (if applicable)

```

**Step 3: Answer the questions (10 minutes).**

Concisely. In bullet points. Don't write an essay. 1–2 sentences per question.

**Step 4: Ask AI to form the spec (5 minutes).**

Prompt:

```

Based on my answers, form a spec:

1. What we're building (1 paragraph)

2. Completion criteria (list)

3. Constraints (list)

4. Data model / architecture (if applicable)

5. What we're NOT building (list)

Format: compact, no more than 1 page.

```

**Step 5: Verify the spec (5 minutes).**

Read it. If something's off — fix it. If everything's fine — hand it to the agent as an instruction.

**Total: 30 minutes.** This is not "planning in a vacuum for a long time." This is a structured dialogue with AI that formalizes your understanding of the task.

---

## Why Sheyko Gave This Advice

Because he confuses **two different situations**:

**Situation 1: A company doesn't know what it wants and tries to write a 50-page document in a vacuum.** Yes, this is useless. The document will be outdated before it's finished. AI will build according to the document, and then it turns out something else was needed.

**Situation 2: A company doesn't know what it wants and uses AI for a structured dialogue that formalizes understanding in 30 minutes.** This is not "planning in a vacuum." This is a **requirements discovery tool**. And it works.

Sheyko criticizes Situation 1 but advises forgetting about Situation 2. That's a mistake. Situation 2 is exactly what you should be doing. And it doesn't contradict the idea of "understand what's needed first." It **helps** you understand what's needed.

---

## Conclusion

The advice to "forget about Spec-Driven Development" is harmful. It multiplies rework, increases token consumption, reduces quality, and embeds architectural mistakes into the prototype that becomes production.

A spec in the AI era is not a 50-page document. It's a **1-page contract** that a human forms in dialogue with AI over 30 minutes. This contract guarantees the agent builds what you need, not what it guessed.

A minimal spec **pays off immediately**: 30 minutes of formulation saves hours of rework and reduces rework from 40–60% to 5–10%.

"Forget about the spec" is advice for those who don't know how to write specs with AI. And that's their problem. But it doesn't mean specs aren't needed. It means they don't know how to create them.