Doing this work on the machine you own

The assumption worth dropping

Most writing about this work assumes a recent laptop with sixteen gigabytes of memory and a stable connection. A large share of people reading this have a phone, or a machine with four gigabytes, or a connection that disappears for hours.

Almost all of this work is reachable from there. Some of it is not, and this lesson says which.

A phone is a real computer

On Android, Termux is a full terminal with a package manager. git, python, clang, node, vim, ssh: the actual tools, compiled for the device, free and open source. A phone from 2020 runs a Python test suite without difficulty.

What a phone is bad at is typing and reading. A five-pound Bluetooth keyboard changes the experience more than any software. Reading a long diff on a small screen is hard, and no trick fixes it.

On iOS the position is worse (no general terminal) so the practical route is connecting to a machine elsewhere, which is the next section.

Borrow a machine

When the local device is the constraint, move the work.

• GitHub Codespaces includes a monthly free allowance for personal accounts, giving a real Linux container with VS Code in the browser.
• Google Colab provides free notebook sessions with a GPU, subject to idle limits and no guarantee of availability.
• Kaggle notebooks provide a weekly GPU quota, around thirty hours, which is more generous than most people realise and is free.
• A small virtual server costs about five dollars a month. Install tmux and code-server, and you have a persistent development machine reachable from a browser.
• code-server on any spare machine at home, reached over Tailscale or a similar free tier, turns an old desktop into your workstation.

The pattern is the same: the phone becomes a terminal, and the work happens somewhere with memory.

Surviving a bad connection

This is a design problem, and it has good answers.

tmux or screen on the remote machine. Your session survives the disconnection. Reconnect and everything is as you left it, mid-command. This single habit removes most of the pain of intermittent connectivity.

Git is offline by design. Commit, branch, rebase, read history, run bisect: all local. You need the network only to push and pull, which is seconds.

Take documentation offline. DevDocs downloads complete API references for hundreds of languages and libraries into browser storage. man pages, pydoc, go doc and --help are already on your machine. A large share of what people ask a chat interface is in a reference page that is already local.

mosh instead of ssh where you can install it: it survives network changes and reconnects without dropping the session.

Running a model locally

This is where hardware bites, and the honest numbers matter more than encouragement.

A 4-bit quantised model of around 7 billion parameters needs roughly 4 to 5 GB of memory. A 3B model needs around 2 GB and will run on a mid-range phone, slowly. llama.cpp runs on CPU only and works on hardware with no GPU at all; ollama wraps it in something easier.

What a small local model does well: completion, boilerplate, explaining unfamiliar syntax, writing a regular expression, drafting a test, renaming things consistently. Those are a real fraction of daily work.

What it does not do well: multi-step reasoning over a large codebase, subtle debugging, anything needing a long context. Module five made the point that many of those tasks are ones you should be doing yourself; that is true and it is also partly a consolation. The gap is real.

What cannot be done on constrained hardware

Said plainly, because false encouragement wastes people’s time.

Training or fine-tuning anything substantial. Running large open-weight models: a 70B model needs tens of gigabytes even quantised. Large-scale data processing that does not fit in memory. Compiling very large codebases in reasonable time. iOS and macOS development, which requires Apple hardware.

For several of these the answer is the borrowed machine: Kaggle’s weekly GPU hours will fine-tune a small model. For the Apple case there is no free path, and that is a real barrier, not a matter of effort.

What this actually costs

A usable setup: a second-hand Android phone, a cheap Bluetooth keyboard, a free GitHub account, a free Kaggle account, and optionally five dollars a month for a server. Everything else on this page is free and open source.

That is a genuine change, and it is worth stating without inflating it: the capital barrier to learning this work is now very low. The barriers that remain are electricity, bandwidth, time, and the fact that most documentation and most hiring happens in English. Those are not solved by any tool on this list.