I built the software that ran my Decoupled Days slides in five weeks. Most of it on a flight, some of it inside a management meeting, glancing down between agenda items to type continue. That story is everywhere right now. A solo dev, a greenfield project, working software in days.
It is also not software development. Software development is five developers, a client, requirements nobody wrote down, a codebase somebody else maintains, and a deadline. The talk below spends a while on why the solo story doesn’t scale and what the measurements actually show. This post skips all of that and goes straight to the model, because after the talk the question I kept getting was “what do I hand my team?”
If you want every claim with its source, the deck publishes as an annotated article.
One piece of the diagnosis is worth keeping, because it explains why the fix is a process change and not a better model. Generation accelerated. Review, QA, deploy, and on call did not, so the pile-up lands right after the code gets written, and the velocity chart calls it progress.
One box becomes two
Your SDLC survives. Requirements, design, QA, deploy, on call, none of it moves. The only box that changes is implementation, which splits into two phases with a contract between them.
Scaffolding comes first. A senior developer paired with a CLI agent generates the whole system, rough. It starts with a plan, not a prompt. The agent drafts the build plan from the requirements and the design, the developer argues it down, and then it builds. The output is running code.
Refinement follows. The full team, QA included, works ticket by ticket with IDE tools. Edge cases, error handling, polish, until every acceptance criterion is met and stakeholders sign off.
So the four phases, each with an owner and an artifact:
| Phase | Who | Artifact | Done means |
|---|---|---|---|
| Requirements | Product owner, UX research | PRD, stories, acceptance criteria | Stakeholders sign off |
| Solution design | Architect, UX design | Diagrams, specs, ADRs, wireframes | Survives technical review |
| Scaffolding | One senior dev plus a CLI agent | Running code | Happy paths work, patterns established |
| Refinement | The full team, IDE tools | Production software | Every acceptance criterion met |
The strip to memorize is the AI posture. Human dominant on the ends, AI dominant in the middle with human direction. Iterate freely inside any phase. The model is only strict about the boundaries and the artifacts that cross them.
Isn’t this just waterfall? No, and the difference is precise. Waterfall assumed perfect upstream knowledge and punished late change with contract pain. This model iterates freely inside every phase. What it refuses to do is let phases blur into each other silently. Architects and film editors take the same discipline for granted. Film even has a named event for it, picture lock. Software’s answer to all that structure has been one undivided job title.
What a scaffold is
The scaffold is running code that is intentionally incomplete in documented ways. Every word is load-bearing. Running means it executes and demos on real infrastructure. Intentionally incomplete means the gaps are choices, not accidents. Documented means the gaps are written down.
If you remember loading images on dial-up, ticket-by-ticket development is a baseline JPEG. Full quality, a sliver at a time, no view of the whole until late. The scaffold is the progressive JPEG. The entire image shows up immediately, blurry, then sharpens pass by pass. Stakeholders can react to a progressive image at 30 percent loaded.
Five properties separate a scaffold from an expensive mess:
- Happy paths work end to end, on real infrastructure.
- Patterns are established. Auth, error handling, component structure, API conventions, each defined and demonstrated at least once.
- Edge cases are identified but deferred, in DEFERRED markdown files. An empty deferred list doesn’t mean the work is done. It means whoever built the scaffold didn’t think hard enough.
- The UI is wireframe quality. Layout and flow are correct, pixel polish is delayed on purpose.
- Nothing is mocked that would take architectural surgery to unmock. If it needs a database, it uses a real database with a minimal schema.
What a scaffold is not
The name matters because every wrong name causes a different failure. Call it a prototype and the code gets thrown away, so teams rebuild what was already sound. Call it an MVP and it ships, so the deferred edge cases go to production undeclared. Call it a spec and the whole point is lost, because specs don’t run.
There is one danger built into the technique. A scaffold demo looks 80 percent done and is 20 percent done, because the happy path is exactly what demos show. The client sees it, believes it, cuts the refinement budget. The countermeasure is a sentence, said in every single scaffold demo: this is the scaffold, the pattern is locked, refinement starts next week and will take X weeks.
The handoff is the whole point
Before anyone joins, make the agent clean up. Point the static tools at the scaffold. Linters, the type checker, duplication detectors, security scanners. The agent fixes every finding and the tools run again, around the loop until it comes back clean. Static tools don’t hallucinate, which makes them the perfect sparring partner for a model that does. Cleanup by the agent costs tokens. The same cleanup after four developers have built on top of the mess costs the team.
Four artifacts cross the boundary at handoff. ADRs, capturing why the key decisions were made, since the what is already visible in the code. The DEFERRED files, per component. The refinement backlog. And a patterns doc, how to do things the right way in this codebase, versioned with the code instead of rotting in a wiki. Then a live walkthrough, not a document, where the scaffolder explains decisions while the team can still ask why. If the scaffolder can’t explain a decision, it doesn’t hand off yet.
And the agent that wrote the code is still there. Every inherited codebase now comes with something that answers questions.
Rules that keep it honest
AI never writes the requirements. This model verifies every phase against the phase before it. Design checks against requirements, the scaffold checks against the design, refinement checks against the deferred list. Requirements have nothing upstream except a human who understands the business. A hallucinated line of code fails a type check, a test, a review. A hallucinated requirement reads as plausible, gets designed, scaffolded, refined, and ships as working software that does the wrong thing. AI still helps in that phase, but the rule is transform, don’t invent. PRD to backlog, notes to acceptance criteria, never authoring the intent.
Commit size is a phase signal. A few large, coherent scaffold drops, the boundary event, then a flurry of small refinement commits, one ticket each. If your git history doesn’t change shape at the boundary, the phases have blurred.
Review the artifact, not the diff. Line-reviewing the whole scaffold drop is duplicated effort, since refinement revisits every line anyway. Go deep on the data model, the most expensive thing to change later. Review one example of each pattern line by line, because every ticket will copy it. Audit the deferred list. The walkthrough is the review.
And the one cultural rule, enforced in review: if you can’t explain it, it doesn’t ship.
Two questions decide who does the work
The phases say when the AI leads. They don’t say which ticket goes to an agent and which goes to a person. For that, ask two questions about any unit of work. Judgment density: how much does the right answer depend on business context, system history, and trade-offs the model can’t see? Pattern density: how well represented is this work in public code?
Two axes, four quadrants, four postures.
The trap quadrant is low pattern, low judgment. A rare vendor API or a legacy bug looks easy, but the work isn’t represented anywhere and the AI won’t say it hasn’t seen it before. It produces something confident, plausible, and invented. Investigate first, then teach the AI what you found.
Now plot real tasks and notice where the dots pile up. Scaffolding sits in the AI-leads corner, but most enterprise work lands on the judgment side. AI commoditized typing, not judgment. The developer who takes ambiguity, makes the quadrant call, and owns the direction became more valuable, not less.
How to try it
Pick a greenfield feature with a real deadline, real stakes, and bounded scope. A pilot nobody cares about proves nothing. Name the phases out loud, with the boundary as an event.
Staff for the real ratio. On a promotion service my team shipped, story points said ten weeks and it took four. One dev-week of scaffolding, eight dev-weeks of refinement. Scaffolding is judgment bound, one person with high leverage. Refinement is capacity bound, the team in parallel. Staff for that, not for the excitement.
Measure rework, not velocity. Reverts, post-merge churn, review queue depth, plus the phase diagnostics like handoff questions and scaffold assumptions that proved wrong. Velocity will go up no matter what. That’s not the signal.
Nothing here is foreign. It’s how you already build inside a single pull request, happy path first, then iterate until release-ready. The scaffold just gives the rough-but-running half a name and a handoff, and the iterate half becomes the team’s phase. The phases were always there. AI changed the scale, so now they need to be done on purpose.