In April 2000, Joel Spolsky wrote an essay complaining about a magazine article that advised startups to use open plan offices, skip the free coffee, and save money on build-outs.
Joel's argument was devastating. He pointed out that programmers need flow. That getting into the zone takes fifteen minutes. That a one-minute interruption from a colleague costs thirty minutes of real productivity. He did the algebra: put two programmers in adjacent cubicles, and the one who asks a quick question saves himself fifteen seconds but costs his neighbour fifteen minutes.
Give them private offices with doors, Joel said, and the economics reverse. The programmer who would have asked a quick question will instead spend thirty seconds looking it up. Net saving: fourteen minutes and thirty seconds.
It was brilliant. It was correct. And it was built on an assumption that no longer holds.
Joel's entire argument rested on one thing: that a programmer's productivity depends on holding a lot of little details in short-term memory.
Local variable names. The state of a search algorithm halfway through implementation. Which file you were editing and why. The shape of the data structure you were building. All of it, balanced precariously in your head, ready to crash down the moment someone tapped you on the shoulder.
This was true. For twenty-five years, it was obviously, painfully true. Every programmer knew the feeling of being interrupted and watching their mental model dissolve. The fifteen-minute recovery time wasn't an exaggeration. Sometimes it was worse.
But here's the thing about assumptions: when the underlying reality changes, the conclusions built on top of them stop working. Even the good ones. Even Joel's.
I don't hold code in my head anymore.
Not because I've become lazy or less capable. Because there's no reason to. The AI holds it for me. It knows the local variable names. It knows which file I was editing. It knows the state of the algorithm, the shape of the data structure, the thing I was trying to do before I got interrupted.
When I come back after an interruption — a call, a coffee, a different project entirely — I don't spend fifteen minutes rebuilding a mental model. I spend thirty seconds asking "where were we?" and the agent tells me. Often better than I could have reconstructed it myself, because it doesn't forget things or confuse what I was doing on this project with what I was doing on the other one.
The costly part of an interruption used to be rebuilding context. That cost has collapsed.
But something else happened that Joel didn't predict, because it didn't exist yet.
I don't read code the way I used to.
I used to read code the way you read a novel — linearly, carefully, building understanding line by line. I'd open a file, start at the top, and work my way through it until I understood what it did. When reviewing someone else's code, I'd read every line of the diff, holding the before and after states in my head simultaneously.
I don't do that anymore. Almost nobody does, though not everyone admits it.
Now I describe what I want and the agent writes it. I review the output, but I'm not reading it line by line. I'm scanning it the way an architect scans a building — checking the structure, the proportions, the things that feel wrong. I'm asking "does this do what I intended?" not "what does line 47 do?"
When I need to understand existing code, I don't read it. I ask about it. "What does this function do?" "Why is this check here?" "What happens if this value is null?" The answers come back in natural language, faster and more accurately than I could have extracted them from the source.
The code is still there. It still matters. But my relationship with it has fundamentally changed. I've gone from reading it to interrogating it.
Joel was right that flow matters. He was right that deep concentration produces the best work. He was right that interruptions are expensive.
But the flow state has moved.
It used to be: hold the code in your head, manipulate it mentally, translate your mental model into keystrokes. The flow was about maintaining a fragile tower of implementation details.
Now it's: hold the product problem in your head, make design decisions, direct the agent, evaluate the output. The flow is about maintaining a clear picture of what you're trying to achieve and why.
This is a different kind of concentration. Less fragile, actually. When someone interrupts me now, I don't lose the variable names — the AI has those. What I might lose is the thread of a design decision, the "why" behind a choice I was about to make. But that's more resilient than implementation details. I can usually pick it up again in a minute or two, not fifteen.
The flow I protect now isn't "don't make me lose my mental model of the code." It's "don't make me lose my train of thought about the product."
So does this mean Joel was wrong about private offices?
No. But the reason for them has changed.
You still need space to think. You still need quiet. Interruptions still cost something. But the cost has dropped dramatically, because the thing that was most expensive to rebuild — the mental model of the code — is now held externally.
The irony is that the open plan office might actually be less damaging now than it was in 2000, precisely because the thing it destroyed — concentration on implementation details — is no longer the primary mode of work.
I'm not advocating for open plan offices. I still prefer a door. But the argument for that door is different now. It's not "I'll lose fifteen minutes of productivity." It's "I need space to think clearly about what to build and why."
That's a weaker argument, honestly. Harder to quantify. Harder to win a budget fight with. Joel's algebra was elegant because the numbers were stark. The new algebra is muddier.
Let's redo Joel's thought experiment for 2026.
Mutt can't remember how the authentication middleware works. In 2000, he'd either look it up (thirty seconds of reading code) or ask Jeff (fifteen seconds, but costing Jeff fifteen minutes of lost flow).
In 2026, Mutt asks the agent. Two seconds. Jeff is not interrupted. Mutt doesn't read the code. The agent explains it in plain English, Mutt gets his answer, and both programmers continue without breaking stride.
The entire category of interruption that Joel built his argument around — "I need to know something that's in someone else's head or in the code" — has been largely eliminated. Not by office layout. By tooling.
I'd be lying if I said nothing was lost.
There was something valuable about reading code carefully. About building a deep, line-by-line understanding of a system. About the kind of knowledge that only comes from having personally traced the execution path through every edge case.
When you interrogate code through an AI instead of reading it directly, you understand it differently. More efficiently, probably. But less deeply. You know what it does without knowing how it feels. You can describe the system without having lived in it.
This matters less often than you'd think. But when it matters, it matters a lot. The bugs that come from not-quite-understanding are the worst kind — the ones where everything looks right but something is subtly, invisibly wrong.
Joel's programmer with a head full of implementation details would have caught those bugs. The programmer who asks the agent "does this look right?" sometimes won't.
Joel's essay was about a magazine columnist giving bad advice about office space. But the deeper point was about respecting the nature of the work — understanding that programming requires a specific kind of concentration, and that anything which disrupts that concentration has a real, measurable cost.
That deeper point still holds. The work still requires concentration. It still requires protecting the conditions that allow good thinking.
But the nature of the concentration has changed. The thing in your head isn't the code anymore. It's the intent. The design. The product. The "why."
And the cost of interruption, while still real, is a fraction of what it was. Because the most expensive thing to rebuild — the mental model of the implementation — is no longer in your head.
It's in the machine. Where, honestly, it probably always belonged.