The Vibe Father
Playbook
Most "prompt engineering" advice was written for chatbots, and it quietly poisons the way people talk to coding agents. A chatbot answers a question and stops. An agent reads files, edits them, runs commands, and keeps going until it decides it's done — or until your vague instruction lets it wander off and do something you never asked for. The tricks that make a chatbot chatty ("act as a senior engineer," "think step by step") do almost nothing here. What works is unglamorous and mechanical: give the agent a task it can complete without guessing.
We run agents daily, and the single highest-leverage change we ever made wasn't a clever phrasing. It was writing tasks the way you'd write a work order for a contractor you can't call back mid-job. Here's the whole method.
The core idea: decision-complete tasks
An agent fails in exactly one way — it hits a decision you didn't make for it, and makes it wrong. Should it add that dependency? Refactor the neighboring function? Touch the config? If your task leaves those open, the agent decides, and agents expand into ambiguity like gas into a vacuum. A decision-complete task pre-answers every decision the agent might face, so there's nothing left to guess.
Five parts make a task decision-complete:
- Goal — what "done" looks like, in one plain paragraph. Not "improve the login" but "users who enter a wrong password see an inline error and stay on the page."
- Files in scope — the explicit list the agent may touch. Naming files does two jobs: it saves the agent a search, and it fences it out of everything else.
- Constraints — patterns to follow, libraries not to add, code not to touch. This is where you encode the taste the agent doesn't have.
- Definition of done — the exact command that proves it.
npm test -- auth, not "make sure it works." A command exits zero or it doesn't; opinions don't. - Out of scope — named explicitly. The things you're deliberately not doing now. Unstated, they get done anyway, badly.
Scope fences: the highest-leverage sentence
The most useful line in any agent task is the one that says what not to touch. "Only edit src/auth/login.ts; do not modify any other file, do not add dependencies, do not reformat existing code" prevents the classic disaster where a small fix becomes a 40-file diff you can't review. Scope fences are cheap to write and save you from the single most common agent failure: the change that quietly grew. If you write one extra sentence per task, make it a fence.
Ask for a plan first on anything big
For a one-file change, just say go. For anything touching multiple files or you're not sure of the shape, add one instruction: "Show me your plan before writing any code. List the files you'll change and what each change does. Wait for my approval." This is the cheapest bug-prevention there is. A wrong plan costs one message to correct; a wrong implementation costs a broken branch and an hour of untangling. You catch the misunderstanding while it's still just words, and you catch it before it's touched a single file.
The plan also surfaces the agent's hidden assumptions. When it says "I'll add a new table," you learn it didn't see the table that already exists — and you fix that in the plan, not in a debugging session.
One task per message
Batching feels efficient and isn't. When you ask for five things in one message and something breaks, you can't tell which of the five did it, and neither can the agent. Worse, agents interleave the five and produce a tangle where each change assumes the others. Ship one task, watch it land, verify it, then send the next. The rhythm feels slow and it's the fastest path to a working result, because every step is small enough to see and reverse. If you find yourself writing "also" in a task, that's a second task — send it separately.
The copy-paste task template
Here's the template we actually use. Fill in the blanks, delete nothing, and you've written a decision-complete task in under two minutes.
GOAL
<one paragraph: what "done" looks like, in behavior a user could see>
FILES IN SCOPE
- path/to/file-you-may-edit
- path/to/other-file-you-may-edit
(Do not modify any file not on this list.)
CONSTRAINTS
- Follow the existing pattern in <a nearby file to imitate>
- Do not add new dependencies
- Do not reformat or refactor code you weren't asked to change
DEFINITION OF DONE
- <exact command that must pass, e.g. npm test -- auth>
- Paste the real output of that command when you're finished
OUT OF SCOPE
- <things you are deliberately NOT doing this round>
PLAN FIRST
If this touches more than one file, show your plan and wait for
approval before writing any code.It looks like a lot to fill in. It isn't — most of it is two or three words per line, and the two minutes you spend saves the twenty you'd spend correcting a confident, wrong diff.
Two more habits that punch above their weight
- Make the agent quote evidence, not claims. End every task with "paste the actual command output." "This should work now" is not evidence; a green test run is. Agents are trained to sound finished — force them to prove it, and half your verification is done for you.
- Reference real anchors, not vibes. "Match the style of
src/api/users.ts" beats "make it clean." Point at a concrete example in your own repo and the agent imitates something real instead of inventing its idea of good.
What this has to do with context
Here's the honest limit of prompt engineering: no phrasing rescues an agent that can't see the right files. The best task in the world fails if the agent is guessing about a table it never read or a convention it never saw. Wording gets you a decision-complete request; what the agent actually knows when it reads that request is a separate, bigger skill. That's context engineering, and it's where the real gains live — the prompt is the smaller half.
Put together, the method is almost boringly simple: one task at a time, every decision pre-made, a fence around what it may touch, a plan first when it's big, and a command that proves it's done. Do that and agents stop feeling unpredictable — because you stopped leaving them anything to be unpredictable about. When you're ready to coordinate several of them at once, our multi-agent field guide extends the same discipline across a team.
