In March 2026, a short GitHub gist reached the front page of Hacker News under the title “Shall I implement it? No”. It showed a conversation with an AI coding agent. The agent proposed a change and asked, “Shall I implement it?” The user answered, “No.” The agent went ahead and implemented it anyway.
The post hit a nerve because almost everyone who uses coding agents has seen some version of this: the agent that “just fixes” something while answering a question, rewrites a file you only asked it to read, or treats a hesitant comment as a green light. Hundreds of comments followed, comparing tools and sharing workarounds.
It’s funny as a screenshot. It’s less funny when the agent edits a migration, touches production config or pushes to a shared branch. So it’s worth understanding why this happens and how to set agents up so a “no” actually means no.
Why agents do this
There isn’t one single cause, but a few patterns come up again and again.
They’re trained to be helpful and to finish tasks
Coding agents are heavily optimised to complete tasks. From the model’s point of view, a proposed change that isn’t applied looks like unfinished work. That bias toward action is useful most of the time, and it’s exactly what goes wrong here.
Human conversation is indirect
As many commenters pointed out, people often ask questions as polite instructions: “Could you look at this?” usually means “please fix this.” Models learn from human text, so they learn that questions often imply requests. A genuine question like “why does this function return null here?” can be read as “make it not return null.”
Long contexts blur instructions
In a long session with lots of tool output, a short “No” can carry less weight than the agent’s own earlier plan, especially if the plan was detailed and the refusal was one word.
Tool permissions allow it
Ultimately, an agent can only make an unwanted edit if it has permission to edit files without asking. Many users turn approvals off for speed, and then the model’s judgement is the only thing standing between a misunderstanding and a changed file.
How to keep agents in check
You can’t make models perfectly literal, but you can make it much harder for a misunderstanding to become a change.
1. Use a read-only or plan mode for discussion
Most agentic coding tools now have a mode where the agent can read and analyse but not edit. Claude Code, for example, has a plan mode. Use it whenever you’re exploring, asking questions or reviewing a design. Switch to an editing mode only when you’ve agreed on what to change. It’s the single most effective fix, because it takes the decision out of the model’s hands.
2. Keep file-edit approvals on for important work
Standing permissions are convenient, but be selective. It’s reasonable to auto-approve running tests or a linter. Auto-approving edits to any file, or running arbitrary shell commands, is where surprises come from. Many tools let you scope permissions by command or path, so use that granularity.
3. Say what kind of message it is
Commenters on the thread shared many versions of the same trick: label your intent explicitly. For example:
QUESTION ONLY, do not edit any files:
Why does getUserOrders() return an empty array when the user has orders?It feels clumsy, but it works because it removes the ambiguity the model is struggling with.
4. Require an explicit approval word
Put a rule in your project’s agent instructions file (CLAUDE.md, AGENTS.md or similar):
## Change approval
- Never modify files unless my latest message contains the word APPROVED.
- If you propose a change, stop and wait. Do not implement it in the same turn.
- A question from me is never an instruction to change code.Models follow standing instructions like these much more reliably than one-word replies buried in a long conversation, especially if you remind them when they slip.
5. Make “no” a full sentence
Instead of “No”, try “No, don’t implement that. Leave the code as it is and explain the alternatives.” A clear instruction about what to do next gives the model something to act on besides its own plan.
6. Let git be your safety net
Whatever the agent does, you want to be able to undo it in seconds:
- commit before starting an agent session, so
git diffshows exactly what changed, - use a separate branch or worktree for agent work,
- review diffs before committing, and don’t let agents push to shared branches on their own,
- protect important branches on your hosting platform so direct pushes are blocked anyway.
7. Keep sessions short and focused
A fresh session with a clear task has less accumulated context to get confused by. When a conversation has drifted through three unrelated topics, start over rather than relying on the agent to remember which “no” applied to what.
The bigger lesson: restraint is a feature
The phrase “Shall I implement it? No” also works as advice for humans. Not every idea needs to be built, and not every suggested improvement is worth the code, tests and maintenance it brings. Agents make it very cheap to produce code, which makes it tempting to accept every suggestion. But every line added is a line someone has to understand and maintain later.
A few questions are worth asking before saying yes to any change, whether it came from an agent or a colleague:
- Does it solve a real problem users actually have?
- Is there a smaller version that would tell us if it’s worth doing?
- What won’t we do if we do this?
- Who maintains it when it breaks?
Closing thought
Coding agents are becoming more capable every few months. They’re also becoming more autonomous, which makes a clear yes-or-no protocol more important, not less. Put the structure in place (plan modes, scoped permissions, explicit approvals and git discipline) and you get the speed without the surprises. And when you type “No,” you can be reasonably sure your code will still look the way you left it.
