Alex Reid South Dakota, USA 15H AGO

I am a Mohs surgeon who built and shipped an iOS app without formal software engineering training. The surprising part was not only getting AI to write the code; it was getting AI to remember what it had already done. I built ErgoSherpa because up to 90% of surgeons in my field report musculoskeletal symptoms, while our training fails to address them. I wanted to help surgeons improve their health easily between cases. It is free on the Apple App Store and at ergosherpa.com. The bottleneck was maintaining coherence over time. Many sessions seemed to start from zero: I would re-explain the architecture, then watch a fix quietly undo something I had solved earlier. Three habits fixed that. First, I created persistent project documentation: a `MEMORY.md` index file plus separate topic files for architecture and business decisions. I update them at the end of every session so a new session can read the files first and pick up where the last one stopped. Second, I stopped handing one model the whole job. I use three models and match them to the task. Claude Fable audits only. I open a separate session, point it at the codebase, and require a prioritized checklist with the file path, the problem, and the fix in one sentence—without writing code. A model that did not write the code and has no memory of the project reviews it more honestly than the session that built it. I paste that checklist into a Claude Opus session, which handles the codebase repairs. Claude Sonnet handles routine work such as content updates, image processing, and scheduled maintenance, often from handoffs written by Opus or Fable. Nothing gets implemented on the auditor’s word alone: I have Opus flag any decision that needs human input. This workflow caught a deep-link handler that accepted authentication tokens from any URL and a database policy missing its write-side check. Third, I verify against production, not just the code. Some of the most frustrating parts of the project involved fixes that were correct in the file but wrong on the user’s screen because of a cached asset, a stale database row, or an iOS process that needed a force-quit. I no longer consider anything fixed until I have checked the live app. Step-by-step: 1. I keep a project memory directory with a `MEMORY.md` index and separate topic files for architecture and business decisions, updating them at the end of every session. 2. I open a separate Claude Code session running Claude Fable and prompt it to audit the codebase and return only a prioritized checklist: file path, line number, the problem in one sentence, the fix in one sentence, with no code or commentary. 3. I keep the auditor in its own session with no project history so it reviews the code independently instead of defending work it wrote. 4. I paste the checklist verbatim into a Claude Opus session and have it work from the top down, reading each file and making each change. 5. I tell Opus to flag anything it believes is a false positive instead of implementing it, keeping a human in the loop on key findings. 6. I use Claude Sonnet for routine work such as content updates, image processing, and scheduled maintenance, often from handoffs written by Opus or Fable. 7. I verify every change against the live production site rather than the local files because cached assets and stale database rows can make correct code behave incorrectly for users. 8. I append confirmed lessons and architectural decisions to the project memory so the next session starts from the project’s current state.