This is part 5 of a 5-post series on professional agentic coding for senior engineers.
There is no single best coding agent.
There is a best surface for the task.
That distinction matters.
If you choose the tool because it is fashionable, you will bend the workflow around the tool. Senior engineers should do the opposite: choose the surface that gives the right context, permissions, verification loop, and review path.
use Codex when you want repo-aware terminal work
Codex is a strong fit when the work is close to the repository and you want the agent to inspect files, edit code, run commands, manage plans, use subagents, and produce a verified diff.
Good Codex tasks:
- bug fixes with tests
- repo investigations
- refactors with clear boundaries
- PR review with
/review - multi-step terminal workflows
- tasks that benefit from
AGENTS.md - long-running goals with explicit verification
Good Codex prompt:
Goal: fix the import cycle causing the API package to fail typecheck.
Context: start with pnpm typecheck output and packages/api/src.
Constraints: no new dependencies, preserve public exports.
Done when: typecheck passes and /review finds no blocking correctness issues.
Codex is not magic because it is Codex. It is useful because it can work in the same environment as the code and show evidence.
use Claude Code for terminal-native planning and hooks
Claude Code is strong for terminal-native coding flows, plan/explore workflows, subagents, project memory through CLAUDE.md, and hooks for repeatable checks.
Good Claude Code tasks:
- explore a new codebase area before editing
- implement a bounded change with a plan
- use subagents for specialized review
- run repeatable local checks
- keep recurring project notes in
CLAUDE.md
Good Claude prompt:
Use plan mode.
Inspect the checkout flow and current tests.
I want to add retry handling for transient PSP timeouts.
Do not edit files until you explain the existing flow and propose a minimal plan.
Claude Code's plan-first workflow is especially useful when the engineer wants the model to slow down before touching files.
use GitHub Copilot agents for GitHub-native issue-to-PR work
GitHub Copilot coding agent is useful when the work naturally starts as a GitHub issue and should end as a PR.
Good Copilot agent tasks:
- well-scoped issues
- small-to-medium feature changes
- docs updates
- test additions
- simple bug fixes with clear reproduction
- repository-governed workflows
The issue has to be concrete.
Bad issue:
Improve onboarding.
Good issue:
## Goal
Show validation errors inline on the signup form instead of only as a toast.
## Scope
- apps/web signup form only
- no API changes
## Done
- invalid email and missing password errors show inline
- existing signup tests pass
- PR includes screenshot
Copilot can also use repository instructions and custom agents. That makes it good for org-level workflows, but only if the instructions are maintained.
use IDE chat or autocomplete for small local edits
Not every task needs a full agent.
Use IDE chat or autocomplete when:
- you are editing one function
- you know exactly what to change
- the risk is small
- verification is immediate
- the surrounding context is already in your head
Example:
Rewrite this function to remove the duplicated null checks.
Keep behavior identical.
No need to spin up a full autonomous loop for every small cleanup.
when not to use an agent
Sometimes the right answer is: do not delegate this yet.
Avoid agents when:
- the product decision is unclear
- the acceptance criteria are political or subjective
- the change affects money movement without strong tests
- the task requires production secrets the agent should not access
- the migration is destructive
- the blast radius is not understood
- there is no realistic verification path
This does not mean agents can never help.
They can investigate, write a plan, enumerate risks, or draft tests.
But implementation should wait until the human decision or verification path exists.
bad practice: tool loyalty
Tool loyalty is when engineers say:
I do everything in Claude.
Or:
I only use Codex.
Or:
Copilot should handle all issues.
That is not engineering judgment. That is brand attachment.
Better:
- use Codex when the local repo and terminal loop matter
- use Claude Code when plan/explore and subagent workflows fit
- use Copilot when GitHub issue-to-PR governance is the cleanest path
- use IDE completion for tiny edits
- use no agent when the problem is not ready
the selection checklist
Before choosing a surface, ask:
- Where does the source of truth live: local repo, GitHub issue, production logs, design doc?
- Does the task need local secrets or local state?
- Does the task need a PR from an issue?
- Does it need a plan before edits?
- Does it need subagents or fresh-context review?
- What tools must run to prove success?
- What permissions are safe?
- What is the blast radius if the agent is wrong?
The answer usually tells you the tool.
closing the series
The professional workflow is not "use more AI."
It is design the loop.
Context.
Plan.
Patch.
Proof.
Review.
Reusable instructions.
Senior engineers who do that will get leverage from agents.
Senior engineers who skip it will get bigger diffs and more review fatigue.
The model matters.
The loop matters more.
sources
- OpenAI Codex manual
- Claude Code best practices
- Claude Code subagents
- GitHub Copilot: get the best results from Copilot coding agent
- GitHub Copilot repository instructions
- GitHub Copilot custom agents
To test my projects, I use Railway. If you want $20 USD to get started, use this link.
Top comments (0)