()=>{}

A year ago, on my laptop, I started to use the newly introduced — and still very imperfect — agent mode of GitHub Copilot to push forward my private project, the Retro Build Tool (RBT). The project had stagnated for a long time, and it was AI that finally brought it back to life. Today I use just my Android phone and Claude Code with remote control, which talks to a mini PC that runs around the clock at my house. When I write it down like that, it sounds like a decade of progress, but it has been just twelve months.

A typical ‘coding session’ now looks like this: I pull the phone out of my pocket, I read what the agent has done since I last checked, and I send the next instruction — accept a plan, order a challenge against it, or tell it to execute the next step. Somewhere at my house, a mini PC checks out branches, compiles, runs the tests and commits, and then it waits for the next message — no laptop gets opened at any point. This post is about that setup: the box, the phone, and the full automation that has to sit underneath before you can drive real work from a screen in your pocket.

The box and the phone

Somewhere along the way I realised that nothing in my workflow needed the laptop any more. The plans were files in a repository, the skills were procedures the agent followed on its own, and even the end-to-end test runs of the Gradle plugin were easily automated, so my part had shrunk to reading and deciding — and a phone screen handles both perfectly well. The software side of the story had settled, so the hardware was the last thing to catch up, and eventually it did.

The centre of my current setup is nothing special: a no-name mini PC bought in September 2025 for roughly 600 euro — a small black box with an AMD Ryzen 9 7940HS, 32 GB of DDR5 RAM and a 1 TB NVMe drive, running Windows 11 Pro. It sits at my house and runs around the clock. There is a monitor attached, but I sit at it only occasionally and for other purposes — when I am coding, the screen stays dark.

What it does have is Claude Code. The agent runs there, among my checked-out repositories, and I connect to it from my Android phone using remote control. The phone is the only ‘terminal’ I use: I read what the agent has done, I send the next instruction and I put the phone back in my pocket. Sessions happen wherever I am — commuting, on the train, on the sofa. In fact, the honest trigger for a session is not a place at all: it is noticing that my token quota has renewed. That is what a ‘development environment’ has shrunk to in a year — a phone, a quota, and a box at home doing the actual work.

Robustness is the whole game

There is a less exciting side to this arrangement: robustness. A remote-only setup is exactly as good as the box staying up and the session staying alive. As I write this, the box is about 1500 kilometres away from me, and the phone is the only way I can reach it, so at that distance every reboot, network problem or dropped session is not an annoyance — it is a full stop.

In practice, three things have caused me trouble. The first was the operating system’s good intentions: a consumer mini PC is tuned to save energy, so left alone it will happily drift into sleep or a low-power mode — and for a box whose whole job is to be there when I reach for my phone, this is a fatal habit that had to be configured away. The second is electricity itself: I live in a village where power cuts are not rare, and no software makes up for a dead socket. The third was the remote control feature of Claude Code, which in its early days was not particularly stable — though it has improved a lot in recent months.

The countermeasures are simple. Sleep is turned off entirely, the BIOS is set to power the machine back on the moment electricity returns, and the Claude consoles start automatically on login. For emergencies there is Remote Desktop — not for working, only for logging in after a power loss, so that the autostart can do its job and I can put the phone back in charge. Remote Desktop is also my remedy when the remote control itself misbehaves, though that has grown much rarer in recent months.

Remote means fully automated

There is a precondition to this phone-only workflow that is easy to miss: full automation. Let me be precise about what that means, because it does not mean an agent running unattended. The questions the agent can raise are of two kinds: mechanical ones that can safely be pre-approved, and decisions that must always come back to a human — and the two must not be allowed to blur into each other. The acceptance phase is still there, and it is needed more than ever — Claude Code can potentially access every file on my PC, so I very much want to know what it intends to do before it does it. Full automation means something narrower: I never code manually, I never create or delete a file by hand, the interfacing with the git repository and with the coding platform (gh) is automated, and the quality gates and the review process are handled by skills. Everything mechanical is decided in advance and lives in the repository itself, and what remains for me is to accept or refuse. To be fair, when the agent stops mid-task to ask whether it may run git push, the session does not die — remote control simply pauses and waits for a decision, and the question pops up even on my watch. That is exactly why the mechanics must be pre-approved: a wrist that buzzes for every git push quickly teaches you to tap ‘yes’ without reading, and then the acceptance phase — the one part that must not be automated — turns into a reflex. The questions that reach me should be the ones that really deserve my attention.

RBT is a good example of what that looks like after a year of growth. Its CLAUDE.md is a small constitution: the build commands, the hexagonal architecture rules the generated code must obey, commit-message conventions, and coverage targets. Around it sits a set of skills — prompt packages, really — that wrap the whole development lifecycle: a plan skill that turns a feature into a structured action plan, an execute skill that implements it step by step and keeps an execution log, a challenge skill that red-teams the plan before any code is written, and a fixme command that feeds errors back into the plan when something goes wrong. The plans are synced with GitHub issues, and the pull requests are opened by a skill too.

Verification is where ‘narrowing the corridor’ — my old answer to ‘can we trust the generated code?’ — stopped being just a nice phrase and became actual configuration. The agent has skills to build, run static analysis (Spotless, Detekt), execute the full test suite with coverage thresholds, and finally run an end-to-end test: publish the freshly built plugin locally and build a real Commodore 64 game with it, checking that the expected artefacts come out. The agent does not ask me whether the change works, because it is equipped to find out.

Two more details complete the picture. First, the mechanical work — running Gradle, git, gh — is delegated to subagents on a cheaper model, so the expensive tokens are spent on reasoning rather than on watching a compiler scroll by. Second, there is a permission allowlist in the repo’s settings: some thirty pre-approved commands and skills, collected one confirmation at a time, and this is precisely the list of questions the agent no longer needs to ask me. That list, more than any model release, is what freed me from the keyboard.

None of this orchestration is carved in stone, by the way. The constitution, the skills, the allowlist — they evolve as the work demands, and they evolve the same way everything else does now: I prompt for it. When a convention starts to annoy me, or a new routine repeats itself often enough to deserve a name, I tell the agent to rewrite its own instructions — remotely, from the same phone. The harness is just another codebase, and the agent maintains that one too.

Conclusions

1. In twelve months, my development environment shrank to a phone, a token quota and a cheap box at home. The laptop did not survive the year.
2. A remote-only setup lives or dies on robustness: kill sleep, auto-recover after power loss, autostart the agent, and keep a bare-minimum way in for emergencies.
3. Remote agentic coding requires full automation of the mechanics: a narrowed corridor, automated verification and pre-approved permissions. Every mechanical question that still reaches you is noise that trains you to stop reading — keep only the acceptance decisions.
4. The one part that must never be automated is acceptance — reading and reviewing a reviewable artefact, such as a plan document, before it is acted on. Everything mechanical is pre-approved so that the questions which do reach the phone are the ones that genuinely deserve attention.