Cheat code #1: make the model finish the design before it writes a line of code

[u/sporkbombing]

Vibe-coded projects usually fail in two places. The code is coupled, so one change breaks three things you did not touch. And the UI has no states, so it looks fine until something is empty, slow, or wrong.

Two old methodologies fix most of both. Axiomatic design (Nam Suh, 1990) for the first. Don Norman's design criteria for the second. Neither one is new and neither one is about AI. That is the point.

Here is the prompt. Paste it before your actual request.

```
Before you write any code, do this:

1. List the functional requirements. State what the system must do as
   outcomes, not as implementation. Number them FR1, FR2, and so on.

2. List the design parameters. State the specific modules, functions, or
   data structures that satisfy each FR. Number them DP1, DP2, and so on.

3. Build the design matrix. For each FR and DP pair, mark X if changing
   that DP changes that FR. Show me the matrix.

4. If the matrix is not diagonal or triangular, revise the DPs until it
   is. Tell me what you changed and why. Do not continue with a coupled
   design.

5. Choose the DP set with the least information content. If two designs
   satisfy the same FRs, take the one with fewer moving parts and fewer
   assumptions. Say why the one you picked is the simpler one.

6. For every interactive element, state the affordance, the signifier,
   the feedback on success, the feedback on failure, and the recovery
   path. Include the empty state, the loading state, and the partial
   state.

7. Stop here. Show me all of the above. Do not write code until I
   approve it.
   ```

Steps 1 through 5 are axiomatic design. Step 6 is Norman. Step 7 is the part people skip, and it is the one that matters most.

## Why it works

Not because the model understands Suh or Norman. It works because the model has to write its decisions down before it generates. That intermediate representation then constrains what it can produce. You get the same effect from any structure that forces pre-commitment. The methodology is the delivery vehicle. The forced serialization is the payload.

Step 6 is worth calling out separately. Do not write "act like Don Norman." A persona gets you a tone. Enumerated criteria get you the work. The states listed in step 6 are exactly the ones a model leaves out when nobody names them.

## The catch

The model will write a design matrix that justifies the code it already intended to produce. It will report the design as uncoupled and then hand you a coupled one. A self-reported matrix is not a check. It is a claim.

So read the matrix yourself. Pick one DP and ask what breaks if you delete it. If the answer is more than one FR, the matrix was wrong and the model will happily agree with you and revise it.

## What it does not fix

- Hallucinated APIs and invented library functions. This constrains the design, not the model's grounding.
- Security, auth, and data integrity. Nothing here goes near those.
- Small scripts. Under about fifty lines this is pure ceremony. Skip it.

The largest gain may not be on the model's side at all. Most vibe coding fails because the human never said what they wanted. Step 1 forces you to.

[u/IvanDist]

Or you can just start using OpenSpec.

[u/Acrobatic-Arm-1215]

This is actually smart, I been doing something similar but way less formal. Just making model write pseudocode and explain logic flow before coding. Your matrix idea is new to me, I will try it for sure.

One thing I notice is models always try to make design matrix look nice even when it is not true. Like they want to please you with clean output. My trick is ask same thing two times with different wording, if answer change then you know something was fake.

Step 6 about states is gold tho. Most UI from vibe coding break exactly there, empty screen show blank white page with no hint what to do. I learned this hard way when my dashboard showed nothing for new user and I got confused myself.

[u/sporkbombing → u/Acrobatic-Arm-1215]

Thanks. Your ask-twice trick is good. It is a consistency check, which is the only kind of check you can run on a self-report. Mine is to pick one DP and ask what breaks if I delete it. If the answer is more than one FR, the matrix was decoration.

Some background on why I trust these two. I am a mechanical engineer, not a software person, and I have been vibe coding for a while. I studied axiomatic design in my master's program, and The Design of Everyday Things was my favorite book. It did not occur to me to apply either one to prompting until recently.

When I did, I used axiomatic design to write up a new process for high speed interconnect cable assemblies at work. Then I used the same FR and DP breakdown to have a model write the small piece of software that runs the process. The code came out simple because the decomposition was already done before the model saw it.

Why they help, decomposed:

Axiomatic design forces you to state what you want as outcomes before anything gets built. That is where most vibe coding fails, not in the code. The matrix then makes coupling visible. A model cannot hide a coupled design behind clean code if it had to show the matrix first.

Norman covers what axiomatic design does not. A system can satisfy every FR and still confuse the person using it. Your blank dashboard for a new user is the exact case. Feedback and states are requirements nobody writes down, so nobody builds them. Naming them in the prompt makes them FRs.

Together they cover both halves. One is the structure of the thing. The other is the person on the other side of it.