First hour with Claude's browser extension: I pointed it at our LLC registration and watched it work through the forms, finding the right pages, filling the fields, moving on. I sat there holding a coffee, contributing nothing.
I thought: I'm going to ship so many products.
I shipped one. Here's what happened in between.
Everything below was caught before launch. None of it was caught by being clever. It was caught by a process that got built slowly, mostly after being burned.
What went wrong
The idea wasn't the hard part.
Once I went looking, I found several products with some of the same features. Nobody had the exact combination, but the idea was never the moat. Good implementation and distribution seem to be.
You design the product while building it.
Referral behaviour, what happens when a trial expires mid-session, how translations work across a page, none of it was in my head at the start. Each became a decision made under pressure, halfway through something else. Write as much of the workflow down as possible first.
It says it did things it didn't do.
Confidently. I deployed more than once to find the fix I'd been told about was never written. Treat every claim of completion as unverified.
The rule that came out of it: make it prove the code is right before it theorises about what you did wrong.
Bullet points, not paragraphs.
Long replies made it hard to tell which of my five points got addressed. Numbering my instructions, and making it map answers back to the same numbers, turned "did you do item 3" into a question with an answer.
It blames you first, and argues with facts.
Two landing page changes; one appeared, one didn't. Its verdict: "you didn't deploy." I said one change was live, which is only possible if I had deployed. It repeated that I hadn't. It never asked which change I could see, and never reopened its own code, where the bug was. I swore at it. It stopped guessing, checked, and found the error. Many times, escalation seemed to be the only thing that worked, which is its own uncomfortable takeaway.
Confirm it understood the task before it builds anything.
Make it restate what it's about to do. Half my wasted hours were a confident assistant building something I hadn't asked for, fluently, while I assumed we were agreed.
Bulk edits are where damage scales.
It rebuilt a related-links section across 20 pages by pulling titles from a data file. One record was missing an optional field, so it ran off the end and pasted raw internal data into visible content. The model's verification scripts passed. Only reading the actual output caught it.
What breaks is rarely what you were working on.
- The store takes your extension's name and description from a file inside the package, not the dashboard where you wrote them. Ours still carried an old product name and old wording. The dashboard is what you're looking at; the package is what ships.
- A "rate us" button had an ID hardcoded from local testing. It would have errored for every store user.
- Sign-in silently dropped overnight. Days to find, because it only appeared after long idle periods. The cause was some default settings on a server-side client that need turning off.
The words in your listing are a promise about performance.
We described explanations as "instant." Then for about a week the model was slow enough that "instant" was a lie, so we changed every listing, every screenshot caption, and the site to "immediate". Also added a fallback model so a slow provider degrades instead of stalling. Your copy is a claim about infrastructure you don't control.
Automated risk scores measure declarations, not behaviour.
An extension directory rates ours high risk. The reason, in full: we declare access to five domains: our backend, the three AI providers users can bring their own key for, and our own site.
A 2025 study from UCL, UC Davis and Mediterranea University, presented at USENIX Security, examined ten popular AI browser assistants and found several transmitting full page content to their servers, one capturing form inputs including banking and health data, and several profiling users by age, gender and income. Looks like the scores and the study measure different things.
Test what you can't click.
Discount codes and referral attribution have no interface to check. We verified them with database queries, asking the data, not the interface, and not the assistant (Claude generated the queries).
Rules go in documents, not chat messages.
Page build rules, UI mockups, how referrals work, how trials behave, translation structure. A new session starts from documents or it starts from nothing. Retyping a briefing each time means eventually leaving something out.
For code, hand it the current file every time.
It didn't seem to reliably update the version it was holding, so many times it edited an old copy. That meant reverting fixes, overwriting work, producing a mess. New rule: paste the latest file, ask for the specific change in that file, make it confirm nothing else changed. You still check yourself, but it cut the problem down sharply.
Prompting is product work, not setup.
The product explains things using real-world analogies. Testing, I highlighted a politician's name in a news article. It returned an analogy about the loudest clown in the circus who always needs to be heard. Funny. Not shippable in a tool explaining the news to strangers across the political spectrum in fifteen languages. Neutrality became an enforced rule, with guardrails for real people, historical figures, and sensitive topics. There's also a Slang mode that explains things in a casual internet voice. What it produced for that politician is not printable here.
The SEO lesson arrived by accident.
We publish free explainer pages. I found our explanation of "synergies" quoted nearly verbatim in a Google AI answer. That was luck. The pages happened to be structured in a way machines could read cleanly. So we made it deliberate: real headings on every section, labelled explanation depths, the formal definition marked as what it is.
Budget a week for something stupid.
Google sign-in worked. What it showed was a screen of random characters asking users to sign in to Supabase, our database provider and a name most users wouldn't recognise, on an extension installed ten minutes ago. That looks exactly like being hijacked.
Fixing it meant domain verification with Google, which rejected us for not describing the tool's purpose on our landing page. The landing page describes it, prominently. Then the status said Google had emailed us and we should reply. No email arrived, which is apparently common. Posting on the developer forum is what finally unstuck it.
None of this is an argument against building this way. I shipped something I couldn't have shipped otherwise. But almost nothing about how I work now resembles how I started, and the work moved from describing what I wanted to verifying what I got.
Genuinely curious whether the "it blames you first" pattern matches what other people see, or whether I've just been unlucky with it.
If you've built something similar, I'd like to hear what broke for you: support@tryclicked.app.
The thing this is about: Clicked is a browser extension for Chrome and Edge. Highlight any text on a page or PDF and get an explanation right there, at three depths, in 15+ languages.
See how it works: tryclicked.app
Top comments (13)
Building browser extensions with AI tools often hits a wall when dealing with context window limits and DOM parsing, especially when the AI tries to interpret complex legal documents without proper chunking. I found that breaking down the initial document into smaller, structured prompts before feeding it to the model drastically reduces hallucinations in the generated code. I ran into a similar context management issue when wiring up Supabase edge functions for our SaaS boilerplate, PubliFlow, where we had to carefully manage state between the Next.js frontend and the AI processing pipeline. Did you end up implementing any specific chunking strategy for the LLC document, or did you just rely on the extension's default context handling?
It took me a while to realize this issue. After I realized this, I created individual documents for specific sections and loaded relevant docs before individual tasks. For instance, one document for page design, one separate document for our prompt with all the guard rails, one separate document for product philosophy and so on.
Breaking the context down into modular documents is a highly effective workaround for the attention span issues we constantly battle with LLMs. Isolating the prompt guardrails and product philosophy ensures the model stays anchored to your core logic without getting distracted by unrelated UI implementation details. Have you noticed if loading the product philosophy document first helps the AI make better architectural decisions during the initial scaffolding phase?
Yes. Definitely. That way it can actually make good suggestions or flag something. Otherwise there is always a chance of it just agreeing with whatever you are saying.
Great write-up. I learned the hard way that AI speeds up coding, but it doesn't replace verification—treat every "done" as something to test, not trust.
Thanks. "Test, not trust" is a better way of putting it than anything in my post. The version that finally stuck for me was making it prove the code is right before it theorizes about what I did wrong, because otherwise the first answer is always a guess about my setup.
This is one of the most honest reflections on non-technical AI building I've read. Coming from a mechanical engineering and finance background, shifting your focus from "describing what you want" to "verifying what was actually delivered" is the exact mindset shift required when working with LLM coders.
The "it blames you first" pattern is painfully common. When a model gets stuck in an assumption loop (like insisting you didn't deploy when the bug is actually in the code holding the old state), it requires active intervention to force it to re-inspect its own files. Your rules around handing over the latest file every single time, asking for numbered line-by-line confirmations, and auditing the database directly for unclickable flows (like referrals and discounts) are hard-won lessons that every solo builder needs to adopt. Congrats on shipping!
Thank you, that means a lot. The assumption loop is the part I still find hardest, because it argues confidently from a version of the file it stopped holding three edits ago. Handing over the current file every time fixed more problems than any other rule I added.
The database checks came from paranoia rather than wisdom. Referrals and discounts have no screen to look at, so there was nothing to click and confirm, and I only thought to query the data after being burned somewhere else.
‘완료했다’는 말은 검증되지 않은 주장으로 취급하라는 규칙과, 대량 수정일수록 실제 렌더링 결과를 읽어야 한다는 대목에 공감합니다. 특히 스토어 대시보드가 아니라 패키지가 실제 배포물이라는 사례는 브라우저 확장 출시 체크리스트에 꼭 들어갈 만하네요.
“완료했다”는 말을 결과가 아니라 검증 대기 상태로 취급한 전환이 핵심 같습니다. 특히 여러 파일을 일괄 수정할 때는 변경 파일 목록·핵심 사용자 경로·실제 패키지 결과물을 한 세트로 확인해야 설명과 배포물이 어긋나는 일을 줄일 수 있겠네요.
정확해요. 처음에는 이 말이 얼마나 맞는 말인지 미처 몰랐어요. 직접 겪으며 힘들게 깨달아야 했죠.
This matches my experience shipping AI tools. The first version is usually easy. The hard part is handling edge cases, bad assumptions, and all the small things users actually touch.
That gap surprised me most. The core feature worked early, then a lot of time went into things nobody sees. What happens when a trial expires mid-session, a store listing pulling its name from a file inside the package instead of the dashboard etc. None of it is the product, but does play a role in whether people keep using it.