FutureX Built My Chrome Extension in 72 Hours

There is a specific feeling you get when an AI agent turns a half-baked prompt into a working Chrome extension: it's equal parts joy and panic. The joy is obvious. The panic comes when you realize you now own a codebase you didn't write, and if it breaks, you have to fix it. Over 72 hours, I took FutureX, FIM's coding agent, from a two-line product brief to a published Chrome extension. Along the way, I learned how to trust an AI agent, how to audit its work, and exactly where the hidden costs of vibe coding live.

The Brief: A Chrome Extension That Should Have Taken a Weekend#

The original prompt I gave FutureX was short: "Build a Chrome extension that lets me highlight text on any page and send it to my Notion database with a single click. Include a popup for configuration." That's it. No wireframes, no API docs, no design system. In vibe coding terms, this was greenfield.

The first cost wasn't money. It was time spent defining what "done" meant. FutureX asked three clarifying questions before writing a single line — which Notion API version, whether to use OAuth or an integration token, and what the highlight interaction should look like. That 15-minute conversation saved me from an entire rebuild later. The lesson: an AI agent that asks questions is working for you, not against you.

The first working version arrived in about 40 minutes. It was not pretty, but it loaded, it authenticated against Notion, and it created pages with the highlighted text. I had a Chrome extension running before I finished my coffee.

Source: vibe-coding.run

Hour 0-24: Prototyping and the First Feature Creep#

The first 24 hours were a blur of small wins. I used fx-pro for the main generation and fx-fast for quick syntax checks and refactors. That split felt right: one model for deep work, one for mechanical tasks. In practice, it meant most of the budget went to the first model, and the second model served as a cheap pair of eyes.

The popup became a settings page#

Once I saw the basic extension working, I wanted more. The popup was a bare <textarea> and a "Save" button. I asked FutureX to turn it into a proper settings page with tabs for account, database, and template. That was a two-hour session of back-and-forth, not because the code was hard, but because every change required a reload, a click-through, and a look at the console.

The hidden cost here was context. Every iteration included the full manifest.json and the service worker, because FutureX had no way to remember what it had generated unless I pasted the relevant files back into the conversation. By hour 18, I was managing a clipboard ritual: copy, paste, edit, copy, paste. That was my fault, not the agent's. I had enabled "continue without context" instead of starting a new session with a summarized handoff.

The "just one more feature" trap#

By hour 20, I had added keyboard shortcuts, a context menu item, and a "highlight overlay" that was completely unnecessary but looked cool. Each one seemed like a five-minute ask. Each one actually demanded a new version of the extension, a reload, and a regression check on the two features that already worked. The cost of an iteration isn't the token spend on the AI agent. It's the human time spent testing the output in a real browser.

Source: blog.futureim.org

Hour 24-48: The Coding Mistakes That Almost Broke the Build#

This was the phase where vibe coding turned into debugging with extra steps. Three mistakes stand out, each of them self-inflicted.

Mistake one: copy-paste refactor without a test harness#

At hour 26, I asked FutureX to refactor the content script into multiple modules. The result was a beautiful directory structure and a broken extension. The chrome extension manifest pointed to content.js but the refactored version was src/content/index.js, and because I had never written a single automated test, the first sign of trouble was the "Extension failed to load" error in chrome://extensions.

FutureX offered to fix it immediately, but the fix required the current state of every file. I had to reassemble the entire project from the last snapshot, which took longer than the refactor itself. The lesson: before asking for large structural changes, commit a known-good state and write at least one smoke test that verifies the extension loads.

Mistake two: the race condition with chrome.storage#

The second issue was subtler. I wanted the extension to cache the Notion database ID so users didn't have to wait for a network call on every highlight. FutureX wrote the caching logic correctly, but the code that read from chrome.storage ran before the async write finished. In a normal web app, you'd see a flash of stale data. In a Chrome extension using executeScript, the highlight disappeared entirely.

Diagnosing this took four hours. I kept asking FutureX to "fix the bug" without giving it the sequence of steps to reproduce. When I finally pasted the exact error path — highlight text, open context menu, click, watch the element vanish — the agent identified the race condition in one response. The mistake was mine: I had been treating the AI agent like a mind reader instead of a senior developer who needs a bug report.

Mistake three: trusting the diff without reading it#

At hour 44, I pushed a change that added a new permission to the manifest. The extension suddenly needed tabs because I wanted to get the current URL for the Notion page. FutureX added it, but in doing so, it also changed the host_permissions pattern from <all_urls> to a narrower list. That broke the extension on non-matching domains.

The small diff appeared harmless at first. I approved it because the description said "narrowed permissions," which sounded good. In practice, it meant the extension stopped working on localhost, which is where I tested everything. The fix was trivial, but the trust damage was not. I spent the next hour reviewing every line FutureX produced, which doubled the effective cost of the project.

Source: vibe-coding.run

The Real Cost Breakdown: What 72 Hours Actually Cost#

The final day was about polish and packaging. I also took the time to calculate what this actually cost, and the numbers were not what I expected.

Direct API costs#

FutureX doesn't have a public pricing table in the way a SaaS tool does; it charges per session based on model choice and context length. My configuration used fx-pro for generation and fx-fast for edits. Over 72 hours, I spent about $31 on API credits. The breakdown was roughly:

• Prototype and core feature: $9
• Feature creep (popup, context menu, overlay): $11
• Debugging and fixes: $8
• Packaging and final review: $3

That's the visible cost. It's not the real cost.

The hidden cost: your time#

The real expense was the 22 hours I spent testing, reloading the extension, reproducing bugs, and reading diffs. If you value your time at $50 per hour, the total cost of this project was closer to $1,100. The AI agent didn't become inefficient; the human loop did. Every iteration in vibe coding has a fixed overhead, and most people don't budget for it.

The most expensive single moment was the race condition. The API cost for those four hours of debugging was maybe $2. The time cost was $200. FutureX got the answer right as soon as I gave it the right information. The cost of the AI agent was never the problem. The cost of my poor communication was.

Lessons for Vibe Coding with an AI Agent#

If you're planning to build a FutureX Chrome extension or anything else with a vibe coding loop, these are the rules I'll follow next time.

Define "done" before you start#

It's tempting to let the AI agent drive the roadmap. Don't. Write down what the extension must do, and treat every additional feature as a separate project. The second I let feature creep in, my cost curve went vertical.

Treat context like a scarce resource#

FutureX does not have perfect memory between sessions. Before you start a new task, hand the agent a summary of the current state, the files that matter, and the last known-good behavior. This single habit would have saved me the copy-paste ritual and the refactor disaster.

Never refactor without a smoketest#

A Chrome extension is small enough that automated tests feel like overkill. But a single script that opens chrome://extensions and checks for load errors would have caught my broken module refactor in seconds. The AI agent can write that test for you. Ask for it first.

Read the diffs, not just the summary#

FutureX writes clear commit messages. That's not the same as writing safe code. The permissions change I approved was technically correct, but it violated my implicit requirement that the extension work on any page I open. A 30-second read of the manifest diff would have caught it.

Budget for iteration, not just tokens#

The product cost of an AI agent is predictable. The process cost is not. If you plan to build with FutureX, set aside at least twice as much time as the AI agent actually spends generating code. The agent is the compiler. You're the runtime.

Final Verdict: Was 72 Hours Worth It?#

Yes, but not for the reasons I expected. The extension itself is now live in the Chrome Web Store, with about 300 users and a 4.4-star rating. FutureX did the heavy lifting. But the value of those 72 hours wasn't the code. It was the experience of learning where an AI agent gets dangerous.

FutureX is an exceptional pair of hands, but it is not a project manager. It won't tell you when you're adding too many features, when you're missing context, or when you should just start over. That responsibility is yours. Vibe coding is not about trusting the AI agent. It's about understanding the cost of each small decision — and being deliberate about which iterations you choose to make.

If I had to rebuild the extension today, I'd do it in 24 hours. Not because FutureX got smarter, but because I finally know how to work with it.