Should I vibe code
AI writing, knowledge bases, personas, and browser assistance
An API key inside a browser extension is a public API key. The .crx is a zip file and anyone can open it.
?
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
Rytr and Wordtune are both SHIP IT on this site and most of that reasoning survives here: rewriting a paragraph is one prompt, a persona is a system message, and forty use-case templates are forty rows in a table. Build that and you have built the thing. TextCortex is now selling something larger — knowledge bases over company documents, agents, and a browser extension it advertises as working across thirty thousand sites — and those two additions are what move this a band. An assistant that helps you write anywhere is an assistant that reads everywhere. A content script matching all URLs sees the focused field on your bank's transfer page, your admin console and your password manager exactly as readily as it sees Gmail, and the model at the other end has no way to tell which was which. Meanwhile whatever key that extension calls the API with is not a secret in any meaningful sense, because an extension is a zip file that anybody can download and unpack. The generation genuinely is one sitting. Delivering it into every text box on the internet, safely, is the part that is not.
What actually breaks
not "if". the specific failures.
- The API key, if it ships inside the extension. Unpacking a .crx is a right-click, and the key becomes a free proxy with your card behind it
- The proxy you build to fix that, which now needs authentication of its own or it is the same hole with an extra hop
- Scope. A content script matching all URLs reads the focused field on every site, including the ones where that text is a password reset, an internal ticket or a medical appointment
- Contenteditable, which is where extensions in this category actually die. Gmail, Notion, Slack and Salesforce each disagree about selection, undo and paste, and each disagreement is a separate bug with no shared fix
- The knowledge base, once it holds company documents. Retrieval that ignores who is asking is a search engine over things people were not meant to read
- Manifest and store policy, which will break your extension on a schedule set by two browser vendors rather than by you
- Streaming output into a page you do not control, where your insertion fights the host application for the cursor and loses in front of the user
- Model deprecation, which silently changes the voice of everything the tool writes and gets blamed on the prompt
Is that you?
the verdict is a default, not a law
- It is yours, the key lives on your machine or a server you control, and nothing is distributed
- It works on one or two sites you actually write in, invoked by a hotkey rather than watching every field
- The knowledge base is your own files and nobody else's, or there is no knowledge base at all
- You would be equally happy with a clipboard tool and a menu of prompts, which is most of the value for a tenth of the surface
- Colleagues install it and it carries a shared key you cannot rotate per user
- The manifest asks for all URLs and the content script runs before anyone invokes it
- The retrieval corpus mixes documents with different audiences and the answer does not check who asked
- You could not list, right now, which sites your code runs on and what it sends when it does
If you build it anyway
the checklist, then the prompt that enforces it
- Never put a provider key in the extension. Call a proxy you control, authenticate each user against it, and put a per-user rate and spend cap in front of the model.
- Ask for activeTab or a per-site opt-in rather than all URLs. Broad host permissions are the easy path and the one you cannot walk back after people have installed it.
- Read on explicit invocation only. A hotkey or a click, never a listener watching every field, and never a background scrape of page content.
- Show the user exactly what will be sent before it is sent, at least once per site, and keep a local log of every request. An assistant you cannot audit is one you cannot trust with a work laptop.
- Redact before transmitting: strip anything matching a card, a token or a long random string from the selection. It costs an afternoon and removes the worst accident.
- Deny-list the sites where this should never run — banking, password managers, health portals, your own admin console — and ship that list rather than waiting to be told.
- If there is a knowledge base, filter candidates by the asking user's permissions before retrieval, not after generation.
- Offer a local model path for sensitive text. Ollama makes that a configuration option rather than a project, and it is the honest answer to "can I paste this?".
I am building an AI writing assistant: a browser extension plus a prompt library, and later
retrieval over my own documents. Build it in this order and refuse the convenient version.
1. No provider API key in the extension, ever. Not obfuscated, not split, not in a build
variable. If I ask for it to "just work for now", explain that a .crx is a zip file and
that the key is public the moment it ships.
2. Build the proxy first: my server, per-user authentication, per-user rate limits and a
hard daily spend ceiling that fails closed.
3. Then permissions. Start with activeTab and explicit per-site opt-in. Refuse to write a
manifest matching all URLs, and tell me what I would be granting if I insisted.
4. Reading page content happens only on my explicit invocation — a hotkey or a click on a
selection. No listeners on focus or input, no background collection.
5. Before the first request to any new site, show me precisely what text will leave the
browser and make me confirm for that site.
6. Add a redaction pass on the selection: strip card-shaped numbers, token-shaped strings
and anything from a deny-list of sites — banking, password managers, health portals,
internal admin tools. Ship that deny-list, do not wait for me to write it.
7. Keep a local, readable log of every request: site, timestamp, characters sent, model. I
should be able to answer "what did this send today?" without a debugger.
8. Only then the writing features: prompt library, personas, tone presets. These are rows in
a table and a system message, so do not let them take the whole weekend.
9. Insertion into the page replaces the selection and nothing else, and must be undoable in a
single ctrl-Z. Test in Gmail, Notion and Slack specifically, because each one handles
contenteditable differently and that is where this category of tool dies.
10. If I add a knowledge base, filter permissions before retrieval rather than after
generation, and keep the corpus mine rather than the company's for now.
11. Support a local model endpoint as a first-class option, so sensitive text has somewhere
to go that is not a third party.
12. Out of scope unless I ask again: distributing this to colleagues, storing anyone else's
documents, and autonomous agents. The first turns a personal tool into software with
users and a key rotation problem.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 the everywhere part and you want it to keep working. Roughly twenty-four dollars a seat buys an extension that has already lost the fight with Gmail's editor and won the rematch, key handling that is not your problem, and a knowledge layer with access control in front of it. What is genuinely not worth buying is the writing itself — a hotkey, your own key and a file of prompts covers most of what people use these tools for, and this site rates the narrower versions of that idea, Rytr and Wordtune, as ship-it. Build the small one. Buy the ubiquitous one, or do without it.
$23.99/mo is cheaper than your weekend.
There is barely anything to exit, which is the strongest argument for building this one. Prompts and personas are a JSON file you should keep in a repository from the first day; conversations are rows in SQLite worth exporting to Markdown so the useful ones survive; and the model is a configuration string, so switching providers should be an environment variable rather than a refactor. The single thing that does not come back is the text you already sent to a vendor, which is why the retention setting and the deny-list matter more than any of the code. Write the extension so that removing it removes everything except that file of prompts.
Actively developed interface for local or hosted models with document retrieval and prompt libraries already built in.
Local model runner that turns "can I paste this into an AI tool?" into a configuration choice rather than a policy question.
Questions
Why is this a band harsher than Rytr and Wordtune?
Those two are judged as what they are: a prompt library and a rewriting box. This one is judged as what it now sells, which includes an extension advertised across thirty thousand sites and retrieval over company documents. Neither of those additions makes the build harder — they make the failure larger. An assistant on one site with your own key is genuinely ship-it, and if that is what you build, ignore the band.
Can I not just obfuscate the key in the extension?
No, and it is worth being clear about why. Obfuscation changes how long it takes somebody to find the key, not whether they can. The extension has to send the key to the API, so it has to hold it in a form it can use, and anything the extension can do a person with the extension can do. The only fix is that the key never leaves your server.
What is the smallest version worth building?
A hotkey that takes the current selection, sends it with a prompt you picked from a small menu, and puts the result back. No background listeners, no all-URLs manifest, no stored documents. It is an evening, it covers most real usage, and it has almost none of the surface that makes the full product a maintenance job.
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.
Its product is forty prompts in a dropdown. You can have forty prompts in a dropdown by lunchtime.
The rewrite is one prompt. The product is a browser extension that doesn’t eat your cursor in Gmail.
A generate endpoint with no auth is a free LLM proxy, and strangers find those before your marketing team does.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice