DEV Community: Olivia Lee

Building a lightweight note-taking workflow with AI transcription

Olivia Lee — Sun, 06 Sep 2026 13:02:21 +0000

A lightweight note-taking workflow needs exactly three properties: capture that finishes in under five seconds, storage as plain files you control, and retrieval that works with grep. Anything that misses one of the three gets abandoned within a month, and the one that gets missed most often is the first.

This is for developers who have set up a note system, used it enthusiastically for three weeks, and then quietly stopped. The reason is almost never the organisation scheme. It is the friction at the moment of capture, which is the only moment that has to compete with whatever you were actually doing.

The short version

Notes fail at capture, not at organisation. If recording a thought costs more than a few seconds of attention, you stop recording thoughts.
Voice is the only input that does not require you to leave what you are doing.
Export to Markdown immediately. A transcript locked inside a product is a note you will lose when you switch products.
Grep is the entire search system. If your notes are plain text in one directory, you do not need anything else.

What makes a lightweight note-taking workflow survive past week three?

Three properties, and they are not the ones most setups optimise for.

Property	The test	What fails without it
Capture under five seconds	Can you record a thought without stopping what you are doing?	You stop capturing. The system is empty by week three
Plain files you control	If the app shut down tomorrow, do you still have the notes?	Migration cost keeps you in a tool you no longer like
Retrieval by grep	Can you find a note without remembering where you filed it?	You build folders and tags, then stop trusting them

Look at what is not on that list. Backlinks, graph views, nested tags, templates and daily-note automations are all downstream of having notes in the first place. A beautiful vault with nine entries is not a note system; it is a screenshot.

The reason capture is the binding constraint is worth stating plainly. A thought arrives while you are mid-debug, mid-review or mid-conversation. Recording it in text costs a context switch, and a context switch costs the thing you were doing. Faced with that trade, most people choose the work and lose the note, which is the correct local decision and a terrible aggregate one.

There is a second-order effect that makes it worse. The thoughts most worth keeping tend to arrive at the worst moments: mid-debug, when you notice the real cause of a bug you were not looking for; mid-review, when you spot the pattern that explains three other complaints; mid-conversation, when someone says the thing that changes the design. Those are precisely the moments with the highest switching cost. So the capture friction does not filter randomly. It filters out your best notes first.

Capture: the only input that works while your hands are busy

Typing a note requires you to stop. That is the entire problem, and no keyboard shortcut fixes it.

Voice does not have that property. You can describe a thought while your hands stay on the keyboard, while you are walking to a meeting, or while you are waiting for a build. The cost is roughly the cost of saying the sentence out loud, which is where the five second target comes from.

The practical setup is a recorder that also transcribes, so that the audio never becomes a second thing to process. Record in the browser or upload the file afterwards, and let it come back as text with a summary and the action items separated out. If you want one, https://vomo.ai does this and exports the result as Markdown, which matters for the next section more than any of its other features do.

One honest caveat, because tool posts usually skip it. Automatic transcription is reliable on ordinary speech and unreliable on exactly the words a developer note is made of: library names, flags, error strings, anything camelCase. Budget thirty seconds to fix those before the note goes into your directory. Filler words and punctuation do not matter, because you are not going to read this note top to bottom. You are going to grep it.

Two habits make the correction pass shorter. Say technical names slowly and, when it matters, spell the unusual ones: the two seconds you spend saying "P-K-C-E" are cheaper than the thirty you spend guessing what "pixie" meant. And say the context before the thought, not after. "About the retry logic in the payment worker" at the front of a recording is the line you will search for later, and putting it first means the transcript begins with it rather than burying it at the end where you have to read the whole thing to find it.

Storage: files over app

Once the note is text, put it in a file you own and stop thinking about it.

Steph Ango, who runs Obsidian, wrote the clearest statement of this principle in an essay called File over app: "In the fullness of time, the files you create are more important than the tools you use to create them. Apps are ephemeral, but your files have a chance to last." His condition for durability is worth quoting too: "if you want to create digital artifacts that last, they must be files you can control, in formats that are easy to retrieve and read."

That rules out leaving your notes inside a transcription product's library, which is where most voice notes end up. The recording tool is a capture device. It is not a filing cabinet, and treating it as one recreates the migration problem you were trying to avoid.

A structure that has no moving parts:

notes/
  2026-09-04-cache-invalidation-idea.md
  2026-09-04-standup-blocked-on-oauth.md
  2026-09-03-review-notes-payments-pr.md

One directory, no subfolders, date first, three or four words of topic. Markdown because it is specified, plain, and readable by anything. No nesting, because a hierarchy is a decision you have to make at capture time, and decisions at capture time are what this whole workflow is trying to remove.

Retrieval: grep is the entire search system

If the notes are plain text in one directory, search is already solved.

rg -i "oauth" ~/notes/
rg -i "cache" ~/notes/ -l
rg -i "blocked" ~/notes/ --sort path

ripgrep searches the whole directory faster than a note app opens, and it is already installed on most developer machines. The second command lists filenames only, which is usually what you want when you are trying to remember whether you wrote something down at all.

This is the argument against tags and folders, and it is not an aesthetic one. Tags require you to predict, at capture time, the category you will search by later. That prediction is usually wrong, and a wrong tag is worse than no tag because it makes the folder look organised. Full text search asks you to remember a word that was actually in the note, which is a much easier thing to remember.

The one thing worth adding by hand is a first line that says what the note is about in the words you would search with. Not a title, a search key. "Cache invalidation on the pricing endpoint" beats "idea" by an enormous margin, and it costs four seconds.

Worth being clear about the limits of this. Grep finds strings, not meaning: it will not surface the note you wrote about "invalidation" when you search for "cache busting", and no amount of discipline fixes that entirely. The mitigation is boring and effective, which is to write the search key with the words you actually use at work rather than the words that sound canonical. If your team says "the pricing endpoint" and never says "the rate service", write "the pricing endpoint". Your future search will use your own vocabulary, not the documentation's.

FAQ

Why not just use Obsidian or Notion?

Use them if you like them. Obsidian in particular stores plain Markdown files in a directory, which satisfies two of the three properties on its own. The point of this post is not tool selection: it is that whatever you use has to solve capture, and most setups solve organisation instead. If your tool of choice has a fast enough capture path, you are already done.

Does the audio need to be kept?

Usually not. Once you have corrected the technical terms, the text contains everything you will ever look for and the audio is thirty times the size. Keep the recording only for the conversations you might need to quote, and let the rest go.

What about longer things, like a whole meeting?

Different problem. This workflow is built for single thoughts, which are short and arrive unpredictably. A recorded meeting produces a long document with several speakers, and it needs its own header, its own structure and probably its own place to live. Do not put it in the same directory: it will drown the short notes in search results, which quietly breaks the retrieval property.

Whisper-powered transcription, explained: what actually happens to your audio

Olivia Lee — Sat, 11 Jul 2026 16:22:18 +0000

If you have used any AI transcription tool in the last two years, there is a good chance a Whisper-family model did the heavy lifting under the hood. OpenAI's release in 2022 reset expectations for open speech recognition, and the architecture is worth understanding whether you are wiring it into a product or just curious why the output got so good so fast.

This is a walk through what happens between "audio file" and "text," at the level of detail a developer actually wants. No math beyond what clarifies the idea.

Step one: audio becomes a picture

A model does not consume raw waveform samples directly. The first thing that happens is a conversion into a log-Mel spectrogram, which is a 2D representation of the audio: time on one axis, frequency on the other, intensity as the value.

Whisper resamples everything to 16 kHz and computes an 80-channel log-Mel spectrogram using 25-millisecond windows with a 10-millisecond stride. In plain terms, it slices the audio into heavily overlapping short frames and, for each frame, measures how much energy sits in each of 80 frequency bands, on a scale tuned to roughly match how human hearing weights pitch. The result is an image-like tensor, and treating speech as an image is a large part of why convolutional and transformer machinery works on it at all.

Step two: the 30-second window

Whisper processes audio in 30-second chunks. That is a fixed architectural choice, not a preference. Shorter clips get padded to 30 seconds; longer files get split and stitched back together afterward.

This detail explains a class of bugs you will hit if you build on raw Whisper. If a chunk boundary lands in the middle of a word, or in the middle of a sentence, the model can lose the thread at the seam. Production systems put a voice activity detection pass in front, so cuts happen during natural pauses rather than mid-syllable. If you have ever seen a repeated phrase or a dropped word at a suspiciously round timestamp, a naive 30-second split is a prime suspect.

Step three: encoder to decoder

The spectrogram goes into an encoder: two convolutional layers, positional encoding, then a stack of transformer blocks. The encoder's job is to turn the acoustic picture into a sequence of internal representations that capture what was said, independent of who said it or in what language.

A decoder then generates text tokens autoregressively, one at a time, attending to the encoder output. This is the same encoder-decoder transformer shape you have seen in translation models, which is not a coincidence. Whisper was trained partly on translation, so the machinery is shared.

Step four: the multitask trick

Here is the elegant part. Whisper does not run separate models for "detect the language," "transcribe," "translate," and "find the timestamps." It folds all of that into one decoder using special tokens at the start of the sequence.

The decoder is prompted with tokens that say, in effect, "this is the transcription task, the language is Spanish, include timestamps," and it conditions its output on those instructions. Swap the task token and the same model translates instead of transcribing. This is how a single set of weights, trained on around 680,000 hours of weakly supervised multilingual audio, covers 50-plus languages and collapses what used to be a whole pipeline of separate components into one forward pass.

That training approach matters too. "Weakly supervised" means it learned from a huge pile of imperfect, real-world transcripts scraped from the internet rather than a small, pristine, hand-labeled set. The messiness is a feature. It is why the model tolerates accents, background noise, and cross-talk far better than earlier systems trained on clean studio data.

From model to product

Raw Whisper gives you a transcript. Turning that into something a non-engineer wants involves several stages the base model does not handle: punctuation and casing cleanup, speaker diarization (Whisper does not tell you who spoke), and a language-model layer that summarizes and pulls out structure.

If you would rather consume the finished chain than assemble it, a tool like Vomo's audio to text wraps the whole thing: upload or paste a link, get a speaker-labeled transcript at 95%+ accuracy plus a generated summary, chapters, and action items, with the option to query the transcript conversationally. Useful as a reference implementation for what "done" looks like, even if you end up building your own.

The base architecture is stable and well understood now. Most of the interesting engineering in 2026 has moved to the layers around it: cutting latency toward real time, and feeding domain vocabulary in so the model stops mangling your product names. The recognition problem is largely solved. Everything on top of it is still wide open.