For most of my career, writing the code was the part that ate the day.
Not the thinking. Not the design. The typing, the wiring, the forty minutes spent remembering how that one build tool wants its configuration. You would start the week with a clear idea of what needed to exist and end it having produced maybe sixty percent of it, because implementation is slow and unforgiving and full of small detours nobody estimates.
And the whole time, a second list was growing quietly in the background. The article someone posted in the team channel. The conference talk with 200,000 views that everyone referenced and you never watched. The new book, Thinking in Platforms, on the shelf, spine uncracked. The vague intention to actually understand how the programming language you write every day handles closures, or memory, or scheduling - not the usage, the mechanics.
That list never got shorter. There was always a ticket, a bug or a next feature. The saw stayed blunt because there was always more wood.
The constraint moved and we barely noticed
Then AI got good at the typing.
Not at deciding what to build or at predicting whether an abstraction will survive the next three features. But for the mechanical production of code - the part that used to be the bottleneck - it is genuinely fast, and Claude Code and Codex do not tire at four in the afternoon.
Which means, for the first time in twenty five years, a lot of us have hours back. Real ones.
And here is what most of us did with them.
We filled the gap with more of the same
The obvious move, once one agent is working, is to start a second one. Then a third. Five terminals, five branches, five tasks in flight, you tabbing between them like an air traffic controller who has had too much coffee.
It feels enormously productive. It looks like leverage.
But watch what actually happens over a day of it. Your throughput does not scale linearly with the number of jobs, because you are now the integration point. Every one of those branches needs reviewing, and reviewing is the expensive cognitive work, not the writing. You context-switch every few minutes, which costs more than the switches save. Two of the five turn out to be solving the wrong problem, which you would have caught in ten seconds if you had been paying attention when you wrote the prompt instead of half-watching another terminal.
Mostly, though, running five agents is a way of spending your newly freed time on exactly the same activity as before. We got handed a gift of time and immediately converted it back into implementation volume, because implementation volume is what we have always measured ourselves by.
What the time is actually for
The reason to spend it learning is not self-improvement in the vitamins-and-jogging sense. It is that the skill AI has not replaced is precisely the one that depth produces.
An agent will confidently hand you something that compiles, passes the tests you thought to ask for, and is wrong in a way you will find out about in production in five weeks. The only defence is that you know enough to feel the wrongness. That feeling is not a personality trait. It comes from having read the article about that failure mode, having once taken apart how the runtime actually schedules work, having tried the thing in a toy project and watched it fall over.
The better AI gets at producing options, the more the job becomes choosing between them. Choosing well requires knowing the option space - which is reading. And the person who has read widely also asks for better things in the first place, which is where most of the quality gets decided anyway.
So, concretely, what I would spend the reclaimed hours on:
-
The backlog. The saved articles, the bookmarked talks, the paper that keeps getting cited. Not skimmed at 11pm. Read properly, in daylight, as work.
-
Behind the scenes. Pick one construct you use constantly and go one level down. How does the garbage collector decide? What does the compiler do with that generic? Why is this API shaped like this? Usage knowledge plateaus. Mechanical knowledge compounds.
-
The tool you keep hearing about. Install it. Give it two hours and a real problem, not a tutorial. Most of the time you will conclude it is not for you, and that conclusion is itself worth having when the next architecture discussion happens.
-
Deliberate experiments. A spike with no ticket attached. Rebuild something small a different way to find out what the trade-off actually feels like rather than what the blog post claims.
-
Your own field. The rate of change is not going to slow down. Time spent keeping up is no longer a luxury you fund out of evenings and weekends. It is now affordable during working hours, which is new, and worth defending.
The honest counterpoint
Sometimes five parallel jobs is the right call. There are weeks with a hard deadline and a known scope, where the work genuinely is mechanical and volume is genuinely the answer. I am not arguing for a monastery.
The argument is against it being the default. Parallelism should be a decision you make for a reason, not the thing that happens automatically because idle hands feel uncomfortable and starting another agent is the easiest way to make the discomfort stop.
There is also a version of this that goes wrong in the other direction - reading as procrastination, tabs as a hobby, learning that never touches anything you ship. The test is simple enough: did what you read change something you did, argued for, or rejected in the following month? If not, you were entertaining yourself.
The part I keep coming back to
We spent years saying we had no time to sharpen the saw because we were too busy sawing. That excuse has expired.
The sawing is mostly handled. What remains is knowing where to saw, which depends on how sharp you are. Developers who emerge ahead won't be those who ran the most agents in parallel but those who finally read the backlog.