Filing bugs at the speed of speech

The clip above is a real bug report. I recorded my screen for about 50 seconds and talked over it, the review queue was rendering broken and I said so while clicking through it. I never typed a word about this bug. By the next morning it was fixed, while I slept.

This is the story of how bug reports got that cheap.

Engram was going great, and that was the problem

Engram is my personal memory system, and at the time it was moving fast. The build process had a night shift: during the day I sit with an agent, we break work down into GitHub issues with all the details, and at night, when my laptop is off, a cloud routine clones the repo and works through whatever is waiting. Most mornings something is done before I am. How that routine came to be is a story for another post.

Then I started the first UI. I was at state zero, no UI existed at all. The design came out of one very long session, and it was heavy. When I say heavy, I mean a first MVP carrying a lot of features, because when you start from scratch there is nothing to lean on. I handed the design to an agent the way you would hand a Figma file to a builder, I basically said, you have the design, assume it is right, go build it. And I went away.

When I came back it had built the whole thing. It had also built a lot of bugs, which honestly was fine, that is how it goes, a design on paper always assumes things the real app refuses to do. I walked through the new UI once and I could already count 15 to 20 bugs.

Then I realised, oh shit, now I have to explain all of these. My method at the time was chat. Describe a bug in words, attach a screenshot, hey this is one bug, here is another one, it should have looked like this. Finding the bugs took minutes. Filing them this way would have eaten the rest of my day, and I am shipping quite a few things, life is hectic. So there I was with a pipeline that fixed bugs overnight, and it was starving, because feeding it was manual.

Waste time once

I try to follow one rule: automate everything, especially the annoying parts. If something costs me minutes every single day, I will happily spend a day killing it. It always feels wrong in the moment, stopping real work to build process, and it has paid for itself every time. The whole night shift exists because of this rule. So the bug-filing bottleneck was not really a bug-filing problem, it was the next thing in line to automate.

And the shape of the fix was sitting right there. Engram is supposed to be my database layer. If it can hold anything I give it, it can hold a screen recording. So the contract I wanted was this. I record the screen and talk. I click on the broken thing and say what should have happened, when I click on this, this is not happening, when I search for this, the search is broken. One or two related bugs per clip, never more, otherwise the clip buries its own findings. And when I stop recording, the only thing I owe the system is a file path.

What we wrote down first

Like everything else here, this started as a written-down GitHub issue, requirements first, before any code.

The first thing we wrote was an honest question: is this worth building at all? GitHub issues already take video attachments, drag, drop, done, zero effort. If all I wanted was a video stuck to an issue, the feature already existed. What I actually wanted was different, and writing it down made it sharp: the recording should live in Engram as durable context, searchable next to everything else I know, and the issue and the recording should link to each other both ways. A GitHub attachment is a file on a ticket. An Engram capture is evidence I can find again in a year.

The second thing that felt important: the whole flow had to cost one path, nothing else. No forms, no manual transcription, no "please describe the steps to reproduce". The recording already contains the steps to reproduce, I literally perform them on camera.

And we wrote down one honest blocker. Nothing in the stack could turn my narration into text. The agent could read images and PDFs but not audio, so it could not derive repro steps from a video on its own. Something had to produce a transcript. Two options went into the issue: run Whisper locally, free per use but a setup to maintain, or call a cloud model per video, simple to wire but a cost every time.

How it actually got built

It came in two pieces.

First the media lane, the general half. Any audio or video that lands in Engram gets a transcript and a caption written next to it, automatically, landing is enough. This is the piece that answered the blocker, and we went cloud, and cheap: Gemini's flash-lite tier. Transcription is mechanical work, exactly the place where the cheapest model that clears the bar wins, and it kept my machine free of a Whisper setup to maintain.

The implementation had its war stories, as these things do. The model we planned as the default turned out to return 404 for newly created API keys, the whole model family did, so the default that shipped came out of the first live eval instead. Gemini also rejects the standard QuickTime mime type, video/quicktime gets HTTP 400, it wants the non-standard video/mov, so the lane converts it on the way out, and Engram keeps the real file type on its side. And two paranoia rules made it in: a video is never buffered into the server's RAM on its way to the provider, and anything longer than 30 minutes gets rejected, and it says why, instead of disappearing quietly. If the API key is missing, the lane just skips, no crash, no retry loop.

Then the skill, the specific half. I hand it a path. It probes the file, captures a bug entity in Engram, uploads the recording, and lets the media lane write the transcript. Then it files a GitHub bug issue whose repro steps come from what I clicked and what I said, with timestamps, and it links the issue and the recording to each other. From there the night shift takes over.

One chain, end to end

Here is a real one from the archive, the same bug as the clip at the top.

The flow filed an issue titled "Review-queue grouped layout renders corrupted", and its repro steps cite my recording by timestamp: "[00:03]–[00:19] in the linked recording shows clear headers, distinct document grouping, and working accept/reject buttons with a rationale line. … [00:38] onward shows the broken state — overlapping or misaligned text and list items, content effectively unreadable." The night routine picked it up and opened a pull request, and by the morning the layout was fixed.

I cropped the bottom off that one. The evidence section is where the issue points back at the recording, and it names the capture by id, which is mine and stays mine.

The title says it closes a different issue number than the one above. One dropped brace broke two things I had reported separately, so the fix landed against the other one. I would rather show you that than crop it and hand you a tidier story.

Most of my bug clips run 20 to 80 seconds. That is the entire cost of a bug report now, and honestly it is the most natural way to explain a UI bug anyway, you point at the thing while it is misbehaving.

The trade, again

The media lane built for bug reports now transcribes everything else I give Engram too, voice notes, walkthroughs, journal entries.

And every clip still ends the same way. I say the bug out loud, I paste a path, and I go do something else. Morning handles the rest :)

Next in this series: the night shift itself, why a queue of GitHub issues became the center of how I build, and how the routine that works it runs.