Should I vibe code
Organize a novel bible, scenes, characters, and optional bring-your-own-model drafting
Your novel is the asset, not the app. Keep it as files you can read without it and the AI part is just a menu.
?
Their verdict, the Hobbyist 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
Nothing here belongs to anyone but you. It is your manuscript, your story bible, your model key, and the worst thing the software can do is waste an afternoon — with one exception worth building around, which is that it can also eat a chapter. Novelcrafter's interesting engineering is not the editor and not the AI; it is context assembly, the business of deciding which characters, locations and earlier scenes to put in front of a model for the scene you are writing now, and doing it without resending the whole novel every time. That part is a genuinely fun problem and a personal version tuned to how you actually plot can beat the general one. Keep the prose in plain files under version control and this is one of the better weekends on the list.
What actually breaks
not "if". the specific failures.
- Autosave racing the editor, which is how a scene gets truncated to its first paragraph and then written over the good version
- An AI rewrite applied in place, with no copy of what the paragraph said before you asked for something better
- Context assembly, the real product here — send too little and the model forgets who the sister is, send too much and every keystroke costs money
- Token spend, invisible until the statement arrives, because the tempting design resends forty thousand tokens of codex on every generate
- Your provider key, harmless in a desktop app and somebody else's free model access the moment the app has a URL and a text box
- The codex drifting out of step with the manuscript — you rename a character in chapter nine and the story bible keeps insisting otherwise
- Search across a hundred and twenty thousand words, which is a grep until it is an index
- Export to something an editor will accept, which means a .docx with real styles rather than markdown and an apology
Is that you?
the verdict is a default, not a law
- The manuscript lives as plain files on your disk, in a repository, backed up somewhere that is not your disk
- The AI is optional and off by default, and drafting still works when the provider is down or out of credit
- It is yours alone, so the story bible is a schema you can change on a whim
- You would enjoy the tool-building as much as the writing, because for the first fortnight it will be most of the writing
- You would host it for other writers — that is unpublished manuscripts plus somebody else's model key on your server, and a completely different entry
- The only copy of the book is a row in the app's database
- You are on a deadline, since a tool you are still debugging is not a tool you are writing in
- You want the AI to make the decisions; nothing in this build protects a novel from being drafted by a model you never read closely
If you build it anyway
the checklist, then the prompt that enforces it
- Store scenes as markdown files in a git repository, one file per scene, with the codex as frontmatter or YAML beside them. Everything else in this app is replaceable; that directory is not.
- Never let a generation overwrite text in place. Write to a new version, show a diff, and require an explicit accept — the whole point of an AI drafting tool is that you keep the version it did not improve.
- Commit automatically on a timer and on every accepted change. Version control is the entire disaster-recovery story for a novel and it costs one line of code.
- Make context assembly explicit and visible: show which codex entries and prior scenes went into a prompt, and cap it. A silent context builder is how you get both continuity errors and a surprising bill.
- Put the API key in the OS keychain, never in the repository or a config file that ends up committed, and print the running spend somewhere you cannot avoid seeing it.
- Build export to .docx with real paragraph styles before you build anything clever. It is how the manuscript leaves for a beta reader, an editor or a submission, and it is always needed sooner than expected.
- Keep the app read-only over the codex until the writing side is stable. An AI that edits your story bible while you draft is a continuity bug generator with good intentions.
I am building a personal novel-writing tool: scenes, a codex of
characters and places, and optional AI drafting through my own API key. The
manuscript is the only thing here that matters. Protect it first and treat every
AI feature as decoration on top.
1. Storage before features. Scenes are markdown files on disk, one per scene,
with stable filenames; the codex is YAML beside them. No proprietary database
holds the only copy of anything.
2. Initialise a git repository in that directory and commit on a timer and on
every accepted edit. Show me the command to recover yesterday's version in the
README.
3. Only then the editor. Autosave must write to a temporary file and rename
atomically — never truncate in place. Write the test where a save is
interrupted halfway.
4. AI generation never writes over my text. It produces a candidate, shows a
diff, and waits for an explicit accept. If I ask for a one-click rewrite in
place, refuse and explain why once.
5. Context assembly is explicit: show exactly which codex entries and prior
scenes were included, with a token count, and cap the total. Never silently
send the whole book.
6. Print running token spend in the UI after every call. Cost is invisible in
this kind of app until the statement arrives.
7. The API key goes in the OS keychain. Never in the repository, never in a
dotfile, never logged. If I ask you to host this so friends can use it, stop
and tell me that is now a server holding other people's unpublished
manuscripts and my key.
8. Build .docx export with real paragraph styles early, plus plain markdown
export of everything including the codex.
9. The tool must work fully with AI switched off — writing, searching and
organising are the base product.
10. Out of scope, and say so: collaboration, publishing, grammar checking and
anything that touches the codex automatically while I draft.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 to write rather than build, which for most novelists is the correct answer. Hobbyist is $8 a month and buys a codex, an editor, and a context system somebody has already tuned across thousands of manuscripts — and since the AI is bring-your-own-key either way, the subscription is not what you pay the model with. Build your own if the plotting method is idiosyncratic enough that no general tool fits, or if you simply want the project.
$8/mo is cheaper than your weekend.
There is barely an exit to plan if you start correctly: a folder of markdown scenes plus a YAML codex in a git repository opens in any editor on earth, and Obsidian, novelWriter and Scrivener all import something close to it. The migration you cannot face is the other one — a hundred thousand words in a SQLite table with a schema only your app understands and no exporter, discovered on the evening the app stops launching after an OS update.
Plain-text novel editor that keeps the manuscript as files on disk with its own outline and notes model.
Open-source writing tool with a character and plot bible, outlining and distraction-free drafting.
Questions
canivibecodeit says KINDA. Why are you softer?
They are judging whether an agent produces something as capable as Novelcrafter in a sitting, and it will not — the codex, the chat and the review tooling are years of work. We are judging whether you should ship what you build, and here the answer is easy: it is your manuscript, on your machine, with no users, no money and no regulator. The only real hazard is losing words, and git solves that before lunch.
What is actually hard about this build?
Context assembly. Everything else is an editor and some forms. Choosing which characters, places and earlier scenes to put in front of the model for the scene you are on — cheaply, repeatably, and in a way you can inspect when the model forgets a name — is the part that separates a toy from something you keep using in chapter twenty.
Is bring-your-own-key a risk?
Not while it stays on your machine in the keychain. It becomes one the instant the app gets a URL, because a text box that calls a model with your key is free model access for whoever finds it, billed to you. If you ever host this, that is the first thing to solve and the reason the answer above is scoped to a local tool.
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.
A fiction brainstorming tool is prompts with a nice wrapper. Make it yours.
Twenty-five reports, and most of them are counting things. The one you can’t write is the grammar engine.
A grammar checker you run locally never has to be trusted with what you wrote.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice