There’s a particular kind of pride in being able to approve a pull request from a phone. Or to review a build status while away from the desk. Or to check whether an overnight agent run completed successfully, without opening a laptop. It feels like progress, a loosening of the traditional tether between knowledge work and a specific physical setup. And in one sense, it is.
But mobile work is more interesting as a diagnostic than as an achievement. The things you can actually do from a phone tell you something important about the nature of that work. And the things you can’t, whether you’ve tried or not, tell you something equally important. The boundary between them traces the line between supervision and execution, which is one of the central lines being redrawn in contemporary software development.
What a phone allows
When I think through the work I’ve done from a phone, the pattern is consistent. I approved a deployment after someone sent a build notification. I reviewed a short pull request and left a comment. I checked whether an agent run had surfaced any blockers. I read through a drafted spec to give a quick sense check before a longer session. I merged a small change that had been waiting for sign-off.
All of that work is real. The approvals matter. The comments shaped decisions. The spec reviews prevented misunderstandings from propagating into implementation. But all of it shares a common character: it is work done on things that other processes produced. The deployment, the pull request, the agent run, the spec; these were not generated on the phone. They arrived as objects for me to evaluate. My role in each case was to assess and decide, not to produce.
This is what supervision looks like when it’s distributed across time and attention. Someone, or something, did the execution work. The execution produced artifacts. I engaged with the artifacts as they surfaced, from wherever I was, using whatever device I had available. The phone was not a constraint, because the work I was doing didn’t require more than what a phone provides.
What a phone won’t allow
The other side of the pattern is just as clear. I’ve never debugged a subtle concurrency issue from a phone. I’ve never designed a system architecture while standing in a queue. I’ve never done any serious exploratory coding from a mobile keyboard. These aren’t just inconveniences to be solved with a better app or a foldable display. They reflect something about the nature of the work.
Debugging depends on full context. You’re following threads through a codebase, tracing state changes, reading error messages that may reference lines you haven’t seen yet, forming hypotheses and testing them by navigating across multiple files. The cognitive load is high and the environment must expand to match it. A phone’s form factor constrains not just the screen but the working memory available to hold the problem. You can start, but you can’t get far.
Architecture work is similar. Designing systems well requires holding many things in view simultaneously, because constraints interact. A decision about the data model affects the API design, which affects the client contracts, which affects deployment considerations. Good design happens in the space where those interactions can be seen. That space is not the phone screen.
Exploratory coding, the kind where you don’t yet know what you’re building, requires a different kind of engagement again. You’re following hunches, trying things to understand what they do, letting the code push back against your assumptions. This is a conversation between you and the codebase, and it requires fast iteration and full visibility. Mobile interfaces are not built for conversations.
The diagnostic value
Taking the two sides together, a useful question emerges: if I imagine doing this work from a phone, does that feel plausible? Not whether it would be convenient, but whether it would actually work. If the answer is yes, that’s a signal worth attending to. Work that can be done from a phone is probably supervisory: work done on artifacts produced by other processes, work where you’re the decision point rather than the execution engine.
This matters because the ratio of supervisory to execution work is shifting. As agents take on more implementation tasks, as asynchronous processes handle more of the routine parts of building software, more of what a senior developer does becomes supervisory in character. Not all of it, and not permanently, but enough that the distinction is worth naming.
The phone test is not scientific. It’s a way of noticing. If you observe yourself doing a certain kind of work and think “I could do this from my phone,” you’ve probably identified a piece of work where you are in the role of observer and decision-maker, not implementer. That tells you something about what the work requires and where your attention is needed.
Not a goal, but a signal
There’s a version of this observation that becomes distorted. The distorted version says: if you can do more work from a phone, that’s a measure of productivity, and you should try to maximise the share of your work that’s phone-accessible. Follow that logic and you’d optimise for a role that’s entirely supervisory, never hands-on, always deciding but never building.
That’s not a role most developers would recognise as satisfying, and it would erode something important. The judgment required for good supervision is not separable from the practice of execution. You can only evaluate an architecture well if you’ve designed enough architectures to know how they fail. You can only supervise debugging effectively if you’ve spent time doing it yourself. The supervisory role draws on a reservoir of execution experience, and that reservoir drains if it’s never replenished.
The point is not to maximise phone-accessible work. The point is to recognise what phone-accessible work tells you about the nature of different tasks. Supervisory work can be distributed across time and device because it doesn’t require the full execution environment. Execution work still needs the full environment because the full environment is part of how that work gets done.
The proportion of supervisory work may grow as agent-assisted development matures. That’s the direction several of these articles have been pointing toward. But growth in supervisory work is only valuable if the underlying execution capacity is maintained. If the work that must stay central is neglected because you’ve spent too long optimising for what can be done from the margins, the quality of the supervision will eventually follow.
Where the centre still sits
This is the last article in this phase of the series. The previous articles have traced a shift: toward asynchronous work, toward supervision, toward agents handling implementation while humans handle direction. That shift is real and continuing. But it doesn’t dissolve the centre; it moves it.
What must stay central is the capacity to engage with execution work when it matters. Not continuously, not exclusively, but sufficiently. The ability to design, to debug, to explore unfamiliar code, to understand systems well enough to know when something is wrong that looks right. These things don’t happen on a phone because they depend on an environment built for thinking, not just reviewing.
Mobile work is a clue about what has become genuinely supervisory in your work. It’s a useful signal when something shifts from requiring full engagement to requiring only your assessment. But following that signal toward a fully mobile practice would be following the symptom instead of the thing it points toward.
The work that must stay central is revealed by what can’t move to the phone. Not what you haven’t bothered to try on mobile, but what genuinely doesn’t work there. That’s the work still requiring the desk, the environment, the full context. That’s the work still requiring you to be present, not just reachable.
Software development is becoming more distributed across time and device. That’s the direction. But the distribution is uneven, and the unevenness is informative. Some work travels well. Other work doesn’t. Knowing which is which, and maintaining your ability to do both, is what the transition requires.