1 Two habits, used together

Spec-driven development and test-driven development answer different questions. They belong in one order: decide what you are building, then prove one small piece at a time.

Spec-driven development means a short plan exists first. That plan is the spec. It lists what the program should do, what it should not do, and how you will know you are finished. You do not type that file. You prompt an AI for it, then you read what came back before you invent extra features.

Test-driven development means a check exists before the code that should satisfy it. A test is a tiny automatic check, like “12 plus 3 must come back as 15.” The first time it runs, it fails, because the feature is not there yet. Then only enough code is added to make that one check pass.

You do not write the spec or those checks yourself. You prompt an AI, then you check the result. An AI here is a coding assistant you talk to in plain language. A prompt is the message you send it. First prompt for the spec and read it. Then name one line, prompt for a failing check only, wait until it fails, then prompt for the smallest fix.

• The spec is the agreementIt names the work. You prompt for it, then you check it. If a feature is not in the spec, you do not build it yet
• The prompt is the skillYou prompt for the spec, then one failing check, then the smallest code that makes it pass. You do not write the spec or the test
• Together they stay honestThe spec names the behavior. The AI turns one line into a check you can run. The screen comes last

1. SpecPrompt for what done looks like, then check it
3. Fail promptPrompt for one check that is not satisfied yet
5. Pass promptPrompt for only enough code for that check
7. RepeatNext line from the spec

2 A small calculator as the practice case

I needed an example small enough to finish quickly. A calculator with add, subtract, multiply, divide, and a clear button is enough. Divide by zero should show the word Error. No memory keys. No extra science buttons. The calculator is only the practice case, so the prompts stay concrete. The finished calculator is at the end of this article.

• Small enough that a long planning process would be more than this job needs
• One known special case, already named: dividing by zero

The sequence I used prompt for the spec→prompt for a failing add check→prompt for the smallest add→repeat for the rest

3 Prompt for the spec before any calculator code

I did not type the spec. I prompted the AI to install Vitest and write specs/spec.md in the same message. Vitest is a program that runs the automatic checks. Then I stopped and read the file. Later prompts point at it.

1. Prompt the AI to install Vitest and write the spec. Stop there.
2. Read what came back: what we will build, what we will skip, and how we will know we are done. Prompt again only if the file is wrong.
3. Do not prompt for the math functions yet. The spec already says they should live in their own file, away from the on-screen buttons.

# Calculator spec

## Rules (keep this small)

- Spec first. Do not invent features that are not listed here.
- Tests prove the engine. The UI only calls the engine.
- One failing test at a time. Write only enough code to pass that test.
- Out of scope is part of the contract. Ignore it on purpose.

## Problem

A visitor can use a small calculator with the four basic operations on two numbers, then clear the display.

## In scope

- Add, subtract, multiply, divide
- Clear
- Pattern: enter A, pick an operator, enter B, press `=`
- Divide by zero shows `Error`

## Out of scope

- Memory keys (M+, MR)
- Percent
- Parentheses or operator precedence chains
- Scientific functions
- Keyboard support

## Acceptance (EARS-style)

- When the user adds 12 and 3, the display shall show 15
- When the user subtracts 9 from 20, the display shall show 11
- When the user multiplies 6 by 7, the display shall show 42
- When the user divides 20 by 4, the display shall show 5
- When the user divides 10 by 0, the display shall show `Error`
- When the user presses Clear, the display shall reset to 0

## Engine contract

Pure functions in `calculator.js`. No DOM.

- `add(a, b)` returns a number
- `subtract(a, b)` returns a number
- `multiply(a, b)` returns a number
- `divide(a, b)` returns a number, or the string `Error` when `b` is 0

## Done when

- [ ] Spec written before production code
- [ ] Each operation has a failing test, then a passing test
- [ ] Divide-by-zero is covered
- [ ] UI uses the same engine
- [ ] Acceptance clicks match this file

That is the file the AI wrote. I read it before any calculator code. “EARS” is only a name for lines that say “when this happens, this should appear.” The “left out” list is part of the agreement. If it is not in the spec, I do not add it, even when it would be easy.

4 Prompt for a failing check, then the smallest fix

The spec already said that 12 plus 3 should become 15. I did not type a test. I prompted the AI for one automatic check of that line, and I told it to stop when the check failed. Add was missing, so the check received nothing useful. That failure is useful. It means the check is real, and the feature is not done yet.

• Prompt for one check only. Name the spec line. Do not prompt for the calculator code in the same message
• Stop when the check fails. A missing function name is a valid failure. Then send a second, smaller prompt
• The second prompt is only “make this one check pass.” Do not add subtract, multiply, divide, or buttons

5 Repeat the same prompts for the next operations

Subtract, multiply, and divide (when the second number is not zero) used the same two prompts as add. Name the next spec line. Prompt for one failing check. Wait. Then prompt for only enough code to pass it. Dividing by zero is a later prompt, because the spec already separated that case. I am showing the subtract fail prompt below. The pass prompt was the same shape as add: only enough code for that one check.

Each row is a pair of prompts: fail first, then the smallest fix. If I had prompted for a plain divide and stopped there, JavaScript would later return Infinity when someone divides by zero. Infinity means “this number has no end.” The spec called for the word Error, so that case waited for the next prompt.

6 Divide by zero was already in the spec

I did not discover this problem by clicking buttons. The spec already said that 10 divided by 0 should show Error. I prompted the AI to turn that sentence into one failing check. The current divide function returned Infinity. The check failed, which is what we want at this step.

I did not type the fix. The AI added a simple rule: if the second number is 0, return the word Error. My part was the two prompts, then reading the report.

7 Prompt for the on-screen buttons last

The automatic checks already proved add, subtract, multiply, divide, and the Error case. Only then did I prompt the AI for the calculator at the end of this article. The buttons should not redo the math. They should call the four functions that already passed.

8 References

These are the sources I used while writing this article. Some describe larger planning systems. Some describe the fail-then-pass habit. I ran that habit by prompting an AI, not by typing the spec or the checks.