Why ad-hoc delegation falls apart

Lately I've been delegating whole tasks to AI — including a full-stack project built end-to-end, just to see what happens.

At first I did it freestyle. The result:

• lots of issues, lots of debugging
• the same prompt repeated over and over before things clicked
• a context window that fills up fast — and once it does, the responses start hallucinating

I tried open-source plugins, skills, and tools built for exactly this. They worked, but they were overkill: more tokens, more context overhead, for problems I mostly didn't have.

So I settled on a personal workflow for building new projects from scratch. I don't know if it has an official name, so let's call it Sprint Driven Development.

One rule: every project gets a docs/sprint folder

The implementation is simple. In every project, set up a docs/sprint-<x>/ directory:

```docs/└─ sprint-<x>/ ├─ plan.md ├─ tasks.md ├─ final-report.md ├─ reports/ ├─ rca/ (optional) └─ resources/ (optional)AGENTS.md (optional, repo root)```

Then two rules drive the whole thing:

1. Every sprint targets one specific goal. Sprint 1: slice the UI. Sprint 2: the backend. Sprint 3: integration. And so on.
2. Every sprint, the agent follows the same contract: at minimum, produce a plan, tasks, per-phase reports, and a final report.

What each file is for

• plan.md — start in plan mode; the agent plans before it builds anything. This is where most of the human loop happens: you discuss with the agent until the direction is actually right.
• tasks.md — once the plan is reviewed, break the work into the smallest tasks possible, grouped by phase.
• reports/ — the agent generates a report per phase: what was built, findings, how to run it. From these, you decide whether to test each phase manually or keep going.
• rca/ — when something breaks, have the agent fix it and write up the root cause. The next time the same issue shows up, you just point back here.
• resources/ — reference material for the next sprint. Sprint 2 writes api-contract.md; sprint 3's agent just reads it.
• AGENTS.md — instructions handed over from a previous sprint. Backend done in sprint 2? The sprint-2 agent explains the integration flow — endpoint chaining, edge cases — as instructions for sprint 3.
• final-report.md — the sprint summary, so you get the overview. It doubles as compact context for the next sprint, or for debugging in the same session.

What you actually get

Everything is tracked: the plan, task checkpoints, per-phase reports, RCAs, resources, the final report — even instructions for the next agent.

The effect isn't just tidiness. Switching sessions becomes trivial, and so does handing a task — or a whole sprint — to a different agent or model. I've tested this across tools (CommandCode, Claude Code, OpenCode), swapping models and sessions mid-project. Everything picks up where it left off, no re-explaining from zero.

One tip before you start: write the plan and tasks with a reasoning model (Opus, GLM 5.2, DeepSeek V4 Pro). Once those two files are solid, the implementation is safe to hand to a cheaper model.

Here's the template: docs/sprint template.