Should I vibe code
Capture notes quickly and retrieve them through semantic search and related-memory suggestions
Semantic search over fifty notes is magic. Over five thousand it's a ranking problem you have no way to measure.
?
Their verdict, the Mem Pro price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Retrieval over your own notes has become a genuinely small program — a capture box, an embedding call, a vector index and a model that answers over the top ten hits. You will have it working before dinner and it will feel like magic, because your first fifty notes are all about the same three things and everything is related to everything. The trouble shows up around note two thousand, when "related memories" starts confidently surfacing the wrong neighbours and you have no way to tell whether retrieval got worse, because you never built an evaluation set and almost nobody does. That ranking, tuned against corpora far larger than yours, is Mem's actual product. The stakes stay low throughout — your notes, your machine, nobody else's problem — so build it. Just keep the notes as files, because the day you change embedding model you are reindexing everything, and the day you lose interest you would like your writing back.
What actually breaks
not "if". the specific failures.
- Retrieval quality as the corpus grows, silently, with nothing in the system that would tell you it had
- The embedding model, which you will eventually change, at which point every vector in the store is meaningless and the whole archive needs recomputing
- Chunking, which quietly decides what is findable at all — get it wrong and a note exists but cannot be reached by any query you would think to type
- Capture friction, which is the entire reason people pay for this: Mem takes two seconds, and the version where you alt-tab and wait for an embedding takes six
- An answer that cites a note you deleted last month, because the vector index and the note store drifted apart and nothing reconciles them
- An assistant with read access to your calendar and inbox, which will cheerfully follow instructions written into a meeting invite by someone else
- Your notes as rows in a schema only this app understands, which is how a second brain quietly becomes a hostage
Is that you?
the verdict is a default, not a law
- The notes are yours, the index is on your machine, and nothing syncs anywhere you have not chosen
- Markdown files on disk are the record and the database is a derived index you can throw away and rebuild
- Every answer cites the notes it came from, and clicking a citation opens the actual note
- You are happy to be the only user, forever
- Other people's notes go into it, at which point the retrieval failures become theirs
- It gets write access to anything — files, email, calendar, a shell — on the strength of an LLM's judgement
- The notes exist only inside the app's own database, with no export you have actually tested
- You need it to be right rather than useful, and cannot tell the difference from the UI
If you build it anyway
the checklist, then the prompt that enforces it
- Files first, index second. Markdown on disk is the durable artefact; the vector store is a cache you should be able to delete and rebuild in one command without losing a word.
- Store the embedding model name and version with every vector. Without it, the day you switch models you cannot tell which rows are stale and the collection silently becomes a mix of two vector spaces.
- Make retrieval inspectable: show which chunks were retrieved and their scores next to every answer. It is the only feedback loop you will ever get on whether it is working.
- Build a tiny evaluation set early — thirty questions with the notes you know should come back — and rerun it whenever you touch chunking, the model or the ranking. Twenty minutes of work buys the only evidence you will have.
- Reconcile deletes. Removing a note has to remove its chunks, its vectors and its index entries, or the assistant will keep quoting things you deleted.
- Give the assistant read access and nothing else. If it can send, delete or execute, a poisoned calendar invite or a pasted web page becomes a command channel into your notes.
- Optimise capture before you optimise retrieval. A second brain you do not put things into is a schema, not a tool.
I am building a personal notes app with semantic search and an assistant that answers over my own notes. Treat retrieval quality and data durability as the real problems and push back when I chase features instead.
1. Before anything else, fix the storage model: Markdown files on disk with YAML front
matter are the record. The database and vector store are derived caches.
2. Write the "rebuild the whole index from the files" command second, before any UI, and make
sure it is the way I recover from every future mistake.
3. Store the embedding model name and dimension alongside every vector, and refuse to query
across mixed model versions. Explain why a silent model swap corrupts the results rather than breaking them.
4. Make chunking an explicit, configurable step and show me sample chunks for three real
notes before indexing anything.
5. Every answer must cite the chunks it used, with scores, and each citation must open the
underlying file. No uncited answers.
6. Build a thirty-question evaluation set with expected notes, and a command that reruns it.
Tell me the pass rate whenever chunking, the model or the ranking changes.
7. Deleting a note deletes its chunks, vectors and index rows in the same operation. Add a
test that queries for the deleted text afterwards.
8. Optimise capture before retrieval: a global hotkey to a plain text box that saves in under
a second, with enrichment happening in the background.
9. Give the assistant read-only access. Refuse to give it send, delete or shell capability,
and say that untrusted text — a web page, a calendar invite — becomes a command channel the moment it can act.
10. Default to local inference and a local index. If I ask for a hosted API, tell me that
provider's retention policy first.
11. Out of scope unless I ask again: sharing, multi-user, and anything that puts someone
else's notes in the same index as mine.
12. Finish by telling me what my exit looks like: a folder of Markdown files that any other
tool can read.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
You want the retrieval to be good rather than yours. $12 a month buys ranking that has been tuned against a lot more text than you will ever write, a capture path measured in milliseconds, and an iOS app on the day you need one. The self-built version wins on the two axes that actually matter for notes: your data never leaves the machine, and it is still readable in ten years.
$12/mo is cheaper than your weekend.
One folder, one file per note, Markdown with YAML front matter for tags, dates and links. Everything else — embeddings, index, graph, chat history — is derived and disposable. Do that and the corpus outlives the tool: any future app indexes it in a single pass and any future model re-embeds it overnight. Do the opposite, and your exit is a SQLite file with a BLOB column and three years of writing you can technically still read.
Self-hostable AI second brain that searches and chats over your own documents with local or hosted models.
Active open-source workspace with local-first documents and databases.
Questions
canivibecodeit says one sitting. Is that right?
For the demo, yes — a capture box, embeddings, a vector index and an answer endpoint is genuinely an evening now, and there are enough templates that you may not write much of it. What is not an evening is the second half: chunking you can defend, an evaluation set, delete reconciliation, and a capture path fast enough that you actually use it. Those are what make the difference between a toy and a tool, and none of them are fun.
How would I even know retrieval had got worse?
You wouldn't, which is the point. A semantic search always returns ten results and they always look reasonable, so degradation reads as "I guess that note wasn't relevant". The only cure is boring: write down thirty questions and the notes that should come back, and rerun them whenever you change anything. It takes twenty minutes and it is the single highest-value thing in this entry.
Why does the assistant's write access matter for a personal app?
Because the text going into it is not all yours. A calendar invite, a forwarded email, a web page you clipped — any of them can contain instructions, and a model reading them as context does not reliably distinguish your intent from theirs. Read-only, the worst case is a bad answer. With send or delete, the worst case is your notes acting on somebody else's sentence.
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.
E2EE and an AI that reads your notes pull opposite ways. The homemade version resolves it by keeping your key.
A supertag is a type. Which makes your notes app a schema, and schemas don't have weekends — they have migrations.
Beautiful documents are a typography problem, and typography does not respond to prompting.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice