# Using encapsulated development to code on my phone

DevFeed: [Using encapsulated development to code on my phone](<https://devfeed.tech/articles/using-encapsulated-development-to-code-on-my-phone-21585.md>)

Original publisher: [Read original article](<https://maryrosecook.com/blog/post/using-encapsulated-development-to-code-on-my-phone>)

Published: 2026-05-25T07:00:00Z

Content type: article

Language: en

Sources: [Mary Rose Cook](<https://devfeed.tech/sources/mary-rose-cook.md>)

Topics: [Development](<https://devfeed.tech/topics/development.md>), [Code](<https://devfeed.tech/topics/code.md>), [test](<https://devfeed.tech/topics/test.md>), [developer tooling](<https://devfeed.tech/topics/developer-tooling.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [development](<https://devfeed.tech/tags/development.md>), [devtools](<https://devfeed.tech/tags/devtools.md>), [test](<https://devfeed.tech/tags/test.md>), [tests](<https://devfeed.tech/tags/tests.md>)

## AI overview

The author describes using encapsulated development to code on a phone. Each prompt leaves the repository in a known, stable, verified, and stateless condition, supported by refactoring and automated end-to-end testing.

## Source excerpt

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 is 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 those parts of the system as black boxes. For example, I don't know exactly 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 low quality code. I do a string of refactors to get things back on track, then start building features again. Verified Every change must be correct. I don't have time to 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. For a web app, this might mean 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 ini