It’s the opposite of being interrupted because the agent holds the state.

I’ve spent hours staring at a completely black screen, unable to figure out why my graphics code won’t render a single pixel. I’ve spent hours puzzling over C++ compilation errors, wading through obtuse template expansions. I’ve spent hours stepping through code in a debugger, sweating bullets over accidentally clicking “step over” when I meant “step into”. And in 2026 I spent two months authoring 500 PRs with Claude Code, ranging from one-liners to huge refactors, which combined would have taken me over a year to do by hand.

Movie Chain

The idea of a movie-related website was born from my pastime of watching directors’ entire filmographies while walking uphill on the treadmill. As I worked my way through every movie by a single director I admired, I wondered what a movie website would look like if it were designed in 2026.

Two months later I launched movie-chain.com. Written entirely with Claude Code, nothing by hand, the interface makes it easy and engaging to make a “chain” between stars and their movies by simply dragging images, like playing Six Degrees of Kevin Bacon graphically.

In the screenshot above we started with Quentin Tarantino’s movies in Column 1, then put the cast of Once Upon a Time in Hollywood in Column 2, then Brad Pitt’s entire filmography in Column 3. This requried only two drag-n-drops. One Movie Chain user declared “the fluidity makes browsing feel like an experience rather than a chore” and another wrote “Holy crap, I love this, I do this in IMDb all the time”.

The Simul

Walt Whitman wrote, “I am large, I contain multitudes.” While I’ve primarily identified as a programmer, like many programmers I’ve also done design, testing, and architecture. I’ve been a team leader, a mentor, and an informal manager. I’ve had input on product decisions and pontificated on business strategy. However, I was surprised to learn, when Claude Code relieved me of the burden of grinding out line after line, that these other personalities were far more developed than I realized, and at times they sang.

It took a few months of working with agentic tools to be comfortable with them. I think people feel if the input to something is English, it should be immediately intuitive. But English is combinatorial and unconstrained. While you can type anything, some approaches work much better than others. Eventually I got the hang of it, and started steering not just one Claude Code agent, but three to five of them.

Sitting idle while one agent beavered away was dead time; running several agents eliminated it. The act of switching to a new agent was viscerally satisfying, knowing the previous one was doing useful work in the background, like heading out to lunch while downloading a large file. Often what took the most time were non-coding tasks. Claude wrote ad hoc SQL queries to explore my data, set up my Fly.io account using only the fly CLI, and put me to shame wielding Linux tools like sed. Finally I used Claude to research and assemble featured movie boards, like the “highest rated movies of 2025”.

I’d dabbled with voice input in the past, but this time it stuck. Voice saved wear and tear on my hands, but was also a lot faster. I used the additional time to explain things to Claude more fully, or even meander if I was unsure exactly what I wanted. So there I was in my home office, late afternoon sun streaming in, talking to five artificial intelligences in plain English.

Rapidly cycling between five tasks sounds like it violates the classic programmer rule: one interruption can cost hours of productivity. But tending to multiple Claude Code agents felt like the exact opposite of being constantly interrupted. It felt more like the Netflix series The Queen’s Gambit, when Beth Harmon plays a “simul” against the entire chess club. She calmly steps from board to board, making one move at a time.

When programming by hand, you patiently build up a mental representation of both the problem and your solution. This is why an interruption can be so devastating: the mental models can outright collapse. It’s also one reason programmers are known for working late into the night, fearing sleep will wipe away that state and force them to start anew the next day. With Claude I had no such fear. Like a chess board in a simul, the state was always there waiting for me. I could walk away for an hour, or even days, and when I returned ask Claude to explain exactly where we left off. Having it hold the state instead of me changed everything.

Working with agents was never stressful or frantic. It was engaging and even addictive. You stay in flow making an endless series of decisions, but most of the decisions are small and quick. If a demanding choice does come up, you can take as much time as you need, since no human is waiting on you.

How much I cared about the specifics of the generated code varied wildly. I often didn’t even glance at a thousand lines of new code, because it had no architectural implications and I knew it could easily be replaced. Other times I would dig into micro-decisions Claude made, critiquing it harshly, holding its hand through a dozen refactors I felt were necessary to bring the codebase back to order. I found that ignoring the code entirely, as some vibe coders do, was not viable for a large complex system.

The Hard Parts

Ward Cunningham’s “technical debt” is a wonderful phrase because there is so damn much of it in software. Agentic coding flipped the table on how I managed technical debt. Yes, agents can generate technical debt at alarming speeds, but they can also pay it down head-spinningly fast. They are excellent at refactoring; they are gifted at manipulating the code while preserving externally visible behavior. Because of this, many more internal decisions are two-way doors, decisions that can more easily be reversed, and you don’t have to feel bad asking Claude to throw something out and start over, even if it’s the fourth time. When I switched graphics engines to PixiJS, Claude managed the swap with a single PR, doing something that would have taken me days of research, experimentation, and implementation.

I was empathetic to Claude’s attempts to satisfy my requests. If Claude struggled to implement something, whether taking too long or repeatedly causing bugs, I noticed and stopped it. I’d often revert its partial work. Claude loves screenshots, and these can make requests much more concrete than just a salad of words. Several times I recorded video of Movie Chain, and played it back frame-by-frame, showing Claude exactly where a rendering glitch was.

The word “taste” can seem pretentious, but the human’s ability to discern the difference between two potential approaches is essential. This can be UI/UX taste or taste about the internals: software engineering aesthetics. You should develop an immediate, almost unconscious reaction to what you’re seeing. Claude is trained on “everything”, but you aren’t writing everything, you’re writing something very specific. For example, I used my experience as a gamedev to nudge Claude to keep the app running at 60Hz even while paging through thousands of images.

A particularly painful experience with Claude happened when I was working on an image layout algorithm. No matter how many times I tried, I could not get it to satisfy my requirements of placing the movie posters chronologically while keeping them vertically compact. I finally whipped out my spiral graph-paper notebook and tried to write the algorithm myself. After an hour I realized what I was asking for was in fact impossible. There were conflicting constraints and no way to satisfy them, without moving to a very different approach.

The real solution required first deducing that there was no solution, and Claude couldn’t do that. This taught me to avoid asking Claude to implement things unless I had some idea how I would do it myself. People make fun of vibe coders for spending hours “arguing with their AI”. I tried to never do that; if it failed to implement something I’d revert, re-assess, and subdivide the problem into more doable steps. Because I was willing to recursively subdivide any task Claude struggled with, I found I could almost always bite-size my way into a working solution.

Agents excel on greenfield projects, which leads to a great first impression, but as the code grows in size and complexity, performance can degrade. I suspect people online complaining that “the model has gotten a lot dumber recently” are often just experiencing the agent struggle as their codebase grows in size and complexity.

One specific gotcha is parallel systems: two places in the code which implement the same functionality. Agents only have partial context, so like an airline pilot maintaining two families, they will sometimes construct the same feature in two places. I discovered these issues after witnessing Claude have to fix the same bug twice, which wasn’t like it. But once I identified the problem, Claude enthusiastically combined the two systems in a single PR.

The Future

I’ve grown to love this current era of agentic coding, but given the rate AI models and agentic tools are evolving, it’s clearly ephemeral. We are starting to see impressive software systems built by people who have never coded: doctors, architects, and plumbers. This trend will compound rapidly. What happens to software engineers when everyone can create software, when the tools are so good they do everything I, as the human, was doing for Claude these last few months?

Before VisiCalc launched in 1979, there were very few electronic spreadsheets in the world. Today there are billions. These spreadsheets exhibit the same wide dynamic range you find elsewhere in software, from a three-line shopping list to spreadsheets backed by millions of lines of OCaml. In the future this dynamic range will only grow. Millions of people will build personal software for themselves and their families, but humans will also tackle globe-spanning engineering problems, which will require extreme discipline and won’t be captained by weekend warriors.

Building out this diversity of systems will require a vast range of skills and personalities. Software engineering won’t go away, but instead move to ever higher levels of abstraction, allowing the volume of software produced to expand as the individual developer becomes more productive.

So build with agents to discover and cultivate your strengths, including the ones you didn’t know you had. I realized that I had more diversity and depth of skills than I knew about, and I hope that many people will come to the same conclusion. We need a multitude of strong players to win the many high-stakes games ahead of us.