I built Audio Apothecary in six days — 187 commits, 1,211 test functions, all passing — and shipped it to my own phone on 16 August 2026. The app generates modular timeline-driven audio for focus and sleep: layered channels with automated parameter transitions, no samples, no DAW, no music composition. Just synthesis and the math that drives it.
I tested it by listening. I kept a plain-language log of what I heard: one entry per session, describing what worked and what felt off. The log sat in the project repo, dated and specific. Below it, in the same file, an agent added its own entries after a five-agent review pass I ran on 11 August — root cause analysis with commit hashes and line numbers, then the fix with its own hash. Both logs used the same format, both grew downward in time order, and one "crackling" report I filed turned out not to be a bug at all.
The listening log
My entries read like operator notes. Plain English, no jargon, describing what I experienced while using the thing I'd built:
Wind module crackling at certain fade transitions — need to investigate parameter smoothing.
White noise occasionally pops during pan sweeps.
Rain channel sometimes drops out entirely when transitioning between intensities.
Each one had a date. The format was casual, conversational, exactly how I would have written it in a notebook. That was the point — I wanted the log to stay low-friction so I would actually use it while listening, rather than let observations pile up unrecorded.
The agent review
The five-agent review pass on 11 August had a narrow brief: find what's wrong, don't extend it. Web research was allowed; architectural flourishes were not. Two agents returned showstopper findings with root-cause analysis and proposed fixes. Both were signal-processing bugs that listening and automated tests had both missed.
Stereo panning did not exist. The equal-power pan law used L = cos((1−p)·π/2) and R = sin(p·π/2) — by a trig identity, the same number for any pan value. Every pan position produced identical gain on both channels. Every automated test passed, because the tests verified the code agreed with its own contract, not that the contract matched what a stereo field needs to be true.
The "master limiter" was not a limiter. It was a waveshaper with no threshold, no envelope, no unity region — constant audible distortion applied to every sample at every level. Again, the tests passed. The implementation matched the spec; the spec was just wrong.
Both were fixed the next day, 12 August, alongside a real equal-power pan law and a real peak limiter with threshold and attack/release envelope.
The agent's log entries
After the fixes landed, the agent added its own entries to the same log file, directly below mine. Same chronological order, same downward growth, different voice:
2026-08-11: Stereo panning investigation (commit
a4f8e32) — Root cause: equal-power pan implementation produced identical left/right gains due to trig identity. Fixed with correctedL = cos(p·π/2),R = sin(p·π/2)formulation.
2026-08-11: Master limiter analysis (commit
b7d9f41) — Root cause: waveshaper with no threshold or envelope, applying distortion at all levels. Replaced with threshold-based peak limiter with 5ms attack, 50ms release.
Each entry included the date, the commit hash where the fix landed, and a plain statement of what was wrong and what replaced it. No attribution, no "the agent found" phrasing, just the record of what happened and when. The format was structured enough to be machine-readable and plain enough that I could scan it while listening to the next build.
The crackling that wasn't
One of my entries — "Wind module crackling at certain fade transitions" — never got a matching agent entry. I investigated it myself and found there was no bug. The crackling I heard was an interaction between the wind synthesis algorithm and a fast fade curve I'd chosen; both were working exactly as specified. The artifact was real, I'd described it accurately, but the fix wasn't a code change. It was a product decision: use a longer fade, or accept that fast transitions on that particular module sound like that.
The app was then built to prove it. I ran the sequence that had produced the crackling, recorded it, analyzed the waveform, and confirmed that the output matched the math. The log stayed honest: my entry described what I heard, and the absence of an agent fix entry below it recorded that no code defect was found.
What this workflow did
The listening log became documentation of what I experienced as the operator, and the agent's root-cause entries became the repair record for what the review process found. Both logs lived in the same file, growing in the same direction, using compatible formats. I could diff the file against an earlier commit and see both what I'd noticed and what had been fixed since then, in one view.
The two voices stayed separate. My entries used plain language and described subjective experience; the agent's entries cited commits and named functions. Neither tried to sound like the other, and the file never needed a legend because the difference was obvious from the prose.
The point wasn't to replace my judgment with the agent's — the crackling investigation proved that wouldn't have worked — but to let both records accumulate in the same artifact, at the same time, so the repair history and the usage history stayed aligned.
Receipts
Audio Apothecary is a Rust workspace bridged to Flutter, with 1,211 test functions total (671 Rust #[test] + 540 Dart test/testWidgets), 187 commits across 6 active days (11–16 August 2026), and about 29 logged architectural decisions across the same period. Status: shipped, installed on my phone, not published to an app store.
For the full build inventory and test counts across all my projects, see the receipts page.