Zachary Lee’s KeyEcho—a desktop app that plays mechanical-keyboard sounds on keypress—was already an 800-star project when he decided to rebuild its hot path. The result is a clean 27x speedup (1184ns/op to 43.5ns) using zero-copy playback, deduplication, and lock-free state. What’s more interesting than the numbers is how he got there, and the one fix he refused to merge.

Lee documented his workflow in a July 2026 post, and it reads like a field report from a new kind of team: one developer, two AI agents with specialized roles, and a set of patterns that separate effective collaboration from blind delegation.

Goals, not orders

Lee rarely gave step-by-step instructions to his agents. “I gave goals… and reviewed at the checkpoints.” This is the inversion of the typical prompt-chaining workflow. Instead of dictating the implementation, he described the outcome and let the agent explore.

He intentionally split model roles:

  • Claude Fable played outside-the-box engineer—“surfacing angles I had missed.” It handled architectural exploration.
  • GPT-5.6 acted as executor: hand it a decided plan and code came back “close to perfect.”

This two-person-team feeling (one thinks, one builds, I decide) matches the emerging consensus among teams using multiple models. Specialize by cognitive mode, not by task name.

Parallel exploration, serial synthesis

Lee used git worktrees to let agents review different parts of the codebase simultaneously without touching the main tree. This is a concrete implementation of the principle that exploration parallelizes cleanly. The bottleneck remains synthesis—the human sees the threads and weaves them. “The synthesis still has to happen in one head.”

That one head is the developer. Not the LLM. The agent has no sense of sunk cost, no memory of past incidents, and no ability to decide when to stop. Lee cut the armv7 build from the 1.0 release after a two-hour CI emulation failure. “Deciding to stop is a human job.”

The fix that passed everything but missed the point

The most instructive moment came during CI. Linux armv7 failed under QEMU because libgit2 couldn’t fetch a git dependency. An agent proposed dropping the git pin and using the published crates.io version instead. CI would turn green. Clean. Minimal. Wrong.

Lee rejected it because that pin held cpal at version 0.18, which included a critical behavioral fix: default-device rerouting when you unplug headphones. The crates.io version resolved to 0.17.3. The change would silently drop a user-facing feature—no test covered “unplug headphones, sound follows.”

This isn’t an edge case. It’s a canonical example of the problem with LLM-driven dependency management. The agent has no memory of the bug report (#41, #20) that led to the pin. It sees a CI failure, searches for a cure, and offers the one that looks cleanest. The human sees a feature that cost time to implement and preserves it.

Real fix: cargo vendor + build offline inside QEMU.

Write the “why” next to every pin

Lee’s first lesson: document the reason next to every dependency pin, workaround, and magic number. An agent has no institutional memory. The code itself is the only shared artifact. If the commit message says “bump cpal to 0.18 for device-following fix,” the agent won’t parse it—but a next human will, and the next agent can be prompted to check the commit log.

Second lesson: never accept a dependency version change you didn’t ask for, even when CI is green. CI can only test what you wrote. It can’t test what you deliberately chose not to break.

What this means for team flows

Lee’s case isn’t about tool superiority—it’s about division of cognitive labor. The AI handles exploration, parallel scanning, and execution within a bounded plan. The human owns synthesis, judgment, and the decision to stop. That sounds obvious, but most workflows invert it: humans describe steps, AI executes, and judgment gets buried in the prompt.

The patterns here—role specialization, goal-level delegation, git worktrees for parallel review, and the hard rule against unwarranted version changes—are transportable to any team using AI as a contributor. They don’t require expensive custom orchestration. They require discipline about where you place the why.