Designing It Before You Build It

Ten minutes of design saves hours of rebuilding. The temptation is to open the tool and start connecting things; resist it until you can draw the whole thing on one line.

---

1. The three layers

Every system you have built in this course is the same three layers.

INPUT  ->  JUDGEMENT  ->  OUTPUT
where work    what AI      where it
arrives       decides      lands

Write yours as one line before anything else:

New form response -> AI classifies urgency -> if urgent, notify me;
otherwise add a row to the sheet

If you cannot write that line, you are not ready to build. Not because the tool is hard, but because you have not yet decided what the thing does.

---

2. Specify the input precisely

This is where most designs are too vague, and vagueness here is what causes the runaway costs.

Too vague	Precise enough
"an email"	an email to support@, from outside our domain, not an auto-reply
"a form"	a submission to the intake form where "type" is not blank
"every hour"	07:00 on weekdays, only if there are new items since last run
"a new row"	a new row where Website is filled and Status is empty

Write your filter conditions out. Every condition you add removes a class of run you would otherwise have paid for.

TRIGGER: 
FILTER:  
         AND 
         AND 

---

3. Design the judgement step

Two questions, and they matter more than which model you pick.

What exactly is it deciding? One job per AI step. "Classify and draft and summarise" is three steps, and combining them makes all three worse and none of them debuggable.

What does the output look like? Constrain it. The next step has to parse this.

Classify this into exactly one of: [A] | [B] | [C] | other
Respond with only the single word, lowercase, no punctuation.
If genuinely unclear, respond: other

Temperature: 0–0.2 for anything a later step depends on. 0.5–0.7 only for the final human-facing generation.

Chain rather than combine

If you need several things done, chain them. Each step does one job and passes its output to the next.

Step 1: Extract the customer's question as a single sentence.
Step 2: [output of 1] Classify it: billing | technical | sales | other.
Step 3: [output of 1 + 2] Draft a reply using the relevant policy.

Slower to run, substantially better output, and when something goes wrong you can see which step did it.

---

4. Decide where the human goes

Not everywhere — that defeats the purpose. Where the risk is.

If the AI is wrong, the damage is	Human position
Nothing, it is a suggestion	Not required
An internal record is wrong	After output, with a log to correct from
Someone outside sees it	Before output. Always.
Money moves, or a person is affected	Before output, plus a second check

The test: if this runs wrong 100 times before anyone notices, what is the damage?

For a capstone, the answer should almost always put a human before the output. Draft-first is the default for a reason.

---

5. Decide what happens when it fails

Every step can fail. Design for it now, not after it does.

If the AI step returns nothing        -> 
If the AI step returns malformed output -> 
If an external service is down        -> 
If the input is missing a field       -> 
If the whole workflow errors          -> 

Every one of those blanks should end with "and a human is told". Silent failure is the worst property an automation can have, and it is the default unless you design against it.

---

6. The design document

Fill this in completely before opening a tool.

PROJECT: [NAME]

ONE LINE:
[trigger] -> [judgement] -> [output]

TRIGGER:
FILTER:

STEPS:
1. [step]  ->  [what comes out]
2. [step]  ->  [what comes out]
3. [step]  ->  [what comes out]

AI STEPS:
| Step | Decides what | Model tier | Temp | Output format |
|---|---|---|---|---|
|  |  |  |  |  |

HUMAN REVIEW:
Who:
What they check:
Before or after output:

FAILURE PATHS:
| Failure | What happens |
|---|---|
|  |  |

COST:
Per run:            Runs/month:            Monthly:
At 5x volume:

HOW I STOP IT:

That last line is not a joke. Know how to turn it off before you turn it on.

---

7. Sanity-check the design

Before building, walk through three scenarios on paper:

The normal case. Follow the data through every step. Does the output make sense?

The empty case. A blank field, a missing attachment, an empty response. What happens at each step?

The wrong case. The AI misclassifies. Where does that item end up, and does anyone find out?

If the third scenario ends with "it disappears", add a fallback route before you build anything.

---

⚠️ Common Mistakes

• Opening the tool first. Ten minutes of design saves hours of rebuilding.
• A vague trigger. "New email" instead of a filtered condition. The single most expensive design error.
• One AI step doing three jobs. Chain them; each step does one thing.
• No defined output format. The next step cannot parse prose.
• Forgetting the failure paths. They are not edge cases; they are Tuesday.
• Putting the human everywhere. Then you have automated nothing. Put them where the risk is.
• Not calculating the cost before building. Volume surprises are much less pleasant after launch.

---

What's Next: The design is on paper. Time to build it — one step at a time, testing as you go.