Why a project falls apart at the third correction, and what spec coding is
The first pass brings delight, the third a dead end: correcting the form breaks the menu, fixing the menu breaks the block from the second pass. The cause is structural: the project has no description, only a history of requests. Below is a different order of work and the six points that set it.
The first pass brings delight, the third a dead end: correcting the form breaks the menu, fixing the menu breaks the block from the second pass. The cause is structural: the project has no description, only a history of requests. Below is a different order of work and the six points that set it.
Delight on day one, a dead end on day three
A familiar curve for everyone who has tried building something with a model.
The first pass. You described the idea and got a working page. In an evening. Delight.
The second. You asked for a block to be added — it was added, everything works. More delight.
The third. You asked for the form to be changed — it was changed, but the menu stopped working. You fix the menu and the block from the second pass breaks.
The fifth. You no longer remember what was there originally, and neither does the model. It is easier to start again.
And many do start again — for the third time.
The cause is not that the model is getting stupider. The cause is that the project has no description, only a history of requests.
Why edits break the project
Let us go through the mechanics, because without them it is unclear what to fix.
The model does not remember your project. It sees what you showed it in this conversation. Everything decided earlier and left in your head does not exist for it.
Every request is a new task with no context. You say "change the form" and the model changes the form. It does not know that three passes ago you agreed the form's data goes to a particular place in a particular form. It will redo that, because nobody told it.
Decisions accumulate and the description does not. By the fifth correction the project has two dozen implicit rules, not one of which is written down. Every new request has a chance of breaking any of them.
That is not a problem of a particular model and not a problem of bad prompts. It is a structural problem of working "by request".
What spec coding is
A different order of work. One phrase instead of the whole explanation: description first, assembly second.
Not "make me a landing page" followed by twenty clarifications, but first a document stating what should come out — and assembly from that.
The difference looks like this.
Working by request: request → result → correction → result → correction → chaos.
Working by description: description → assembly → a change in the description → reassembly of the part concerned.
The key point in the second scheme: what gets corrected is the description rather than the project. The project is brought into line with it. So changes do not accumulate as a layer of patches — they are always consistent with one source.
What goes into the description
Not a forty-page technical specification. Six points are enough.
What this is and who for. One or two sentences. Who needs it and what task it solves. Without that, the model makes something "in general" rather than "for this".
The screens and what is on them. A list of pages or states with the contents of each.
What happens on actions. Button pressed — what happened. Form submitted — where it landed. Invalid data entered — what was shown.
Where the data is stored. What must persist and what lives only in the session.
What must not exist. The most skipped point and the most useful: a list of explicit prohibitions. Do not collect extra data, do not change the structure of what exists, do not add features nobody asked for.
What already works and must not be touched. A list of what is finished. That is exactly what saves you from the third correction breaking the second.
How Spec Coding works in practice
Step 1. Describe it before the first request. The six points above. Twenty minutes of work, and they pay back at the second correction.
If phrasing it is hard, ask the model to compose the description from your idea: you describe the task in words and get a structured document, then you correct it. Correcting something finished is faster than writing from scratch.
Step 2. Assemble from the description. Hand over the document whole rather than a summary.
Step 3. Change the description rather than the project. If something new is needed, put it into the document first, then request the change with a reference to the updated text.
Step 4. Keep a list of the untouchable. Every request for a correction ends with a sentence about what must not be changed. That is one line, and it prevents most breakages.
Step 5. After every correction check more than the new part. What worked before has to be checked too. Five minutes against an hour of investigation.
Why this matters especially when you are not writing the code
A programmer who wrote by hand holds the project in his head: he remembers why something was done that way and will not break it by accident.
You do not remember, because you did not write it. And the model does not remember, because it does not store it.
The description replaces what neither of you has — a shared memory of the project.
Hence a non-obvious conclusion: the less you understand code, the more important the description is for you. It is not for the model, it is for you.
What this gives with a client
The description is the technical specification. The same document is shown to the client before starting: here is what will come out. Agreed, then assembled.
It closes off endless revisions. "Addressing comments until the client is fully satisfied" is the phrasing that has contractors working for months unpaid. Comments are accepted within the agreed description; everything else is separate work for separate money.
It protects you on handover. A project with a description can be passed to another person. A project without one cannot be passed at all, and that is your own problem when you want to pass it on.
And it justifies the price. A client who sees a document of six sections argues with the items rather than with the total.
What the platform offers for Spec Coding
Site templates — 343 prompts, and they are built on exactly this principle. Each card is not "make a landing page" but a full brief: structure, typography, colours, animation behaviour on hover and scroll. On average around 10 000 characters, the most detailed up to 75 000.
That is, the description has already been written for you, and written by somebody who knows what belongs in it. The preview is visible before launch.
The prompts are not tied to a specific service: they paste into any environment that can write code. Plus plan.
Skills for Claude Code — over 10 000. A skill is a chain of agents with the task divided into parts and each passed on — the same logic as spec coding, only inside one tool. The catalogue is open to everyone, the files come with Basic.
The "Engineers" category assistants — from Basic. They will help compose a description from your idea.
Registration is free and opens three days of full Basic access.
Where to start today
One action. Take the project that is falling apart and write the six points for it after the fact. Especially the last: what already works and must not be touched.
Twenty minutes. Then make your next correction request with a reference to that document and an explicit list of the untouchable.
Usually the project stops breaking immediately — not because the model got cleverer but because it finally has what it lacked: a description of what it is fixing.
Why a description works: the mechanics of cascades
Spec coding is a particular case of a general principle, and the "Basic prompting" course covers it separately.
Cascading prompts. A large task is broken into a chain of small requests and the model goes along it step by step.
Why that is needed — the phrasing from the lesson: each separate request is precisely focused, the model does not scatter and solves one sub-question. You control every step, check the intermediate answers and steer onwards.
The example straight from the lesson is assembling a landing page: first invent the structure, second write the headlines, third the block texts, fourth the detail.
The conclusion, which explains the whole article: you lead the model along a clear plan, like a scriptwriter. A project description is exactly such a plan, only written once and reused.
The "Basic prompting" course (the "Cascading prompts" lesson) — Basic plan.
Where writing a spec before code is taught
The express course "Claude: from the first prompt to your own library of mega-abilities", Creator and above ($9) — the eight tags of a mega prompt: role, goal, task, response structure, constraints, success criteria. That is a spec, only for a model. The phrasing from the course: understand the structure once and you stop hunting for good prompts in chats, because you assemble your own in five minutes.
The express course "Bureau of personal AIs", Creator and above ($9) — designing before assembly.
The Gemini express course ("Google Gemini + a team of 12 Gems…", $9, Creator and above) gives the same frame differently: role, context, task overview, step-by-step instructions, constraints, success criteria. Six blocks filled in for your task produce an industrial prompt.
Ready briefs as a benchmark for scale. The Site templates section, Plus plan — prompts averaging around 10 000 characters, the most detailed up to 75 000. That is a full specification running to dozens of pages. It is worth opening one and seeing what is described in it: usually it contains everything you would remember at the third correction.
Assistants, Basic plan: Prompting Assistant, GPT Prompt Master, Bot architect.
Skills where the spec is built into the process
The article explains why a project falls apart. These tools do not let you start writing code until the spec is agreed. All of them are advanced skills: Creator+, or $9 one-off, or 1,000 XP.
- Spec before code — four phases with gates: describe, plan, break into tasks, implement. Each requires explicit approval. Large tasks have a phase zero — a check for whether several independent pieces are sitting inside one request
- Spec Kit — specification-driven development with AI — an open set of processes and /speckit-* commands: first fix what is being built and why, then plan, tasks and implementation
- Development through specifications — seven stages from discussion to archive, with requirements in "shall" form and criteria in a "given — when — then" structure
- A technical specification — six obligatory sections, and the most important is the last: conditions of readiness as executable commands with an expected result. Not "it works" but a specific check
- Fixing acceptance criteria — it freezes the definition of done before work starts. Any attempt to rewrite requirements along the way becomes visible in the change history
- Breaking work into subtasks — by vertical slices: each piece gives a working result rather than half a feature. Checkpoints every two or three tasks
- A step-by-step development plan — goal, boundaries, what we will not do, risks, a list of files. The "will not do" section matters more than the rest
- Change impact analysis — directly about the third correction from the title: what else this change will affect
What to take without installing anything. The format from the fourth item: a condition of readiness should be a command that can be run rather than the phrase "it should work". Disagreements arise exactly where readiness is described in words.
What to take on the platform for this task
- Basic prompting — course with the "Cascading prompts" lesson; Basic plan.
- VIBE CODING — course: from an idea to a clear technical brief and a built app; Creator plan.
- Spec Kit — specification-driven development with AI — skill; advanced (Creator+, $9 or 1,000 XP).
- Spec before code — skill; advanced (Creator+, $9 or 1,000 XP).
- Prompting Assistant — assistant: creating and optimising prompts; from Basic.
- Site templates — 343 full brief-prompts; Plus plan.
What to read next
An application's architecture as a building — so corrections go to the right address.
A 30 000 character prompt — what a real description looks like.
From prototype to product — what to add once it has stabilised.
Skills for Claude Code — chains instead of a single request.
Claude Code + NotebookLM — where to keep research that does not fit in the context.