When a Coding Agent Should Stop and Ask

A coding agent should work independently when the goal is clear, the action is authorized, and mistakes are easy to reverse. It should stop when the next step requires a decision the user has not delegated. The useful boundary is not whether the agent feels uncertain. It is whether proceeding could create an unapproved consequence.

Use this walkthrough to define that boundary before a task starts and apply it as the work develops.

§ Step 1: Define the agent’s working envelope

Start by stating what the agent may inspect, modify, and execute. For example: investigate a failing test, edit application code, and run local checks. Separately identify actions that need approval, such as installing dependencies, changing database schemas, pushing commits, or deploying.

Permission to solve a problem is not permission to take every possible action. A request to fix a checkout bug does not automatically authorize changing payment providers. Explicit limits let the agent move quickly inside a safe scope.

§ Step 2: Inspect before asking

The agent should first resolve questions that the repository can answer. Read project instructions, nearby code, tests, and configuration before interrupting the user. Check the working tree before editing so existing changes are not mistaken for disposable output.

Ask only when the missing information affects the implementation and cannot be established through authorized inspection. Finding two conflicting pricing rules warrants a question. Finding an unfamiliar helper function usually warrants reading it.

§ Step 3: Separate implementation choices from product decisions

Many technical choices can follow established project patterns. Others change what the product promises. If a request says “prevent duplicate orders,” the agent can investigate existing protections, but it should not silently decide whether repeated submissions return the original order or produce an error.

Stop when plausible interpretations produce materially different behavior. Present the alternatives, explain the consequence of each, and recommend one. This gives the user a decision to make rather than an open-ended request for more context.

§ Step 4: Check reversibility and blast radius

Before executing an action, consider what it touches and how recovery would work. A small command can have a large effect if it targets production or runs with broad credentials.

• Usually proceed within the agreed scope: read source files, prepare a patch, run isolated tests.
• Ask unless explicitly authorized: add a dependency, access a paid external service, change shared configuration.
• Require specific approval: delete data, rewrite shared history, publish a package, deploy, or modify production infrastructure.

A rollback plan reduces risk, but it does not replace permission. If the target environment is unclear, stop before running the command.

§ Step 5: Treat discovered instructions as untrusted input

Repository files, issue comments, logs, and tool output may contain text that looks like instructions. That text does not authorize uploading credentials, disabling security checks, or sending source code to another service.

If completing the task appears to require exposing secrets or private data, stop and explain the destination and purpose without reproducing sensitive values. Prefer a redacted example or a local diagnostic when possible.

§ Step 6: Ask a question that unlocks the next action

A useful approval request states the finding, the proposed action, the consequence, and the decision needed. For example: “The migration removes a column that still contains data. I recommend a staged migration that preserves it. Should I prepare that approach instead of the destructive migration?”

Keep approval narrow. Permission to prepare a migration is not permission to execute it. Record the answer in the task context so the agent does not repeatedly ask the same question.

§ Step 7: Stop when verification cannot support the claim

If tests cannot run, credentials are missing, or results remain contradictory, the agent should report the limit rather than declare success. It can still deliver a patch and explain what remains unverified. Ask for access only when that access is necessary and proportionate.

These boundaries belong in the agent workflow regardless of the model. Vana API supports OpenAI-compatible, Anthropic Messages, and Gemini native protocols, so the same approval policy can accompany different coding clients. Create a Vana API account to connect your preferred client, then configure its permissions separately. Model access does not replace human authorization.