Objective
Your mission
Apply the start-fresh decision framework to a real debugging situation and make a rational decision. Output: decision_log.md.
You need: A project where you're stuck (or can create a stuck situation).
Time: 20 minutes.
Step 1: learn the decision framework (5 min)
Signs it's time to start fresh:
- 3+ failed correction rounds and the build isn't converging
- Fresh-context technique didn't help
- Fundamental architecture is wrong
- The build is worse than the starting point
- You can't identify the root cause
- Each correction takes longer
Signs you should keep iterating:
- The build is 70%+ working
- Problems are specific and isolated
- The architecture is sound
- You've done fewer than 3 correction rounds
- Each correction makes progress
The cost calculation:
"If I spend 10 more minutes correcting this build, what's the probability it'll be working? If I spend 30 minutes on a fresh build with a clearer spec, what's the probability it'll be working?"
If corrections: 20% chance, fresh build: 80% chance → start fresh. If corrections: 70% chance, fresh build: 90% chance → keep iterating.
The professional's secret
Professional developers start fresh more often than beginners. Not because they're less skilled, but because they recognize the sunk cost fallacy faster. A beginner thinks "I've invested 45 minutes, I can't throw that away." A professional thinks "I've invested 45 minutes and the build is worse. A fresh build takes 30 minutes. I'm saving 15 minutes by starting over."
Step 2: assess your situation (5 min)
Think about a time you were stuck on a build — or create a situation where you're stuck by building something and breaking it beyond easy repair.
Write in your file:
## Situation
Project: [what you're building]
Time spent so far: [minutes]
Current state: [what works, what's broken]
Step 3: apply the framework (5 min)
Write in your file:
## Signs It's Time to Start Fresh
[Check each that applies:]
- [ ] 3+ failed correction rounds
- [ ] Fresh-context technique didn't help
- [ ] Fundamental architecture is wrong
- [ ] Build is worse than starting point
- [ ] Can't identify root cause
- [ ] Each correction takes longer
Total: [N/6]
## Signs to Keep Iterating
[Check each that applies:]
- [ ] Build is 70%+ working
- [ ] Problems are specific and isolated
- [ ] Architecture is sound
- [ ] Fewer than 3 correction rounds
- [ ] Each correction makes progress
Total: [N/5]
## Cost Calculation
- 10 more minutes of corrections: [X]% chance of working
- 30 minutes of fresh build: [Y]% chance of working
- Expected value of corrections: 10 min × [X]% = [result]
- Expected value of fresh build: 30 min × [Y]% = [result]
Step 4: make the decision (5 min)
Write in your file:
## Decision: [Start Fresh / Keep Iterating]
## Reasoning
[Why did you choose this? Reference the signs and cost calculation.]
## If Starting Fresh:
- Refined spec: [what you'd change based on what you learned]
- What you're bringing from the previous attempt: [spec, plan, learnings, chunking plan]
- What you're leaving behind: [the broken code, the polluted context]
## If Keeping Iterating:
- What specific correction will you give? [3-part framework: what's wrong, what I want, what to keep]
- What's your limit? [how many more rounds before you'll reconsider]
You've spent 45 minutes on a build that's now worse than where you started, and you can't find the root cause. What does the framework say?
A build worse than its starting point with no identified root cause signals a fresh start. The 45 minutes already spent is sunk cost; compare the odds of the next 10 minutes.