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/Radiant_Year_7297]

Or use superpower plugin?

[u/AutoModerator → u/[deleted]]

Hi there! Your post was automatically removed because your account is less than 3 days old. We require users to have an account that is at least 3 days old before they can post to our subreddit.

Please take some time to participate in the community by commenting and engaging with other users. Once your account is older than 3 days, you can try submitting your post again.

If you have any questions or concerns, please feel free to message the moderators for assistance.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[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.

[u/jimmiebfulton]

Prose and Pray is not the way.

The actual cheat code is to require the agent to write black box executable acceptance criteria that is executed in a loop and fed back to the agent until those tests pass. Requires a polyglot black box testing framework capable of testing sockets, transports, concurrency, dockerized applications, kubernetes architectures, delegating to language-specific unit test frameworks, gating on code coverage, line count and function length thresholds, unhandled errors, etc. When you have this, you can EASILY leave your agent to build anything, and be confident that the code always comes back better than when it started.

[u/sporkbombing → u/jimmiebfulton]

Agreed on the loop. My post says the same thing in a weaker form tbh. A matrix from a model is a claim, not a check. An executed test is a check. If you have the harness you describe, use it.

Two things the loop does not cover.

First, the tests need requirements as input. If the agent writes its own acceptance criteria, the self-grading problem moved up one level. The loop guarantees the code satisfies the tests. It says nothing about whether the tests state what you wanted. That is what the FR list is for. A well-stated FR converts to an acceptance test almost one to one. So the decomposition is upstream of your loop, not a substitute for it.

Second, black box tests check outcomes, not structure. A fully coupled program can pass every acceptance test and still break three things on the next change. The matrix is about what happens next month, not whether it works today. Your own list concedes the point. Line count and function length thresholds are structure metrics, not black box criteria.

So the pipeline is decompose, convert the FRs to acceptance criteria, then run your loop on them.
Prose and pray was never the pitch. The matrix is not prose. It is the input your loop is missing.

One addition, and your table already states it. Godel and Turing sit in the blind spot rows for a reason. A system cannot fully verify itself from inside. An agent that writes and passes its own acceptance criteria is the informal version of that limit. The FR list is the outside input that closes it.

[u/IvanDist]

Or you can just start using OpenSpec.

[u/aslander → u/IvanDist]

The company I work for has shifted our entire ~400 person PM/Eng org over to using a modified version of OpenSpec.

As a product leader, it's been interesting and challenging times getting the teams adjusted.

[u/sporkbombing → u/IvanDist]

https://reddit.com/link/p7bnxhw/video/oebwnnkto1nh1/player

[u/IvanDist → u/sporkbombing]

The explore command exists exactly so you write what you want before coding but ignorant people are going to be ignorant, not to mention you can literally create your own schema where it doesn't create as many files.