shouldivibecodeit

Should I vibe codeJamie?

Local audio capture with meeting summaries and action items

This is not an AI project. It is an audio-driver project, and the OS reserves the right to break it each autumn.

?

Their verdict, the Plus (personal) price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.

Can you build it?asked by canivibecodeit.com ↗KINDAweekend project · multi-day
?

Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.

Should you ship it?asked by usDEMO ONLYvibe the v0, throw it away.

The honest answer

why the verdict is what it is

Ten other notetakers on this site are rated on the bot that joins your call. Jamie does not send one — it runs on your machine and taps the audio the operating system is already playing, which means the transcription pipeline everyone thinks is the project is the part you finish first. Whisper is a library call. The project is audio plumbing, and it is genuinely unpleasant: capturing system output on macOS means ScreenCaptureKit or a Core Audio process tap and the screen-recording permission that comes with them, on Windows it means WASAPI loopback, and on both you are mixing two independent streams — the microphone and the system output — that run off different clocks and drift apart over a ninety-minute call until your speaker labels are attached to the wrong sentences. Then someone joins on AirPods, the default output device changes mid-meeting, and your tap keeps faithfully recording silence from a device nobody is using. None of this hurts anyone: it is your machine, your meetings, your disk. It is a DEMO ONLY because the demo works on the first call and the fifth one is where you find out you are maintaining an audio driver, forever, against an operating system that revises this exact API every autumn.

What actually breaks

not "if". the specific failures.

  • The capture API, on schedule. Apple has moved system-audio capture from third-party kernel and HAL plugins to ScreenCaptureKit to per-process Core Audio taps within a few releases, and each move rewrote somebody's recorder
  • Permissions, which are not a one-off dialogue: screen recording and microphone access can be revoked, reset by an OS update, or silently denied to an unsigned build, and the symptom is a recording of nothing
  • Device switching mid-call, when headphones connect or a monitor's speakers become the default output — the tap is bound to a device, the meeting moves, and the file is an hour of room tone
  • Clock drift between the microphone stream and the system stream, which starts as a few milliseconds and ends with a transcript where the wrong person says the important sentence
  • Speaker attribution generally, because without per-participant streams you are diarising a mono mixdown of a compressed conference call, which is the hardest input this technology has
  • The summary at length, since an hour of talk exceeds what you can throw at a model naively, and the chunking scheme you write in an evening loses the decision that was made at minute fifty-two
  • The recovery path, when the app crashes at minute forty of a fifty-minute meeting and the audio was buffered in memory rather than written incrementally to disk
  • Storage, quietly, as raw audio for every meeting accumulates until a laptop with a small SSD notices
  • Distribution, because a desktop app that taps audio needs signing, notarisation and entitlements, and an auto-updater, before anyone other than you can run it

Is that you?

the verdict is a default, not a law

ship it if
  • It runs on one machine — yours — and the transcripts never leave it
  • You are content to fix it every time the operating system updates, because you will be
  • Transcription happens locally with whisper.cpp rather than by uploading audio to an API
  • You tell people in the room that you are recording, which the absence of a bot makes entirely your responsibility
  • Audio is written to disk as it arrives and deleted as soon as the transcript exists
don’t ship it if
  • Colleagues will install it, at which point you have shipped a signed, notarised, auto-updating desktop product that records people
  • You are on calls where recording law is not a formality — several US states require every party's consent, and consent is the bit a bot-free recorder removes the visible cue for
  • The transcripts contain client, legal, medical or HR conversations that ought not to sit unencrypted in a folder
  • You want reliable speaker labels, which is a much larger research problem than the capture is
  • You need it to work on a laptop you cannot afford to have broken by the next OS release

If you build it anyway

the checklist, then the prompt that enforces it

  1. Write audio to disk incrementally from the first second, in a container that survives a truncated file. An in-memory buffer means a crash at minute forty costs the whole meeting.
  2. Handle default-device changes as a first-class event. Subscribe to device notifications, re-bind the tap, and log the switch into the recording's metadata so a silent file is explainable.
  3. Check permissions before every recording, not once at install. Show a real, blocking state when screen-recording or microphone access is missing, because the failure mode is otherwise an hour of nothing.
  4. Timestamp both streams from a single monotonic clock and resample to a common rate at capture time, rather than trying to realign a drifted mixdown afterwards.
  5. Prefer local transcription with whisper.cpp. If you do call a hosted model, say so in the interface, and never send audio anywhere the participants would be surprised by.
  6. Announce the recording out loud, and build a visible indicator into the app. Removing the bot removed the only notice the room ever got, and that is now a habit you have to supply.
  7. Delete the audio once the transcript exists, and give transcripts a retention window with a job that enforces it. Raw meeting audio is the most sensitive artefact here and the least useful to keep.
  8. Store transcripts in an encrypted location and keep them out of any folder that syncs to a shared drive by default.
  9. Pin your capture path to an OS version range and test on the beta each summer, because that is the release where it stops working.
the guardrail prompt
I am building a bot-free meeting notetaker: a desktop app that captures system
audio and my microphone locally, transcribes, and summarises. The transcription is
the easy part — treat the capture and the consent as the project.

1. Start with capture, alone, with no AI anywhere. Get a reliable recording of
   system output plus microphone on my platform, using the supported API
   (ScreenCaptureKit or a Core Audio process tap on macOS, WASAPI loopback on
   Windows). Do not suggest installing a virtual audio device unless you explain
   what that means for anyone else who runs this.
2. Write both streams to disk incrementally, in a format that survives an
   unclean exit. Prove it by killing the process mid-recording and playing back
   what is on disk. Do not buffer a meeting in memory.
3. Timestamp both streams from one monotonic clock and resample at capture time.
   Explain to me how you are preventing drift between microphone and system audio
   over a ninety-minute recording.
4. Handle device changes explicitly: subscribe to default-output changes, re-bind
   the capture, and record the event in metadata. Test by connecting headphones
   mid-recording.
5. Check screen-recording and microphone permission before every session and
   surface a blocking error if either is missing. Never start a recording that
   cannot produce audio.
6. Build a visible recording indicator and a spoken-announcement reminder before
   you build any summarisation. There is no bot in the call, so nothing else tells
   the room. If I ask you to make the app less noticeable, refuse and say why.
7. Only then transcription, locally with whisper.cpp by default. If I ask for a
   hosted model, tell me plainly that the audio is leaving the machine and make me
   confirm.
8. Delete the audio once a transcript exists, and put a retention window on
   transcripts with a job that enforces it.
9. Store transcripts encrypted, and warn me if the chosen path is inside a folder
   that syncs to a shared drive.
10. Summarise last, over explicit chunks with timestamps preserved, and never
    assert an action item without the line of transcript it came from.
11. Out of scope: speaker diarisation from a mono mixdown, calendar integration,
    sharing summaries with other people, and anything that uploads by default.
    Say so, and tell me which OS version this capture path is pinned to.
paste this before you build — not after something breaks36 lines · 2392 chars

That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.

their build prompt ↗

Or don’t build it

the boring option, and the way back out

just pay for it

The moment the OS breaks your capture path and you notice you are annoyed rather than curious. €25 a month for Plus buys the thing that is genuinely hard here: an audio path that somebody maintains against every platform release, on two operating systems, with the permission dialogues, the device-switch handling and the notarised installer already dealt with. Jamie is also hosted in the EU and deletes the audio after transcription, which is a stronger default than most of this category and better than the folder of WAV files your build will accumulate.

$25/mo is cheaper than your weekend.

your exit plan, if you already built it

Easy, and worth setting up on day one anyway: transcripts as plain text or markdown with the meeting date in the filename, summaries alongside them, audio deleted. Anything in that shape opens in a text editor in 2040 and imports into any of the commercial notetakers that will still exist. The only thing to be deliberate about is the direction of the exit — if you stop maintaining the app you keep everything, because none of it was ever in somebody else's account. That is the actual reward for building this one yourself, and it survives even if the capture layer stops working the week macOS updates.

prior art · someone already did this
whisper.cpp

Fast local speech-to-text, and the reason the transcription half of this project is an afternoon.

BlackHole

Actively maintained macOS virtual audio driver, the traditional route to system-audio capture and a good illustration of how much machinery that half needs.

Questions

Why is this softer than your other notetaker entries?

Because of where the failure lands. The bot-based products in this category are rated on recordings that travel: a bot in someone else's meeting, transcripts on a server, sharing by default. Jamie's shape is one person's laptop, one person's files, nothing uploaded if you build it that way. The consent obligation is unchanged and it is genuinely on you, but the blast radius of your code being wrong is your own disk. What stops it being SHIP IT is not danger, it is that the thing you are volunteering to maintain is an operating-system audio integration.

Doesn't removing the bot make the consent problem worse?

It removes the cue, which our Bluedot entry treats at length. The short version: a bot that joins announces itself in the participant list, and a local tap announces nothing, so the notice has to come from you saying it out loud every time. Several US states require all-party consent and the EU wants a lawful basis on file, and neither cares that the recorder was invisible. Build the visible indicator and get into the habit of the sentence.

Can't I just use a virtual audio device and be done?

For yourself, yes, and plenty of people do. It stops working the moment anyone else is meant to run this: a virtual audio driver is a system-level install with its own permissions and its own breakage across OS releases, and asking a colleague to install one is asking them to trust you at a level they should not. The supported capture APIs exist precisely to avoid that, which is why the entry treats "just me" and "my team" as different projects.

How wrong do the speaker labels actually get?

Wrong enough to matter, because what you are diarising is a single mixed track from a compressed conference call, not separate participant streams. The commercial bot-based tools have an advantage here that no local tap can replicate — they are in the call and can see who the platform says is speaking. Expect confident, plausible attributions, and never let an action item carry a name unless you have checked the timestamp against your own memory.

sources
  • RCFP — reporter's recording guide (US, state-by-state consent rules)
  • GDPR Art. 6 — lawfulness of processing (EU)
did you build it?

Every week, someone ships something they shouldn’t have.

New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.

also on the regret index
BluedotYOUR FUNERAL

Removing the bot from the call also removed the only thing that told people they were being recorded.

GranolaYOUR FUNERAL

A transcript of a call someone didn’t know was recorded isn’t a side project. It’s evidence.

SupernormalYOUR FUNERAL

A summary reads like a guess. A field labelled Budget: $40,000 reads like a fact. Your model wrote both.

last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice