Agentic Coding Workflows.

Agentic coding gives an AI model a goal and lets it take many actions to reach it. Autocomplete only predicts text near your cursor.

An agent works in a loop:

• it inspects the repository and plans the work
• it edits files and runs commands
• it reads test failures and tries again

A person supervises the run and reviews the result.

Autocomplete is much narrower. Nothing changes until the developer accepts a suggestion. An agent can touch many files and use tools, so it can get more done and also do more damage.

Use autocomplete for quick local drafting. Use an agent for a clear, bounded task with reliable checks and limited permissions. Make sure someone has the review capacity to understand everything it changes.

Coding agents fall into five common categories, grouped by where and how they work.

Cloud agents return a branch or pull request. Issue-to-pull-request agents prepare a reviewable change, and CI or scheduled agents run maintenance tasks. The boundaries overlap, because one product may support several modes. Copilot cloud agent, for example, is also a cloud agent.

So compare agents on two axes. The first is the execution environment, with its tools and permissions. The second is how much supervision each needs and how results return to the team. Those differences matter more than the category name.

A good task specification tells the agent what outcome is required and how success will be checked. Include:

• the current problem and the expected behavior
• the relevant files or interfaces
• the important edge cases
• constraints and clear non-goals
• the tests or commands that should pass

Keep the task small enough for one coherent change. Point to a current example instead of describing every style rule. State which files or public contracts must stay unchanged, and which actions need approval. If important information is missing, tell the agent to stop and ask instead of guessing. Guide the implementation, but leave out details the agent can safely discover from the repository.

Acceptance criteria are observable conditions that must be true when the task is complete. They can describe an API response, an error case or a performance limit. They can also name a user interaction or a set of tests that must pass. Good criteria focus on behavior, not on a guess at the implementation.

They matter because an agent needs a clear stopping point and a way to check its own work. "Improve the parser" is vague. "Reject an unterminated quote and preserve quoted commas" is verifiable. Add negative criteria when needed, such as no new dependency or no schema change. Reviewers can then compare the final diff with the same contract, instead of judging a broad claim that the task is done.

A plan-act-review loop splits agent work into controlled stages that repeat until the task is verified.

• Plan. The agent inspects the task and proposes steps, assumptions and risks. It also lists the files it expects to change. A person or policy approves the direction.
• Act. The agent performs one bounded step and gathers evidence, such as test output.
• Review. The agent and supervisor compare the result with the plan and acceptance criteria. They correct mistakes, update assumptions and choose the next step.

This is safer than one long run because a wrong direction shows up early. Plans should stay light for small tasks. They become more detailed as impact, uncertainty and irreversibility grow.

Supervising a running agent means watching its direction, permissions and evidence instead of waiting only for its final message. Review its plan, inspect important tool calls and answer real ambiguities. Stop the run when it repeats failures or goes beyond its scope.

Supervision does not require approving every harmless file read. Set safe defaults and reserve attention for writes, network access and new dependencies. Destructive commands and design choices need that attention too.

Ask for checkpoints on long tasks and keep git changes visible. Give the agent concrete evidence or a corrected constraint, never vague encouragement. The supervisor remains accountable for deciding whether the work is safe, complete and understandable enough to merge.

An approval gate pauses the agent before an action that needs human permission. The permission prompt should show the exact command or operation, why it is needed and what resources it can affect. The person can allow it once, allow a narrow class of similar actions, or reject it.

Gates reduce the chance that a mistaken or malicious instruction causes damage. Use them for:

• file writes outside the task's scope
• package installation
• network access
• credentials
• production systems
• destructive commands

Make low-risk actions safe by default and keep prompts specific, so users are not trained to approve everything. Approval is not proof that the action is correct. It is a decision to permit a known impact within the larger review process.