The blog you are reading runs on a content management system Partha built with Claude, an AI model. The first version took under three days, and he has kept extending it since. It now publishes four websites, handles sign-in for several people and backs itself up every night.
The part of that project we would recommend to every team took no code at all. Before any building started, Partha wrote a specification of a few pages and signed it off. Everything else was checked against it.
The problem
AI tools are now good enough to build working software, documents and workflows from a description. That is the risk as much as the benefit. A model builds what you describe, and it fills every gap in the description with something plausible.
Teams see this first with content. Ask for a policy and you get a policy-shaped document: well organised, confident, and full of decisions nobody made. The same thing happens, at a larger scale, when a team asks an AI assistant to build a tool. Every gap becomes a decision, and nobody can say later who made it or why.
The solution: decide first, in writing
Partha's spec went through five drafts before sign-off. These five sections did most of the work.
Why. A short paragraph and three points on what the new system had to achieve: faster pages, almost nothing for attackers to target, one place to manage every site. Every later choice could be tested against them.
Decisions settled. A table, one row per decision: the admin address, which sites, who has access to what, how sign-in works, what the editor feels like, where it runs, how email is sent, and one row that mattered more than the rest: no automation may publish. Each row is one line. Once a decision is written and signed, the AI has a fixed point to build to, and a reviewer has something specific to check.
How it fits together. The parts, what each one does, and what keeps working if one stops. For this system, the answer was: the public sites stay up even when the admin is down.
Credentials. Every key the system holds: where it lives, what it can do, and what happens if it is stolen. With the worst case written next to each key, it is obvious which ones are wider than they need to be.
Weak points. Each risk with the specific measure that closes it, named exactly: "two-factor sign-in for every user, with lockout after five failures".
What the spec did during the build
It settled arguments before they started. When a change request contradicted a decision, the question became "do we change the decision?" instead of a quiet drift.
It made review possible for a non-engineer. A reviewer does not need to read every line of code to check the running system against a decision table.
It made changes visible. After sign-off, two decisions changed: the blogs moved from their own subdomains into a folder on each main site, and publishing moved from writing files on the server to pushing them through GitHub. Both changes were deliberate, recorded and explained. A spec that changes on purpose is working. The risk is a spec that is ignored.
It kept the scope honest. A week into the project, the system gained a feature for posting short videos to social platforms. A few days later Partha removed it. Video brings formats, lengths and platform rules that words and images do not, and the spec's "why" did not call for it. Taking a working feature out is easier when there is a written reason the system exists.
How a team can use this
The same approach works whether a team is asking AI to build a tool, a workflow or a set of templates.
Write the why in a few lines. If you cannot, you are not ready to build.
List the decisions as a table. One row per decision, one line per row. Leave nothing for the AI to decide that a person should own.
Name the rule that can never break. Ours was about publishing. Yours might be about client data, approvals or brand claims.
Write down every key and access the system will hold, with its worst case beside it.
Get a sign-off, even if the sign-off is your own, on a date. Then build.
When a decision changes, change the spec first.
A few pages and five drafts. It is still what we check every change against.