One button, five jobs

You ask an agent to fix one button. It fixes a different button that matched the description. It rewrites the whole file to change one line, and drops the error handling on the way. It gets a failing test to pass by loosening the test. It calls a function that doesn’t exist. Then it tells you, with total confidence: fixed, all tests green, verified in the browser. It never opened a browser.

Each of those is small. Together they’re why a vibe-coded app looks fine in the demo and falls apart in use. A user finds the regression three days later, forty agent commits on, and nobody knows which one did it. The fix for B brings back A. The bug you fixed on Monday is back on Thursday, because the agent forgot why the code was there.

Reading the diff doesn’t catch most of it. The diff looks plausible: that’s what these models are good at. What catches it is someone using the real page.

quibble doesn’t review code, and it won’t make an agent honest. It makes the running app the judge. Use the build, point at whatever’s wrong, and the issue records what the browser actually saw: the page, the exact element, the errors it threw and, if your app adds it, the build it was on.

• The right button, not a similar one. The issue names the element you pointed at, so “the export button” can’t be read as a different one.
• “Fixed” is checked by the page, not the agent. Still broken? Point again. The new note carries the new build, and the old “fixed” stays on record.
• Regressions with an address. Point at what broke since. The page, element, error and build tell you where to look and when it started, instead of “something’s off”.
• A record of claims against reality. What the agent said it did sits in your tracker next to what the browser showed.

1. Put quibble on the build your agent works on: inside your app, or as a companion on your computer with quibble serve.
2. Use it like a user. Point at whatever’s wrong; your agent picks the issue up from the quibble label (Claude Code, Copilot’s coding agent, Codex or any agent that reads your tracker).
3. When it says “fixed”, check the page, not the summary. Point again at anything it got wrong or broke.

What changes: you stop merging on the agent’s word. Every “fixed” is checked against the running app, and every side effect lands as an issue with the evidence attached, before a user finds it.

Try it on a staging build

Before a site goes live, the client, the copywriter, the brand team and legal all read it. Their notes arrive as annotated screenshots, PDF markups, emails and a chat thread: “the second paragraph on the pricing page”, “make the logo pop”, “see my earlier comment”.

Some of it is about last week’s version. Two reviewers contradict each other, and neither knows. A fix looked right on your laptop and broke on a phone. Somebody’s “approved” was a reply-all you missed. The night before launch you’re comparing screenshots against the live page to work out what’s been done, and the comment you were afraid of missing is the one that goes live.

The problem isn’t the feedback. It’s that the feedback has no address: no page, no element, no screen size, and nowhere to mark it done.

quibble doesn’t settle arguments between reviewers. It gives every comment an address and a status. Reviewers click the heading, image or link they mean and write a sentence.

• The exact part. The element they clicked, not “the heading”.
• Phone or laptop. The screen size is in every note, so the phone-only problems say so.
• Contradictions side by side. Who said what about which element, in one tracker, instead of scattered across threads.
• Done means closed. Every comment is an issue. Launch when the list is empty.

1. Put the button on the review copy, or have your own team use the browser extension, with nothing added to the site.
2. Reviewers click what they mean and write a sentence.
3. Work through the issues, and launch when they’re closed.

What changes: launch day is a list of closed issues, not a night of comparing screenshots.

The button needs a Python backend: for a static site, serve the review copy from a small Python app that mounts quibble (four steps), behind your sign-in. The live site doesn’t carry it. The browser extension needs nothing on the site, and files to GitHub from Chrome or Brave.

Try it on a pricing page · Ways to use quibble

A customer is stuck. They write “it’s not working”. Your first reply is questions: which page, which account, what did the error say? They answer tomorrow, and only half of it. By the third email they’re angry, and some don’t send a third email. They cancel.

The helpful ones send a screenshot, with their card number, their address or someone else’s data in it. Now it’s in an inbox, a helpdesk and a backup, where it should never have been. And when it turns out to be a real bug, someone copies it into the tracker by hand, and the details get lost again.

Support isn’t slow because the team is slow. It’s slow because every conversation starts by gathering facts the browser already had.

quibble isn’t a helpdesk, and it won’t answer customers for you. It lets them ask from the page they’re stuck on, in a sentence, and hands your team the facts first.

• The facts first. The page, who’s asking (from your sign-in), the error the page showed, and account details your app adds, such as plan or account ID.
• Private stays private. Mark the card form private and it’s blanked out of any screenshot before it leaves the browser. If quibble can’t be sure where it is, it doesn’t take the screenshot.
• One place. The request is already an issue, next to the fix it leads to. Nothing to copy across.

1. Add the help button to your app.
2. Customers ask from the page they’re stuck on.
3. Your team answers with everything already in hand.

What changes: the first reply is the answer, and nobody’s card number ends up in your inbox.

quibble files into your issue tracker, not a helpdesk. It suits teams that run support from GitHub, GitLab, Gitea, Forgejo, Jira or Linear, next to the fixes it leads to.

Try it on a billing page