Should I vibe code
Organize linked notes as typed objects such as people, books, meetings, and ideas
Typed objects and backlinks is a schema decision, and you have opinions about schemas.
?
Their verdict, the Pro price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
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
Object-oriented notes are a small graph database with a nice editor. Very buildable, and the structure you choose will suit you better than a general one.
What actually breaks
not "if". the specific failures.
- The schema, which you will get wrong first — and every object already created has to be migrated when you change it
- Deciding what is a type versus a tag, a question with no correct answer that shapes everything downstream
- Typed relations, where a Person linked to a Meeting needs a defined behaviour when one side is deleted
- Capture friction, since typing a note is instant and choosing a type before writing is not
- Export, because a graph of typed objects flattens badly into files and the structure is the part you would lose
You model Books, People and Meetings and it feels right for a month. Then you add Articles and realise Books and Articles are the same thing with different fields, and that half your Meetings should have been Projects. Fixing the model means migrating two hundred objects you created under the old one. Nothing is lost and nothing is broken — you simply spend an evening doing data entry for a system you built to avoid doing data entry, and the second schema will also be wrong.
Is that you?
the verdict is a default, not a law
- You start with two or three types and add a fourth only after weeks of use
- Every object is also a Markdown file, with structure in front matter
- You accept the first schema is a draft
- Capture requires choosing a type before you can write anything down
- Objects exist only as database rows with no file representation
- The schema changes weekly and each change means migrating everything
- There is no export that preserves the relations
If you build it anyway
the checklist, then the prompt that enforces it
- Allow an untyped note. Requiring a type before writing is the friction that kills capture, and typing something later is easy.
- Start with two or three types and earn the fourth through weeks of actual use rather than designing the ontology up front.
- Store every object as a Markdown file with structure in front matter, so the notes survive independently of the schema.
- Define relation semantics explicitly — what happens to a link when its target is deleted or retyped.
- Write the export before the third type, and make sure it preserves relations rather than just prose.
- Expect to migrate. Keep a script that converts one schema version to the next, because there will be a next.
Before you build a typed note system, apply these and push back if I ask you to break them. 1. Allow capture without choosing a type. A plain note must be creatable instantly and typed later. Tell me that requiring a decision before writing is the friction that stops people using these systems. 2. Start with two or three object types. Refuse to design a full ontology up front, and tell me the first schema is a draft that will need migrating. 3. Store every object as a Markdown file with its structured fields in front matter, so the content survives the schema and the app. 4. Define relation semantics explicitly before implementing them: what happens to a link when its target is deleted, renamed, or changed to a different type. 5. Write a migration script alongside the first schema change and keep it, so changing the model is a routine operation rather than an evening of manual data entry. 6. Build export before adding a third type, and make sure it preserves relations — not just the prose, which is the easy half. 7. Index backlinks and typed relations on write. 8. Keep the type system small and say in the README what it deliberately cannot express. 9. Out of scope unless I ask: collaboration, publishing, queries with a custom syntax, mobile, AI features.
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
$12 a month buys a considered ontology and sync. Build your own precisely because you have opinions about the schema — that is the appeal and the hot take says so — but keep every object as a file so that having the wrong opinion twice costs an evening rather than the collection.
Markdown files with front matter, plus a relations export that names both ends and the relation type. The prose survives trivially; the graph is what needs deliberate export, and it is the part you spent the effort building.
Active open-source workspace with local-first documents and databases.
Questions
How is this different from the Bear entry?
Bear is about plain notes and the one hard problem, sync. This is about structure: the moment notes become typed objects with relations, you have designed a schema — and schemas are wrong the first time. The failure is not data loss, it is migration work you keep having to do to yourself.
Why allow untyped notes in a typed system?
Because thoughts arrive before their classification. Forcing a type at capture means either choosing wrongly to get past the dialogue, or not writing it down at all — and the second happens more than people expect. An inbox of untyped notes you classify later gets you the structure without paying for it at the worst moment.
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.
Beautiful documents are a typography problem, and typography does not respond to prompting.
Sync is the hardest problem you will ever underestimate, and the loser is your notes.
Block references are the fun part. Block references at 50,000 blocks are the part that ends projects.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice