Should I vibe code
Rewrite selected text or turn vague coding requests into implementation-ready prompts from any website.
A content script on every site you visit, holding your OpenAI key. The demo takes an hour. Google Docs takes months.
?
Their verdict, the 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
A content script, a keyboard shortcut and one fetch call is the whole idea, and canivibecodeit is right that an agent will hand you a working Chrome extension inside a sitting. Two things stop it becoming something you keep. The first is where the key lives: bring-your-own-key in a browser extension means a provider credential sitting in extension storage, travelling out of a content script that you granted access to every site you visit, which is a far larger permission than a text tool needs and a genuinely awkward thing to have on a work laptop. The second is that in-place rewriting is per-site engineering forever. Replacing a selection in a plain textarea is four lines; doing it in Gmail's compose, Notion's editor and Google Docs — which renders to a canvas and has no DOM text to select — is three separate projects, and every one of them breaks when the site ships on Tuesday. Your v0 will work everywhere except the four places you actually write.
What actually breaks
not "if". the specific failures.
- The in-place replace, which nukes the browser's undo stack in most rich editors — the original draft is not one Ctrl-Z away, it is gone
- Google Docs, which renders text to a canvas rather than the DOM, so a selection-based extension has nothing to read and nothing to write
- Every other editor with its own model: Gmail compose, Notion, Slack, Linear and anything built on ProseMirror or Lexical each need bespoke handling
- The API key, stored in extension storage where any code running in your extension's context can read it and where it goes into your git history the first time you commit a test fixture
- Host permissions, because <all_urls> is what makes the tool universal and also what makes it a script with read access to your bank, your CRM and your password manager's autofill fields
- Whatever you highlight, which is now in a model provider's logs — including the paragraph of a customer email you were only trying to make politer
- Cost, when a long selection on a documentation page becomes a fifty-thousand-token request and there is no budget cap because it is your own key
- Manifest V3 and the store review cycle, which has already changed the rules twice and will again
- Streaming responses into a live editor, where a partial write plus a user keystroke produces text neither of you wrote
Is that you?
the verdict is a default, not a law
- It is unpacked, loaded locally, and never leaves your own browser profile
- Host permissions are an explicit allowlist of the handful of sites you actually write in
- It copies the rewritten text to the clipboard rather than replacing anything in place
- The key is yours, the usage is yours, and nobody else's text ever passes through it
- You plan to publish it to the Web Store, at which point other people's keys and other people's selections are your problem
- It requests <all_urls> because that was the easy default
- It writes into an editor without a way to get the original text back
- Your work laptop has a policy about what may be sent to third-party model providers, and you have not read it
If you build it anyway
the checklist, then the prompt that enforces it
- Ask for the narrowest host permissions that work — an allowlist, or activeTab plus an explicit user gesture. <all_urls> is the difference between a text tool and a keylogger you wrote yourself.
- Never do a destructive in-place replace. Copy to clipboard by default; if you must write into the field, capture the original first and offer one-key revert that restores it exactly.
- Keep the API key out of the content script entirely. It lives in the background service worker, the content script sends text and receives text, and the key never enters a page's context.
- Show the selection you are about to send, with a character count and an estimated cost, and require a confirmation above a threshold. Silent sending of whatever happened to be highlighted is the whole privacy problem.
- Redact before you send: strip anything matching card, key and token patterns from the selection and tell the user you did.
- Put a hard daily spend cap in the background worker and refuse to exceed it. A runaway loop against your own key has no other stop.
- Detect the editors you cannot safely write into — Google Docs, canvas-rendered surfaces, anything with a virtual DOM — and degrade to clipboard rather than corrupting the document.
- Log nothing to remote services. If you want usage stats, keep them local, and say so in the readme so future-you believes it.
I am building a browser extension that rewrites the text I select on any page using an LLM, with my own API key. The two failures I care about are destroying a draft with an in-place replace and shipping a credential or a customer's text somewhere I did not intend. Build against those first.
1. Start with the permission manifest and justify every entry. Default to activeTab plus an
explicit allowlist. If I ask for <all_urls>, push back and explain what a content script on
every site can read.
2. Default output is the clipboard, not the page. In-place replacement is opt-in per site, and
whenever it happens you first store the original text and register a single-key revert that
restores it byte for byte. Assume the browser's native undo will not work.
3. Detect surfaces you cannot safely write to — Google Docs' canvas renderer, virtualised
editors, contenteditable with a custom model — and fall back to clipboard instead of
guessing. Say clearly which editors are supported.
4. The API key never touches a content script or a page context. It lives in the background
service worker, and content scripts exchange only plain text over runtime messaging.
5. Before any request, show me the exact selection, its character count and an estimated cost,
and require confirmation over a configurable size. No silent sends.
6. Run a redaction pass over the selection for card numbers, API keys, bearer tokens and
anything that looks like a secret. Strip them, and tell me what was stripped.
7. Enforce a daily spend ceiling in the background worker with a hard refusal past it. My own
key has no other brake.
8. Handle streaming carefully: never write partial output into a live editor while the user can
type. Buffer the full response, then apply it in one operation.
9. No telemetry, no remote logging, no analytics endpoint. If you want usage counts, keep them
in local storage and document that in the README.
10. Write the uninstall path: clearing extension storage must remove the key and every cached
selection, and say in the README exactly what was stored and where.
11. Out of scope unless I ask again: publishing to the Chrome Web Store, syncing prompts across
devices, and any server component of my own.
12. Finish by telling me that $9 a month is roughly ten minutes of my time and buys someone
else's per-site editor handling, and ask which four sites I actually write in.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 write in Google Docs, Notion or Gmail more than you write in a plain textarea. Nine dollars a month, or sixty-nine once with your own key, buys the per-site editor handling that is the entire hard part of this category, and keeps being maintained the week those sites change. If you write mostly in an IDE or a markdown editor, the self-built version is genuinely competitive — and ChatGPTBox already exists, is open source, and will save you the first weekend.
$9/mo is cheaper than your weekend.
There is almost nothing to exit from, which is the good news. Keep your prompt library as plain markdown files in a folder rather than in extension storage, and the only thing you lose by deleting the extension is the keyboard shortcut. Revoke and rotate the provider key when you stop using it, since a key that lived in a browser profile for a year should not be the one you keep. If you did ship it to anyone else, the honest exit is an unpublish plus a note telling them to rotate their own keys.
Open-source browser extension that integrates LLMs into arbitrary pages, including selection-based actions and bring-your-own-key.
Questions
canivibecodeit says YES and one sitting. What do you disagree with?
Nothing about the build. A working extension that reads a selection, calls a model and pastes the answer back really is one sitting, and theirs is the right answer to the question they ask. Ours is whether you keep it. The version you have after a sitting works in textareas and breaks in the three editors you spend your day in, and it is holding a provider key behind a permission that lets it read every page you open. That is a fine thing to run locally and a bad thing to treat as finished.
Is bring-your-own-key safer or riskier than a hosted plan?
Riskier, in this shape. A hosted plan means the vendor holds the credential and your exposure is a subscription you can cancel. BYOK means a long-lived provider key with billing attached sits in your browser profile, gets copied into your dotfiles, and has no spend cap unless you wrote one. It is a good trade if you build the cap and keep the key out of page contexts. It is a bad trade if you paste it into the popup and forget about it.
Why does Google Docs keep coming up?
Because it does not render text into the DOM. Docs paints to a canvas, so there is no selected node for a content script to read or replace — the official route is the Docs API or an add-on, not an extension. Any tool that claims to work "everywhere on the web" has either done specific work for it or quietly does not support it, and finding out which is the fastest way to judge one of these products, including your own.
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-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice