Vision, plan, build, verify.
A method for building real software with AI, in which one person holds the vision and every decision, an AI architect turns that vision into written plans, and an AI builder builds only what was written down and approved. It was developed while one person, who is not a developer, built and ran a production sales system for a custom fabrication business. Nothing in it is specific to that business.
The diagram below follows a single piece of work from idea to done. Select any part to see what it does and what it connects to, or take one of the two walk-throughs: one where the work goes to plan, and one where the vision runs into something and has to change course.
For the numbers behind the system this method built, see What it took: building a sales CRM.
Beneath the flow is the set of pieces the work runs on. Each one exists for a reason and lives where it does for a reason. Select any of them to see which parts of the work use it.
Building production software with AI changes where the risk sits. The AI is fast, capable and confident, including when it is wrong, and it is not reliable at reporting on its own work. The expensive failures are not the loud ones that stop everything. They are the quiet ones: a file that silently did not save, a step reported as done that was never run, a plan built against something that stopped being true last week.
Directed Build is arranged around that. It assumes nothing is true until it has been read back from the record, and it spends a little speed on every piece of work so that silent failures become visible ones. Slow is recoverable at any point. Silent is recoverable only by accident.
It also fits one particular shape of work: a single person with a clear sense of what the business needs but who is not a developer, building systems that real people depend on every day. That person cannot review code line by line. What they can do is hold the vision, decide at the right moments, and look at what was built. The method is built so that those three things are enough.
None of this was designed up front. It accumulated one incident at a time.
The written plans exist because the conversation that produced a plan is not a reliable place to keep it. The independent check exists because a report of success turned out, more than once, not to mean success. The hand-off works the way it does because of a sequence that ran in both directions: plans pasted directly into the builder were cut short or blocked on the way in, so plans moved into the shared record. Then the builder's own safety system blocked work whose instructions arrived only inside a file, because nothing showed they came from the person. The remedy for one channel's failure had caused the other's. The fix was to separate permission from content: the person's own message carries the permission, and the record carries the work.
The copy-and-paste channel between the person and the AI failed in at least six distinct ways, each recorded with its date. Output arrived with its middle missing. Lines arrived welded together. Formatting symbols were silently eaten and took characters with them. Output arrived looking complete when it was not. Each became a rule, and most of the rules share one theme: read the result from the source, not from the report.
Some lessons were about the tools doing the checking. A search once reported no matches across a project. Before accepting that, a second search was run for something known to be there. It also returned nothing. The search tool could not see that project at all, so its "nothing found" meant nothing. Check the instrument before trusting its zero.
The method was also tested against the alternatives before being kept. When newer tools made it possible to move the planning role into the builder's own environment, that was not decided on a hunch. It was tried on a real, small task with a known correct answer, and measured four ways: how often the person had to carry things between tools, whether they felt they had to watch the work to trust it, whether every check actually ran, and whether an automated reviewer agreed with the independent check. It ran cleanly. It was also recorded with three qualifications. The trial tested building and reviewing, not planning. The reviewer had checked the builder's own summary of what had been approved, rather than the approved text itself, which meant it could not have caught a copying mistake. And a second trial never ran, because the vendor changed the product it depended on. The person decided on the evidence available: keep the current method, and revisit once the tools settle.
That decision, and the trial behind it, were themselves written, checked and verified by the method being judged.
A method like this goes stale the way any document does, quietly. Four habits keep it current.
Every correction is dated. A rule that turns out to be wrong is not rewritten. The original stays, with a dated correction beside it saying what changed and why. Anyone reading later can see what was believed, when, and on what evidence.
The later dated correction wins. When two copies of a rule disagree, what matters is which carries the later dated correction, not which document is more important. Some duplication is deliberate, and a deliberate copy says so and names its source, so a reader can tell drift from design.
Rules that keep being missed move, rather than being repeated. If a rule is broken twice, restating it more firmly in the next set of instructions is the wrong fix. The right fix is to move it to a layer that applies automatically: from a skill to the always-on rules, or from the always-on rules to an automatic check.
The list of checks has a ceiling. The checklist run before any work is handed to the builder has five checks. When a new lesson arrives, it extends an existing check or something is cut. A checklist that only grows eventually stops being read.
Directed Build grew out of one person's work, but its principles are not tied to any business, tool or field.
Keep the vision with a person. AI can plan, build and check. Deciding what the work is for, and when it has to change, stays with someone who is accountable for the result.
Write it down before it is built. A plan that lives in a conversation is gone when the conversation ends. A plan in a shared record can be approved, checked against and revisited.
Separate who plans from who builds. When the same hand does both, nothing checks either.
Check the result, not the report. Read what actually landed. A confident summary is not evidence.
Make stopping the safe choice. A builder that stops when something does not match is working correctly. A builder that guesses its way through is where silent failures come from.
Grant permission narrowly and in the person's own words. Name the actions that are allowed. Anything not named is not allowed, so mistakes fail safe.
Protect what is live. Experiments run where nothing reaches the people who depend on the system. The production system is only changed through the full method.
Check the instrument before trusting its answer. Test your checks against something you know is there before trusting what they say is missing.
Turn every failure into a dated rule, and move rules that keep being missed to where they fire automatically. Memory is not a control.
Change course on purpose. When the vision is blocked, decide on the evidence you have, write down why, set a point to revisit, and move on. Nothing is lost if the record holds it.