I became a billionaire today.
Not in the currency I expected - but I'll take it. Cursor's "Year in Review" told me I went through 2.42 billion tokens. The number isn't the point. The point is what it signals: over the past year, AI went from something you tried occasionally to something that's effectively running alongside you all day. The jump wasn't linear. It was stepwise - quiet for a while, then suddenly continuous.
What surprised me most wasn't that models got better at code. It was how quickly that improvement changed what "doing the work" even feels like.
The center of gravity has moved
In a lot of everyday engineering tasks, the model now implements faster than many humans can. Sometimes it also implements cleaner than you'd expect, especially when the problem is well-framed and the constraints are explicit. That doesn't mean engineering is turning into prompt typing. It means the job is reorganizing itself around a different bottleneck.
For years, "writing code" was the visible core of the craft. You'd hold a mental model of the system, make design choices, and then spend hours translating those choices into implementation. That translation step used to be heavy: keeping all the pivots, workarounds, and edge cases in your head while you shaped classes and glue code into something that compiled and didn't break production.
Now a big part of that translation work can be offloaded. And when that happens, the work shifts upward. The time that actually matters goes into defining the problem precisely, designing a workable approach that fits the system, and then doing the unglamorous but decisive part: testing, verification, and integration. You spend more energy asking "what should this be?" and "how do we know it's right?" than "how do I type this fastest?"
That shift is subtle until you feel it in your daily flow. Then it becomes impossible to unsee.
Context switching is back - and it's not a moral failure
There's an effect many developers dislike: context switching returns.
The old story in software is that good engineers disappear into a single context for hours. Deep work became a virtue, and switching became a symptom - of distraction, poor planning, weak discipline, or bad culture. That story wasn't wrong; it was optimized for a world where humans were the fastest part of the pipeline.
But when AI is actively implementing, "staying in the same context" can become strangely expensive. If you're sitting there waiting for the model to churn through files, refactor boilerplate, generate tests, or draft integration code, you're not doing deep work. You're just… waiting. And in a world where the machine can produce iterations quickly, waiting is a premium form of doing nothing.
So switching comes back, but in a different shape. You delegate a chunk of implementation and then you move - not away from the work, but into a different part of the work. You review something else. You refine requirements. You tackle another thread. You think about risks, observability, data migrations, edge cases, and what "done" actually means.
What changes is not that you switch more. What changes is that switching becomes the default rhythm of a directed workflow.
The real dividing line: switching into value vs. switching into noise
In this new loop, the senior/junior gap doesn't disappear. If anything, it becomes more obvious.
When implementation is abundant, what differentiates people is judgment and prioritization. Some context switches move outcomes forward; others are just convenient escapes. The difference isn't whether you switch - almost everyone will. The difference is where you go when you do.
If you treat those gaps - while the model is working - as an invitation to drift into distraction, you'll feel busy without moving much. If you treat them as an opportunity to strengthen the work from another angle, you start shipping with fewer surprises. You tighten the spec. You add the missing test that prevents a regression. You verify security assumptions. You document the tricky decision while it's still fresh. You line up the next set of prompts so the model's next iteration is sharper, not broader.
Over time, that habit compounds. You end up with less "implementation fog" in your head and more clarity about what matters. The feature becomes lighter to carry because the model is hauling more of the low-level weight - while you keep the system coherent.
What people call "vibe coding," and what it actually is
"Vibe coding" is a funny term, but it points at something real: building by intent and iteration, with the model doing a large share of the typing. The danger is that the phrase makes it sound like you're improvising without rigor - like vibes are the replacement for engineering.
In practice, the healthy version looks less like improvisation and more like direction. You describe the goal, the constraints, and the interfaces. You let the model draft. Then you do what matters: validate, test, verify, and integrate. You're not "coding less." You're moving the effort into the parts that decide whether the code is correct, safe, and maintainable.
The "vibes" aren't the point. The loop is.
The opposite view deserves real respect
There is a strong opposing view, and it's not just nostalgia.
Complex systems still demand deep understanding, sustained reasoning, and careful design. AI can generate code that looks right and even passes basic tests, while hiding subtle failures - security gaps, performance cliffs, race conditions, broken invariants, or assumptions that won't hold under real traffic. If you let speed replace comprehension, you can end up with a codebase that is "delivered" but not truly owned by anyone.
There's also a human risk: if people outsource too much, they may stop building intuition. And when production misbehaves, intuition matters. A team that can't reason about its own system is a team that will suffer when the bill arrives.
In regulated environments, safety-critical systems, or domains where mistakes are expensive and hard to detect, the counter-argument becomes even stronger. In those contexts, slower, more human-driven approaches can be not only preferable but necessary. The discipline of deep work remains a competitive advantage when correctness is the product.
That world exists - and in some corners, it will win.
Why the vibe-coding path is still the more probable future
Even acknowledging all of that, I think the "vibe coding" path - or more accurately, the directed, AI-assisted iteration path - is more likely to become the default in most software organizations. Not because it is always better in an absolute sense, but because it aligns with incentives and with how tools evolve.
First, speed compounds. Organizations are under pressure to deliver, and workflows that reliably shorten cycle time spread quickly. The teams that learn to delegate implementation while increasing verification will outpace teams that keep the old labor split. Not everywhere, not always - but enough to set the norm.
Second, the bottleneck has moved upstream. The scarce skill is increasingly not producing code, but producing clarity: defining the right problem, choosing the right constraints, shaping interfaces, and knowing what "good" looks like. That naturally pushes engineers into a loop where you spend less time typing and more time directing and evaluating. When your value is judgment, it makes sense to keep multiple threads alive and to move between them as the machine produces drafts.
Third, the cost of verification is actively shrinking. The best critique of vibe coding is that verification becomes a burden. But the industry is already investing heavily in reducing that burden through better test generation, better static analysis, better security tooling, stronger CI feedback, and smarter review assistance. As those guardrails improve, the most painful part of AI-assisted building gets cheaper. That makes the workflow more stable - and therefore more adoptable.
Finally, humans adapt to leverage. Even engineers who dislike context switching will use a loop that makes them feel effective. Once you experience the ability to move two or three tasks forward while the model implements a fourth, it's difficult to return to a mode where everything waits on your keystrokes.
Over time, the sloppy version of vibe coding will get punished - by outages, security incidents, and maintenance pain. The professional version will remain, and it will look less like "vibes" and more like a mature practice: small steps, crisp constraints, heavy verification, careful integration, and real ownership.
What this means in day-to-day work
The practical conclusion isn't "switch more" or "let AI do everything." It's that engineering becomes more like managing parallel workstreams, where your job is to keep the system coherent while the machine accelerates the drafting.
Context switching returns, but not as chaos. It returns as a normal part of a loop where you define, delegate, verify, and integrate - again and again.
So the question "who likes context switching?" might be the wrong question. The more useful one is: can you switch into the parts of the process that actually increase quality?
In a world where implementation is abundant, rigor becomes the craft. And the engineers who thrive won't be the ones who can stare at a single file for six hours. They'll be the ones who can hold intent steady, steer the machine, and still ship software that is safe, maintainable, and real.