The hype problem

A new "best model" every two weeks. A tool every week that supposedly changes everything. Trying to keep pace with that speed mostly achieves one thing: you keep switching your setup without productivity actually improving.

My approach: evaluate new tools against clear criteria, not out of curiosity.

Three questions before every tool switch

  • Does it solve a concrete problem? Not "it's cooler," but: which specific bottleneck does it remove?
  • What's the switching cost? Integration, configuration, learning curve, team alignment. Is the effort worth the gain?
  • What's the risk? Data protection, vendor lock-in, stability. For productive workflows especially, reliability matters more than features.

Models by task

No model is optimal for everything. The relevant question isn't "which is the best model" but "which model is right for this task." That's a different question.

What helps: building task profiles. Which tasks need deep reasoning, which are fine with fast completion, which need code specialization. That gives you a map of models, not a ranking of models.

Editor vs. CLI vs. API

Three integration layers with different trade-offs:

  • Editor integration: low barrier to entry, good for inline completions and quick questions. Weaker for complex, multi-step tasks.
  • CLI agent: full filesystem access, good for complex implementations and refactors. More setup, but noticeably more control.
  • API directly: maximum control, for your own workflows and automation. Requires engineering effort, but gives the most flexibility.

Team context beats personal preference

What's optimal for me isn't necessarily optimal for the team. A tool only one person knows well creates dependency. A tool anchored in the team creates capacity.

Especially with agent workflows: what isn't documented doesn't exist for the team. The best personal solution that nobody else understands is, for the team, a worse solution than a mediocre one everyone can use.

Stability over features

In productive setups, stability matters more than a feature lead. A tool that works reliably beats one that can do more but breaks often. That's especially true for workflows I run overnight or that are wired into production systems.

Testing new features: yes. Putting new features into production workflows: only after a few weeks of stable use.