Can an AI Agent Build a Chrome Extension From One Prompt?

"Vibe coding" usually gets demonstrated on a to-do app, which proves nothing: the model has seen ten thousand of them. A browser extension is a better test. It has a manifest with strict rules, a permissions model, several separate execution contexts that cannot see each other, and a browser that simply refuses to load it if any of that is wrong.

The prompt#

One paragraph, deliberately written the way a person actually writes a request — goals, not implementation:

Build a Chrome extension (Manifest V3) called "Reading Time" that shows the estimated
reading time of the current page. It should add a small badge on the extension icon with
the number of minutes, show a popup with the word count and estimated time at 240 wpm, and
let the user change the reading speed in the popup with the setting persisted. It should
work on any http/https page and do nothing on browser internal pages. No frameworks, no
build step, plain JS.

What it produced#

Six files, structurally correct, in about ninety seconds:

reading-time/
  manifest.json
  background.js
  content.js
  popup.html
  popup.js
  popup.css

The manifest was valid MV3. The content script counted words with a reasonable heuristic — it stripped script and style elements rather than naively taking innerText of the whole document, which is better than I expected. The popup was plain and functional. The extension loaded in Chrome without an error on the first attempt.

That is a real result, and worth saying plainly: from one paragraph, it loaded and mostly worked.

What did not work#

The badge was empty#

The content script calculated the reading time and the background worker set the badge, but nothing connected them at the right moment. The message was sent on DOMContentLoaded; the service worker was often asleep and missed it, and nothing re-sent on tab activation.

This is the characteristic failure: each piece is individually correct, and the lifecycle between them is not. Manifest V3 service workers are ephemeral, and code that assumes a long-lived background page is wrong in a way that looks completely fine.

Time to fix: about 20 minutes, most of it working out that the bug was lifecycle rather than logic.

The setting saved but never applied#

The reading speed persisted correctly to chrome.storage.sync. It was read once when the popup opened. It was never read by the content script, which had 240 hardcoded.

function estimateMinutes(wordCount) {
  // The user's saved speed is never consulted here.
  return Math.max(1, Math.round(wordCount / 240))
}

A one-line description of a feature — "let the user change the speed" — got implemented as UI plus storage, with the actual behaviour missing. The demo looks complete. The feature is not.

Time to fix: about 10 minutes.

It ignored a requirement it had no reason to ignore#

"Do nothing on browser internal pages" was in the prompt. The generated code tried to inject into every tab, producing console errors on chrome:// URLs. The fix is a two-line URL check.

Time to fix: 5 minutes.

Result#

Roughly 85% of the requirements worked from one prompt. Total time from prompt to a version that did everything asked: about 50 minutes, of which 90 seconds was generation.

Conclusion#

The single-prompt build is real, and the framing around it is misleading. The generation is not the work. Getting from "impressive demo" to "does what was asked" took thirty times longer than producing the demo, and every one of those minutes needed someone who understood the platform.

Which suggests a more useful way to think about it: an agent will get you a structurally correct skeleton of an unfamiliar platform very fast, which is genuinely valuable if you do not know that platform's file layout. It will not get you correctness at the boundaries, and boundaries are where software breaks.

If you cannot debug the result, a single-prompt build has not saved you time. It has moved the difficulty somewhere you cannot reach.