Describe the feature, let the agent write the code, then you read every line before it ships.
Give it the full context up front — your stack, the existing files it touches, and what 'done' looks like. Vague ask, vague code.
Copilot's agent mode and chat can do multi-file work if you point it at the right files and describe the goal. Don't just sit and hit tab.
Ask right after the feature is done, while the context is fresh. Tell it which test runner you use or it'll pick one you don't have.
Have the agent read the existing code first and explain it back to you before it changes anything. If its explanation is wrong, you caught a problem early.
Fence it in. Tell it exactly which files it may touch and that everything else stays untouched. Agents love to 'improve' things you didn't ask about.
Autocomplete finishes the line you're typing. An agent takes a goal, plans across files, writes code, and can run commands. Different jobs, different trust levels.
It's predicting plausible code, not executing it. It'll invent function names, use an old API, or assume a package version you don't have. Confident and wrong is its default failure mode.
The context window is how much code and conversation the agent can hold at once. Feed it too much and it forgets the start; feed it too little and it guesses.
Good instinct — payments are where confident-wrong code costs real money. Before you ship, have the agent walk you through every failure case: what happens on a duplicate event, a failed charge, a retry.
Then test those cases yourself with the provider's test tools. Don't trust that it handled idempotency just because it said it did.
It touched something it shouldn't have, or changed shared code. Paste the failing test output back to it and ask what its change did to that code path.
Then decide if you trust its fix or want to revert and try again with a tighter scope. This is exactly why you commit before letting an agent loose — so you can undo.
Yes for speed, but read what it writes. An MVP built by an agent you don't understand becomes a codebase you can't debug at 2am when a user hits a bug.
Let it build fast, but make it explain the tricky parts as it goes. You're not just shipping — you're the one who maintains this next week.
They overlap but fit different setups. Pick by where you work and how much autonomy you want the agent to have.
| Tool | Best for | The catch |
|---|---|---|
| OpenAI Codex | Delegating whole tasks in a sandbox | You review async, less line-by-line control |
| GitHub Copilot | Living inside VS Code with an existing repo | Best in Microsoft's ecosystem, subscription |
| OpenCode | Terminal-first, open-source, model-agnostic | Rougher edges, you configure more yourself |
More autonomy means more speed and more ways to break things. Match it to how much you trust yourself to catch mistakes.
| Approach | Good when | Risk |
|---|---|---|
| Suggests code only | You want to review every change | Slower, more manual work |
| Runs commands itself | Repetitive or well-scoped tasks | Can delete or break things fast |
| Sandboxed autonomy | Bigger tasks you'll review after | You may not notice bad decisions early |
Because someone has to know if the feature is right, not just working. The agent has no idea what your users actually need, why the last dev made a weird choice, or what breaks the business when it fails.
It writes code faster than you. You decide what to build, catch the confident mistakes, and own it when it ships. That job isn't going anywhere — but the person who only copy-pastes without reading is.
Trust the speed, verify the logic. It'll nail boilerplate and get the shape right, but it will also quietly skip a security check or handle the wrong error. Read every line before it goes near production.
Treat it like a fast junior who never admits they're unsure. Great output, zero accountability — that part stays yours. Commit before it runs, test the failure cases yourself, and never ship what you haven't read.