• Signal: Claude Code produced a working multi-device acoustic localizer, and the author reports it found the beep source to within about 40 cm.
• The first version was written without being run; the working system came from live iteration against real devices.
• One planned feature, device self-positioning by sound, worked poorly and was replaced by manual rough placement.
• The evidence is one room and one author, with no baseline against a manual search and no error distribution.
• The README documents hard constraints: HTTPS for phone microphones, mirror-image ambiguity, and clock mapping accurate only to tens of milliseconds.

A coding agent built a tool that located an intermittently beeping device in a cluttered room, and the result held up in the one test that matters: the author reports finding a carbon monoxide detector with dead batteries within about 40 cm of the estimate. The project, Beep Locator, is documented in a blog post and an open repository. Both are first-party, so this is a credible proof of concept, not an independent evaluation.

How the system works

Beep Locator turns spare devices into a microphone array. Each listener keeps a rolling 60-second audio buffer in the browser, flags candidate beeps with an FFT-based detector, and reports them to a Python server. The server has the nearest device play a chirp so every uploaded clip can be aligned in time, and the arrival differences feed a location estimate. Per the repository README, everything runs on WebAudio and WebSockets, and the design follows the 2007 BeepBeep acoustic ranging paper.

What Claude Code did, and what needed a human

Claude Code wrote the first version from a problem description, including reading the BeepBeep paper, but nothing had been run at that point, according to the author. Debugging then happened live: the server could push new JavaScript to connected devices without reloading pages, which avoided re-granting microphone permission. One design element failed: having devices ping each other to map their own positions worked poorly, so a manual rough-placement mode was added. The tool needed human judgment and a hand-placed layout to work.

Where it breaks

The README lists real constraints. Phones need HTTPS to open the microphone, so setup relies on cloudflared tunnels. Listeners need volume up, silent mode off and the screen on. Distances alone cannot separate a room from its mirror image, so the map must be flipped by hand. Device-to-server clock mapping is only accurate to tens of milliseconds. The author's own interface warns when arrival times are physically impossible, which can signal echo or a different sound source.

Verdict: a credible proof of concept, not a benchmark

Treat this as feasibility, not measured performance. The reported outcome was a location within about 40 cm, and a dead-battery detector in that pile of boxes. That is one room, one author, no baseline against searching by hand, and no error distribution. Anyone needing repeatable accuracy, or a locator for safety-critical devices, should not rely on it. The signal is the workflow: an agent with a live feedback loop on real hardware. We could not independently reproduce the run.