Apr 26, 2026·essay·5 min

From MATLAB to Vibe Coding

My 2026 dev stack is roughly half the size it was two years ago — and the one habit I quietly miss.

The number of tools I touch on a normal workday in 2026 is roughly half what it was two years ago.

1. How I got here

In college I wasn't really much of a coder. My MATLAB was clumsy. What I was actually good at was math, physics, and electromagnetism — the kind of work where you derive equations on paper and lean on intuition to understand a system. Most of those equations have since faded; what stuck was a habit, the "think first, then compute" way of approaching a problem.

I didn't take code seriously until 2017, the summer I finished undergrad and moved to the U.S. for a PhD. At USC was where I first wrote anything with real engineering scale. Python was the first language I actually had to debug. Somewhere along that stretch, "programming" stopped meaning "expressing equations" and started meaning "coaxing systems." The first is a one-shot intellectual exercise; the second is a long, repeated negotiation with a not-quite-transparent machine. Both are called writing code, but the kind of attention they demand is different.

From there the trajectory of the toolchain moved in only one direction: fewer keystrokes per year. Between 2017 and 2023 I wrote everything myself — learning frameworks, debugging dependency conflicts, getting environments to line up cleanly enough that the code could actually run. That was the period of really writing it. Then 2024 was the first year AI entered my workflow in any meaningful way: pasting snippets into ChatGPT, plus GitHub Copilot's inline suggestions. AI was there, but I had to go fetch it for every fragment — the subject of the workflow was still me. In 2025, Cursor brought AI into the editor itself; suggestions floated up while I typed, which removed the cost of context-switching but kept my hands on the keys. And in 2026, with Claude Code, the direction reversed completely: I describe a task, the agent runs it, and what I do becomes review rather than assembly. None of these years were the result of a deliberate plan on my part — the tooling just stepped up one tier each year, and a bigger slice of the work could be handed off.

Somewhere along that arc, ML framework details faded out of my daily attention. PyTorch versions, CUDA toolkit compatibility, the various environment conflicts and their fixes — these were never things I memorized, exactly, but I did have to align them tightly enough that the code would actually run. That alignment work was a real part of the workday. Now I barely think about it. Part of that is the agent abstracting it away, but the larger reason is that the position of my own work has moved up: from "tune this model" to "design what the agent does at the system level." The framework detail isn't something I deliberately forgot — it's been moved out of my line of sight by where the work now sits. I don't miss that environment-wrangling era at all.

2. What I touch every day

When I lay out the "what do I actually use daily" list, the set of tools I genuinely open is small. Below is the current full inventory — anything that could be merged into a single tool has been merged, and anything that didn't need to exist on its own no longer does.

  • Editor: VS Code. Same for years.
  • Terminal: VS Code's built-in. The simplest possible setup.
  • Language: Python for almost everything professional.
  • Frontend: Next.js for personal projects (this site included), but I vibe-code it — Claude does most of the typing.
  • Writing: Markdown for anything longer than a quick note. This post too.
  • AI assistant: Claude Code.
  • Cloud: Cloudflare for visitor analytics; the host is something else.
  • Notes & planning: Apple Notes for raw capture, Claude Code to organize each day's plan.

That list is shorter than I expected when I sat down to enumerate it. My default assumption had been that the toolchain would expand with the complexity of the work — but what actually happened is the opposite. Each new layer of AI capability has subsumed or merged several tools I used to assemble myself. There's no longer a thing on my desktop that I open "just for one small task"; most of those small tasks have been absorbed into a handful of core entry points.

3. Forced migration to Claude Code, then no going back

The Cursor → Claude Code switch wasn't my call. My company moved everyone over at the start of 2026. I was actually resistant — switching tool habits always carries a learning cost, and Cursor had been working well for me. But within a week the new setup had stabilized, and it became clear that this was a more profound migration than any I'd done before. It wasn't a surface-level UI change. It was a reversal in the direction of collaboration.

The distinction looks subtle but is actually total. Cursor still has me as the subject: I type, AI suggests the next line off to the side, I accept or reject, and the rhythm is set by my keystrokes. Claude Code reverses that: I describe a task and its constraints, the tool executes, and once it's done my role is to review rather than to assemble. The rhythm is set by its runs, not mine. The first model is autocomplete with a brain. The second is delegation in the real sense of the word. Who actually wrote the code is a question with very different answers in each setup.

Once delegation happens a few times, it's hard to retreat back to the autocomplete loop. I can no longer comfortably switch back to AI-in-an-IDE — the rhythm of "type a character, wait for a suggestion, decide whether to take it" feels intolerably slow next to handing off the task whole. I used to think IDE-embedded AI was the destination for the tool category. I now think of it as a stop that's been passed.

4. The habit that fell off the pace

A thinner stack isn't pure gain. What I miss most isn't a tool I removed from my workflow — it's a habit I used to keep.

I kept a handwritten daily work log for years. From a modern productivity lens this practice is inefficient: writing is slow, finding things is hard, you can't reorder pages, and once something is on the page it stays there. But the slowness was the point. The pace of handwriting forced me to think a single thing all the way through — it didn't allow mid-stream context switches or encourage running multiple threads at once. A continuous, uninterrupted, sizable block of thought was, back then, close to my default working state.

The shape of my workday now is nothing like that. I have multiple sessions, multiple documents, and multiple agent runs open simultaneously, and I have to context-switch constantly to keep all the threads from dropping on the floor. Apple Notes plus Claude Code is custom-fit for that mode — fast input, searchable, infinitely re-arrangeable. They keep up with the pace. But what they serve is a multitasking workday, not the older mode of "one long block on one thing." Slow tools can't survive in a multitasking workflow because they can't keep pace, and there isn't a clever fix for that.

If I could carve one habit back into this thinner stack, it would be the notebook.

5. What I'm watching next

I work on agent systems at MiroMind, so "agents will do more" isn't an open question for me — they will. The trajectory of the engineer's role in this industry, from "person who writes code" to "person who uses an agent" to "person who designs how agents collaborate," is already pretty clear. What I'm actually watching is a quieter question with sharper consequences: as the agent gets faster and more careful, can I still tell when it's wrong?

Reviewing agent output looks like an easier role than writing code from scratch — the agent does the labor, I gate the quality. But there's a less visible floor underneath this: to catch the agent's mistakes, you have to know slightly more than it does on the specific question at hand. That margin is shrinking, and shrinking faster every year. The progression goes from "I review the code the agent writes" to "I review the evals system the agent writes" to, eventually, "I review another agent that runs the evals system." Each step is a retreat. The judgment I still hold gets scarcer relative to the rest of the pipeline at every step, but the surface where I can still apply it directly also shrinks.

That's part of why I'm starting to look at the notebook again. The slow, single-threaded, uninterrupted thinking that handwriting demands — I used to think of it as a working style time had passed by. I now think of it as practice for judgment itself. A few years out, slowing the body down may stop being a default state and become a scarce, deliberate choice that has to be actively protected.