Build the Right Thing

Spec-First Prompting

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

Architecture options: three ways to build it, priced in plain English

Before you accept the first approach the AI suggests, make it lay out the real options and what each costs you later.

Copy & paste into your own LLM

You are a pragmatic software architect advising someone who builds with AI and doesn't write code by hand. I will describe the feature or app. Produce: A) OPTIONS TABLE — 2-3 genuinely different ways to build this. For each: how it works in one plain-English sentence, rough build effort (hours / days / weeks), what it roughly costs monthly to run, and the failure it's most prone to. B) LOCK-IN + REVERSIBILITY — for each option, what I'm committing to (a data shape, a service, a pattern) and how painful it is to change my mind in 3 months. C) RECOMMENDATION — which option fits my stated constraints and why, in 3 sentences, plus the ONE question whose answer would flip the recommendation. D) DECISION RECORD — a 5-line note I can save: what we chose, what we rejected, and why — so future sessions don't re-litigate it. Inputs: [WHAT I'M BUILDING] · [MY CONSTRAINTS: BUDGET / TIMELINE / SKILL LEVEL] · [EXPECTED USERS OR SCALE] · [WHAT'S ALREADY BUILT] Rules: Do not invent prices, service limits, or performance numbers — label every figure an estimate and tell me to verify current pricing and limits on the provider's own page before committing. Options must be real alternatives someone would defend, not strawmen around your favorite. Keep my proprietary product details out of the summary beyond what I pasted.

Why it works: The first architecture an AI proposes is a default, not a decision. Forcing real alternatives with reversibility and plain-English run costs surfaces the tradeoff you're actually making, and the saved decision record keeps the next session from quietly rebuilding on a different foundation.

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

Error-message triage: what it says, what it means, what to check first

A wall of red text you can't read. Get a plain-English translation, the likeliest causes, and the smallest thing to check first.

Why it works: An error message is evidence, not an insult — but only if someone translates it. Ranked causes with a one-line check each turn panic into a checklist, the what-not-to-do section blocks the silence-the-error reflex that turns one bug into three, and the rotate-exposed-credentials rule catches a real security miss builders make constantly.

Useful? 👍 Yes👎 No

Trust, but Verify

Verification & Trust

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

Diff self-review: make the AI explain its own change before you accept it

The AI changed five files and you're about to click accept. Make it review its own diff like a skeptical outsider first.

Why it works: Accepting multi-file AI changes on faith is how working apps quietly rot. Forcing a plain-English changelog against stated intent surfaces the unrequested 'improvements' that cause mystery breakage, and the run-it-yourself verdict keeps the human as the actual approver rather than a rubber stamp.

Useful? 👍 Yes👎 No

Ship Small, Keep It Working

Refactor & Shipping

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

Incremental feature slicing: turn the big ask into small, verifiable builds

You want something big and the temptation is one giant prompt. Slice it into steps where each one runs, gets verified, and can't take down the last.

Why it works: Giant prompts produce giant, unverifiable changes — and when they fail, they fail everywhere at once. Slicing to always-working checkpoints with a save point between steps means each AI session risks only one step's work, and the cut line converts 'it's 80% done' from a feeling into a shippable line.

Useful? 👍 Yes👎 No

Manage the Machine

Session & Context Management

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

Restart or push through: the call to make when a session goes in circles

Forty minutes in, the AI is patching its own patches. Decide — with evidence — whether to push through, restart the session, or roll back the code.

Why it works: The restart decision is the highest-leverage judgment call in AI-assisted coding, and sunk-cost pressure makes builders reliably choose wrong. Named circling signals turn a feeling into evidence, and forcing every 'push through' to carry a hard attempt limit means even the wrong call fails fast instead of eating the afternoon.

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 gets 5 desk-ready coding prompts every day. $14.99/mo.