Photo by Bayu Syaits on Unsplash.
Coding with AI is starting to feel weird.
Not because the tools can write code.
That part is already old news.
The weird part is that the work keeps going after you leave your desk.
You start a task.
You walk away.
Then your phone asks whether the AI should run a command, change a file, or keep going.
At first, that sounds convenient. Then you realize something else: you are not just coding anymore. You are supervising.
For years, the AI coding story was framed around the editor.
Autocomplete got better. Chat got better. The assistant moved into the IDE. The pitch was simple: you type, the model helps.
But the newer pattern is stranger.
The agent does not only answer while you sit there. It keeps working. It asks for approvals. It runs tests. It waits at boundaries. It carries context from one step to the next.
And increasingly, your phone is becoming the place where you supervise it.
This is not really about coding on a phone
"Coding on your phone" sounds like a gimmick.
Most developers do not want to debug a large codebase from a small screen. A phone is a bad IDE, a bad terminal, and a bad place to read a complicated diff.
But that is not the interesting part.
The phone is not becoming the new laptop. It is becoming the new control surface.
OpenAI recently brought Codex into the ChatGPT mobile app, so users can stay connected to active work while Codex continues running on a connected host or remote environment. Anthropic's Claude Code Remote Control follows a similar idea: a running local Claude Code session can be steered from claude.ai/code or the Claude mobile app.
GitHub is moving in the same direction with Agent HQ, where Codex and Claude are available in public preview across GitHub, GitHub Mobile, and VS Code for eligible Copilot users.
The details differ.
The pattern is the same.
AI coding work is leaving the single glowing rectangle of the IDE.
It is becoming something you can start, leave, check, approve, reject, and resume.
The new work is watching the work
Traditional programming is active and continuous.
You sit down. You load the project into your head. You edit, run, inspect, and repeat.
Agentic programming is more interrupted.
You describe a goal. The agent tries a path. It asks for permission. It produces a result. You review. You correct. You decide whether the next step is safe.
That makes the developer less like a typist and more like an operator.
Not a manager in the corporate sense. More like someone watching a process that can move without them, but should not be trusted without them.
The skill changes.
The question is no longer only: can I write this code? It becomes: did I give the agent the right task, and can I trust what it did?
Why mobile makes the shift obvious
Mobile access matters because it makes the agent feel less like a tool and more like a worker in progress.
When the work can keep moving after you leave your desk, programming starts to look less like one focused session and more like a series of check-ins.
That can be useful.
A test run finishes while you are commuting. A refactor pauses for approval while you are in another room. A small bug investigation produces a summary before you sit back down.
For many teams, that is real leverage.
But it also has a cost.
Work that used to stay inside the coding session can leak into every gap of the day. The phone buzzes, and suddenly you are thinking about a repo again.
You are no longer "coding," exactly, but you are still carrying the system in your head.
That may be the most underrated change.
Small screens create big permission problems
An AI coding agent is useful because it can act.
It can inspect files, run commands, edit code, use tools, and sometimes interact with external systems.
That same ability is why it needs boundaries.
Approving an action from a phone is convenient. It can also be dangerous if the interface hides too much context.
Ask the boring questions:
- What exactly is the command?
- Which directory will it run in?
- What files changed?
- Is the agent using secrets?
- Did the task get influenced by an untrusted issue, comment, web page, or dependency output?
This is where the conversation has to move beyond productivity.
OWASP's work on LLM and agentic AI risks gives useful language for the problem: excessive agency, tool misuse, prompt injection, unexpected code execution, and weak oversight.
Those risks do not disappear because the approval button is on a phone.
The best agent is not the one that asks for nothing.
The best agent is the one that knows when to stop.
Good delegation is becoming a developer skill
The most practical lesson is not "let AI do everything."
That is the lazy version of the story.
The better lesson is that developers need to learn how to delegate work that is specific enough to be useful and bounded enough to be safe.
A good agent task sounds like:
- "Investigate why this test fails and summarize the smallest likely fix."
- "Add tests for this function, but do not change production code yet."
- "Refactor this small module without changing behavior, then show me the diff."
- "Check whether this pull request touches authentication, secrets, or payment logic."
A bad agent task sounds like:
- "Fix the app."
- "Make this better."
- "Clean up the project."
- "Do whatever is needed."
The difference is not just prompt writing.
It is control design.
If the agent is becoming more autonomous, the human has to become more precise.
The IDE is no longer the whole battlefield
For a long time, developer tools competed around the editor.
The editor mattered because that was where the work happened.
But if agents can operate across repositories, terminals, issue trackers, cloud environments, and mobile approval flows, the editor becomes only one surface among many.
The new competition is around the control plane:
- Where do you assign work?
- Where do you see progress?
- Where do you approve risk?
- Where do you review the result?
- Where do you stop an agent before it does something stupid?
That is why Codex mobile, Claude Code Remote Control, and GitHub Agent HQ belong in the same conversation.
They are not identical products, but they point at the same future: coding agents that live across devices and ask the developer to supervise motion rather than type every step.
This will not remove the need for engineering judgment.
It will expose who has it.
The phone is just the symbol
The phone is not the destination.
It is the symbol of a deeper transition.
Coding is becoming less like one person continuously typing and more like a loop:
delegate, observe, verify, approve, correct.
That loop can be powerful.
It can also be exhausting.
The developers who benefit most will not be the ones who accept every AI-generated patch. They will be the ones who can frame the right task, spot weak reasoning, set clear permissions, and know when a small approval is actually a big decision.
The future of coding may not look like someone sitting at a laptop for eight uninterrupted hours.
It may look like someone glancing at a phone, rejecting a bad plan, approving a safe step, and carrying the architecture of a system around in their head all day.
That is not just a new tool.
That is a new rhythm of work.