In most discussions today, it feels like using advanced AI models has become a status signal:
higher usage, bigger bills, “Claude maxed out again”, etc.
But my experience has been a bit different.
I still primarily use a cheap model setup, and it has been enough for my workflow.
Here’s why.
1. I still consider myself the engineer
The core principle for me is simple:
The model is a tool, not the engineer.
As long as the model can:
- follow instructions
- generate decent code
- respect constraints
then it’s usable.
At the beginning, I mainly used ChatGPT web for coding because it was the most consistent option for instruction-following at the time.
Other tools existed, but they weren’t reliable enough in structured tasks.
2. Claude is good — but the limits are real
Claude is genuinely strong in many cases:
- good reasoning
- clean code generation
- strong long-context understanding
But in practice, there’s a constraint that matters a lot:
usage limits.
And once you hit that limit mid-flow, your workflow gets interrupted.
That alone changes how I evaluate tools.
3. Other models improved, but instruction-following is still inconsistent
Over time, more models started appearing — including some cheaper or open alternatives.
Some are fast. Some are cheap. Some are surprisingly capable.
But I consistently noticed a pattern:
- They say they will follow instructions
- But the actual output drifts
- They modify things I explicitly told them not to touch
- Tool usage is often simulated, not executed properly
That mismatch makes them harder to trust in structured engineering work.
4. The real requirement: predictable behavior
For my workflow, I don’t need the “smartest” model.
I need the most predictable one.
Because I usually work with:
- well-defined architecture
- strict boundaries on what should change
- clearly scoped tasks
- explicit instructions on where NOT to modify anything
In that setup, consistency matters more than raw intelligence.
Right now, tools like DeepSeek V4 / Flash via OpenCode are “good enough” for that.
They follow structure, respect context, and don’t overcomplicate changes.
5. Why I never “had to switch to Claude”
I often see developers talking about:
- hitting Claude limits
- paying high monthly bills
- relying heavily on Claude for everything
But in my case, I never reached that point.
Not because Claude is bad — it’s not.
But because:
my workflow is constrained enough that a cheaper model already satisfies the requirements.
And when the problem is well-defined, you don’t always need the most powerful tool — just the most reliable one.
6. The trade-off people miss
Yes, Claude can be better in many scenarios.
But the trade-off is simple:
- Better reasoning → higher cost + limits
- Good enough reasoning → stable + cheap + continuous usage
And for engineering work, continuity often wins.
Final thought
I don’t avoid Claude because it’s bad.
I avoid it because:
it is not the most cost-effective tool for the way I structure my work.
At the end of the day, I still believe this:
The best AI tool is the one that reliably follows your instructions — not the one that sounds the smartest.
And so far, for my use case, a cheaper model has been more than enough.
Top comments (0)