How Projects Evolve

The Shape of Growth

The implementation loop described in the previous guide does not change as your project matures. The four commands stay the same. The agent team stays the same. The QA gauntlet runs the same checks. What changes is your experience of the loop, and eventually your role within it.

In the early weeks, the system requires your full attention. By the middle months, it earns your trust. In the long run, something more interesting happens: the execution layer becomes so frictionless that it recedes into the background, and you find yourself spending the majority of your time where your expertise actually matters: designing systems, not implementing them. This guide describes that progression.

The First Weeks

A new WSD project is all Design Mode. You are creating the PRD, crafting the Action Plan, designing features, establishing the architectural vocabulary that will govern the project. The AI is your collaborator in these sessions, but you are driving every decision. This is the most intellectually demanding phase of the project, and the work that matters most, because every specification you write and every decision you make here becomes the foundation that the execution layer builds on.

The first Compilation Mode workscopes are foundational: scaffolding the project structure, establishing the test suite, configuring tooling. The QA gauntlet does not have much to check yet. The Health-Inspector may report mostly SKIPPED checks on a project that has no code. The Test-Guardian has no tests to run. The Documentation-Steward has few specifications to compare against. The full weight of the quality system is present but largely dormant.

Agent behavior during this phase is generic. Your Design Decisions document is empty. The agents follow WSD’s default rules and whatever project-specific context exists in the PRD and Action Plan, but they do not yet know your preferences for naming conventions, architectural patterns, or coding style. You will notice moments where the agent makes a choice you would not have made. This is expected and is the beginning of a calibration process that continues throughout the project.

Commits are frequent during the first weeks. The project is changing shape rapidly, and each workscope establishes structure that subsequent work depends on. The git diff review is thorough here because you are building the foundation.

Finding Your Stride

Once you build enough momentum — the timing depends on the project’s complexity and pace — the system starts paying dividends that outweigh the ceremony.

Design Decisions accumulate. Each time an agent makes an architectural choice you correct, you run /add-dd and the fix becomes permanent. The fourth agent to encounter the same situation handles it the way you want, because the decision is now encoded. The corrections compound: a project with ten design decisions produces noticeably more aligned output than the same project with zero. By twenty, the difference is dramatic.

The QA gauntlet finds its footing. With a real test suite in place, the Test-Guardian catches genuine regressions. With specifications written and code to compare them against, the Documentation-Steward catches real drift. The Health-Inspector’s linting and type-checking catches real quality issues. Rejections start happening — agents produce work, the gauntlet catches a problem, the agent fixes it, and you receive cleaner results than you would have without the review. You begin to encounter design conflicts and resolve them faster than you would have without your documentation collection. The QA system transitions from ceremonial to substantive.

Your post-workscope reviews become lighter. The first few times you viewed the diffs, you read every line. Now you skim with more trust, because the patterns are familiar, you’ve prevented brain debt, and the QA gauntlet has already caught the categories of errors you used to find manually. You still review — the Git Guardrail is a principle, not a phase — but the review is faster because your confidence in the system has been earned through repeated confirmation.

The WPD tree grows deeper. Features gain their own specifications with multi-phase implementation plans. Tickets appear as issues are discovered and resolved. The Action Plan evolves from a flat list of tasks into a navigable map with branches leading to detailed feature documents. You develop an ambient familiarity with the tree’s shape — you know which branches are active, which are complete, and roughly where the Task-Master will go next.

The Mature Project

A mature WSD project, one that has been through dozens or hundreds of workscope cycles, operates with a rhythm that would be unrecognizable to someone seeing WSD for the first time.

It is true that the system runs faster and that agents make fewer mistakes, but these are not the only changes. The most significant change is where you spend your time. Compilation Mode becomes so frictionless that it barely registers as cognitive work. You confirm the workscope assignment, let it run, glance at the journal if you are curious, review the diff, commit, start fresh. The ceremony is the same, but the mental overhead has dropped to near zero. The QA gauntlet catches real issues, but most workscopes pass on the first attempt because the agents have been calibrated by the same rules and decisions the gauntlet enforces.

This frees you to do what you could not do before: spend the majority of your working time in Design Mode. Not because there are more features to spec — though there usually are — but because the execution layer no longer competes for your attention. You design the next feature while workscopes compile the current one. You refine specifications while the QA gauntlet validates the last batch of changes. You explore architectural ideas while the Task-Master works through the checkboxlist you wrote last week. Your primary activity becomes engineering at the specification layer — deciding what to build, how it should behave, and what constraints govern the design.

Escalations become rare. When they reach you, they tend to involve genuine judgment calls — a specification ambiguity, a design trade-off, a case the rules do not cover, rather than routine compliance issues. Your attention is reserved for the decisions that actually require human judgment. The prompt archive, if you have been maintaining it, now contains the complete design history of the project — every decision considered, every approach rejected, every insight that shaped the system.

The shift is subtle enough that you may not notice it happening. But at some point you realize: your attention has aimed toward writing specifications and reviewing diffs, not consumed by implementation. You are developing software without writing it. You are “vibe coding,”¹ but with a firm hand on the wheel.

Your brain has migrated to the specification layer, and WSD is what put it there.

The Convergence

This is worth pausing on. The experience described above resolves a tension between two approaches to AI-assisted development — one that preserves engineering rigor but lacks velocity, and one that provides velocity but lacks structural integrity at scale. The Craft Continues philosophy page explores this tension and its historical parallels in depth.

The arc of a WSD project synthesizes both. The engineering discipline of specifications, phased plans, and quality gates becomes the input to an execution engine that operates with the speed of AI-driven coding. The developer who reaches the mature phase described above has not abandoned either practice. They have both: the rigor of traditional engineering expressed through the specification layer, and the velocity of AI-driven execution carrying those specifications into reality.

Both paths arrive at the same place: the developer operating in the specification layer, with confidence that what they design will be built correctly.

The Feedback Compound

The most important dynamic in a maturing WSD project is how corrections compound. Each rule you add, each design decision you encode, each standard you promote fixes every future instance of a problem, not just the one that prompted it. The effect compounds, across every agent, in every session.

Early in a project, you might add three design decisions in a week. Each one eliminates a category of error that previously required manual correction. By the time you have fifteen or twenty decisions encoded, the agents’ output has shifted measurably — not because the AI model improved, but because the context it receives is richer and more precisely calibrated to your project.

This compounding effect extends beyond explicit rules. The specifications themselves improve. Early Feature Overviews may be vague in places that cause implementation confusion. Later Feature Overviews are sharper, because you have learned what agents need to produce good work and what ambiguities cause problems. The documentation system accumulates institutional knowledge that no individual agent possesses but every agent benefits from.

The practical result is that WSD projects get easier to run over time, not harder. The overhead stays roughly constant — the four commands, the session cycling, the post-workscope review. But the value per cycle increases as the system accumulates the context, rules, and specifications that make each workscope more precise and each review more routine.

What Stays the Same

The ceremony does not change. /wsd:init → /wsd:prepare → /wsd:execute → /wsd:close, fresh session, repeat. The four commands are the same on day one and day three hundred. The agent team is the same. The QA gauntlet runs the same checks.

What changes is not the process but the practitioner. The developer who began by carefully reviewing every line of a git diff becomes the engineer who designs systems while those diffs generate themselves. The front-loaded investment in structure — the PRD, the Action Plan, the feature specifications, the design decisions, the rules — is what makes this transformation possible. Without that foundation, faster execution just produces faster chaos. With it, faster execution produces the experience that WSD was designed to enable: engineering as design, not as typing code.

The discipline is not in trusting that it gets easier — though it does. The discipline is in building the specification layer that lets you work where your expertise matters most, and trusting the system to carry those specifications into reality. That is the arc of a WSD project: not just a process that improves, but a practice that transforms.

Footnotes

1. A. Karpathy (@karpathy), “There’s a new kind of coding I call ‘vibe coding’…,” X (formerly Twitter), Feb. 2, 2025. [Online]. Available: https://x.com/karpathy/status/1886192184808149383 ↩