Fable 5 is about as capable as AI models get right now, and it will still confidently build you the completely wrong thing — if you prompt it wrong.
The fix is one line. It takes under ten seconds, and it is the exact thing I do before I build any automation for a client: automated invoicing systems, custom dashboards, real internal business tools. This is the walkthrough version of that.
The prompt
Before it writes a single line of code, send this:
Interview me before you write any code, until you fully
understand the build and can confidently build me the
perfect system.Then just answer the questions it asks. That is the whole technique.
Why this works
AI builds the wrong thing for the same reason most software projects fail: people start building before they understand the problem. A model given a one-line request does not stop and ask what you meant. It fills every gap with an assumption, and because it is good, it fills them fluently — you get a finished, confident, coherent app built on a stack of guesses.
Forcing it to interview you flips the order. It has to understand the blueprint before it lays a single brick. The assumptions still get made — they just get made out loud, as questions you can answer, instead of silently inside the code.
The model was never the bottleneck. The brief was.
The walkthrough
Four steps, about ten minutes
Step 1: Send the interview prompt first — before anything else
Open a fresh chat and send the prompt above on its own. Do not attach your idea to it yet. If you describe the build in the same message, most models will start building anyway and ask questions afterwards, which defeats the point.
Step 2: Answer in plain language
It will ask who uses this, what happens to the data, what the edge cases are, what it should do when something fails. Answer like you would explain it to a new hire. You do not need technical vocabulary — “when an invoice is more than 30 days late, email me, not the client” is a perfect answer.
Step 3: Say “I don't know” when you don't know
This is the step people skip. If you do not have an opinion on something, say so and ask what it would recommend and why. You get the reasoning, and you get to disagree with it before it becomes code rather than after.
Step 4: Ask for the spec back, then approve it
Before it builds, send: “Summarise the full build back to me as a spec, including every assumption you are making.” Read it. Correct anything wrong. Then tell it to build. Catching a wrong assumption in one sentence costs seconds; catching it in a finished app costs the whole build.
What good answers look like
The interview is only as good as what you put into it. A few patterns that consistently produce better builds:
| It asks | Weak answer | Answer that gets you the right build |
|---|---|---|
| Who uses this? | My team | Two people: me (full access) and a bookkeeper who should only see paid invoices |
| Where does the data come from? | A spreadsheet | A Google Sheet that my VA updates daily, roughly 200 rows, columns can move |
| What should happen on failure? | Show an error | Stop, don't half-write the record, and send me a Slack message with the row that failed |
| How many records? | Not many | About 300/month now, maybe 3,000 in a year — build for the 3,000 |
What you actually save
- A rebuild. The usual failure is not a broken app, it is a working app that solves the wrong problem — and that costs the entire build, twice.
- Usage limits. Long generate-then-discard cycles burn far more than a short conversation does.
- Your own clarity. Half the time the interview surfaces that you had not decided something. Better to find that out in a chat than three hours into a build.
Where it does not help
Being straight about the limits: this is a scoping technique, not magic. It will not save a build that is genuinely too big for one pass, it will not stop a model from making implementation mistakes inside code, and on a truly trivial task — a one-off script, a quick regex — the interview is slower than just asking.
Use it when you are building something you intend to keep. That is the same rule that applies to choosing what to automate at all: repetition and permanence are what justify the setup cost.
Frequently asked questions
Does this prompt work with any AI model?
Yes. It is not model-specific — it works with any conversational coding assistant, because it is exploiting something universal: models default to answering rather than to asking. The only variation is how many questions you get back. If a model asks two shallow questions and starts building, reply with “keep interviewing me, you don't have enough to build this yet” and it will continue.
Why send the prompt before describing what I want?
Because if you describe the build in the same message, most models treat that as the brief and start generating, then ask clarifying questions afterwards as a courtesy. Sending the instruction alone sets the mode first, so your description arrives as an answer to its first question instead of as a build order.
How many questions should it ask before building?
For a small internal tool, expect somewhere between five and fifteen. If it asks two and offers to start, it does not have enough — push it to keep going. The signal that it is genuinely ready is when the questions get boring: edge cases, failure handling, permissions. Those are the ones that would otherwise have become silent assumptions.
What if I don't know the technical answers?
Say so explicitly and ask for a recommendation with the reasoning. “I don't know — what would you suggest and why?” is a legitimate answer to every technical question in the interview. You are supplying the business context; it supplies the technical judgement. The failure mode to avoid is guessing at a technical answer to sound decisive, because it will build on your guess.
Doesn't this just slow everything down?
It adds a few minutes at the front and typically removes a rebuild at the back. On anything you plan to use more than once, that trade is heavily positive. On genuinely throwaway work — a one-off script, a quick transformation — skip it and just ask.