“Agentic” gets used loosely enough to mean almost anything with a chat window attached to it, so it’s worth being specific: an agentic coding workflow is one where the model doesn’t just suggest text, it takes a goal, decides what to look at, edits multiple files, runs commands, reads the output, and iterates — without you copy-pasting each step by hand. That loop changes what kinds of tasks are worth handing over, and it changes how you need to supervise them.

The unit of work gets bigger

Autocomplete operates at the line or function level: you’re steering constantly, so mistakes are cheap and immediately visible. An agent operates at the task level — “fix the flaky test in the payments module,” “add pagination to this endpoint and update the callers.” The correction loop is slower, so an error compounds across more edits before you see it. The practical upshot: the tasks that suit this workflow are the ones with a clear, checkable end state — tests passing, a type error resolved, a described behavior reproduced — not open-ended “make this better.”

Give it a way to check its own work

The single biggest difference between an agent that’s useful unsupervised for twenty minutes and one you have to babysit is whether it has a fast, reliable feedback loop of its own: a test suite it can run, a type checker, a linter. Without one, it’s working blind and will confidently report success on a change that doesn’t actually work. With one, most of the self-correction happens before you ever look at the diff. If your project doesn’t have fast tests around the area you’re delegating, that’s worth fixing first — it pays off for human contributors too, not just the agent.

Scope the blast radius before the task starts

Three things are worth deciding upfront, not mid-task:

• What files are in play. A task scoped to “the export module” fails differently than one scoped to “wherever seems relevant” — the second one occasionally decides a shared utility needs refactoring and takes the change somewhere you didn’t expect.
• What’s reversible. Local file edits in a git-tracked repo are cheap to undo. Anything that touches a database, sends a request, or calls git push is not, and deserves an explicit stop for confirmation rather than being bundled into the same autonomous loop.
• What “done” means. State the exit condition, not just the goal — “done when pnpm test passes and the new endpoint is documented” gives the agent something to check itself against instead of guessing when to stop.

Review the diff, not the transcript

It’s tempting to skim the agent’s running commentary and call it reviewed. The commentary is the agent’s narration of its own reasoning, which is exactly the thing most likely to sound confident regardless of whether the underlying change is correct. Read the diff the way you’d read a colleague’s PR — cold, without the narration influencing your read of it. If the explanation and the diff disagree, the diff is what ships.

Where it still falls short

Long-horizon tasks that require holding a lot of implicit project context in your head — “this is fine here because of a constraint three services away” — are still where agents make confidently wrong calls. That’s not a prompting problem you can fully engineer away yet; it’s a reason to keep the tasks bounded and the feedback loop tight rather than a reason to avoid the workflow. Used inside those limits, it’s a genuine step up from writing every line by hand — used outside them, it’s a fast way to generate a plausible-looking diff that’s wrong in a way that takes longer to find than it would have taken to write yourself.