Selected work / Case study 03
How I ship
with AI agents.
I'm a designer, not an engineer. This is how I take an idea to installed, working software I can trust, with one AI building it and another checking it.
- My role
- Product direction, specifications, acceptance criteria, release decisions
- Part of
- StephOS: the recorder, archives, memory and the assistant Nyxen
- Built with
- Claude Code builds; Codex reviews independently
- Status
- In daily use by me; no external users yet
I don't write the code.
I decide what ships.
AI coding agents can produce a lot of software quickly. The hard part is knowing whether it does what you meant, and whether it broke something you already had. As a designer without an engineering background, I needed a way of working where "done" didn't depend on reading code or trusting a confident summary.
The person
A designer directing AI agents on a real, long-running product.
The task
Take each change from an idea to an installed release, without losing data or breaking what already worked.
The challenge
Make quality something I can see and check, not something I have to take on faith.
Every change starts
as a proposal I approve.
Before any code, each change is written up as one small slice: what it does, what it deliberately doesn't do, and how we'll know it works. I approve it in my own words, often with conditions. One small feature, a count of messages since saved work was approved, was approved only if the wording said "in this chat," and a count of zero was never called "current."
A finding that changed the design
A design once treated half-finished reply fragments as "progress." I rejected it: a fragment isn't an update. The design changed to a real lookup step that has to report what it found, to me, in plain words.
One builds.
A different one checks.
Claude Code builds each slice in its own workspace, with tests. Then Codex, a separate AI, reviews the exact change before anything is installed. I relay the reviews myself, so I read every finding.
In each of the last five releases, the reviewer's first verdict was "required changes": 15 problems in all, every one fixed before install. As of October 24, 2026.
- 1
"Stop sharing with Cloud" didn't stop automatic sends in chats approved the old way.
- 2
Damaged approval data could still let a message send.
- 3
Hiding the assistant's bookkeeping could also hide part of my own message.
- 4
A failure reading progress notes could turn a good answer into a failed one.
The review step isn't ceremony. It finds something real every time.
Ten checked steps
from approved to installed.
Approval isn't installation. Every release goes through the same ten steps: the files must match exactly what was reviewed, a recovery copy of the current app is made first, and the app's data, memory and permissions are captured before and after and compared. I unlock the app myself at the install step.
| Requirement | How it's checked |
|---|---|
| Exactly what was reviewed | The installed files match the reviewed change, byte for byte. |
| Nothing else changed | Data, memory and permissions are compared before and after: identical. |
| Nothing lost | File counts match (2,240 before, 2,240 after), and only the expected files were rewritten. |
| A way back | A recovery copy of the previous version is kept for every install. |
| My approval | The install can't finish until I unlock the app. |
Installed
isn't proven.
A feature can be installed and still not be shown working in real use. My release record keeps two columns: installed, and demonstrated in use. Several features honestly say "not yet" or "synthetic check only," and one says "unverified."
| Capability | Installed · Demonstrated in use |
|---|---|
| Automatic recall across permitted chats | Installed · Yes, in my own use |
| Progress notes after replies | Installed Oct 19 · In first live use; whether they're useful is still my judgment |
| One standing approval for Cloud | Installed · Not yet used |
A failure, and the rule it left
I once made a results file read-only to protect it. The next authorized run couldn't write to it, and the failure first looked like a problem with the AI provider. The rule now: freeze finished files by recording a fingerprint of their contents, never by locking a file a later run still needs.
A way of working,
not a one-off.
AI builds it. AI checks it.
I accept it.
changes since August 14
installed versions kept, each restorable
dated decision records
Counts as of October 24, 2026.
Proven in my own use
- Proposals approved in words, with conditions
- Independent review on every release
- Ten-step installs with recovery copies
- Installed and proven tracked separately
Not yet
- No external users or team yet
- The reviewer is an AI, not a human engineer
- I relay reviews by hand, by choice
- My numbers aren't compared with anyone else's
Next case study
Continuity
with consent.
Designing AI memory people can permit, inspect and correct.