[Using encapsulated development to code on my phone]
I’m lucky enough to have a wife, two young children and a job as an AI Engineer at Notion. I’m also lucky enough to have a side project.
Some weeks, I’ll get half an hour on my laptop to work on this side project. Most weeks, I won’t. Yet, I’ve averaged two commits to the project per day for the last three months.
How? By building on my phone. But, really, by making it possible to build on my phone.
The broad approach: encapsulated development. Each prompt leaves the repo in a known, stable, verified, stateless condition that permits the next change.
Known
My mental model of the project must be functional enough that I can make future changes. This doesn’t mean I understand everything. I may not know the architecture of some parts of the system. I may not know how some implementations work. But I can understand the behavior of the parts of the system as black boxes. I may not know how the particle system stores particles. But I do know that, when it spawns particles, it doesn’t allocate new objects.
Stable
The quality of the software must be high enough for the next change to be successful. This means well factored, working code.
Sometimes, the project will start to crumble with the accumulation of poor implementations. I do a string of commits to get things back on track, then start building features again.
Verified
Every change must be correct. I can’t manually test changes. The kettle has just finished boiling.
Incorrect changes build into a wobbly tower. Each prompt must include how it will be verified as correct. This usually means end-to-end tests. Having Chrome DevTools actually click through the UI to check it works. Or spinning up the API and checking that inputs produce the expected outputs. Or going full StrongDM and implementing the external services the product interacts with. In my case, I’m working on a tool for making video games. So I built a headless version of my engine. Test code can initialize it with a set of game objects, supply synthetic user inputs, then view screenshots to verify the behavior.
Stateless
Every change should go uninterrupted from prompt to production. At the end of my session - probably 30s or a minute - the project is in a new, known, stable state.
It’s somewhat acceptable to set aside a prompt partway through writing it. To resume, all I need to do is read the text. Quite bad is having set aside a PR. When I return I have to figure out what still needs to be built, what still needs to be fixed. On a phone. This is difficult because a phone has a small screen and low bandwidth input. It’s effortful to draw together the state of an artifact.
Worst of all is letting the project go off the rails. About two months ago, my project got into a pickle. I’d charged forwards at the beginning, and, now, I had a codebase that was plain JS and raw Node with no templating or routing. I knew I wanted to refactor it to TypeScript and Next. And I knew it would be too high a mental load to do that refactor across dozens of commits on my phone. I needed my laptop to be able to research the code, write the plan and have enough visibility to steward the refactor. So, one night, I stayed up way too late and got the project back on the rails.
The worst part about these stateful, interrupted sessions is that, the more chaotic the state the project has been left in, the fewer opportunities I have to make the next bit of progress. If I’m in a known, stable state, I only need to dictate a prompt. And I can do that while the kettle boils, or while I’m waiting on the platform at Castro Street. But, if I’m halfway through a PR, I’ll need to do some reading and scrolling and I might have got nothing done when the K arrives and wrecks my train of thought.
Oral literacy
Many of these measures are good even for projects not built on a phone. A well-understood, stable architecture. Robust verification of correctness. Stateless changes. But something is lost. Planning and design are good. And they’re quite difficult with only a phone.
It’s like an oral culture. If I want to put together a more complex feature, I have to keep it aloft in my brain. Maybe jot down a few notes in Bear. But, no sketchbook, no Figma, no design doc. No divergence, no exploration. This hampers the quality of what I build.
Still, it feels silly to focus too much on this loss. Without LLMs and phones, the project wouldn’t have existed in the first place.
Subscribe to my newsletter to hear about my latest work