Should I vibe code
Grammar, clarity, tone, and AI writing assistant across apps
You are building a thing that reads everything you type. At least this way, you are the one reading.
?
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
Checking is easy; being everywhere is the product. A local version confined to your editor is the honest 80% and comes with a much better privacy story.
What actually breaks
not "if". the specific failures.
- The input surface, because working everywhere means reading everything — including the password field, the medical form and the private message
- Latency, since a suggestion that arrives after you have typed the next sentence is not a suggestion
- Sending keystrokes to a model, which turns every document you touch into an API request to somebody
- False positives, which are worse than silence — a tool that flags correct writing gets switched off in a week
- Editor integration, which is a different, hostile problem in every single application
It works well enough that you leave it on everywhere, which was the goal. Then you are filling in a form for something private — a clinic, a bank, an application — and you notice the suggestion popup appear over the free-text box. Nothing has gone wrong. The tool is doing precisely what you built it to do: reading the field, sending it away to be checked, and offering a better sentence. You just had not pictured what 'works in every text field' meant until you saw it working in that one.
Is that you?
the verdict is a default, not a law
- It runs on demand inside one editor, on text you selected, rather than everywhere always
- The model runs locally and nothing leaves the machine
- It is a batch tool you paste into rather than a keyboard listener
- It reads text globally across applications
- Keystrokes are sent to a remote model without an explicit per-document decision
- There is no exclusion for password, payment and sensitive fields
- You are aiming to match the suggestion quality rather than a narrow subset
If you build it anyway
the checklist, then the prompt that enforces it
- Prefer on-demand over ambient. A tool you invoke on a selection has almost none of the risk of one that watches every field.
- If it must be ambient, exclude password, payment and credential fields explicitly, and default to an allowlist of applications rather than everything.
- Run locally if you can. A local model with narrower ability beats a better remote one that copies your writing to a server.
- Show the user what is transmitted and when, and never send in the background without an indicator.
- Tune for precision over recall. A false positive costs trust and trust is the whole product here; missing an error costs nothing.
- Debounce and cap request rate, or the cost model is per keystroke.
Before you build a writing assistant, apply these and push back if I ask you to break them. 1. Ask me first whether this is on-demand or ambient. Push me hard toward on-demand — invoked on a selection — and explain that 'works in every text field' means reading medical forms, private messages and anything else I type, which is a decision rather than a feature. 2. If it must be ambient, use an allowlist of applications rather than running everywhere, and explicitly exclude password, payment, and any field marked sensitive by the platform. Show me that exclusion code. 3. Prefer a local model. If text is sent to a remote service, say so in the UI at the moment it happens, and never transmit in the background without a visible indicator. 4. Never log or persist the text being checked. Process and discard. 5. Tune for precision, not recall. Tell me that a tool which flags correct writing gets uninstalled within a week, while one that misses some errors just seems modest. 6. Debounce input and cap the request rate. Explain what per-keystroke API calls cost at my typing speed. 7. Make suggestions non-blocking and never auto-apply. The user accepts or ignores; nothing changes text on its own. 8. Measure end-to-end latency and report it. A suggestion arriving after I have moved on is worse than none. 9. Out of scope unless I ask: tone rewriting, plagiarism checking, organisation-wide style rules, browser extension distribution.
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 you want the ambient version, buy it — $30 a month covers a suggestion engine tuned over years and integrations with applications that each fight you differently. A narrow local on-demand checker for your own editor is a good project and a genuinely different, safer thing.
$30/mo is cheaper than your weekend.
Keep any personal dictionary and style preferences in a plain exportable file, and keep the tool's footprint to something you can uninstall cleanly — an ambient assistant that leaves accessibility permissions or input hooks behind is a thing people forget they granted.
Open-source grammar and style checker and the primary Grammarly-like prior art.
Questions
Why is precision more important than catching every error?
Because the two failures cost different amounts. A missed error is invisible — the sentence was already yours. A false positive interrupts you to be wrong, and after a handful of those people stop reading the suggestions and then turn the tool off. Recall can improve later; trust generally does not come back.
Is a local model good enough?
For grammar and clarity on ordinary prose, a small local model or even rule-based checking gets a long way, and it removes the entire question of what leaves your machine. It will be weaker at tone and rewriting. That is a reasonable trade for a tool that has access to everything you type.
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.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice