A Plan Fails

A hand-written AI agent run, line by line. The lesson: recovery means distrusting your plan.

task
I plan eight hours of work and get four. Figure out why.
Watch this run on the timeline →
plan
Four hours go missing every day. I write a plan — but a plan is only my theory of the fix.
  1. Look at a real day
  2. Name what eats the time
  3. Build the fix
  4. Check a real day
readyesterday, hour by hour
evidence before theories
eight hours of work planned — barely four happened
Eight hours planned, four happened. That's a lead, not proof.
Four lost hours. A tighter schedule should get them back.
dorebuild the day into strict time blocks
I bet the plan on it — a stricter schedule.
every hour blocked and labeled
The schedule is built. I haven't seen it work yet.
looktoday, against the blocks
a fix only counts if the day improves
still four hours lost — the blocks got ignored
Still four hours gone. A failed check doesn't just kill the fix — it puts my whole plan under suspicion.
your call
I was wrong. You call the next move.
Still four lost hours. Where do I look next?
“follow where the hours go” or “tighten the schedule again”
The script writes both paths. Beats tagged with a pick happen only on that path.
if you picked “tighten the schedule again
docut every block to 45 minutes, add alarms
Tighter, then. Forty-five minute blocks.
if you picked “tighten the schedule again
day three: the tighter blocks got ignored too
Ignored again. Repeating a failed fix harder is still the same guess.
if you picked “follow where the hours go
Guessing hasn't helped. Follow where the lost hours actually go.
if you picked “follow where the hours go
The schedule theory dies here. The plan built on it dies with it.
if you picked “tighten the schedule again
Discipline wasn't the problem. Trace where the hours actually go.
plan dead — built on a guessed cause
I kill the whole plan. Every step inherited the guess, so patching one step can't save it.
plan
New plan, built differently — every step starts from where the hours actually went, not a theory.
  1. Trace where hours go
  2. Find the real cause
  3. Fix that instead
  4. Check a real day
readthe phone's screen-time report
follow the hours instead of guessing at them
3 hr 41 min of phone yesterday — most of it midday
There it is — almost four hours of phone. The evidence was always there; my theory kept me from looking.
A schedule can't compete with a phone within reach. So move the phone, not the blocks.
readwhen the phone takes over
understand the cause before designing the fix
worst stretch is 11am–2pm — the middle of the work day
It eats the middle of the day.
dophone in another room until 2pm, one check at lunch
move the phone, not the blocks
phone parked — mornings are clean
looktoday, hour by hour
the same check that failed under plan A
seven of eight planned hours actually happened
Seven real hours — because I let plan A die.
done
recovery means distrusting your plan
  • ·Plan A was a bet on a guessed cause — the check exposed it.
  • ·When the fix failed, the plan was the suspect, not just the fix.
  • ·Following the real hours, not the theory, found the phone.

Every line above is a hand-written script; no model.

The same lesson with code: A Plan Fails — “/api/orders is returning 500s — fix it.

the other runs:
  • A Clean Run — “Tests are failing in utils.test.ts — find out why and fix it.
  • Memory Fills Up — “Rename getUser → fetchUser across the codebase — 14 files.
  • A Clean Run — “What can I make with what's in my fridge?
  • Memory Fills Up — “I saved 14 apartment listings. Which ones should I actually tour?