Every AI Coding Tool I Actually Pay For in 2026 (And What I Dropped)
Every list of AI coding tools online reads like a sponsored roundup, ten tools, no strong opinions, everything gets a passing grade because nobody wants to say a popular tool isn't worth the subscription. I'm not trying to sell you anything here. This is the actual stack I use daily to build CrimsonWatch and handle freelance client work, what earns its spot every single month, and what I tried and quietly stopped opening.
What I use for the heavy lifting
Claude is still where I send anything that requires actually understanding the system before writing a line. Architectural decisions, working through a tricky schema change across the Inngest job pipeline, reasoning about how a change in one part of CrimsonWatch ripples into another. The reason it earns this spot isn't raw output speed, it's that it asks fewer wrong questions about my codebase and makes fewer confident assumptions that turn out to be false. When the cost of being wrong is high, that matters more than being fast.
I'm also using OpenRouter as the layer behind CrimsonWatch's own AI scoring feature, which is a different use case entirely, that's AI as part of the product I'm shipping rather than a tool I'm using to build it. Worth mentioning because it's easy to conflate "AI tools I use to code" with "AI I've built into my product," and they pull from a completely different part of the budget and a completely different set of tradeoffs, mainly around latency and cost per request at scale instead of raw reasoning quality.
What I use for fast iteration
Gemini CLI handles the parts of my day where I don't want to context switch into a heavier tool. Quick scripts, fast iteration on something small, a one off transformation on some data I'm cleaning up. It's not that it's a worse model for hard problems, it's that the friction of using it fits low stakes, high frequency tasks better. I don't want to think hard about which tool to reach for when I'm fixing a small thing fifteen times a day. Gemini CLI is the low friction default for that category, Claude is the deliberate choice for the category where getting it wrong actually costs me something.
That split, cheap and fast for high frequency low stakes work, deliberate and careful for anything architectural, is honestly the whole philosophy behind my stack at this point. Everything else gets evaluated against whether it fits one of those two jobs better than what I'm already using.
What earns a permanent spot beyond the models themselves
TypeScript stays non negotiable, and this matters more in an AI heavy workflow, not less. The type system is doing review work for me before I even read a line, catching a huge share of the loose assumptions AI generated code likes to make. I've said this before and I'll keep saying it, a codebase without strict types is a codebase where AI's mistakes hide longer.
Drizzle ORM earns its spot for a similar reason. Readable, close to the actual SQL, and because it's close to the metal, AI generated queries through it are easier for me to actually verify are doing what I think they're doing, compared to a heavier ORM that abstracts the query away from anything I can sanity check at a glance.
What I tried and stopped using
I went through a phase of trying to run a fully agentic coding tool on CrimsonWatch for stretches of unsupervised work, letting it handle a scoped task end to end without me watching every step. I wrote about exactly what happened when I tested that seriously, the short version is it's genuinely useful for tightly scoped tasks and genuinely risky the moment the blast radius of "confidently wrong" extends past what you're actively watching. I still use agentic tools, I just stopped treating "unsupervised for an hour" as the default mode instead of the exception.
I also dropped a couple of AI powered code review tools that plug into GitHub and leave comments on pull requests automatically. Not because the comments were wrong, they usually weren't, but because they trained me to skim instead of read, waiting for the bot to flag something instead of actually engaging with the diff myself. On a solo project like CrimsonWatch where I'm the only reviewer, outsourcing even a slice of that attention to a bot that might miss something quietly made me worse at catching what it missed.
The actual principle behind all of it
None of these tools are magic, and I think that's the healthiest way to relate to any of them at this point. The stack isn't about finding the single best tool, it's about matching the friction and cost of each tool to how often I'll use it and how much it costs me if it's wrong. Cheap and fast for the fifteen small things I do every day. Careful and deliberate for the one architectural decision that actually matters this week. Everything else is noise dressed up as a recommendation.
If you're building your own stack right now instead of copying someone else's list, that's the actual question worth asking about every tool you're considering. Not "is this the best model," but "what category of my work does this fit, and what does it cost me when it's confidently wrong."