The AI SDLC I Use to Ship Mobile Features

AI didn't remove a single step from how I ship a mobile feature. It changed who does the typing in each one.

The loop is boring on purpose: a spec, a plan written into the repo, an agent that implements in small diffs, tests on every step, an AI review, and a human who merges. The model works inside most of those steps. I own all of them.

1. The spec: the part AI can't do for you

A spec is one page. The problem, what the user sees, every state (empty, loading, error, offline), what's out of scope, and how we'll know it works. If the spec doesn't name a state, the agent will invent one, and invented states are the ones that ship broken.

A model can help me write it. It can't know what the client actually needs, which edge case they mentioned on a call last week, or which flow is quietly carrying the revenue. That conversation is still mine, and it decides whether the rest of the loop is worth running.

2. A plan, written into the repo

Before any code, the agent reads the spec and the files it touches, and writes a plan as a markdown file next to the code. I read it, change it, and only then say go. This is the cheapest moment to catch a wrong approach: changing a plan costs a paragraph, changing the code costs a day.

# Plan: offline cache for the orders screen

## Touches
- data/OrdersRepository.kt (cache first, then network)
- data/local/OrdersDao.kt (new query + migration)
- ui/orders/OrdersViewModel.kt (explicit Loading state)

## Steps
1. DAO query and migration, with a test
2. Repository: read-through cache, with a test for a failed request
3. ViewModel: Loading / Content / Empty / Error
4. UI states, checked on a small phone and a tablet

## Risks
- Migration on existing installs
- Stale data shown as fresh

## Out of scope
- Background sync

Writing it into the repo matters. A plan in a chat window disappears when the session ends; a plan in the repo gets reviewed, versioned, and is still there in three months when someone asks why the cache works the way it does. It also survives the session: a new agent, or a new teammate, can pick up at step three by reading one file.

3. Small diffs, one step at a time

The agent implements one step of the plan per diff. Small enough that I can read the whole thing properly. If I can't review it in one sitting, it's too big, and it goes back to be split.

This is where AI speed actually turns into shipped code. A huge diff from an agent isn't fast. It's a review you're going to do badly, and the bug you miss is the one that reaches the store.

4. Tests run on every step

The agent runs the tests itself and fixes what it broke before it shows me anything. A red test is feedback for the model, not a message for me. By the time a diff reaches me, the boring failures are already gone.

5. An AI review before mine

A second agent reviews the pull request with the spec, the plan and the full files the change touches, not just the diff. It's good at missing states, unhandled errors, a coroutine in the wrong scope, and code that quietly drifted from the plan. I ask it to point every finding at a file and a line, so I can confirm or dismiss each one in seconds.

It doesn't replace my review. It clears the obvious findings so my attention goes to the questions only a human can answer: is this what the client needs, and what happens on the devices we don't test on?

6. A human merges

I merge, every time. Not because the model can't press the button, but because someone has to own what ships, and the store review, the crash report and the angry user don't care who wrote the code. Merging is where I sign my name under the change, and I don't delegate my signature.

1. 1SpecI write it. The model helps me find the states I forgot.
2. 2PlanThe agent drafts it into the repo. I edit it and approve it.
3. 3Code and testsThe agent writes both, one step per diff, and runs the tests before I see anything.
4. 4ReviewAI first, me second, with the spec and the full files open.
5. 5MergeMe. Always.

The model writes most of the code. I still own every line that ships.

The rule that holds the whole loop together

None of this is new. Specs, plans, small pull requests, tests and review are just good engineering. AI makes skipping them more tempting, and a lot more expensive when you do.