I built a native app with several AIs. The most useful thing I wrote in the whole project wasn't code. It was a short list of rules about not trusting their memory.
In the last episode I told how most of my bugs started with a word and not with code. This one is about working with more than one AI: who did what, what went wrong and the method that came out of it.
Who did what
- January: Gemini. The first prompt, the first analysis, the first ideas.
- February: Gemini writes the code. The first custom widgets and functions came from Gemini. I also tried FlutterFlow's own page generator, as I told in episode 2. I dropped it.
- March: Claude becomes the backbone. Funny detail: the first time Claude appears in my notes, it's because another AI recommended it for writing texts (privacy policy, onboarding, notifications). By April it was reviewing the code. By June the main working prompt was written for Claude.
- Cross-checks. I kept asking the same question to other AIs. Gemini stayed my source of creative proposals: in spring it suggested QR codes, recurring events, an automatic check-out and an escape-room style game. Some of those ideas came back months later in a different shape. I also tried ChatGPT. For what I needed it was too agreeable and not concrete enough. A project like this needs someone who tells you when you're wrong.
Gemini's ideas were often new and interesting. Claude had a better view of the whole project and stuck to the rules I had set. In the end I had one AI as the main developer and the others as reviewers and idea generators.
The handoff document
The core of the method is a document I call the handoff: the state of the code, the decisions, the limits I discovered and a changelog. Every working session starts by loading it, together with a fresh export of the project.
It grew with the app:
| When | Size | Sections |
|---|---|---|
| June 1 | 300 KB | 57 |
| mid September | 976 KB | n/a |
| October 4 | 721 KB | 143 |
At almost a megabyte I had to condense it. The document itself was becoming the problem.
When the AI connected to the project
In May I connected the AI directly to the FlutterFlow project through MCP. It could read pages and apply small changes itself. The first batch went well: fourteen fixes applied that way. Then one write corrupted a custom code file. New rule, still valid: the AI can read the project and change settings, but custom code is pasted by me, in the editor, every time.
The worst AI mistake
In the same weeks a chat produced a new version of the file with my push notification functions. It looked complete. The functions were there, with the right names. Their bodies were empty, with only a comment saying where the logic should go.
Deploying it would have replaced working functions with functions that did nothing. Every notification in the app would have stopped without a single error. It was caught before the deploy. From that day a file that looks complete is not code for me until I've compared it with the one that's running.
Rules against AI memory
Most of the method is a list of rules, each with the date of the mistake that created it:
- August 4: never paste texts written by another AI into the project's knowledge. They contained behaviors of the app that didn't exist.
- August 17: if I report the same symptom twice in a row, the AI's source is old. Stop diagnosing and ask for a fresh export.
- August 17: a file is produced by editing the one in the export, never rewritten from memory.
- September 7: never use values "remembered" from previous sessions.
- September 7: when another AI makes a proposal, compare it point by point and say who wins, even when the winner isn't you.
- September 25: a number had been copied into six sections of the handoff and it was wrong. Every number now comes with the command that produces it.
The common thread: an AI's memory sounds exactly as confident when it's wrong as when it's right.
Asking five AIs the same question
In September I had a product decision to make about which features to include. I gave the same prompt to five assistants: Gemini, ChatGPT, DeepSeek, Kimi and Perplexity. Then I had Claude compare the answers against the rules I had already set. Claude was judged too and lost a point for one of its own earlier proposals.
The result surprised me: most of the proposals were things I had already decided. My note that day: when five assistants propose the same things you already decided, the list is complete, not poor. Asking more AIs didn't give me more ideas. It gave me confidence that I wasn't missing any.
The honest limit
The method doesn't make me immune. I work on many fronts in parallel: the app, the backend, the website, the store pages, the outreach. Information still gets lost between them. A recent example: the invite page had been showing its countdown for weeks while my own facts document still listed it as missing.
The handoff reduces these gaps. It doesn't remove them.
What I took from it
- Use one AI as the main developer and the others as reviewers. Merging two developers' ideas by hand is a full-time job.
- An AI that agrees with everything is not helping. Look for the one that tells you no.
- Keep one document that every session starts from. Keep it a photo of the code, not a diary.
- Never deploy what an AI wrote without comparing it to what is running.
- Write a rule every time the AI's memory fails you, with the date. In a few months you'll have a method.
Next and last episode: the finished app. What held, what I'd redo and why building it turned out to be the easy part.
I'm building orbiTome solo, with FlutterFlow and Firebase. More at orbitome.com.
Top comments (0)