Build the Right Thing

Spec-First Prompting

For: Builders about to ask an AI for a new feature or app

Spec-first prompting: write the contract before you ask for code

You're about to ask the AI to build a feature. Write the one-page spec first — vague asks are why builds go sideways.

Copy & paste into your own LLM · open in archive →

You are a product-minded software architect helping a non-engineer specify a feature BEFORE any code is written. I will describe what I want in plain language. Produce:

A) SPEC — what the feature does in 5 sentences or fewer: the user, the trigger, the inputs, the outputs, and what 'done and working' means in observable terms I can check myself.

B) EDGE CASES + NON-GOALS — the inputs and situations the feature must handle (empty, wrong format, double-submit, slow network), and an explicit list of what this version will NOT do, so scope stays fixed.

C) DATA + STATE — what needs to be stored or remembered, where it lives, and what happens to existing data if this changes.

D) BUILD REQUEST — the spec rewritten as a single, precise instruction I can paste into my AI coding tool, with the acceptance checks listed at the end.

Inputs: [WHAT I WANT, IN PLAIN LANGUAGE] · [THE APP IT LIVES IN + TECH IF KNOWN] · [WHO USES IT] · [WHAT EXISTS TODAY]

Rules: Do not invent requirements, tech constraints, or existing behavior I didn't state — list every assumption as an open question for me to answer instead. Where 'done' can't be checked without running the app, say exactly what I should click and what I should see so I can verify it myself. Never include API keys, passwords, or customer data in the spec — reference them as named placeholders.

Why it works: Most AI-built features fail at the ask, not the code — a vague prompt gives the model room to guess. Writing observable 'done' checks and explicit non-goals before any code turns the model from a mind-reader into a contractor with a contract, and the assumptions-as-questions rule stops invented requirements from becoming silent scope.

Useful? 👍 Yes👎 No

Fix the Cause, Not the Symptom

The Debugging Loop

For: Builders whose app just broke — and whose instinct is to paste the error and beg

The debugging loop: reproduce, isolate, fix, verify — one step at a time

Something broke and your instinct is to paste the error and accept whatever rewrite comes back. Run the loop instead — one disciplined step at a time.

Why it works: Non-engineers get stuck in the 'paste error, accept rewrite, new error' spiral because the model jumps to fixes before the cause is isolated. Locking the conversation to one loop stage at a time — and refusing whole-file rewrites during isolation — converts flailing into a binary search, and the verify stage catches the fix that breaks the thing next door.

Useful? 👍 Yes👎 No

Trust, but Verify

Verification & Trust

For: Builders who can't fully read the code they're about to ship

Test before trust: the verification checklist you run before believing 'it works'

The AI says it's done and the happy path worked once. Build the checklist that earns your trust before real users touch it.

Why it works: The most dangerous sentence in AI-assisted building is 'Done — everything works.' Converting the model's own claims into physical checks with visible pass/fail evidence closes the gap between asserted and verified, and the must-pass split keeps a non-engineer from either shipping blind or drowning in QA theater.

Useful? 👍 Yes👎 No

Ship Small, Keep It Working

Refactor & Shipping

For: Builders turning a working prototype into something that survives the next change

Make it work, then make it right: the safe refactor pass

The feature finally works but the code is duct tape. Run a behavior-preserving cleanup — without letting the AI 'improve' it into a broken state.

Why it works: 'Make it right' is where working AI-built apps go to die, because cleanup invites the model to rewrite everything at once. Writing the freeze-list contract before touching anything, then moving one verifiable change at a time, gets you the maintainability without gambling the only thing you actually have — software that currently works.

Useful? 👍 Yes👎 No

Manage the Machine

Session & Context Management

For: Builders running long AI coding sessions that drift, loop, or forget

Session context brief: re-onboard your AI at the start of every session

Every new chat starts from amnesia. Build the project brief you paste at the top of each session so the AI stops reinventing your app.

Why it works: Context is the currency of AI coding sessions, and most builders spend the first twenty minutes of every chat re-teaching their own app — or worse, letting the model guess. A maintained one-page brief with a do-not list and an end-of-session handoff turns each new chat from a cold start into a shift change.

Useful? 👍 Yes👎 No

What you did NOT get today (Pro)

Prompt of the Week (Pro)

This week's bonus: a pre-launch security sweep prompt that walks a non-engineer through the leaked-key, open-endpoint, and unprotected-page checks an engineer would run before shipping — with a strict verify-each-finding rule so nothing gets 'fixed' on trust.

Which section is most useful to you this week?

One tap — it shapes which prompt leads next week.

What would you like to see more of?

Get all five sections — every day

Pro unlocks all 5 sections’ prompts each issue, plus the full searchable archive. $14.99/mo.