Agentic coding gives an AI a goal and lets it take several actions to reach it. The agent can inspect a repository, plan work, edit files, run commands, read test failures, and try again. A person supervises the process and reviews the result.

Autocomplete is much narrower. It predicts text near the cursor, and nothing changes unless the developer accepts the suggestion. An agent can affect many files and use tools, so it offers more leverage and a larger failure area. Use autocomplete for quick local drafting. Use an agent for a clear, bounded task with reliable checks, limited permissions, and enough review capacity to understand everything it changes.

Coding agents can be grouped by where and how they work. Common groups include:

• IDE agents work inside an editor, such as agent features in Cursor or GitHub Copilot.
• Terminal agents work through shell and repository tools, such as Claude Code or Aider.
• Cloud agents run asynchronously in hosted environments and return a branch or pull request.
• Issue-to-pull-request agents start from an assigned issue and prepare a reviewable change.
• Continuous integration (CI) or scheduled agents run maintenance tasks after an event or on a timer.

The boundaries overlap because one product may support several modes. Compare them by execution environment, available tools, supervision, permissions, and how results return to the team. Those differences matter more than the category name.

A good specification tells the agent what outcome is required and how success will be checked. Include the current problem, relevant files or interfaces, expected behavior, important edge cases, constraints, and clear non-goals. Name the tests or commands that should pass.

Keep the task small enough for one coherent change. Point to a current example rather than describing every style rule. State which files or public contracts must remain unchanged and which actions require approval. If important information is missing, tell the agent to stop and ask instead of guessing. A specification should guide implementation without forcing details that the agent can safely discover from the repository.

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

They matter because agents need a clear stopping point and a way to check their own work. Asking only to improve a parser is vague. A requirement to reject an unterminated quote and preserve quoted commas is verifiable. Include negative criteria when needed, such as no new dependency or no schema change. Human reviewers can then compare the final diff with the same contract instead of judging a broad claim that the task is done.

The plan-act-review loop divides agent work into controlled stages. First, the agent inspects the task and proposes steps, assumptions, risks, and expected files. A person or policy approves the direction. Next, the agent performs one bounded step and gathers evidence such as test output.

During review, the agent and supervisor compare the result with the plan and acceptance criteria. They correct mistakes, update assumptions, and choose the next step. The loop repeats until the task is verified. This is safer than one long run because wrong direction is found early. Plans should remain lightweight for small tasks and become more detailed as impact, uncertainty, and irreversibility increase.

Supervision means watching the agent’s direction, permissions, and evidence instead of waiting only for its final message. Review its plan, inspect important tool calls, answer real ambiguities, and stop the run when it repeats failures or expands beyond scope.

Good supervision does not require approving every harmless file read. Set safe defaults and reserve attention for writes, network access, new dependencies, destructive commands, and design choices. Ask for checkpoints on long tasks and keep git changes visible. Do not rescue the agent by giving vague encouragement; provide concrete evidence or a corrected constraint. 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 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 scope, package installation, network access, credentials, production systems, and destructive commands. Avoid training users to approve everything by making low-risk actions safe by default and prompts specific. Approval is not proof that the action is correct; it is a decision to permit a known impact within the larger review process.