Hey everyone. Picture a Friday pizza rush where someone yells “make food” into the kitchen. No ticket. No size. No toppings. No allergy note. The line still moves. The pies that come out are… creative. Review becomes an argument about what “food” meant.
That is what a lot of coding-agent prompts still look like in 2026.
We have agents that can read a repo, open a branch, edit files, run commands, and open a pull request. Raw generation speed is not the bottleneck anymore. Ambiguous intent is. If you treat the prompt like a chat wish, you get a lottery ticket. If you treat it like a change specification, you get something closer to a junior engineer who actually read the ticket.
Hi, I’m Robert Massey, software engineer and computer science professor with twenty-plus years in the trenches. AI is a tool and an assistant. Programming or coding is still a skill. Software engineering is still engineering solutions with software. You still own architecture, risk, and the merge button.
Stop prompting for code. Prompt for a change.
When I write a ticket for a human, I do not say “fix login.” I say what broke, where it lives, what must stay untouched, and how we will know it is fixed. Agents need that same brief. Maybe more so, because they will confidently invent the missing pieces.
Think of the prompt as the smallest RFC that can ship. Four questions almost always pay for themselves:
- What observable behavior should change?
- Where in this repo should the agent look first?
- What is out of bounds?
- How will we prove it worked?
Call those Task, Context, Scope, and Acceptance if you want a label.
What good looks like (and what does not)
Weak: “Improve the patient search.”
Better: “On the patient search page, add an Active / Inactive filter. Active is the default. The filter must work with the existing name search. Do not change the API. Mirror patterns in the current search component and its data hook. Afterward, run the project’s real test or lint command from the repo config.”
A few rules of thumb I give:
- If you cannot observe it, you cannot accept it.
- If the agent can expand the blast radius, it will unless you fence it or shield it.
- Standing house rules belong in durable project docs (
AGENTS.md,CLAUDE.md, RULES.md or your stack’s equivalent): package manager, “do not edit generated files,” how to discover validation. Keep the prompt about this change you need to make.
Features, bugs, and refactors are different conversations
Same four questions. Different emphasis.
Feature work: name the new behavior and the default path. What does the user see before and after? Create observabilities with a dashboard to observe the input, processing, and outputs.
Bug fixing: lead with evidence. What the user sees, steps to reproduce, expected vs actual, logs or error text. Ask for the most likely root cause from that evidence. In the root cause analysis if the cause cannot be confirmed, say what is missing. Apply the smallest change that addresses the root cause. Symptom-hiding patches still waste the next on-call.
Refactoring: name the invariants. Public API unchanged. Existing outputs unchanged. Known edge cases unchanged. Existing tests still pass for the same reasons. Allowed: internal organization, extraction, naming, removing duplication. Forbidden: sneaking in features or drive-by bug fixes that muddy the review.
Mix those three in one prompt and you get a PR nobody can approve, because nobody can tell what “complete or done” meant.
Make the agent hand you a short audit, not a novel sigh…
When the run finishes, ask for something reviewable:
- Files changed
- What changed
- Validation commands actually run
- Results
- Assumptions it had to make
- Anything it could not verify
- Links to any diff’s to review
That list is load balancing for your attention. You spend review time on risk and gaps, not reconstructing the story from a noisy diff.
Prompt quality is not prompt length
A long prompt with no acceptance criteria can still produce a risky change. A shorter prompt with a precise task, relevant context, a hard scope fence (reduces blast radius), and a real verification method is easier to trust.
Coding agents do not remove review. They make it more important to define what should be reviewed. The goal is not a “perfect AI prompt.” The goal is a task constrained enough to implement and specific enough to verify: the same craft we already expect when we onboard a junior hire or write a solid ticket.
Use the agent. Keep the engineering.
Loved it? Drop a comment with the worst one-line agent prompt you have ever typed (I have a few). Support the shenanigans on Patreon or buy me a coffee, and follow AttuneIT on YouTube, X, and Facebook. Let’s make tech less scary and more awesome.