Fixing bugs from Slack on your phone is not engineering
What Spotify’s commute workflow reveals about the job nobody scoped
Spotify’s co-CEO Gustav Söderström told analysts in February that the company’s best developers haven’t written a single line of code since December. He described their internal system, called Honk, which uses Claude Code for remote real-time code deployment. Then he offered a concrete example:
“An engineer at Spotify on their morning commute from Slack on their cell phone can tell Claude to fix a bug or add a new feature to the iOS app. And once Claude finishes that work, the engineer then gets a new version of the app, pushed to them on Slack on their phone, so that he can then merge it to production, all before they even arrive at the office.”
This was presented as a triumph. The analyst call framed it as velocity. The coverage framed it as progress. And from a product perspective, it is: more features, faster cycles, a dataset nobody else is building.
But read the example again. Slowly this time.
An engineer. On a bus. On their phone. Telling an AI to fix a bug. Reviewing the output on a five-inch screen. Merging to production. Before they’ve had coffee, sat at a desk, or opened a codebase they can actually read.
That’s not engineering. That’s approval. And the difference matters more than most organizations have reckoned with.
The commute workflow is the purest example of the new job
I wrote a piece after this article called “They stopped building and started approving” that looked at the broader shift: engineers moving from makers to monitors, from producing code to evaluating AI-generated output. The Spotify commute workflow is the most crystallized version of that shift I’ve seen.
Strip away the enthusiasm and look at what the engineer is actually doing. They’re receiving a notification. Reading a diff on a phone. Making a judgment call about whether the generated code is correct. Merging. Moving on to the next notification.
There is zero deep work in this workflow. Zero craft. Zero flow state. Zero extended engagement with a system’s internals. The engineer isn’t diagnosing the bug. They aren’t reasoning through the fix. They aren’t testing edge cases in their head while writing the implementation. They aren’t learning anything about the codebase through the act of working in it. They’re approving.
Research on cognitive engagement and flow states shows that deep, skill-matched work produces a specific psychological state: absorption, intrinsic motivation, and the sense that time is passing differently. Csikszentmihalyi’s work on flow documented this across professions, and it maps cleanly to what engineers report about writing code. The act of building, of holding a system’s logic in your head and shaping it, is cognitively demanding but also cognitively restorative. It’s where engineers feel most like engineers.
The commute workflow eliminates all of that. Not as a tradeoff. As a design choice. The system was built to make engineering so efficient that the engineer never needs to engage deeply with the code at all.
What gets lost when the craft disappears
Söderström positioned the commute workflow as evidence that Spotify’s best engineers are more productive than ever. And by output metrics, that’s probably true. More features shipped. More bugs fixed. More velocity on the roadmap.
But output is not the only thing the old workflow produced. The act of writing code produced several things that don’t show up on a velocity chart.
It produced system understanding. An engineer who fixes a bug by reading the code, tracing the logic, and writing a patch comes away understanding the system better than they did before. An engineer who tells Claude to fix the bug and reviews the diff on their phone comes away understanding the AI’s output. Those are different kinds of knowledge, and the second one is shallower.
It produced judgment calibration. When you write code and it breaks, you learn something about the system and about your own reasoning. That feedback loop, attempt, failure, understanding, is how engineers build the judgment that makes them senior. If the AI writes the code and the engineer reviews it, the feedback loop is attenuated. The engineer learns what the AI gets wrong, but they don’t learn from their own mistakes, because they’re not making mistakes. They’re making approvals.
It produced identity. I keep returning to this across multiple pieces because it’s the cost organizations are least equipped to see. Engineers who built their professional identity around the craft of writing code just had that craft automated. The commute workflow doesn’t just change what the engineer does. It changes who the engineer is, from someone who builds to someone who approves. From a maker to a monitor. From an engineer to a quality gate.
It produced recovery. This is the finding from my earlier piece that I think matters most. The act of writing code wasn’t just production. It was the cognitive counterpart to the judgment work. Building and evaluating are different cognitive modes. Engineers naturally alternated between them throughout the day, and the building mode provided recovery from the evaluating mode. When you automate the building, you concentrate the evaluating, and you eliminate the recovery. The result is a job that’s all judgment, all the time, with no built-in mechanism for cognitive renewal.
Steve Yegge described exactly this pattern in his AI Vampire piece: the inexplicable fatigue that comes from coding with AI, the nap attacks, the sense of being drained even when the output is exceptional. His conclusion was that the new workday should be three to four hours. The Spotify commute workflow suggests the opposite trajectory: the workday starts on the bus and never really stops, because the approval function can happen anywhere, anytime, on any device.
The Spotify problem is a boundary problem
There’s a second layer to the commute workflow that I don’t see discussed anywhere in the coverage.
If your best engineers are merging to production from their phones on the bus, where does work end? The commute used to be a transition space. Not quite work, not quite personal time. A cognitive buffer between the office and the rest of your life. The Spotify workflow colonizes that buffer. It converts the commute from recovery time into approval time.
I wrote about boundaries as infrastructure: the idea that boundaries in organizations need to be structural, not just conversational. The commute workflow dissolves a structural boundary that most engineers didn’t even know they depended on. The bus ride was a boundary. Slack on your phone with production merge capability is the removal of that boundary. And the removal was presented as a feature.
This connects to something deeper in my adaptation budget piece: organizations that change the nature of work without changing the expectations around workload, availability, and recovery time are spending their people’s adaptation reserves without measuring the cost. Spotify didn’t announce that engineers are now expected to work on the bus. They announced a capability that makes working on the bus possible, and then celebrated when engineers used it. The expectation is structural even if it’s not stated.
The question nobody asked on the analyst call
Söderström told analysts that Spotify’s best engineers haven’t written code since December. Nobody on the call asked: how are those engineers doing?
Not their output. Not their velocity. Not their feature count. How are they doing? Are they sleeping well? Are they still excited about their work? Do they feel like engineers or like approval machines? Have any of them started interviewing?
These questions weren’t asked because they don’t belong on an analyst call. They belong in a one-on-one with a manager who understands that the job just changed and that the people doing the job haven’t been given a new definition of what good looks like.
I wrote about this in the context of the professor who can’t find his job description: the identity crisis that hits when a tool arrives that does a core part of your job better than you can. The professor’s version: AI explains the material more patiently and more personally than any single human can. The engineer’s version: AI writes the code faster and more consistently than any single human can.
In both cases, the question isn’t whether the tool is better at the task. It often is. The question is what happens to the person whose identity was built on being good at that task, and whether anyone in the organization is paying attention to the answer.
Signals
You’ll know the commute workflow is sustainable when engineers choose to use it rather than feeling like they’ll fall behind if they don’t. When the bus ride is sometimes for merging code and sometimes for staring out the window. When “best developers” is defined by the judgment they bring, not the volume of approvals they process. When someone at Spotify can describe what their best engineers actually do all day now, and it sounds like a job a human would want.
Fifty new features is impressive. The question is what it cost, and whether the people who produced that output are building careers they can sustain, or running a pace that looks like productivity and feels like something else entirely.
The coverage said Spotify’s best engineers haven’t written code since December. What I want to know is whether they miss it.