A full feature, start to ship
Every technique in the course, in order, on one piece of real work.
Here is the whole process on one feature. Times are indicative; the sequence is the point.
Day one: decide
"I want scheduled CSV exports. Do not design anything. Interview me, one question at a time, until you can restate the requirement." => 20 minutes. Surfaces: timezones, what happens on failure, size limits. Output: a corrected restatement. Clear.
Draft from the interview, then edit by hand. Output: specs/scheduled-exports.md. Committed. Clear.
Throwaway prototype: can we stream a 200MB CSV through the email provider? => No. Attachment cap is 25MB. Output: three sentences. Spec updated: link fallback moves into phase 1, not phase 4. Branch deleted. Clear.
Three sessions, no production code, and the plan just survived contact with reality for the cost of an hour.
Day one, afternoon: plan
Vertical slices, riskiest first. Write phases; detail the first three tickets. Output: specs/scheduled-exports/plan.md + t1, t2, t3. Clear.
Days two and three: build
One ticket per session, every session the same shape (Lesson 2.8): open with the ticket, load pointers, plan, implement with the check loop, review the diff, commit, clear.
T1 schema + migration -> followed .agents/skills/add-migration.md (5.4) T2 end-to-end spike -> worktree, paired, 4 turns T3 due-schedule finder -> stopped mid-way, handoff note written (6.4) T3 cont. -> fresh session, note + spec + ticket only T4 monthly rules -> unattended run, preflight done (6.6) T5 CRUD API -> unattended, parallel worktree T6 settings UI -> paired; visual judgement needed
Two things to notice. T3 needed two sessions and that was fine, because the handoff was written. T4 and T5 ran unattended in parallel because both had complete tickets and green checks — but only two, because that was the review capacity available.
Day three: review and ship
- Automated review over the full branch diff, constrained to the five categories (Lesson 6.7).
- Your read: the schema change, the timezone logic, and every test. Skim the UI.
- Fix findings in a session of their own, with its own commit.
- Ship.
Then close the loop
The part that compounds. Fifteen minutes after shipping:
1. Read the log. Which corrections were GENERAL?
-> two new lines in AGENTS.md, one deleted (now a lint rule)
2. Which procedure went wrong twice?
-> new skill: .agents/skills/add-scheduled-job.md
3. Which human review finding could a check have caught?
-> wrote a rule banning setTimeout in src/queue/
4. Which spec gap caused the worst unattended run?
-> added "Decisions already made" to the spec templateThat is the mechanism. Each feature makes the next one cheaper, because the corrections stop being repeated and start being encoded. The agent does not improve; your system around it does.
Try it
Run your big task through this sequence, start to finish. Keep the log. At the end, do the four-question retrospective and actually make the four changes. That retrospective is the difference between having taken a course and having a practice.
Takeaways
- Decide, then plan, then build — each in its own session, each producing an artifact.
- Front-load the risk with a prototype before the plan hardens.
- One ticket, one session, one commit; hand off when a ticket spans two.
- Run the retrospective and encode what you learned, or you will correct the same things forever.
Which single step, if dropped, degrades the whole process fastest?
The retrospective. Without it nothing compounds: the same corrections recur every feature, the brief never reflects reality, and the checks that would free your attention never get written. Everything else is a technique; that step is what turns the techniques into a system that improves.
Module 06 of this course ends here
The Next Steps goes under it: legacy systems, security and supply chain, cost and operations, teams, debugging at depth, and six complete worked projects.
See what is in it →A course by Pieter Zandbergen