A guide for people who are not programmers
A few weeks ago I posted a short video about one phrase: "thin vertical slices". Say it to an AI coding tool and it stops building disconnected pieces and starts building one complete, working path from start to finish. That video got more response than anything I had made before, and the comments all asked the same question: what other phrases work like this?
So I went looking. The answer is 17, and this post covers all of them.
Why a few words change everything
AI models learned from millions of conversations between people who do their work well: engineers, analysts, writers, project leads. When you use the exact phrase an expert would use, you are not adding three words to your prompt. You are pulling in that expert's entire way of working.
That is why "make it professional" changes nothing. The model nods and does whatever it was going to do anyway. And it is why "show me the check that proves it is done" changes a lot. It gives the model a job it can actually perform.
The 17 keywords below are grouped by when you say them: before the AI starts, while it works, and after it finishes.
Before it starts
These shape the plan. Get these right and half the problems never appear.
1. Ask me clarifying questions first
Say: "Before doing anything, ask me the five questions that would most improve the result, and wait for my answers."
The model's default is to fill gaps with guesses. This drags the guesses into the open where you can correct them. Use it on any task that is still fuzzy in your own head.
2. Plan first, don't build yet
Say: "Give me a bullet-point plan. Do not start until I approve it."
Fixing a plan costs one sentence. Fixing finished work costs an hour.
3. Thinnest vertical slice
Say: "Build one narrow path end to end. Finish and show me slice one before starting slice two."
Integration problems show up on day one instead of at the end, and the thing you are building is always in a working state.
4. Working software first
Say: "Every pass must end with something I can open and click, even if it is rough."
Nothing teaches faster than a running build. This stops the model handing you design documents instead of a product.
5. Simplest thing that works
Say: "Only build what this slice needs. No abstractions for later. Duplicate code is fine until the third time."
Engineers call this YAGNI, "you aren't gonna need it". Models over-deliver by training, and this switches that off. The third-occurrence rule is useful because it is a number, not a vibe.
6. Mock data first
Say: "Use fake data and local state. Add a database or login only if this slice cannot work without it."
This prevents a two-screen idea from turning into cloud infrastructure and login flows.
7. Boring, batteries-included tooling
Say: "Use the most common, well-known stack. Don't get creative with libraries."
Models otherwise reach for novel tools, and beginners get stuck in setup instead of building.
8. Time-box it, cut scope not time
Say: "If this cannot be done in one session, tell me what to drop."
This gives the model permission to shrink the task instead of overreaching and failing halfway.
While it works
These control how the job gets done.
9. Verify it, show me proof
Say: "Don't tell me it's done. Show me the check that proves it. Run the tests. Quote the exact line."
Models stop when work looks done. A check they can run is the only way they know the difference. This is the single biggest gap between a demo and something you can trust.
10. Only change X, nothing else
Say: "Make the smallest possible change. Do not rewrite, reformat, or improve anything I didn't mention."
Models tidy up while they are in there. That is how a working feature breaks or a paragraph you liked disappears.
11. Consider three approaches first
Say: "Compare at least three approaches, flag where you are unsure, then pick one and tell me why."
This stops the model committing to its first idea. Skip it for simple tasks; use it for hard ones.
12. If you don't know, say unknown
Say: "If you are not certain, write 'unknown' instead of filling it in. Never invent a source."
An empty field feels wrong to a model, so it fills it. You have to give explicit permission to leave a blank. Essential for anything you will repeat to other people.
13. Flag anything expensive to reverse
Say: "Mark any decision that would be hard to undo later."
Surfaces data structures, logins, and public interfaces before they get locked in.
14. Mark your shortcuts
Say: "Wherever you take a shortcut, leave a note saying so."
Shortcuts are fine. Hidden shortcuts are not. Later you can find and fix them in one search.
After it finishes
These are your quality control.
15. Be blunt, find every way this could fail
Say: "Don't improve this. Find every weakness, rank the top ten by severity, and do not soften anything."
Models are agreeable by default. "Do not soften" is the switch from cheerleader to critic. Almost nobody uses this, and it is the one I would pick if you only try one.
16. Tests only for what already broke
Say: "Don't write a test suite. Add a test only for something that has failed once or that I mark as critical."
Counter-intuitive, but heavy testing kills speed before the idea is proven.
17. Definition of done
Say: "Here is what done looks like:" followed by three to five concrete, checkable conditions.
Never "professional", never "production ready", never "high quality". Vague adjectives mean nothing to a model. Concrete conditions become its checklist, which closes the loop with keyword 9.
The pattern behind all 17
Every keyword does one of three jobs
- Narrow it (3, 5, 6, 7, 8, 10): shrink the scope so the model cannot wander.
- Question it (1, 2, 11, 12, 13, 14): surface hidden assumptions before they cost you.
- Check it (4, 9, 15, 16, 17): add a step that proves the work instead of trusting it.
If you remember nothing else: narrow it, question it, check it.
One prompt to copy today
Paste this as your opening message on any real task:
Ask me clarifying questions first. Then give me a plan and wait. Build the thinnest slice end to end, runnable, with mock data. Verify it and show me proof. Don't touch anything I didn't mention. If you're unsure, say unknown.
After 23 years in enterprise IT, I can tell you none of these ideas are new. They are how good engineers, analysts, and project leads have always worked. What is new is that saying them out loud to an AI now gets you that quality of work, whether you are building an app, writing a proposal, or reviewing a plan.
The full video walks through all 17 with examples: watch it on YouTube.
Which number are you trying first? Tell me in the comments on the video.