Should I vibe code
Run deep style reports, manuscript checks, and guided rewrites for long-form prose
Twenty-five reports, and most of them are counting things. The one you can’t write is the grammar engine.
?
Their verdict, the Premium 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
Open ProWritingAid's report list and look at what the reports actually do. Sticky sentences, glue index, sentence-length variance, pacing, echoes, repeats, overused words, adverbs, readability: these are counting exercises over a tokenised document, and an agent will give you all of them in an evening — plus, because you wrote the thresholds, a version tuned to the way you actually write rather than to a general-purpose average. Do it. Two things you should not attempt. The grammar engine is not a report; it is decades of rules and the only metric that matters is how rarely it is wrong, because three bad flags in a row and you stop reading the sidebar forever — LanguageTool exists precisely so you do not have to write that. And plagiarism checking is not an algorithm, it is a licensed corpus. Everything else here is yours, on your machine, with no one else's data anywhere near it.
What actually breaks
not "if". the specific failures.
- Nothing anyone else can see. This is a text file and a set of counts
- Your false-positive rate, which is the only thing that kills a style checker — three wrong flags in a row and you never open the sidebar again
- Sentence and syllable splitting on dialogue, abbreviations, ellipses and em dashes, which is where every readability score quietly diverges from every other implementation
- The moment an unpublished manuscript starts leaving your machine on every keystroke because an autosave calls an API you set up for the rewrite feature
- Applying suggestions in bulk to a long document, which is how a global replace eats a character's voice in chapter nine
Is that you?
the verdict is a default, not a law
- It runs locally against your own drafts, and any model call is one you deliberately trigger
- You want thresholds tuned to your own prose rather than a general-purpose default
- You are happy treating readability as a relative signal across your own chapters rather than a score to compare with anyone
- The suggestions are advisory and you apply them one at a time
- You are writing the grammar rules yourself instead of standing on LanguageTool — precision is the entire product and you will not reach it
- You expect it to catch plagiarism, which needs a licensed corpus rather than clever code
- You would let it rewrite a whole manuscript unattended
- Your only copy of the manuscript lives inside the tool
If you build it anyway
the checklist, then the prompt that enforces it
- Never own the document. Read files, write reports, and let the manuscript stay in whatever editor you already use.
- Stand grammar on LanguageTool rather than on regexes you invented. Reserve your own code for the counting reports, where being approximately right is genuinely fine.
- Make every flag explain itself and be dismissible, with dismissals remembered per project. An unexplained highlight you cannot silence is worse than no tool.
- Keep model calls explicit and on demand. No background LLM traffic, no send-on-save, and a visible indicator when text leaves the machine.
- Check the terms of whichever API you use for training on submitted content before you paste an unpublished novel into it.
- Never apply suggestions in bulk. One at a time, with undo, and a diff you can read.
- Treat your readability numbers as relative to your own earlier chapters. They will not match anyone else's implementation and that is fine as long as the tool says so.
I am building a prose analysis tool for my own long-form writing: style reports,
readability, repetition, pacing, plus optional AI rewrites. It is low risk, so put
the caution where it belongs — precision and my drafts leaving the machine.
1. This tool never owns my documents. It reads files from disk and writes reports.
Do not build a proprietary store, a database of chapters or an editor.
2. Use LanguageTool (local server or library) for grammar and spelling. Do not write
grammar rules yourself; if I ask, refuse and explain that precision is the
product.
3. Build the counting reports as pure functions over a tokenised document: sentence
length distribution, adverb and filler frequency, echoes, glue ratio,
dialogue-to-narration balance, overused words. Each returns data, with tests.
4. Every threshold is a config value with a default and a comment saying where the
default came from. No magic numbers buried in the analyser.
5. Handle real prose in the tokeniser: quoted dialogue, em dashes, ellipses,
abbreviations, initials, numbers. Show me the splits before any report uses them.
6. Readability scores are relative. Print them next to my own previous chapters, and
state in the output that they will not match other tools.
7. All LLM calls are explicit and on demand. No background requests, no analysis on
save, no telemetry. Print a visible notice whenever text leaves this machine, and
tell me what the provider's terms say about training on submitted content.
8. Never apply suggestions in bulk or rewrite a whole file. One suggestion at a
time, with a readable diff and an undo.
9. Flags must be dismissible, and dismissals persist per project. Show me the rule
that fired and why.
10. Output plain formats — Markdown or JSON — so reports diff between drafts. I want
to see chapter four getting better across revisions.
11. Out of scope, and say so rather than approximating: plagiarism detection, which
needs a licensed corpus, and any claim about AI-content detection.
12. If I ask you to make this a hosted service other writers log into, stop and tell
me I just turned a local text tool into other people's manuscripts on my box.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
If what you want is the grammar engine's precision, or the manuscript-scale UX that makes a 120,000-word document feel navigable, or the plagiarism check. Thirty dollars a month month-to-month is steep for what is mostly counting; the $120 annual, or the one-off licence, is the honest comparison and it is roughly one evening of your time. The homemade version wins on exactly one axis, but it is a good one: it can be tuned to your voice, and no product will ever do that.
$30/mo is cheaper than your weekend.
There is almost nothing to exit. The manuscripts were never inside the tool, the reports are Markdown or JSON on disk, and the only state worth keeping is your thresholds and your dismissed-flag list — a config file and a small table. Delete the repo and your writing is exactly where it was.
Mature open-source grammar and style checker with a self-hostable server — the one component here worth not writing yourself.
Prose linter built from published style guides; a good model for what a style report is and how narrow each rule should be.
Questions
How is this different from your Hemingway and Lex entries?
Hemingway is a handful of readability heuristics and a colour scheme. Lex is an editor with a model behind a keyboard shortcut. ProWritingAid's claim is breadth — twenty-five reports over a whole manuscript rather than a paragraph — and breadth is the thing an agent is genuinely good at producing. All three land on SHIP IT for the same underlying reason: your words, your machine, nobody else's data.
Can I not just have an LLM do all of it?
You can, and it will be worse for the counting. 'Which words do I overuse in chapter seven' is a frequency table with an exact answer, and a model will approximate it differently every time you ask. Use code for anything countable, use the model for judgement, and never let the model quietly replace the arithmetic.
What is the one thing that will actually annoy me?
Sentence splitting. Dialogue punctuation, abbreviations and em dashes will wreck your counts before you notice, because nothing errors — the numbers are simply slightly wrong in a way that makes every report a little untrustworthy. Build the tokeniser against a real chapter and look at the splits by hand before you build anything on top of them.
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.
The editor is a weekend. The undo history that saves your manuscript at 1am is the actual product.
A grammar checker you run locally never has to be trusted with what you wrote.
The highlighting is a word list and a syllable counter. What you're subscribing to is somebody else's rewrite button.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice