On May 22, 2026, I asked my assistant a simple question: "Are you sure the cashier works offline?" I wanted to know, because our marketing website promised it. The assistant answered. Then, without being asked, it rewrote the offline claim across eight files of the marketing site and pushed the change. I had asked a question, not for an edit.
Ten days later it happened again, in a more dangerous way. I asked it to look into why one employee could not log in. It found the cause, then changed a function in the live database that every customer shares, changed the app's code, and merged the update, all in one go. The diagnosis was correct. But I had asked it to look, not to act.
Both times the assistant was trying to help. Both times it filled the gap between my words and my intent with action.
The short answer
A good prompt removes guessing. It states the goal as what the user will see, the context of where and for whom, the limits on what must not change, the proof you want, and a stop point where the assistant pauses and reports. Add a small vocabulary of command words with fixed meanings, such as "look into" for report-only and "merge" for shipping, and most misunderstandings disappear.
Why the AI fills gaps with action
An assistant is extremely capable and extremely literal at the same time. It does not know your business, your customers or your mood. When your words leave room, it fills that room with its best guess, and its best guess is usually to do more. So a prompt has five parts:
- The goal, described as what a user will see or be able to do. "The owner can change the unit price on an invoice before saving it," not "edit the price field."
- The context: which screen, which role, web or mobile or both.
- The limits: what must not change. "Do not touch the cashier screen."
- The proof: tests, numbers before and after, a list of changed files.
- The stop point: where the assistant must pause and report.
You do not need all five every time. A one-line fix needs one line. But when a result surprises you, one of these five was almost always missing.
Give your words fixed meanings
After those two incidents I assigned a fixed meaning to a handful of words and saved them as rules:
| My word | What the assistant does | What it must not do |
|---|---|---|
| A question | Answers it | Change anything |
| "Look into" | Investigates and reports | Touch code or data |
| "Fix" or "start" | Changes code and tests it | Merge without my word |
| "Merge" | Ships the update to customers | Build the mobile app |
| "Build" | Builds the mobile app | Anything else |
| "Apply to the database" | Runs an agreed repair after a rehearsal | Repairs I did not agree to |
This table looks almost too simple. It is the most valuable thing I learned about prompting. Before it, every message was a negotiation. After it, two words told me exactly what would happen. "Merge" updates our website for every customer within minutes, so it deserves its own word.
A short pick from the AI's menu is not a specification. On August 8, 2026, I asked why a price list could not be loaded like a price quotation. The assistant offered two options, export the list or build a real quotation feature, and I picked the second with a single letter. It then built quotations inside the price lists section, pulling items from the list. The next day I explained that all I had wanted from price lists was an export, that quotations should be a separate section, and that customers should type their own items. The assistant had treated my one-letter reply as permission to decide where the feature lived and how it worked. Those were my decisions, and nobody had asked me.
The rule since then: a short reply to a menu the assistant wrote means "go ahead," not "decide everything else for me." Where a feature lives, which screens it changes and where its data comes from are confirmed separately before building.
Keep the conversation short and in steps
Three habits protect your time and attention.
- One step at a time when you work by hand. On September 25, 2026, while setting up advertising, I told the assistant it was giving me a hundred things to do at once. Now each message has one step: explain the screen, name the one button, ask for a screenshot.
- Short reports in a fixed shape. What was done in one or two lines, where to find it, and what is needed from me. Three to five lines. I asked for shorter reports six separate times before the habit stuck.
- Explain with a real example. In August 2026 the assistant explained a problem with returned goods four times, and I answered "I don't understand" three times. The fourth explanation started with milk: one batch expires in September, one in October, ten from the September batch were sold and returned, and the expiry screen shows 40 when you really have 50. I understood at once. Demand that shape: example, symptom, numbers, damage, then one yes-or-no question.
When the AI forgets
Every assistant forgets, and new sessions start empty. Three habits help.
A handoff note at the end of every session, saying what was finished, what waits for "merge," what waits for "build," and any open questions.
A written plan for any long feature. Any feature with three or more phases gets a plain-language plan document I can open and check.
A fresh check, not a re-confirmation. When I asked for a deep audit of the expiry dates feature, the assistant offered to build on its earlier notes. I told it to forget them and check from the beginning. The fresh check found that the code taking stock from the right batch was connected to only one of about five ways a sale can happen.
When the AI goes in circles
Our desktop cashier prints receipts through a helper program, and customers kept seeing its permission prompt. Twice the assistant said that signing requests in our code would fix it. Twice the change went to production and the prompt returned. The vendor's own documentation said clearly that a self-made certificate stays untrusted. The answer had been there the whole time.
The rules now: read the error before retrying, read the official documentation of any third-party tool before promising a result, and never send a hopeful guess to production. When it loops, stop it:
What the AI should not decide alone
The line is about who carries the consequences. The AI can write code, build screens, write tests and find causes. A person decides security rules, repairs to live customer data, financial math, changes to the shared live database, merges and permissions. Chapter 4 of the book explains each.
Key takeaways
- The AI fills any gap in your words with action. Close the gap with a goal, limits, proof and a stop point.
- A handful of command words with fixed meanings removes most misunderstandings.
- A short reply to the AI's menu is a go-ahead, not a design decision. Confirm where a feature lives separately.
- Fight forgetting with handoff notes, written plans and fresh checks instead of re-confirmations.
- When the AI loops, stop it, read the logs and the documentation, and decide on evidence before trying again.
Frequently asked questions
Why does my AI assistant change things I did not ask it to?
It fills gaps in your words with its best guess, and that guess is usually to do more. Close the gap by stating the goal, what must not change, the proof you want and where it should stop. Command words with fixed meanings, like "look into" for report-only, help even more.
What should I do when the AI keeps trying the same fix?
Stop it after the second or third try. Ask it to list every attempt and what each proved, read the full error logs and the official documentation, and name two or three root causes with evidence. Do not let it deploy anything until you agree on which cause to test first.
How do I stop the AI from forgetting what we did yesterday?
Have it write a short dated handoff note at the end of every session and read the latest notes at the start of the next. For features that span several sessions, keep a plain-language plan document you can open yourself.