Software builders sit. That was the deal — deep work in exchange for the back, the wrist, and the long body cost of being good at our job. Autonomous agents broke the deal. The keyboard is no longer the only place the work happens, and the cap on how much I can ship in a day is now set by my walking pace, not by my tooling.
This is not a story about productivity. It is a story about the shape of the workflow changing.
The walk-loop, in operating detail
About a year ago, Cognition's Devin caught my attention. Like a lot of engineers, I do my best thinking on walks. I would be deep into a problem, get a flash of an idea about a nasty UI bug or a missing feature, and have nowhere to put it except a half-written note. By the time I got back to a keyboard, half the thought was gone.
Devin changed that. The mobile app meant I could pull off the path, describe the idea out loud — full context, what I was trying to do, what I had already ruled out — fire off a session, and resume walking.
What happened next was the part I did not expect.
A notification would land in my inbox: Devin was done planning. I would skim it, approve or redirect, and ask it to complete the task. By the time I hit my next milestone, another notification: a finished feature, with screenshots, a Mermaid diagram of what changed, and a PR ready for me to review. Almost every time, I would accept the work.
Then I started running two sessions in parallel. Then three. Then four. At four, I hit a real ceiling — not from the tool, but from the walking pace. Devin returned finished work faster than I could reach the next milestone where I could review it. The bottleneck moved from the tool to me.
Operating reality: the parallelism cap on autonomous-agent engineering is set by your reviewer-bandwidth, not by your seat license. The body, the calendar, and the walk pace are all part of the throughput equation now.
A year later this is no longer novel. The same loop runs today on Anthropic's Claude Code remote sessions. The interface is different, the model is different, but the operating shape is the same: think on the walk, dispatch from the phone, review when you get there.
What stops being the binding constraint
The keyboard-time constraint is the one most engineering orgs are still measuring. Hours in chair. Lines of code. Velocity points per sprint. Those numbers do not describe what is happening here.
In the walk-loop, the binding constraints are different:
- Reviewer bandwidth. How fast can a human read a plan, a diff, a screenshot, and decide?
- Ambient thinking. How many real thoughts can the engineer generate while moving? More than you would expect, once the keyboard is no longer in the way.
- Specification clarity. A bad description on the path produces a bad PR an hour later. The cost of vagueness moved upstream.
- Trust in the agent. "Almost every time, I would accept the work" only happens after the agent has earned the benefit of the doubt. Below that threshold, you spend the walk worrying instead of thinking.
Notice none of those are about typing.
"Faster" is the wrong word
The temptation is to call this faster engineering. It is not. It is differently-shaped engineering. The same hour produces a different artifact: more reviewed plans, fewer hand-typed lines, more decisions made in motion, fewer made in the chair. If you measure by lines-per-hour, the new shape will look worse. If you measure by features-shipped-per-walk, you have to invent a new metric.
This is what the operating reality of a Q4 engineering shop actually looks like — to borrow the framing from The Faster-Horse Trap in AI Adoption. The faster horse here would be making the chair more comfortable, the IDE faster, the keyboard nicer. The automobile is leaving the chair behind.
The deeper lesson: when the workflow shape changes, the metrics that used to measure it stop measuring it. Keep measuring the old metric and you will conclude that nothing happened.
What it asks of the engineer, and the org
For the engineer, the asks are different than the ones the chair asked. Walk three to five miles a day or do not. Build the discipline of describing intent cleanly, in voice, in motion. Trust the agent enough to let it work, and stay close enough to catch it when it drifts. Recover the back, the wrist, the cardiovascular system that the previous shape of the work was quietly costing you.
For the org, the asks are bigger. Stop counting keyboard-time. Build review queues that match the new throughput. Re-imagine on-call, code review SLAs, and pair-programming when one of the pair is in the cloud and the other is on a sidewalk. The agent is not a faster developer; it is a different organizational primitive. The org chart that worked when "engineer" meant "person at desk" will not survive contact with "engineer" meaning "person walking, with four sessions running."
What I am watching next
Two open questions, both worth a future post.
The first is whether the parallelism cap of four — which feels real to me — is actually a property of the human reviewer or of the tools' notification cadence. If a future tool batched returns into a single review burst at the end of a walk, would the cap rise? My guess is yes, but only up to the point where reviewer fatigue takes over.
The second is whether the same loop works for non-engineering knowledge work. Drafting, research, design, customer-research synthesis — all have the same "I think best in motion, then I have to sit down to capture it" structure. The walk-loop should generalize. I have not yet seen a tool that runs the loop as cleanly outside the IDE as Devin and Claude Code run it inside.
Until then, the practical advice is small and concrete: stop optimizing the chair. The chair is the old shape. Walk-time is now build-time. The body of the engineer is part of the operating model.
