"There are no dumb questions" is one of the kinder things we tell each other, and for people it is true. A new teammate asking where the billing code lives is learning the shape of the system; the question builds shared context and the answer takes a minute. But an autonomous agent is not a new teammate finding its feet. It can read the entire repository in the time it takes you to read this sentence. For an agent, some questions really are dumb — and the dumbest ones are the ones it could have answered by looking.
What a dumb question is for an agent
A dumb question is one whose answer is already sitting in the codebase. "Where is the code that handles this?" "What's the build command?" "Do we already have a pattern for this kind of thing?" A human might reasonably ask any of these on their first day. An agent that asks them is announcing that it would rather be hand-fed the context than go and find it — even though finding it is the one thing it is unambiguously better at than you.
The tell is that the answer is discoverable. If the agent could reach it by reading a file, grepping the tree, checking the CI config, or reading the last few commits that touched the area, then asking you for it is not caution. It is offloading work it should have done back onto you.
An async agent pays for questions in whole days
For a chat assistant sitting next to you, a question is cheap: you are right there, you answer, it continues. TaskGoblin is not sitting next to you. It is triggered by an issue assignment, a mention, or a new merge request, and it does its work in a sandbox while you are in a meeting, asleep, or in a different time zone. In that world a question is not a pause — it is a full stop.
An agent that asks "should I put this in services/ or lib/?" and then waits has converted a run that could have finished in minutes into one that finishes whenever you next happen to look at the thread. A single yes/no question, asked at the wrong moment, can cost a day of wall-clock time for thirty seconds of actual thinking. The asynchronous, no-human-in-the-loop model that makes the agent valuable is exactly the model that makes an avoidable question so expensive.
Over-specifying is the same mistake, moved earlier
The natural defence against a question-happy agent is to answer everything up front: paste the directory layout into the prompt, list the commands, spell out the naming conventions, include a snippet of the pattern to follow. It feels responsible. It is the same mistake wearing a disguise.
Hand-written context goes stale the moment the code moves on. When you pre-load the prompt with "we keep repositories in app/Repositories," you are betting that is still true, that you remembered every relevant detail, and that none of it biases the agent toward yesterday's approach. Usually at least one of those bets is wrong, and now the agent is confidently building on a fact you supplied instead of the truth it could have read. You have replaced the real work — understanding the current state of the system — with work about the work, and made the output worse in the process.
A good agent answers its own questions
The way out is not a better prompt. It is an agent that treats your instruction as the goal and goes and establishes the facts itself.
That is why a TaskGoblin run starts by cloning the whole repository into its sandbox — not just the diff under review, the entire working tree — so the ground truth is right there to read. It reads the files, the history of the area it is changing, the issue that triggered it and the discussion on it, and the handoff memory from earlier runs on the same thread. It can run the project's own commands in the sandbox to see what actually builds and passes, rather than trusting a build command someone typed into a prompt six weeks ago. Where it needs live state from your tools, it reads it directly through its integrations instead of asking you to relay it.
The result is that the agent arrives at the same understanding a good engineer would after an hour of reading — except it does it in seconds, and it does it against the code as it is today, not as someone remembered it.
When it should still ask
None of this means an agent should never ask anything. The questions worth asking are the ones the code genuinely cannot answer: which of two acceptable behaviours you actually want, whether a risky migration is in scope, a product decision that only lives in your head. Those are not dumb questions — they are the judgement calls that are yours to make, and a good agent surfaces them clearly and early rather than guessing.
The distinction is the whole point. An agent that asks you where the code lives is wasting the thing it is best at. An agent that asks you which of two products you are trying to build is using your time on the one thing you are best at. We built TaskGoblin to answer the first kind itself, so the only questions that reach you are the ones actually worth your attention.
