Should an AI coding agent assume or ask?
By Soumen Sarkar · October 2026
Short answer: An AI coding agent should assume and keep going in almost every case, as long as it states the assumption plainly where someone can correct it. It should look first, because the answer is often already written down, and when the assumption is high stakes it should still keep going but choose the option that is easiest to reverse.
Why assume rather than ask?
Because a question hands the agent's progress to someone else's calendar. At agent pace, the person who could answer is usually busy with their own sessions, in a meeting or asleep. The agent waits, and so does everything built on it.
An assumption that is stated keeps the work moving and still gives the right person a chance to weigh in. If it is right, nothing more happens. If it is wrong, someone corrects it, usually in a sentence, and the fix is small because it was caught early.
The choice that goes badly is neither of these. It is the silent guess: the agent picks something and says nothing, and the call is discovered weeks later in production.
How should an agent decide?
- Look first. Search the code, the instruction files and the team's record. The answer is often already there.
- Make the reasonable call. Pick what a thoughtful teammate would pick, with the information at hand.
- State it in one line. "Assuming X because Y." The reason matters most: it lets someone else see quickly whether the call holds.
- Weigh the stakes. If the call touches data, money, access, a public interface or deleting something, mark it high stakes and choose the option that is easiest to undo.
- Keep going.
When is asking right?
Just before an action that can't be undone: deleting production data, sending a message to every customer, changing a published API that others already call. Even then, the agent can often do everything up to that step, and leave the last one for a person.
What does this look like in a real change?
An agent is rebuilding the sign-up onboarding in Onboarding · app/onboarding. It meets two unknowns.
The first: can people skip the "invite your teammates" step? Nothing in the record says. It assumes yes, because other steps are skippable, and keeps going. Low stakes; nobody needs to look soon.
The second: does the free trial start at sign-up or when the first project is created? That is money. It finds no decision, so it assumes the trial starts at sign-up, because that is what billing does today, marks it high stakes, and builds the flow so the start moment is set in one place. It keeps going.
The person who owns billing sees the high-stakes line first. The trial should start at the first project. Because the agent kept that choice in one place, the correction is a two-line change, not a rebuild.
What makes assuming safe?
Visibility and a fast way back. An assumption needs to reach someone who can judge it, and their correction needs to reach the agent. Campfyrr does both: an agent states the assumption with one call, gets the answer straight back if the record has it, and otherwise the assumption goes to whoever made the closest decision in that area. High-stakes ones are shown first. The agent never stops waiting for a reply.
Words used here
- Assumption: An assumption is the best available answer to an unknown, stated and acted on, kept visible so anyone can correct it.
- High-stakes assumption: A high-stakes assumption is an assumption that touches data, money, access, public interfaces or deleting things, so being wrong costs more and it should be checked first.
- Team record: The team record is everything a team has written down that a person or agent can search before asking: decisions, rules, handoffs, assumptions and the reasons behind changes.
The principle behind this: Turn unknowns into calls: Nothing we don't know gets to stop us. We name our assumption, and we move.
Move as one at agent speed. Nobody waits. Add Campfyrr to Claude: it briefs every agent before it touches the code, keeps assumptions and handoffs where the team can see them, and never takes your code (what it keeps).