Over the past year, AI changed my workflow faster than anything else in engineering. Every few months there was a new editor to try, a new model to test, or a new agent worth taking seriously. Useful, yes. Also tiring.
What I took from that was simple: stop rebuilding your workflow around the current winner. I care more about having a setup that survives outages, pricing changes, and vendor churn than I do about squeezing out the absolute best capability this week.
So this post is not really about moving from Cursor to Claude Code to OpenCode. That is just the timeline. The whole point is that flexibility matters more than peak capability.
The tipping point
I started using Cursor seriously around March or April 2025.
At first it helped with the obvious stuff. Moving between files faster. Cleaning up code. Refactoring without losing momentum. It made me quicker, but it did not change how I thought about development yet.
That changed a few months later when the first Opus model got good enough for real development work. I think it was 4 or 4.1. AI tooling stopped feeling like autocomplete on steroids and started feeling like something that could move real work forward.
I still dislike the 10x talk around this stuff. For me it was more like 1.1x or 1.2x on a good day. Still meaningful, because no one dislikes writing boilerplate more than me.
After that, AI was no longer the question. The question was how I could rebuild my workflow around it.
Back in the terminal
Later that year, Claude Code got good enough that I could bring that leverage back into the terminal.
That mattered because the terminal is where I actually want to work. I have spent years turning it into the fastest place for me to think. Hundreds of commands. A lot of Neovim muscle memory. Outside pair programming, because I do not want to force Neovim on other people, and the occasional Git diff in VS Code, that is home base.
Claude Code was the first time I got that kind of leverage without having to leave the terminal. I was not trading leverage for comfort anymore.
So the question changed. If the environment finally felt right, what was actually worth optimizing around it?
The workflow became part of the job
From there I started spending a couple of hours a week improving the workflow itself.
Not using it. Improving it.
I tested tools, changed prompts, added skills, cleaned up context, and got more deliberate about where expensive models were actually worth paying for.
That work mattered more than any single model release. The real gain came from building a setup that kept working even while the tools kept moving.
That is when OpenCode started making a lot of sense to me.
Why OpenCode mattered
I do not use OpenCode because it beats every native tool at everything. It does not. Native tools often have an edge.
I use it because it lets me keep my workflow and swap the model layer underneath it more easily. That matters a lot to me.
I do not want to explain to a client that my setup fell apart because one provider had a rough day. I do not want to rebuild my habits every time pricing changes or the leaderboard shuffles.
If your workflow only works when one company is cheap, online, and still winning, that is not much of a workflow. It is a single point of failure.
I use these tools for hours every day. Reliability matters more to me than squeezing out the last bit of capability.
Not every task needs the best model
It also changed how I pick models for different jobs.
Some work really does need the strongest model. Architecture trade-offs. Messy refactors. Unfamiliar systems. Pay for intelligence there.
But a lot of tasks are much smaller than that. Rename this. Move that. Update the tests. Clean up some typing. I am not paying top-tier model prices for chores if I do not have to.
That is partly about cost, sure. It is also about not getting lazy. If the strongest model is always one keystroke away, it gets very easy to stop thinking earlier than you should.
The setup grew out of that.
The setup itself
The setup is honestly boring.
I keep the defaults in my dotfiles: shared AGENTS.md, workflow instructions, and skills that I symlink into the tools I use.
Claude looks for skills in .claude/skills. OpenCode looks in .opencode/skills. I do not want copies of the same setup scattered across repos, so I keep one version and link it where needed. That way both tools behave the same on both my Macs.
Then I add a repo-level AGENTS.md with only the local context that matters for that project. That gives the agent enough to work with without me repeating myself or waiting for a full repo scan.
The actual work happens in Git worktrees. Usually one task per branch, one agent session per worktree.
I am not trying to build the cleverest system here. I want something I can inspect, debug, and change without drama.
That is another reason the terminal still wins for me. My prompt tells me where I am. tmux makes it easy to hop between sessions. Worktrees map cleanly to tasks. Nothing is hidden behind a glossy interface that stops being cute the moment something breaks.
Final thought
I am not telling anyone to move to the terminal. Use whatever environment helps you think clearly.
But if AI is going to sit in the middle of your daily workflow, build for resilience first and keep enough flexibility to pick the right model for the job. Capability still matters. I just do not want everything else depending on it.
A workflow is only really yours when it survives the tool you built it around.
Top comments (0)