Seven Words That Change What the AI Gives You
The whole pitch for vibe coding fits in one sentence: you describe what you want in plain English, and the machine writes the code. That sentence is true. It's also the most expensive true thing in this field, because it quietly implies that plain English is enough, and plain English is not the same as a clear description.
I found this out the way I find out most things.
Trial, and then error
Two methods have worked for me my whole life. The first is trial. The second is error, and it's the one that does the teaching.
I can tell you how to make fire by rubbing two sticks together. You'll nod along, and you'll understand every word. Then you'll go outside and fail for two hours, because nobody mentioned how hard to press, or that the wood has to be bone dry, or that some wood won't light no matter how long you work at it. Those little things are the whole skill, and they don't survive being explained. You have to do it.
The error half matters more than people like to admit. I run, and the runs I remember in any detail are the ones I got wrong. Went out too fast. Wore the wrong thing. Ignored a twinge that cost me three weeks. The good runs blur into one pleasant smear. They were lovely. They taught me nothing.
So when I started playing with AI and realized it could write better code than I ever would, I did what I always do: started badly, on purpose, and paid attention to what went wrong.
What went wrong most often wasn't the code. It was that I'd asked for the wrong thing, in words too loose to mean anything, and gotten back exactly what I asked for.
The hard lesson was vocabulary
Around the same time I was watching a lot of "build an app in a weekend, no experience needed" videos. They're not lying, exactly. You can get an app in a weekend. What goes unsaid is what you're holding on Sunday night: something that runs on your machine, does roughly what you asked, and breaks the first time a stranger touches it in a way you can't diagnose.
The gap between those videos and my actual experience turned out to be words. Not syntax. Not knowing how to write a loop. Vocabulary: the ordinary technical phrases a working developer uses without thinking, each of which means one specific thing and rules out a hundred others.
Precision in the question is what produces precision in the answer. Ask "make this better" and the model has to guess what better means, and it will guess in the direction that's easiest to demonstrate. Ask "make this idempotent" and there's exactly one thing it can do, and you can check whether it did it.
That's the whole series. Asking the right question is what gets you good answers, and you can't ask the right question with the wrong words.
A note on the order
I've grouped these by when you'll usually run into them. This batch is the stuff that bites on day one, before you've generated a single line. But that's a rough sequence, not a rule. If you're already six months into a project, some of these will be old news and something from a later batch will be the thing you needed last Tuesday. Vocabulary isn't a curriculum with prerequisites. Take what's useful, skip what isn't, come back when something breaks.
The seven words
1. Spec
Classic meaning: the written description of what the software is supposed to do.
What changed: it went from paperwork to the highest-leverage thing you own. When you wrote the code yourself, a fuzzy spec got sharpened as you typed, because you couldn't write a vague line of code, so the vagueness had to resolve somewhere. That's gone. A vague spec now produces vague code, confidently, in seconds. You control the what precisely because you no longer control the how.
The prompt it turns into:
Before you write anything: restate what I'm asking for as a short spec. What are the inputs, what are the outputs, and what did I leave undefined? List the assumptions you'd have to make.
The assumptions list is the useful part. That's your spec's holes, found for free.
2. Acceptance criteria
Classic meaning: the testable conditions that define "done."
What changed: if you don't define done, the model defines it for you, and it picks a definition its code satisfies. Not out of malice. It just has to pick something, and the something it picks is the one already in front of it. "Working" becomes "it ran without an error message," which is a much lower bar than the one in your head.
The prompt:
Here's what I want. Write three acceptance criteria I could check by hand, in plain English, before you write any code. Include at least one about what should happen when something goes wrong.
3. Scope creep
Classic meaning: a project quietly growing past what was agreed, a feature at a time, over weeks.
What changed: the timescale collapsed. It now happens inside a single response. You ask for a login fix and get a login fix, a refactored auth module, a new settings screen, and three files you didn't know existed. Every one of those is code you now own and can't explain, and the more of it there is, the less likely you are to read any of it properly.
The prompt:
Change only what's needed for this one thing. List any other improvements you noticed but don't make them. I'll decide separately.
You get the suggestions and keep the diff small. That's the trade you want.
4. One-shot vs. iterative prompting
Classic meaning: none. This one is genuinely new.
What it means: asking for the entire feature in one go, versus building it in steps you can actually check. One-shot is seductive because it works often enough to feel free. The problem is what comes back: four hundred lines you didn't watch get written, which is four hundred lines you will not review honestly. You'll skim it, it'll look reasonable, and you'll merge it.
Iterative is slower per step and much faster overall, because the bug that shows up in step three is findable in step three's twenty lines.
The prompt:
Don't build the whole thing yet. Break this into the smallest steps that each produce something I can run, list them, and stop. I'll tell you which one to do first.
5. Context window
Classic meaning: none. This one is AI-native.
What it means: everything the model can see right now. Anthropic's documentation defines it as "all the text a language model can reference when generating a response," and describes it as a "working memory" for the model. It's finite, and this is the plain mechanical reason the AI "forgets" the architecture you agreed on ninety minutes ago. Those decisions fell out the back.
It also degrades before it runs out, which is worse than a hard limit because there's no error. The same documentation notes that as the token count grows, "accuracy and recall degrade, a phenomenon known as context rot."
What to do about it: start fresh sessions more often than feels necessary, and re-state the important constraints when you do. If a session has gone sideways and you can't work out why, the answer is often that it went sideways forty messages ago and everything since has been built on it.
6. Hallucination
Classic meaning: none.
What it means: the model confidently producing something that doesn't exist: an API method, a config option, a library version, a function argument. It isn't lying. It's completing a pattern, and the completion looks exactly like the real thing because that's what pattern-completion is for.
The tell is that fabrications are plausible. A made-up method name will be named the way that method would sensibly be named. Nothing in the tone marks the boundary between what the model knows and what it's filling in.
The prompt: Anthropic's own guidance is blunter than you'd expect: give the model explicit permission to admit uncertainty, which it says "can drastically reduce false information." So:
If you're not certain a method, option, or library exists, say so instead of guessing. I'd rather have "I'm not sure" than a plausible answer I have to discover is wrong.
7. Sycophancy
Classic meaning: flattery. Telling people what they want to hear.
What it means here: the model agreeing with your bad idea because you sounded confident about it. This is documented behavior, not a folk theory. Anthropic's research on the subject found that the training process "may also encourage model responses that match user beliefs over truthful responses."
Which means the shape of your question partly determines the answer. "Is this a good approach?" is a leading question. So is "this looks right, yeah?" You will get agreement, and agreement isn't information.
The prompt:
Don't tell me if this is good. Tell me the three most likely ways it fails, and what you'd have done differently.
Same code, same model, same minute. Completely different answer, because the second question can be answered wrongly and the first one can't.
What to actually do with this
You don't need to memorize seven definitions. Pick the one that describes a frustration you've had this month and use its prompt tomorrow. My guess, if you're early: it's scope creep or sycophancy, because those two are the ones that feel like the AI is doing something helpful right up until you look closely.
Comments
Post a Comment