Tired of agent hype? Pick by use case.
These are my field notes from ~6 months of advising small & mid-sized startups on coding agent tooling. The question I hear most is: “which coding agent should we standardise on?”
My take (February 2026): start with your primary use case & constraints, not with “today’s best model” lists. In this post, “criteria” means your team & environment (size, maturity, compliance, local-first, provider lock-in, etc.). “Patterns” means recurring fits/misfits I have seen across tools.
My rule of thumb for picking a coding agent is simple:
Pick your primary use case. Pick one tool that fits it. Stick with it until you have a strong reason to reassess (new constraints, new state-of-the-art models, compliance, a bigger team, etc.).
If you are currently evaluating five tools at once: stop. Pick one, learn its sharp edges & align the team.
Chasing something new breaks the flow & the flow is your company pulse (I learned this the hard way). Every new thing takes time to master, learn weak & strong qualities & build shared intuition. If you chase new things for the sake of it, it becomes a never-ending saga with little real value. Assess new tools, give engineers time to play with them (they will figure it out), but lock migration decisions on the team level.
I think the most successful outcomes from those consultations surprisingly fell into the Amp & OpenCode buckets most of the time. By “outcomes” I mean engineering productivity, dev happiness & delivery outcomes. For two different reasons:
Pre-made choices remove a lot of decisions & allow you to move faster. This is the case for Amp. Unified multi-model environments & orchestration can improve morale & collaboration. This is where OpenCode shines.
If you forced me to pick quickly, here is my cheat sheet (it will age fast, but the trade-offs will not).
... continue reading