Day 3: Choose your adventure

3 Days of Spec-Driven Development · Day 3 of 3 · five lessons on four pages, three exercises, a wrap-up · about three hours: 180 minutes including the opener

Specs win. Fix the code, or fix the spec and cascade.

the Linked-Intent Development README (jszmajda/lid), read 2026-09-22

Two days ago you had a chat window. You now have a spec with criteria that can fail, a runner that goes to green on its own, and a critic that audits the result. Today is about handing that to five other people. You will meet three spec frameworks, install exactly one, run one deliberately vague feature brief through it, take a late requirement on the chin, and leave with a comparison card your team can read without taking this course. Pick your track in Lesson 3; your choice sticks for the rest of the day.

Watch this first

Opener · 10 min

#17 - How Zalando Engineers Software & AI at Scale - Bartosz Ocytko (Executive Principal Engineer)

bynd code, 2026-09-20. Watch 0:00 to 10:00, the opening of the chapter How Zalando Scales AI Engineering. Lessons 1 and 2 replay the five minutes from 35:19 that Day 2 Lesson 4 offered.

What to listen for. Listen for the moment the speaker stops describing their own workflow and starts describing a team's. Note what the speaker says a team needs before it lets go of a control. Research found no head-to-head talk comparing the three frameworks, so treat this opener as adoption evidence, not as a recommendation.

Before you start

Day 3 works in day3-work, a copy of your lane at the course root. The shipped sandbox/ is never edited, so what a track wrote is a diff against it. Exercise 1 opens with this block, pasted from the course root. It makes work/ for your answers, copies your lane to day3-work, moves you into it, and copies in the Change C brief and the blank map as ../work/map.md, never over a map you have started. If day3-work already exists, run rm -rf day3-work first: cp -R into an existing folder nests a second copy inside it.

Swift lane
mkdir -p work && cp -R sandbox/swift day3-work && cd day3-work
cp ../day-3-choose-your-adventure/starter/change-c-brief.md .
{ [ -f ../work/map.md ] || cp ../day-3-choose-your-adventure/starter/map-template.md ../work/map.md; }
ls change-c-brief.md ../work/map.md
Kotlin lane
mkdir -p work && cp -R sandbox/kotlin day3-work && cd day3-work
cp ../day-3-choose-your-adventure/starter/change-c-brief.md .
{ [ -f ../work/map.md ] || cp ../day-3-choose-your-adventure/starter/map-template.md ../work/map.md; }
ls change-c-brief.md ../work/map.md

Start Claude Code there with claude. day3-work is the day's project root, the folder holding CLAUDE.md, read from ./CLAUDE.md, and your framework is initialized in it. Setup blocks are pasted from the course root; every other Day 3 command runs from inside day3-work. Starters are at ../day-3-choose-your-adventure/starter/; answers go in ../work/.

To reset, quit Claude Code, then from inside day3-work run your lane's line.

Swift lane
cd .. && rm -rf day3-work && cp -R sandbox/swift day3-work && cd day3-work
Kotlin lane
cd .. && rm -rf day3-work && cp -R sandbox/kotlin day3-work && cd day3-work

It re-copies the shipped lane, leaves you inside it, and leaves ../work/ untouched. Then, in Exercise 1 or 2, re-run that page's setup copy lines (everything after its cd day3-work) and your track's install-and-init steps from Exercise 1. OpenSpec on your PATH and the LID plugins at user scope survive the reset; BMAD lives in the project, so you run its installer again. A fresh copy has no Change C, so in Exercise 3 run your track's install-and-init from Exercise 1, then Exercise 2 through its self-check (its checkpoint saves time), then cd .. and Exercise 3's setup block. Do not reset between exercises: each one continues from what the one before left.

What today needs

The day in order

Eight pages after the video. Lessons 1 and 2 share a page, so the five lessons take four pages.

Ticks need JavaScript and stay in this browser.

Starter files

Each exercise copies the file it needs from ../day-3-choose-your-adventure/starter/ at the step that needs it, so your framework never reads Change C's acceptance suite while it plans and builds. Exercise 3's two late-change assertions are the exception: its setup copies them in, your framework can read them, and step 3's red, before any code changes, proves they bite.

Videos and reading

No video is required to finish an exercise.

Sources