I spent a week coding production features from my phone using Claude Remote Control. Here is the reality of the
What “headless” engineering actually means
Headless engineering is not coding on a phone’s tiny editor. It means treating the mobile device as a remote control for a real development environment that lives somewhere else—your laptop left running, a cloud workspace, or a persistent terminal session. The phone becomes the interface for intent: describe a change, review a diff, approve a deploy, or steer an agent through a task. The compile, test, and runtime work still happens on a full machine with a proper shell, git history, and tooling.
Claude Remote Control fits that model by letting you direct work from a mobile client while the heavy lifting stays on a connected session. For a week of shipping production features this way, the question is not whether the AI can write code. It is whether you can keep quality, context, and safety high when your only window into the system is a small screen and intermittent attention.
What a week of production work from a phone actually feels like
The viable workflow is short loops with hard stop points. You state the goal, constrain the scope, and require evidence before anything is merged: failing test first, then patch, then green suite, then a careful review of the diff. On mobile you skim more than you deep-read, so you force the agent to surface risk—touched files, API shape changes, migrations, auth paths—instead of burying them in a long monologue.
Context is the real bottleneck. You cannot hold a whole codebase in your head while walking between meetings. You compensate with discipline: one feature branch at a time, a written acceptance checklist in the first message, and a rule that the agent must restate the plan before editing. Vague prompts produce sprawling PRs; precise prompts produce small, reviewable changes. When something is ambiguous—product edge cases, error messages, naming—you pause and decide yourself rather than letting the agent invent product policy.
- Keep sessions long-lived on the host machine so the agent has a stable workspace and shell.
- Prefer narrow tasks (one endpoint, one UI state, one bug class) over “finish the feature.”
- Demand a summary of files changed and tests run before you approve any commit.
- Never authorize secrets, production deploys, or destructive ops from a casual chat thread.
Where mobile control works—and where it fails
It works well for tightly scoped production work: bug fixes with clear reproduction steps, small API additions, logging and observability hooks, config flags, and refactors that stay inside a known module. It also works for operational steering—restart a job, check logs, re-run a failed pipeline—when the host session already has the right credentials and guardrails.
It fails when the work needs spatial judgment or dense parallel context: complex UI layout, multi-service design tradeoffs, large refactors with subtle coupling, or incidents that require reading many logs and dashboards at once. On a phone you will miss details in long diffs. You will also lose thread when notifications interrupt mid-review. Those moments are not a failure of the model; they are a signal to switch to a full keyboard and a real monitor before you ship.
A practical standard if you try this yourself
Treat the phone as a control surface, not as the development environment. Keep production access behind explicit gates. Require tests for every behavior change. Review every file the agent touches—even when you trust the tool—because “headless” removes the physical friction that normally forces you to look carefully. Ship small, merge only after you understand the blast radius, and end each session with a clean git state and a short note of what remains.
A week of building this way does not prove you can replace a desk. It proves that with remote control, a disciplined agent loop, and ruthless scope control, you can move real production features without sitting at a laptop—so long as you know when to put the phone down and finish the hard parts the traditional way.