shouldivibecodeit

Should I vibe codeFabric?

AI-organized workspace for files, links, notes, and semantic retrieval

RAG over your own files is a weekend. Then you change the embedding model and re-index four years of your life.

?

Their verdict, the Plus 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

Fabric is fabric.so — a personal workspace that swallows files, links, notes, voice memos and meeting audio, indexes all of it, and lets you ask questions of the pile. Worth stating plainly because "Fabric" is an overloaded name, and because the shape matters: this is retrieval-augmented search over your own life, which is the single most template-covered thing an agent can build in 2026. Chunk, embed, store in pgvector, answer with citations. You will have that working in an afternoon and it will feel like magic on your first two hundred documents. The gap opens later and quietly. Retrieval quality does not fail, it degrades — the same query that surfaced the right note at 200 items returns three plausible wrong ones at 20,000, and nothing in your app is capable of telling you that. Ingestion is where the real work hides: PDFs with columns, scanned images, video, a webpage that is mostly JavaScript. And the day you switch embedding models, every vector you own becomes meaningless at once and you re-index four years of your own archive. None of that hurts anybody. It just means the tool you trusted as your index quietly stopped being one.

What actually breaks

not "if". the specific failures.

  • Ingestion, silently. A folder watcher that stops watching, a PDF parser that returns an empty string for scanned pages, a URL saved as a cookie wall — the item is in the list and nothing is in the index
  • Retrieval quality as the corpus grows. There is no error, just answers that are increasingly confidently about the wrong document
  • Embedding model migration: change the model and every stored vector is incomparable, so the whole archive re-indexes, at whatever the token cost is now
  • Chunking decisions made in week one that you cannot revisit without reprocessing everything — chunk too small and answers lose context, too large and retrieval goes vague
  • Cost, which is invisible until it is not. Transcribing an hour of audio and embedding a thousand-page PDF are both one click and neither shows you a bill
  • Anything you put in that belonged to someone else — a recorded call, a client's contract, a colleague's document — now sitting in a third-party model's request logs
  • Deletion. Removing a file removes the file and leaves its chunks, its vectors and its extracted text in three other places
  • The blob store, which is the actual copy of your documents and the thing nobody backs up because "it is just a cache"

Is that you?

the verdict is a default, not a law

ship it if
  • The files stay on your disk and the app is an index over them rather than the place they live
  • It is one person and losing the index means re-running a script, not losing documents
  • You are running local embeddings, or you have read the retention terms of whatever endpoint you are sending to
  • The corpus is bounded — a project, a course, a year — rather than everything you will ever own
don’t ship it if
  • The app is the only copy of the files it ingested
  • It holds recordings of conversations other people were part of
  • Colleagues or clients put their documents into it
  • You would act on an answer without opening the source it cited
  • Its index is your only record of where something is

If you build it anyway

the checklist, then the prompt that enforces it

  1. Never move the original. Files stay where they are, or get copied to a plain folder you can browse without the app — the index is derived data and must be rebuildable from nothing.
  2. Write the reindex command on day one and run it monthly. If a full rebuild is not routine, an embedding model change becomes a migration you never do.
  3. Record the model name and version alongside every vector. Mixed-model indexes return nonsense and nothing will tell you they are mixed.
  4. Make ingestion failures loud and visible in the UI — a per-item status with a reason, not a log line. Silent skipping is the failure mode here.
  5. Always cite. Every answer names its sources and links to the original, so a wrong answer is visibly wrong instead of plausibly right.
  6. Cap and display cost per operation before running it. "Index this folder" should say what it will cost and what it will send.
  7. Write down what leaves the machine and where it goes, in the README, before the first API key is added. Then check whether local embeddings would do.
  8. Deletion means everything: file, extracted text, chunks, vectors, cached thumbnails, and whatever the provider retained. Build it as one operation and test it.
  9. If you add meeting recording, stop — that is a consent question with its own body of law, not a feature toggle.
the guardrail prompt
I am building a personal AI workspace: files and links in, semantic search and
answers out. Treat the index as disposable derived data and the originals as
sacred. Push back if I ask for the chat interface before the ingestion status.

1. First rule, applied throughout: never move or rewrite an original file. The
   app reads from a plain folder I can browse without it. Everything else is
   rebuildable.
2. Build the reindex command before the search. A full rebuild from originals
   must work end to end on day one, or I will never be able to change models.
3. Store the embedding model name and version on every vector. Refuse to run a
   query across vectors from different models, and say so out loud rather than
   returning blended nonsense.
4. Then ingestion status. Every item has a visible state — queued, extracted,
   embedded, failed — with the reason shown in the UI. Never skip an item
   silently; that is how this rots.
5. Extraction is the hard part, not the model. Handle scanned PDFs, columns,
   audio and JavaScript-rendered pages explicitly, and mark anything yielding
   under N characters as failed rather than indexing an empty string.
6. Every answer cites its sources with links to the originals. A wrong answer
   that shows its working is a bug report; an uncited one is a belief.
7. Before any API key exists, write in the README exactly what leaves my
   machine, to which provider, and what their retention policy says — then
   tell me whether a local embedding model would do the job.
8. Show projected cost before any bulk operation, and cap it. "Index this
   folder" must say how many tokens and how much before it starts.
9. Deletion is one operation covering file, extracted text, chunks, vectors
   and caches. Write the test asserting nothing survives it.
10. If I ask for meeting recording or call transcription, stop and tell me
    recording other people is a consent question with real law behind it.
11. Out of scope: multi-user workspaces, sharing, scheduled jobs and agents
    acting on my behalf. If I want those, $8 a month is the cheaper answer.
paste this before you build — not after something breaks31 lines · 2102 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

When the workspace stops being an experiment and becomes where you actually look for things. Eight dollars a month buys ingestion that handles the awkward file types, transcription you are not metering, and — the part that is genuinely hard to replicate — somebody else deciding when to migrate the index to a better embedding model. If ownership is the point rather than convenience, Khoj self-hosts the same shape over your own documents and can run entirely on local models.

$8/mo is cheaper than your weekend.

your exit plan, if you already built it

Because the originals never moved, the exit is mostly free — the folder is the export. What does not survive is everything the tool inferred: tags, summaries, the connections it drew between documents, and the embeddings themselves. Dump the metadata to JSON on a schedule, one record per item with its path, extracted text, tags and any AI-generated summary, and you can rebuild a new index somewhere else in an afternoon. Skip that and migrating means re-processing the entire archive from raw files, paying the token cost twice.

prior art · someone already did this
Khoj

Self-hostable AI second brain that indexes your documents and can run against local models.

Onyx

Open-source retrieval platform with connectors, incremental indexing and cited answers already solved.

Questions

Which Fabric is this?

fabric.so — the personal AI workspace for notes, files, bookmarks and voice, with semantic search across the lot. Not Microsoft Fabric, the data platform, and not the open-source `fabric` prompt-runner CLI. The name is heavily contested and the three have nothing in common.

RAG is basically a solved recipe now. Why is this not SHIP IT?

Because the recipe covers the demo, not the tool. The parts that are still hard are the ones nobody demos: extraction from awkward formats, ingestion that tells you when it failed, retrieval that stays useful at 20,000 items, and a migration path for the day you change embedding models. A weekend gets you something impressive. It does not get you something you can trust as your index.

What actually goes wrong at scale?

Nothing visible, which is the problem. Top-k retrieval over a small corpus is forgiving; over a large one the right document is often rank eleven. You get a fluent answer built from three near-misses, with no signal that anything went wrong. That is why every answer has to cite its sources — it is the only feedback loop you have.

Is putting my own documents through a model API a privacy problem?

It depends entirely on whose documents they are. Yours, on a consumer API tier, is a decision you get to make. A client's contract, a colleague's draft, or the audio of a meeting other people were in is not, and it stops being a personal choice at that point. Write down what leaves the machine before the first API key goes in, and check whether local embeddings would cover it.

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
NotionDEMO ONLY

You will build twenty percent of Notion in a weekend and the other eighty for the rest of your life.

GranolaYOUR FUNERAL

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

MilanoteDEMO ONLY

The canvas is an afternoon. Being the only copy of three years of a client's reference material is the product.

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