One person, two applications, and the rules that keep them right

Context

The operation runs on a three-week cycle, so at any moment three cohorts of patients are in flight, each at a different one of nine stages. It covers 12+ workflows, from the technician’s daily log to the payment, and since late January it has filled 36 weeks of work folders. I run it every day. I also maintain the two applications that do most of the work: the processing toolkit and the task tracker that shows where everything stands.

Nobody else maintains them. When a billing rule changes, a report format drifts or a scan reads a folder wrong, the person who has to find and fix it is me — the same day, without stopping the operation.

The constraint

AI made writing code cheap. It didn’t make knowing whether that code is right any cheaper. With no team and no second reviewer, every change an assistant makes is a change I have to be able to defend, debug and undo on my own, on a system that handles clinical and billing data. Speed was never the bottleneck. Trust was.

The usual way of working with an AI assistant — ask, accept, move on — produces code nobody can vouch for. I needed the opposite: a way of working where the assistant’s output is checkable by construction.

What I did

• Wrote the working agreement down. Each repository has a file the assistant reads before it touches anything: the process I expect, the hard constraints, and a section called “Things that are easy to get wrong here.” It’s versioned with the code, so the rules change in the same commit as the thing they govern.
• One change at a time, and nothing moves without my go. Implement, verify, report, then wait. Related items aren’t batched. That keeps every change small enough to understand and to undo.
• Evidence, not assurance. “It compiles” is the baseline, never the proof. Logic changes run against the unit suite and against the real trackers, and a report states the method and the result — “18/18 tests, 11 files parsed, 3 correctly blocked,” not “done.”
• Stop when the plan and reality disagree. The assistant is told to stop and ask rather than quietly pick a side. In the tracker’s first stage that happened three times: the spec had been written from the handbook, not from the actual spreadsheets. It’s also told to re-read the real file before trusting a note about it, because a note had been wrong before.
• Chose the model for the job. Every stage ends with a recommendation for which model and how much reasoning the next step needs: the strongest for logic with interacting edge cases, like clinical scoring; a mid-tier model for mechanical changes; the smallest for documentation. Cost follows difficulty instead of habit.
• Made the specification executable. The tracker carries about 300 automated tests. The invoice-drafting tests each reproduce a real past invoice, so a change shows exactly which invoice it would have altered. In the toolkit, every threshold the scoring engine keys on sits in a register with what it measures and the evidence behind it, updated in the same pass as the code.
• Documented for three readers. A private handbook for whoever takes the work over. User manuals for the people using the apps. Developer notes for the assistant working in the repository, kept de-identified, recording what was verified so it isn’t re-derived.

Results

• Two applications that run the daily operation, the first adopted as company operational standard, both maintained by one person.
• The second system started where the first one ended. The toolkit got its written agreement 18 days into its repository. The tracker had one from its first day, and it opens with “same as the toolkit’s” before adding its own constraints. Each system inherits the rules instead of relearning them.
• 93 commits across both repositories between July and October 2026, and about 300 automated tests on the tracker.
• The same habits went into directing others. When I was asked to direct the developers moving these tools onto the company’s platform, the staged, evidence-first way of working came with me — see the two-number backlog.

What I’d do differently

• [Draft — to confirm] I’d give the first application the test suite the second one got. The tracker has about 300 automated tests; the toolkit’s changes are verified by parity checks and end-to-end runs on real data. Those work, but they don’t stand guard between changes the way a suite does.
• [Draft — to confirm] I’d write the agreement before the first commit, not 18 days in. The tracker shows what starting with it looks like.
• [Draft — to confirm] I’d generate the exported documents from their source instead of by hand. The documentation stayed current; its Word and infographic renderings fell behind it, because rebuilding them was a manual step I kept deferring.

Looking back

People ask whether this is “just” prompting. The prompting is the smallest part. Most of the work is deciding what the assistant may do, what counts as proof and what must never change — then writing that down where it applies to every session. That’s a skill, and it compounds.