Intent poisoning: when the commit message and the diff disagree
Intent poisoning is a commit whose stated purpose does not match what the code actually did. Why agents produce it, why it is worse than a bad commit message, and how to detect it automatically.
Intent poisoning is a commit whose stated intent does not match the change it contains. The message says the retry logic was updated for rate limits. The diff does that, and also deletes a validation check, and also changes a default timeout. Nothing in the message is false. The problem is what it leaves out, and the history now contains a claim that will mislead the next person to read it.
Why agents produce it
Agents summarise their own work from their own memory of it, and that memory is weighted toward what they were asked to do rather than what they did along the way. A session that hit an unrelated compile error and fixed it by removing a check will usually describe the change it set out to make, because that is what the conversation was about.
This is not deception, and treating it as such leads to the wrong fix. It is a summarisation gap, and the remedy is to compare the summary against the change mechanically instead of trusting either one.
Why it is worse than a vague message
A vague commit message tells you to read the diff. A specific and incomplete one tells you not to bother. Three months later, when the validation check turns out to matter, the search for when it disappeared runs past that commit twice, because the message does not mention it.
Detecting it
The check is a comparison between two things that already exist: the intent recorded before the commit, and the set of symbols the commit actually changed. If a commit deletes a function that no part of the stated intent accounts for, that is the signal. In Aura this runs in the pre-commit hook:
aura log-intent "Rewrote retry_logic to use exponential backoff for rate limits"
git commit -m "..."
# hook compares the AST delta against the logged intent
# unaccounted deletion of validate_window -> blockedThe hook does not judge whether the change is good. It asks whether everything in it was declared. In strict mode the commit is blocked until the intent covers the change or a human unlocks it.
What to do about it in review
- Read the deletion list first, and check each entry against the stated purpose.
- Treat the changed-file list as part of the claim: a file touched for no stated reason is a question.
- Ask the agent to restate the intent after the work, not before, and compare the two.
The record is the point
A commit whose intent has been checked against its content is worth more later than one whose message was well written. That is the difference between a message and a record. See keeping an immutable record of agent work and reviewing agent pull requests.
What is intent poisoning?
A commit whose stated purpose does not match what the code actually did — the message describes one change, the diff contains that change plus something else. The record is what makes it dangerous: the history now vouches for work nobody reviewed.
Is intent poisoning the same as prompt injection?
No, and the terms are often confused. Prompt injection is input: hidden instructions in a file or dependency that redirect an agent. Intent poisoning is output: the description a commit carries disagreeing with its contents. One is an attack on the agent, the other a defect in the record.
Why do AI agents write misleading commit messages?
Rarely by intent. An agent summarises the change it meant to make, while the diff also holds the incidental edits it made to get there — a deleted assertion, a relaxed check, a stray fix. The message is a faithful account of the plan, not of the result.
How do you detect intent poisoning?
Compare the stated intent against the structural change rather than the text. Parse what the commit did — functions added, removed, signatures altered — and check whether the message accounts for all of it. What the message never mentions is the part worth reading.
Why is a poisoned commit worse than a vague commit message?
A vague message tells you nothing and you go and look. A confident, specific, wrong message tells you the change is understood and you move on. It costs you the review rather than merely failing to help with it, and it keeps costing every reader afterwards.
Aura Crew vs Claude Code Loops: the autonomous work-loop, compared
Claude Code defines four loop types — turn-based, goal, time, and proactive. Aura Crew is the same idea productized: a dependency-ordered work-loop with proof, collision-safety, and any agent. Full comparison.
Autonomous coding agent loops, explained: turn-based, goal, time, and proactive
A coding agent loop is an agent repeating cycles of work until a stop condition is met. The four types explained — turn-based, goal-based, time-based, proactive — with when to use each and how to keep quality high.
How to run multiple coding agents in parallel without merge conflicts
Running several AI coding agents at once collides on shared files. The fix: a worktree per agent, a live team radar, and soft-to-hard zone claims so parallel agents never touch the same symbol. How Aura Crew does it.
Goal-based agent loops: giving a coding agent a definition of done
A goal-based loop keeps a coding agent iterating until a success criterion is met. The trick is a deterministic definition of done — tests, a score, a proof — not an LLM guessing at "good enough." How to write one.