The bookmark folder labeled "best AI coding tools" is a graveyard of expired advice. Every entry was accurate the week someone saved it and wrong within a quarter. Pricing moved, a model got deprecated, a promising startup got acquired, and the ranking that felt authoritative in January now reads like a historical document.
None of that is a reason to stop choosing. It is a reason to change what you optimize for. A specific tool is a depreciating asset. The logic you use to pick it is not. If you can say out loud why a tool earned its place in your stack, you can re-run that reasoning the day it stops earning it, and the switch turns into a cheap decision instead of a painful re-architecture.
That is how we think about our AI engineering stack. What follows is the selection logic we actually use, then the two tools it currently points to: Claude Code and Codex. The tools are the worked example. The reasoning is the asset, and it is the part we would keep even if both picks changed tomorrow.
Why every "best AI coding tools" list is already stale
Look at what happened to GitHub Copilot. In 2026, GitHub announced a move to usage-based billing for Copilot, replacing the flat per-seat pricing that had made it a safe default for years. Tom's Hardware reported that some customers saw effective cost increases of up to 100-fold once the meter started running against real usage. Whether that figure holds for any given team, the direction is what matters. A tool that was a settled line item became a variable one, and every "best tools" list that had ranked it on price went stale overnight.
This is not a Copilot problem. It is baked into the market. Model rosters change monthly. Vendors reprice as their own inference costs move. A feature that was a differentiator in one release is table stakes in the next. Any ranking that leads with today's prices and today's model lineup is measuring a snapshot of a moving target.
So the useful question is not "which tool is best right now." It is "how do we choose so the choice survives the next repricing." Rank the criteria first. The tools fall out of the criteria, and when a criterion's answer changes, you already know what to do next.
The selection logic that does not change
These are the criteria we score every AI coding tool against. Each one lasts because it describes how the tool fits our work, not a number on a pricing page.
- Fit to real workflow. Does the tool match how we actually build, which is multi-file, agentic changes across a real repository rather than single-line autocomplete in one buffer? A tool optimized for the wrong unit of work is a poor fit no matter how good its model is.
- Model-agnosticism and portability. Can the tool run against more than one model vendor, so a model regression or a price change does not strand us? Tool choice and model choice are different decisions, and a stack that conflates them inherits every risk of a single model provider.
- Switching cost and lock-in. If we left this tool in six months, what would we lose? Proprietary config, non-portable project memory, and accumulated muscle memory all raise the cost of leaving. We treat low switching cost as a feature, not an afterthought.
- Reversibility. How cheaply can we back out of a bad change the tool made? A tool that produces small, reviewable, git-native diffs is safer than one that rewrites broadly and asks for trust.
- Trust and verification. Does the tool make code review easier or harder? Output we cannot quickly verify is a liability, however fast it arrived. We favor tools that keep a human firmly in the review loop.
- Cost model transparency. Can we predict the bill before the invoice lands? Usage-based pricing is not disqualifying on its own, but opaque or surprising cost models are, because they turn budgeting into guesswork.
- Security and data boundaries. Where does our code go, and what is retained? A tool that cannot answer that clearly does not get near a client repository.
- Team fit. How long does onboarding take, and can we encode shared conventions the whole team inherits? A tool one person loves and nobody else can adopt is not a stack decision. It is a personal preference.
Notice that none of these criteria name a brand or a price. That is on purpose. They are the questions we can ask again next quarter and the quarter after, and they stay the right questions long after the specific answers have all changed.
Our stack at a glance
Here is what those criteria currently point to, plus the single thing that would move each pick.
| Layer | Current pick | Criterion it wins on | What would make us switch |
|---|---|---|---|
| Agentic, multi-file work | Claude Code | Terminal-native agentic edits with reviewable diffs | A tool with the same review ergonomics and lower switching cost |
| OpenAI-first, fast iteration | Codex | Speed against OpenAI models with tight feedback loops | A materially faster loop, or a model portability gap we could not tolerate |
Two picks, one job each, and an explicit exit condition for both. The table is short on purpose. If it needed twenty rows, the stack would be a liability rather than a decision.
Claude Code: our pick for agentic, multi-file work
Best for. Changes that span several files and need the tool to reason about a whole repository, not a single function. This is the work where autocomplete-style assistants fall down and an agentic tool earns its keep.
How we use it. Terminal-native, inside the actual project, making edits we review as ordinary git diffs. The review ergonomics matter as much as the edits themselves. Because changes arrive as small, inspectable diffs, verification stays cheap and a human stays in the loop by default rather than by discipline.
Limitations. Agentic tools can attempt too much in one pass, and a large speculative change is harder to review than a tight one. We manage that by keeping tasks scoped and treating the diff, not the tool's confidence, as the source of truth.
What would make us switch. A tool that offered the same terminal-native, diff-first review ergonomics with lower switching cost, or a change in how it handled our code that failed the security and data-boundary test. Claude Code is the pick today because it scores well on fit, reversibility, and trust. If another tool scored higher on those same axes, the reasoning would point elsewhere and we would follow it.
Codex: our pick for OpenAI-first, fast iteration
Best for. Fast iteration against OpenAI models, where the priority is a tight write-run-adjust loop rather than broad multi-file refactoring.
How we use it. For the class of work where speed of iteration is the binding constraint and the OpenAI model lineup is the right fit. It complements Claude Code rather than competing with it, which is the whole reason we score tools against jobs instead of ranking them against each other.
Limitations. An OpenAI-first tool concentrates model exposure with one vendor, which is exactly the portability risk our own criteria flag. We accept it here because the iteration speed is worth it for this job, and because our stack as a whole is not single-vendor even though this one layer is.
What would make us switch. A materially faster iteration loop from another tool, or a model portability gap that grew from an acceptable trade into an unacceptable one. Same discipline as before: named strengths, a named weakness, and an explicit trigger.
The volatile layer: what we expect to change
Cursor, Windsurf, Gemini CLI, and a repriced Copilot are all part of the moving field. New entrants keep arriving, models keep leapfrogging each other, and pricing moves in both directions. We track that field. We just do not treat every launch as a reason to re-architect.
This is the payoff of ranking criteria first. When the volatile layer moves, we are not re-deriving our whole approach. We are re-scoring one or two tools against a fixed set of questions. A new entrant does not threaten the stack. It gets scored, and either it beats an incumbent on the criteria that matter or it does not. Because the durable layer holds still, swapping a tool becomes a routine operation rather than a crisis.
How we would re-decide tomorrow
If everything changed overnight, here is the loop we would run, and it is short by design:
- Re-score against the criteria. Take the eight criteria above and score the incumbents and the challenger honestly, with no nostalgia and no sunk cost.
- Weight switching cost explicitly. A challenger has to beat an incumbent by more than the cost of leaving. A marginal win stops being a win once you price the migration.
- Pilot on real work. Run the challenger on an actual task in an actual repository, not a demo. Tools that shine in a scripted demo often stumble on a messy codebase.
- Commit, then move on. Make the call, encode the conventions so the team inherits them, and stop re-litigating. A stack you re-open every week is not a stack.
That loop stays the same whether the trigger is a price change, a model release, or a new competitor. The inputs change. The loop does not.
Key takeaways
- Rank criteria, not tools. A ranking of tools expires. A ranking of criteria does not.
- Treat any "best tools" list, including this one's specific picks, as perishable. The GitHub Copilot repricing is the reminder that today's safe default is tomorrow's variable cost.
- Make switching cheap. Low lock-in and high reversibility are properties you should select for, not ones you discover after you are already trapped.
- Separate tool choice from model choice. A portable stack survives a single vendor's bad quarter.
- Our current answer is Claude Code and Codex, and the answer is allowed to change. The reasoning is the part we intend to keep.
If any of this maps to how you think about building, it is also how our embedded agentic team picks its stack - criteria first, tools second, switching cost always on the table. The tools in our stack will change. The way we choose them is the part worth hiring for.
