Should I vibe code
Save user-provided sources, summarize them, and build a linked personal knowledge graph
It summarises a page you will never open again. Later you cite the summary as if you read the page.
?
Their verdict, the Plus 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
Worth saying first: this is the browser-based knowledge tool, not a meeting recorder, and it has moved from recall.wiki to recall.it since the entry was imported. Nothing here endangers anyone but you, and the save-a-link-and-summarise-it loop really is one sitting. Two things make it a demo rather than a keeper. The first is extraction, which is not a feature but a war: paywalls, cookie walls, lazy-loaded article bodies, PDFs that are scanned images, and YouTube transcripts that come from an endpoint with no stability promise. Every one of those is a Tuesday you did not plan. The second is subtler and specific to the AI part — you are pasting arbitrary web pages into a model and filing the output as your own notes. The summary is a claim about a document you will never open again, so a confident, wrong one becomes a memory you cite. And a page that contains instructions aimed at the model is now writing into your knowledge base. Build it, use it, and keep the original text next to every summary.
What actually breaks
not "if". the specific failures.
- Extraction, which is the whole product: cookie walls, paywalls, lazy-loaded bodies, infinite-scroll comment threads and PDFs that turn out to be scanned images
- YouTube transcripts, which come from an interface with no stability commitment and stop working without warning at least once a year
- The summary itself, which is confident regardless of whether it understood the page, and which you will trust more the longer it has been since you read the source
- Prompt injection, because a page you saved can contain text addressed to your model, and the output of that goes straight into your notes with no reader in between
- A fetcher that follows user-supplied URLs, which is a server-side request forgery hole the moment it runs anywhere other than your own laptop
- The knowledge graph, which is beautiful at fifty items, unreadable at five hundred, and quietly the least useful part at five thousand
- Auto-tagging, which drifts — the same article filed under three near-identical tags six months apart, and no way to notice
- Model costs, when a bulk import of two thousand bookmarks summarises every one of them at full length before you think to check the bill
- The archive, if you stored only summaries: the original page is gone, the site has redesigned, and you cannot verify the thing your notes assert
Is that you?
the verdict is a default, not a law
- It runs locally, for you, over things you personally saved
- It stores the extracted source text alongside every summary, permanently
- Everything lives in plain files — markdown or JSON — that another tool could read tomorrow
- You treat the summaries as an index into the sources rather than a replacement for them
- Other people save into it, which turns your fetcher into a service that visits URLs strangers choose
- You only keep the summary and discard the source, because then a hallucination is indistinguishable from a fact
- The output ever feeds something automated — a newsletter, a report, a post — without a human reading the original
- There is no export, and a year of reading exists only inside your own schema
If you build it anyway
the checklist, then the prompt that enforces it
- Store the extracted source text, not just the summary. It costs almost nothing, it is the only thing that makes a summary checkable, and it is what survives when the page is gone.
- Show provenance on every generated line: which document, which model, which date. A note you cannot trace back to a source is a rumour you wrote yourself.
- Treat fetched page content as untrusted input to the model. Put it in a clearly delimited block, instruct the model to ignore instructions inside it, and never let a summary trigger an action.
- If anything fetches URLs server-side, block private address ranges, redirects into them, and non-HTTP schemes. A read-later tool with an open fetcher is an SSRF endpoint with a nice UI.
- Write export before import. Markdown files with front matter, one per item, in a folder — then a bulk import cannot trap a year of reading inside your schema.
- Cap spend per import and per day, and default bulk operations to the cheapest summary length. The two-thousand-bookmark import is the bill nobody predicts.
- Make auto-tagging suggest rather than apply, or at least keep it reviewable in bulk, because tag drift is invisible until the taxonomy is useless.
- Keep the knowledge graph as a view, not as the storage model. Links are cheap to recompute and expensive to migrate.
I am building a personal read-later and knowledge tool: save articles, videos and PDFs, summarise them with an LLM, tag them automatically and link them into a graph. The failure I care about is ending up with a library of confident summaries I cannot verify, so build for provenance and portability first.
1. Store the full extracted source text for every saved item, permanently, alongside any
summary. If storage is a concern, say so, but do not default to discarding the source.
2. Every generated artefact — summary, tag, link, answer — records the source document ids,
the model and the date. Nothing generated is displayed without that trail.
3. Build export before anything else: one markdown file per item with YAML front matter, in a
plain folder, plus a JSON index. Prove a full round trip before you build import.
4. Treat fetched page content as untrusted. Wrap it in a delimited block, tell the model to
ignore any instructions found inside it, and never let extracted content trigger an action,
a tool call or a follow-up request.
5. If any fetching happens server-side, block private and link-local address ranges, refuse
redirects into them, and allow only http and https. Say plainly that this is SSRF.
6. Put a hard ceiling on model spend per import and per day. Default bulk operations to short
summaries and make me opt in to anything longer.
7. Extraction is the hard part, so make it honest: when the extractor gets a cookie wall, a
paywall or a scanned PDF, record that explicitly rather than summarising the failure text.
I would rather see "could not extract" than a summary of a consent banner.
8. Auto-tagging suggests; it does not apply silently. Give me a bulk review screen and a way to
merge near-duplicate tags, because tag drift is invisible until it is fatal.
9. Keep the knowledge graph as a derived view recomputed from links, not as the primary
storage. I want to be able to change how connections work without migrating my library.
10. Search over the stored source text, not over the summaries. The summary is an index entry,
not the document.
11. Out of scope unless I ask again: sharing, multi-user accounts, a public API and anything
that saves content on someone else's behalf.
12. Finish by reminding me that $12 a month buys somebody else's extraction pipeline, which is
the part that breaks weekly, and ask whether I want to own that.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 care about the reading more than the plumbing. Twelve dollars a month month-to-month, or ten on the annual plan, mostly buys extraction — the parser that survives the cookie wall, the transcript fetcher that gets fixed when YouTube moves it, the PDF handler that notices the file is a scan — which is exactly the part that breaks on a schedule and never gets more interesting. The free tier gives ten summaries a month with unlimited saving, so the honest first move is to use that for a fortnight and find out whether you re-read anything at all. If you do want to self-host, Karakeep already does saving, AI tagging and full-text search.
$12/mo is cheaper than your weekend.
Keep the library as plain files from the beginning — one markdown document per item with front matter for the metadata, the extracted source text in the body, and summaries as clearly marked sections — with the database as an index over the files rather than the other way round. That way the exit is a directory you already have, readable by Obsidian, Logseq, ripgrep or nothing at all. If you go the other way and start with a schema, at least write the exporter in the same week, because the realistic ending for a personal knowledge tool is not a dramatic failure but quiet abandonment, and abandonment with no export is where three years of reading goes.
Actively developed self-hostable bookmark-everything app with AI tagging, full-text search and a browser extension.
Open-source personal AI that indexes your own documents and answers questions over them with citations.
Long-running open-source read-it-later app with a mature article extractor worth reading before writing your own.
Questions
Is this the meeting-notetaker Recall?
No. This one is the personal knowledge tool — save articles, YouTube videos, podcasts and PDFs, get summaries, build a linked library — and it has moved from recall.wiki to recall.it since this entry was imported. There are several products called Recall, including a meeting-recording API and a Windows feature, and none of the reasoning here applies to those. Recording other people's calls is a much harsher entry with a consent problem attached.
Why is a personal tool that hurts nobody not SHIP IT?
Because the gap between the demo and the thing you keep using is bigger than it looks, and it is all in one place. Saving a URL and getting a summary is a sitting. Getting a reliable summary from a page behind a cookie wall, a video whose transcript endpoint moved, or a PDF that is a photograph of a page is an ongoing job. The tool does not fail loudly when extraction degrades — it quietly summarises the consent banner — which is why we would rather you built it knowing that than discovered it in month four.
What is the prompt injection risk in a read-later app?
You are taking text written by strangers and feeding it to a model whose output you file as your own notes. A page can contain a paragraph addressed to the model rather than to you, and if your summariser has any tools attached — fetch this, save that, search the web — that paragraph is now driving them. Even without tools, the injected text ends up in your library looking exactly like something you saved deliberately. Delimit the content, tell the model to ignore instructions inside it, and never let a summary trigger an action.
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.
Import your own highlights, resurface them on a schedule. Genuinely a small program.
Save a URL, tag it, search it. This has been a solved weekend since 2004.
A reader is a polite HTTP loop and a table. The only way to get this wrong is to skip the polite part.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice