Should I vibe code
Write and revise long-form documents with comments, version history, and AI actions
The editor is a weekend. The undo history that saves your manuscript at 1am is the actual product.
?
Their verdict, the Lex 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
Strip Lex back and it is a good text editor with a model on the other end of a keyboard shortcut, which makes it one of the most defensible builds on this list: your words, your machine, your key, nobody else's data. For a solo writer the homemade version is genuinely competitive, because the feature you use forty times a day is 'tighten this paragraph' and not the collaboration layer. The half that will defeat you is the half Lex actually sells — comments from a co-author, a version history you trust at 1am, and a document that survives two tabs disagreeing about what you typed. Build the solo editor. Do not hand-roll merge logic, and never let your own database be the only copy of a manuscript.
What actually breaks
not "if". the specific failures.
- The save path. An editor that autosaves on every keystroke is one race between two open tabs away from writing an empty document over three thousand words, silently
- Undo across a reload — your history is exactly what you thought to persist, and nobody thinks to persist it on day one
- Model output dropped straight into the buffer with no visible boundary, so six months later you cannot tell which sentences were yours
- Streamed edits landing in a document you are also typing into, which is the bug that eats a paragraph and then blames the network
- The API key, which starts in a config file, ends up committed, and then appears in the screenshot of your editor you posted
Is that you?
the verdict is a default, not a law
- It is your own writing, in your own editor, on your own machine
- Every document is a plain file on disk that another program could open tomorrow
- You hold your own API key and the running cost of an AI action is visible in the UI
- Two people draft in the same document and you wrote the merge logic yourself
- The only copy of anything you would be upset to lose lives in your app's database
- You are handling somebody else's unpublished manuscript under an NDA, where a stray log line is a contract problem
If you build it anyway
the checklist, then the prompt that enforces it
- Documents are files. Markdown on disk is the source of truth and the database is an index you can rebuild — that one decision removes most of what goes wrong here.
- Build version history before you build a single AI action: a snapshot on a timer, plus one immediately before every model edit, kept locally and pruned on a schedule.
- No model action writes into the buffer directly. Generate a diff, show it, apply on accept, and keep the pre-edit text until the next successful save.
- Tag machine-written ranges in the document model. You will want to know later, and you will not remember.
- Keep the API key in the OS keychain or an environment variable, never in the document store, and put accumulated token cost somewhere you can see it.
- If you genuinely need two cursors, use Yjs or Automerge. Hand-rolled operational transform is where side projects go to be quietly wrong.
I am building a long-form writing editor with AI actions. The risk here is
losing my own words rather than leaking anyone else's, so order the work
accordingly and push back if I ask you to skip a step.
1. Persistence first. Documents are plain markdown files on disk with a
documented front-matter block. Any database is a derived index that can be
deleted and rebuilt. Do not invent a proprietary document format.
2. Before any editor UI exists, implement local version snapshots: on a timer,
on blur, and immediately before every AI edit. Show me how to restore one
from the command line with the app not running.
3. Assume two windows are open on the same file. Detect the conflict and
refuse to overwrite silently — a stale buffer must never win. If I ask for
real-time multiplayer, stop and tell me to use Yjs or Automerge instead of
writing merge logic yourself.
4. Autosave is atomic: write a temp file, fsync, rename. A crash halfway
through a save cannot be allowed to leave me with an empty document.
5. AI actions produce a proposed diff I accept or reject. Nothing streams
directly into the document I am typing in, and the pre-edit text survives
until the next successful save.
6. Record which ranges came from a model in the document metadata, and surface
that in the UI without changing the exported markdown.
7. The API key comes from the OS keychain or an env var. Never write it to the
document store, never log it, never put it in an error report.
8. Show a running token and dollar cost per document. A rewrite-everything
habit against a frontier model is a bill nobody metered.
9. Use an established editor core — ProseMirror, CodeMirror or Tiptap. Do not
reimplement contenteditable, selection or undo.
10. Out of scope, and say so rather than half-building it: comments, shared
documents, accounts and hosted sync. If I ask for those, tell me that is
the part worth paying for.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
The moment a second person needs to leave a comment. Collaboration, presence and shared version history are most of what $24.99 a month buys, and they are also the exact part where a homemade implementation loses paragraphs instead of throwing errors. If all you wanted was better models attached to your own prose, that part is worth building.
$24.99/mo is cheaper than your weekend.
There is barely an exit to plan, and that is the argument. If documents are markdown files in a folder you already back up, abandoning the project costs you a keyboard shortcut — the writing opens in Obsidian, iA Writer, Vim or Lex itself the same afternoon. The version you would regret is the one where the text lives in SQLite behind a schema only your app understands.
Notion-style WYSIWYG editor with AI autocompletion — the editor half of Lex, and a reminder that editors rot.
Bolts model calls onto an editor and a file format somebody else already maintains.
Questions
Ship it, for something that holds everything I write?
Yes, on one condition: the words live in files, not in your app. A local editor over a folder of markdown has no blast radius, no strangers' data and no regulator, and if it breaks every document is still readable by anything else on the machine. The verdict flips the moment your database is the only place the text exists.
What is actually hard about a text editor?
Selection and undo. Everything visible is a weekend; everything that happens when you undo an AI rewrite across a paste boundary, in a document that autosaved mid-edit, is where real editors spend years. Use ProseMirror, CodeMirror or Tiptap rather than reimplementing contenteditable.
Is running my own API key cheaper than subscribing?
For light use, obviously. For the habit Lex is designed to encourage — rewrite this, again, differently — a subscription is a cap on a number that otherwise has none. Meter it in your own build for a fortnight before deciding you are saving money.
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.
Drafting with sources is a prompt chain. Verifying the sources is the part people skip.
Building the generator takes an afternoon. Building a way to tell when it got worse is the actual product.
Comparing marketing variants is a prompt loop and a scoring rubric you invent.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice