Claude Code vs Codex vs GitHub Copilot: Same Repo, Same Task, 3 Different Workflows

Autocomplete suggests the next line. An AI coding agent tries to finish the whole task: it reads your project, edits several files, runs your tests, notices failures and hands the result back for review.

I gave Claude Code, OpenAI Codex and GitHub Copilot (agent mode) the same FastAPI repository and exactly the same instruction, and watched how each one works.

One honest caveat up front: this is a workflow comparison, not a benchmark. Nothing was timed or scored, and all three products change month to month.

What makes something an "agent"?

An agent runs a loop:

1. Take a request in plain language
2. Gather context: read the files that matter
3. Write a plan, so you see the intent before anything on disk changes
4. Edit code
5. Run the tests
6. When a test fails, go back and try again

That last step, edit → test → edit again, is the whole difference from autocomplete. And it only acts through the tools and permissions you give it. You still decide what gets accepted.

The repo and the challenge

TaskFlow is a small FastAPI service that creates and lists tasks, stored in memory, with existing tests passing.

The instruction, identical for all three:

• Add a priority field with three values: low, medium, high
• Let people filter with a query parameter
• Reject anything that isn't one of the three
• Add tests
• Update the README
• Leave everything else alone

Claude Code: terminal-first

Run in a terminal inside the repo (it also plugs into supported editors):

• It looked around first: the file tree, then the three files it actually needed.
• It wrote a six-step plan in plain English. If the plan is wrong, you find out before a line changes.
• It asked permission before writing files. Give it the smallest permission that does the job.
• It edited four files and showed the diff.
• Then a test failed: one test expected 400, it got 422.

This is the moment that matters. It read the failure and worked out that FastAPI validates the enum before the handler runs, so an unknown value is rejected with 422, not 400. The framework was right and the test was wrong. It fixed the test, reran the suite, and got 5 passing.

Codex: delegate and check in

Here I used Codex's delegated-task shape: describe the task, hand it over, keep working, and check in.

• A progress view shows where it is: reading, planning, editing, running the suite.
• It hit the same 400 vs 422 wall and resolved it the same way. The codebase decided that answer, not the brand.
• You get two things back: a summary of what it says it did, and a diff of what it actually did.

Read the diff. The summary is a claim; the diff is the change. Delegation is comfortable when checking is cheap: clear scope, green suite, a diff you can read in minutes.

GitHub Copilot: never leave the editor

Most people know Copilot as grey text one line ahead (Tab to accept). The same product now has chat and an agent mode that edits across files.

• You pick the context (which files it should consider) and stay in the editor.
• Edits land in place across a working set of four files, each with keep or undo. You approve as you go instead of reading one big diff at the end.
• Tests run in the integrated terminal: same failure, same fix, same 5 passing tests.
• Then the familiar steps: stage, commit, open a pull request.

Its pull isn't that it's smarter. It's that it's already where your hands are.

What actually changed (all three)

Four files:

• models: an enum, so three loose strings become a type the framework can check (which is why validation was almost free)
• main: the route takes an optional, already-validated filter
• tests: two new cases, one valid value and one that should fail
• README: five lines documenting the rule

It's a small change, and that's the point. The value was never typing those lines. It was holding four files in mind, running tests, reading the failure, and coming back with something reviewable.

How they differ

	Claude Code	Codex	Copilot
Lives in	Terminal (+ editor integrations)	App, CLI and editor	Editor and GitHub
You interact by	Conversation inside your repo	Assign, check progress, review	Suggestions, chat, agent mode where you code
Good fit	Terminal-driven work	Clearly scoped, testable tasks	Editor work that ends in a PR
Your job	Scope, context, tests, read the diff	Same	Same

The last row is the same three times. Your responsibility doesn't move.

Five habits for working safely

An agent runs commands and reads files, so your boundaries matter. In the video, one reaches for a .env file. It should stop there, and you should be the reason it stops.

1. Keep secrets out of prompts. Reference the variable name, never the value.
2. Grant the smallest permission that works. Read first; write and run only where needed.
3. Read commands before approving them. Anything that deletes, force-pushes or deploys deserves a pause.
4. Review the diff, not the summary.
5. Run your tests, linter and type checker.

An agent can misunderstand you and be completely confident about it. Confident-and-wrong looks exactly like confident-and-right until you check.

Write the prompt in five parts

Weak: "Make this API better." Better how? Finished when?

Strong prompts have:

1. Goal: what "finished" looks like
2. Scope: what not to touch
3. Constraints: you decide the edge cases
4. Acceptance tests: success is checkable, not arguable
5. Required summary: something to review

Goal, scope, constraints, tests, summary. Write those and most problems disappear.

So which one?

Pick the workflow, not the logo:

• You live in the command line and want direct control → terminal-first agent
• You'd rather hand off a well-defined task and review the result → delegation
• You want help next to your cursor, ending in a PR → stay in the editor

They overlap more every month, so try them on a small, non-sensitive repo and judge the workflow yourself. The skill that lasts is defining the task, giving the right context and verifying the result.

Full walkthrough: https://youtu.be/SoP2H4iKpWA

Which agent should I test on a full real-world project next? Tell me in the comments.

---

Drafted with AI assistance from the recorded video. I make AI, coding and tech tutorials on RainyTech.