How I Settled on Splitting AI Coding Tools
※本記事にはアフィリエイトリンクを含む場合があります。内容は広告の有無に影響されません。
結論
Rather than consolidating on one AI coding tool, splitting roles across complex development, quick prototyping and everyday lookups keeps both cost and accuracy steadier.
The short version
Up front.
| Use | What I use |
|---|---|
| Serious, complex development | Claude Code (the main tool) |
| Getting a simple app into shape quickly | Codex |
| Everyday conversation, lookups, image generation | Gemini |
| Cursor | Handed over its role; little used now |
In one line: Claude Code as the main tool for development, Gemini as the everyday companion.
Claude Code — the main tool for complex development
An AI coding tool that runs in the terminal, and it will carry intricate implementation a long way when handed to it. This became the main tool for development.
The weakness, honestly: there is a sense of cost piling up the more you use it. The capability is not in doubt, but “use it freely without thinking” is not how it feels.
Cursor — the previous main tool
To be clear, Cursor did not get worse. At the time it was straightforwardly the main tool.
What came later was strong enough, so its turn simply stopped coming. That is all.
Codex — getting something into shape quickly
Heavy, complex work goes to the main tool; this is for getting something small into shape quickly. If recommending one to start with, I think it is this.
Gemini — the everyday companion
Less development, more everyday. I use it for lookups and image generation.
Why they stay split
I do not consolidate because the accuracy and cost each use needs are different.
Handing intricate implementation to a strong tool earns its keep, but running lookups and short prototypes through the same thing means the spend stops being proportional to the difficulty. Using an expensive tool on hard work is rational; using an expensive tool on easy work is just expensive.
On deciding to switch
Looking back, switching always happened because what came later was strong enough, never because the previous one got worse.
That ordering is worth being conscious of. Once you start explaining a switch as “the old tool is bad”, the judgement is usually clouded. Migration costs something, so a justifying story becomes necessary.
よくある質問
Q1If picking just one to start with, which?
Choosing for approachability, start with something that gets a simple app into shape quickly. Tools that take on complex implementation are powerful, but cost piles up the more you use them, so making one your main tool before you know what it is for leaves the spend unpredictable.
Q2Why not consolidate on the most powerful tool?
Because the accuracy and the cost each use needs are different. Handing intricate implementation to an expensive tool earns its keep, but running lookups and short prototypes through the same thing means the spend stops being proportional to the difficulty.
Q3How do you decide to switch?
It has happened in the order "what came later was strong enough", not "the previous one got worse". Once you start explaining a switch as "the old one is bad", the judgement is usually clouded.
この記事の根拠
- ドキュメントファイル
本文の主張は、上の記録に書かれていることだけです。運用しているリポジトリは非公開のため リンクは張れませんが、どのファイルの何行目を、どのコミット時点で見て書いたかは 記事ごとに残しています。推測で書いた箇所はありません。