I come from the sales world. I know how to run a deal, forecast a quarter, and get a procurement team to sign. Until recently, I did not know how to ship a mobile app.
On nights and weekends, I’m building a consumer mobile app as a side project, mostly by myself. OpenAI Codex writes most of the code. I write the instructions, pick the designs, and decide what ships.
I went through my repo before writing this. Here’s where it stands. The repo has well over a hundred commits in under a month. It has produced dozens of internal test builds. The last full check ran about 560 automated tests.
For context, here’s the old yardstick. DORA’s 2024 report puts its top tier, 19% of the teams it surveyed, at deploying “on demand,” meaning multiple times a day (DORA 2024 report). My builds go to internal testers, not to production, so that isn’t a clean comparison. Lines of code are worse. In The Mythical Man-Month, Fred Brooks reported compiler teams on a 1960s operating system project producing 2,000 to 3,000 debugged instructions per person per year (page 93, quoted here). One of my commits added about 21,000 lines, roughly seven to ten years of that output. That doesn’t make me ten engineers. Brooks counted planning, testing, and support. My number counts whatever the agent typed. Commits and lines measure activity, not productivity, and the METR study further down shows how easy it is to confuse the two.
The speed is real. So is the mess. Here’s what works and what doesn’t.
What works
1. Treat the instruction file like deal notes
Codex reads a file called AGENTS.md before it does any work. It’s an open format, and agents.md says over 60,000 open-source projects use it.
Mine is less like a README and more like CRM notes on a long enterprise deal. Every decision gets an entry with a date. When I change my mind, the new entry says what it replaces. My current file has 49 sections, and the word “supersedes” shows up seven times.
In sales, if it isn’t in the CRM, it didn’t happen. Same with agents. If a decision lives only in a chat thread, the next session won’t know about it. It’ll undo your work with total confidence.
2. Pick from options. Don’t describe from scratch.
I’m not a designer, and describing a screen in words goes badly. So I stopped. Now I ask for two to four labeled concepts for any real UI change. The agent builds them, I look at them on a phone-sized screen, and I pick one. Sometimes I pick “B, with the header from A.”
Then a standing rule kicks in. An approved mockup is a spec. The agent has to reproduce the layout, spacing, type, and colors exactly, then compare the built screen to the mockup at the same size before it calls the task done. Any difference has to be named out loud, not slipped in.
This is just discovery. You don’t ask a buyer to write the requirements. You show them three options and listen to which one they lean toward.
3. Turn taste into code that fails the build
Writing “use the design system” in an instruction file works about as well as telling a new rep to “use the playbook.” Sometimes they do. Mostly they copy whatever the last person did.
So the important design rules are code now. A custom lint rule fails the build if a screen uses a raw text field instead of the shared one. A design check runs before every web build and every iOS build. The app has a design-system catalog screen the agent can render and compare against.
My instruction file even says old screenshots and old code can’t justify an exception. Agents love to copy the nearest existing example. If that example is from a retired design, you get the retired design back.
4. Make the agent show receipts
I don’t read most of the code. I can’t review it at the level a senior engineer would. So I make the agent prove its work.
Every meaningful change ends with a written evidence report: what it ran, what passed, which screens it actually rendered, and what it didn’t check. One rule says to report honestly which devices, states, and interactions were checked. Pull request descriptions list the test commands and the pass counts.
The repo now has hundreds of these report files. It’s the closest thing I have to a code reviewer.
5. Ban fake data in front of you
Agents hate an empty screen. Ask one to “make the feed look right” and it’ll quietly fill it with sample content, or a test account, or a fixture server from two weeks ago.
I have a standing rule: when I open the app to review it, it runs current code against the real backend with my real account. No made-up sessions, no seeded activity, no invented facts to fill a card. If something required is missing, the agent tells me instead of faking around it.
What doesn’t work
1. The instruction file eats itself
By default, Codex stops reading instruction files once the combined size hits 32 KiB. My root file is about 44 KB.
Worse, I add new decisions at the top. So the oldest, most basic rules sit at the bottom. At the default limit, those are the ones past the cutoff: run lint and typecheck before saying you’re done, check the current framework docs, treat approved mockups as specs. You can raise the limit in the config, but a bigger file is still a harder file to keep consistent.
The fix is boring. Prune what’s been superseded. Move standing rules to the top. Split area-specific rules into nested files, which Codex reads closest-first. A decision log needs housekeeping like any pipeline.
2. Huge diffs nobody can review
When things are going well, the changes get enormous. One recent commit touched 241 files, with about 21,000 lines added and 6,700 removed. Nobody can review that, including me.
Compare that to a bug fix from the same week. Three files, 190 lines. I could actually understand it.
My pull requests are also not reviews. Most got merged within a minute of being opened. They’re receipts for the evidence report, not a second set of eyes.
The fix I’m moving toward: one screen or one behavior per change, and a hard stop when a diff touches more than a few areas at once.
3. The agent’s knowledge is out of date
The mobile framework I use ships breaking changes every major release. The agent remembers older versions and writes code for APIs that were renamed or removed.
One of my most useful rules says not to trust training data. Check the installed version, read that version’s docs, then write code.
4. Agents want to ship
Agents like to finish the job, and to an agent, finished means shipped. That’s why “a test build needs my explicit request” became a standing rule early on. My instruction file repeats some version of “no release was requested” over and over, because one reminder wasn’t enough.
Every release in my repo now has a written authorization that covers that release only. It’s like approval tiers on a discount. The rep can’t just give away 40% because the deal felt close.
5. Feeling fast isn’t the same as being fast
This is the uncomfortable one. In a 2025 randomized trial, METR found experienced open-source developers took 19% longer on tasks when using AI tools. Afterward they still believed AI had sped them up by 20%. METR now says those results are out of date for current tools and has published newer data. The gap between how fast it feels and how fast it is still applies to me.
The 2025 Stack Overflow Developer Survey found the top frustration with AI tools, at 66%, was “AI solutions that are almost right, but not quite.” More developers distrust AI accuracy (46%) than trust it (33%).
“Almost right” describes most of my build sessions. The screen is close to the mockup but not the same. A button is a few points too tall. The back gesture lands on the wrong screen. Most of my side-project hours go to catching those gaps.
What I’d tell another non-engineer
You don’t need to read every line. You do need a system that catches the agent when it’s wrong.
For me that means four things. Decisions are written down with dates. Design rules fail the build. Every change comes with evidence. Nothing ships without a yes from me.
Next on my list: cut the instruction file under the size limit, split it by area, and cap change size so I can read a diff again.
I’m Sam Brovda. I come from enterprise sales and write about building software as a non-engineer.