I would check PR reviews at fixed times, usually around 9 AM, 1 PM, and 4 PM. And I tried to protect two two-hour focus blocks every day.

Was that ever fully real? Not really. Something urgent always slipped through. But even a messy version of that setup helped to get things done.

And I believe that was the point behind all the old context switching talk. If you’re in the middle of a hard problem, interruptions take you out of the zone as an engineer.

If I’m tracing a bug through three services, trying to understand why something only breaks in production, or working through a design decision I still don’t trust, a random Slack ping doesn’t just “take a minute.” It breaks the flow entirely. Then I get to spend the next twenty minutes rebuilding the model in my head.

I used to describe it as being in “the zone,” and I always told people how hard it was to get back into the zone. Not to push people away, but to let people realize that each interruption had a price, and I believe this is becoming more prominent now.

What used to work

Back then, most of the interruptions came from outside the work.

• Slack
• meetings
• PR reviews
• incident noise
• somebody with a “quick question”

Part of the job, yes, but at least the source was clear.

This made me think batch processing these should help here. And in a way it did for a while, since it at least gave enough room to process both the interruptions and the work.

What changed

Currently, the old interruptions are still there, but we added a new category on top of them.

Agents.

And I don’t mean that in some dramatic anti-AI way. I use them constantly, and that’s exactly why I am writing this. I’ve been experiencing it first-hand.

If I have a few agents running in parallel, my day starts looking different fast. One is exploring the next task. One is exploring a refactor. One is looking at the latest tech updates (because who can keep up manually nowadays). Then one of them finishes. Another needs clarification. Another wants me to choose between two directions. Another comes back with a wall of questions because my prompt was missing one detail that suddenly matters a lot.

So now the interruptions don’t just come from Slack and meetings. The work itself keeps interrupting me.

That’s the part that feels different.

In the past, context switching mostly came from other people pulling you away from the task. Today, a lot of it comes from managing the task through multiple half-finished threads at the same time.

Why it feels heavier

What makes this harder for me is that it all feels productive.

Slack is obviously an interruption. A meeting is obviously an interruption. But when an agent finishes a task or asks for clarification, it doesn’t feel like an interruption in the same way. It feels like progress, and often it is progress, but sometimes it’s just another thing that wants a piece of your attention NOW.

That is how I end up with days where a lot happened, and I feel tired by the end of it. Not necessarily in a bad way, but in a different way than I am used to.

When you spend the whole day switching between sessions, reviewing outputs, answering follow-up questions, checking Slack, doing PR reviews, deploying services, and moving tickets, you realize how easy it is to forget or miss things. Not because you’re not trying your best, but mainly because of the constant focus you have to keep up.

That’s why this feels heavier to me now. The old interruptions never left. We just layered more on top.

Deep work still matters

If anything, I think it matters more now.

Agents don’t remove the need to think clearly at all. If anything, we need to think more about how we approach problems, handle evaluation, and make sure we protect our focus.

The focus is required to make sure that we understand what we’re trying to deliver, that we keep critically evaluating changes and requests, and that we break down the work effectively.

What I’m trying now

I don’t have a good solution for this yet. If you do, please feel free to share it with me. But a few things seem to help.

Breaking down your work ahead of time helps. A clear plan for the day helps. Fewer active (meaning executors that need instant feedback) agents help. Batching reviews still helps when I can get away with it, although this one is especially tricky with the current rate of change.

Mostly though, I think the big shift is just understanding that the job changed.

We didn’t make context switching disappear. We found a much more productive-looking version of it, and it’s here to stay.

Some will thrive, others will realize it might not be for them. The only thing you can do to deal with this is adapt and overcome.

The reality is that while code generation has accelerated, delivery pipelines haven’t kept pace. When test suites still take thirty minutes to run, CI pipelines are flaky, and deployments feel like defusing bombs, delivery pipelines haven’t sped up.

Consider this: Systems have been built that work when engineers are putting out 1-2 changes a day, but they break down at 5-10 changes a day. CI still takes 30 minutes per branch, everything needs merging so PRs pile up, and there is typically one deploy to staging every half hour.

This mismatch is often overlooked. Much of the process that’s been layered onto software development comes with speed trade-offs - sometimes intentional, often just organic evolution.

Now that generating code is cheap, one would expect software roadmaps to fly through delivery. But in most cases, that’s not what happens.

We expected the bottleneck to shift to trust decisions: Is this actually the right change? Does it work correctly? Can we ship it without starting a fire drill?

Yet that hasn’t been the outcome. Let’s examine why.

The Bottleneck Phase of AI Adoption

The first hard limit in review is review.

Code can be generated faster than it can be read. That’s where things get tricky.

Small change requests turn into 27-file diffs because AI tools touch nearby helpers, “simplify” abstractions that didn’t need changing, update unnecessary tests, and reformat code on the way out. None of it is obviously broken. Some of it might even be fine. But it still leaves reviewers staring at diffs they don’t have the time to read line by line.

Often, reviewers already have their own work open in three other tabs.

Reviews often become superficial. People start to just skim through changes, and they trust a green pipeline. They approve the shape of the change because tracing every consequence takes time they don’t have. This is not out of bad intention, but rather because it’s the only way to catch up.

These review cycles and safety checks exist for a reason—they protect the production environment. The goal isn’t to scrap them, but to evolve them to match the new generation speed.

That’s one of the real costs here. The goal should not only be ship faster, the goal should be ship faster without lowering quality.

The Three Stages of AI Adoption Maturity

A predictable maturation curve emerges as AI integrates into software delivery:

Stage 1: The Code Generation Boom Teams discover they can generate code faster than ever before for planning, implementation, and even initial review.

Stage 2: The Bottleneck Phase AI gets bolted onto systems that were already slower and messier than desired. Thirty-minute test suites that were tolerable before now become absolutely ridiculous in an AI loop. Changes stack up in a queue, with engineers waiting for things to move through the queue. Flaky CI now becomes even worse, as it not only impacts one change, but ten. Risky deploys create cautious behavior just when tooling is pushing to move faster.

Stage 3: The Automated Trust Phase The real wins come from investing in unsexy but critical infrastructure: fast feedback loops that don’t make you want to scream, clear boundaries so teams aren’t stepping on each other’s toes, boringly reliable deploys, documentation that doesn’t require an archaeology degree to understand, and having enough review capacity to actually keep up with the increased volume.

A flashy AI setup could help move the needle, but lasting improvement comes from evolving systems to match the new pace.

Decision Latency: The Next Bottleneck in the Maturity Curve

Another bottleneck that emerges is decision latency around process and approvals.

Changes get drafted quickly but sit for days due to additional review requests, sign-offs, unclear test plans, and unclear ownership.

This is what we mean by decision latency. The code can be done in an afternoon. The waiting takes the rest of the week.

When it’s unclear who has the final say, when every change needs three sign-offs, or when acceptance criteria only get clear near the end, AI mostly helps teams finish the code and then wait.

This highlights that this isn’t just an engineering structure problem, but more like a process problem that needs evolution alongside AI adoption.

AI rewards decomposition

This is why breaking work down clearly matters.

A sloppy task used to waste one person’s time. Now it can waste one person’s time at much higher speed while producing a lot of plausible-looking output someone has to untangle later.

When AI helps most, the task looks like this:

• break a problem into smaller steps that can actually be verified
• draft an implementation plan before touching the code
• execute a scoped change with clear constraints
• review a diff for missing edge cases or weak tests

When it helps least, the request sounds like “clean this up” or “improve the architecture” or “just take a pass at this module.”

Those aren’t real tasks. They’re a good way to get a diff nobody asked for.

Ownership matters more, not less

When code becomes cheaper to produce, the people who actually matter aren’t the ones who can type the fastest. They’re the ones who can properly scope a change, verify it thoroughly, and stand behind the decision to ship it.

This isn’t nearly as exciting as bragging about 10x productivity gains, but it’s closer to what engineering teams actually need to succeed, without reducing quality.

It doesn’t matter whether the first draft flowed from an AI model, a Stack Overflow snippet, or late-night coding. What matters is who really understood the trade-offs involved, who bothered to check the edge cases, and who’s willing to put their name on it when it hits production.

That’s why ownership becomes more critical, not less, when AI handles the initial draft. The machine can spit out options all day long, but it can’t be paged (yet) when something breaks in the middle of the night. It can’t explain why it made a particular trade-off during Friday’s incident review. It can’t look a stakeholder in the eye and say, “I’ve got this.”

What actually helps

Look, the answer isn’t to artificially slow things down for the sake of purity. The answer is fixing the system around the code.

Here’s what that looks like in practice:

First, break work down properly. Smaller tasks aren’t just easier to manage - they’re easier to generate with AI, easier to verify, easier to review, and way easier to toss out when the model starts hallucinating or going off the rails.

Second, make those feedback loops cheaper. When pumping out more code changes, tests need to be fast, CI needs to be reliable, and deploys need to be boringly predictable. If any of those are slow or flaky, they become instant bottlenecks that negate any speed gains from AI.

Third, get crystal clear on decisions. If every meaningful change requires a meeting and three layers of approval, you’re still optimized for a world where code was hard to write. AI just highlights how broken that process is to begin with.

Fourth, treat review like the bottleneck it often is, because it frequently is. If review capacity can’t keep up with the increased volume from AI assistance, you’re just creating a bigger backlog of unreviewed changes. That’s not progress, that’s just creating future problems for yourself. Make thorough reviewing a priority.

Fifth, make ownership obvious. Someone on the team should be able to look at a change and say without hesitation: “I understand this, I’ve verified it, and I’m responsible for it shipping successfully.”

And finally, when the AI tool isn’t actually helping? Stop prompting it. Seriously. Close the chat window, go back to the original problem statement, and rewrite it in simpler terms. Sometimes the best way to use AI is to not use it at all until you’ve clarified what you actually want, because if you don’t know what you want, how do you expect Claude to know what you want?

The upside of AI in software development is absolutely real. It’s a double-edged sword that can be extremely beneficial when the correct approach is taken, but it can produce significant amounts of low-quality output when the wrong approach is used.

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.