Making AI Coding Work for Enterprise-Grade Browser Extensions

Hi, I'm Todd Schiller, co-founder of Pixie Bricks, and today I'm going to be talking through some of the hard-won lessons that we've learned using AI to code an AI-enabled extension that's used globally by enterprises. Our mission has always been to really empower people to create the perfect experience for the technology that matters most to them. Therefore, our first product was a browser extension because browser extensions enable permissionless innovation. You can automate and modernize sites that you don't yourself control, whether those are third-party websites, vendor websites, government websites. You can also automate and integrate across tabs. And we fundamentally believe that browser extensions are a key part of how do you empower the people closest to the work to really customize their tools to the job.

Browser extensibility is, in fact, a spectrum. There's multiple different ways to customize the standard browser experience. In the past year, we've even seen people, many different forks of the Chromium browser for things like security or embedding AI capabilities directly into the browser. Then you have the standard kind of custom extension experience that most people are familiar with. You go to the Chrome Web Store, you get an extension, it does something. And then you have a category of extensions that, in fact, enable people to customize in different ways. And so one that some people may be familiar with is user scripts like Grease Monkey or Tamper Monkey that allow you to run JavaScript in the context of a web page. And then Pixie Bricks is a different kind that you can think of it like user scripts, but more low code or no code to enable a broader audience to be able to customize. Each of these comes with different tradeoffs. Again, the things on the right side of the screen are generally more lightweight, more agile, but then those comes with tradeoffs of less control, less affordances, and more kind of restrictions in terms of what these can do versus, for example, creating a custom extension or building your entire browser yourself.

As we've started applying kind of AI coding tools like Cloud, like Cursor to the problem of browser extensions, we found there was three main gaps or mismatches in terms of how those tools treat software development lifecycle. The first is that browser extensions are actually distributed systems, even though at first glance they might look like applications. The second is because of the web store structure and how they're distributed, they actually have slower iteration loops than many of these tools that are more focused on web applications. And third and finally, in many cases, you want extensions to be able to work in the context of host sites. Those host sites have changes or might be outwardly hostile to your extension. And so, these things are surmountable, you just have to think through how to best handle them and how to best apply AI coding tools. But for people who aren't familiar how browser extensions work under the hood, I like to describe them as a distributed system in a box. You can think of a browser, it has multiple different tabs, each tab has multiple different frames. And so, your browser extension is injecting context onto each of those. But then you also have surface areas like the side panel and pages, as well as then things that are working behind the scenes. So, storage, the service worker, off screen document, a lot of different pieces that are talking to each other. And so, you run into the usual suspects and distributed systems problems. Everything is async, you're doing message passing with serialized payloads. And so, again, you run into those common problems with distributed systems.

But in some ways, it's worse than a normal distributed system. Some of these components have very complex lifecycle. You have things like tab pre-rendering, backward forward cache, or worker recycling. And so, it's just a different animal in terms of even normal distributed systems. And so, on this, we'll talk through kind of the four best practices that we believe. The first one is really how do you choose the right base foundation, right? So, I don't believe that most people should have to worry about the things that I showed on the last slide.

And so, you want to choose a foundation where you can be the most productive. In our case, we started at the library layer, using various libraries to smooth over quirks in browser extension APIs for better ergonomics. If building for a common use case, consider using frameworks like WXT or Plasma for quicker development. Platforms offering automatic CI/CD and preview builds can streamline the process, especially for Chrome web store submissions.

When building on top of extensions, the choice lies between the user script world with its APIs or a low-code platform like Pixiebricks for higher abstractions in integrations and compliance. After selecting a foundation, focus on maximizing the application's standard components and encapsulating extension-specific code using standard isolation tactics like dependency injection. Explicit coding practices aid AI in understanding code context, and enforcing boundaries with linters provides instant feedback.

Creating fast feedback loops in browser extensions involves using tools like TypeScript, Lint rules, and AI for custom rules to prevent bugs. Headless tests with mocks and fakes support realistic integration testing, while testing boring components can leverage Storybook and Playwright MCP for end-to-end and integration testing across various browser types and versions.

And so what you want to do is create a big area of those boring applications, and then encapsulate the extension-specific code. That would be the extension code that uses the APIs, the messaging frameworks, messaging bus, etc. Use the standard isolation tactics here, use dependency injection. When using AI, it's always better to be explicit than implicit. This helps the AI have better context locally in terms of how a particular piece of code is working. I always recommend enforcing boundaries using linters or other tools to give instantaneous feedback.

Creating fast feedback loops in a browser extension world involves various strategies like using TypeScript, Lint rules, and AI for custom rules. Quick feedback loops include TypeScript usage, type information differentiation, Lint rules, and custom rules with AI. For integration testing, headless tests are crucial; leverage dependency injection, mocks, and fakes. Testing boring components can be done with Storybook and Playwright MCP. End-to-end testing tools can be used for different browser types and versions, like Canary.

Shift left to catch issues earlier, avoiding relying on slower feedback loops. In extension development, automated tests and QA should not run on host pages due to slowness and potential issues with robotic behavior detection. Create test pages for encountered patterns to avoid slowdowns. Even with Shadow DOM usage, some styles can leak through extensions, so extreme-style test pages help identify conflicts with host styles. Avoid running automated tests or QA on host pages directly to prevent issues with robotic behavior and speed considerations.

Again, take advantages of dependency induction. Use mocks, use fakes in the right places in order to be able to do integration tests in a realistic way. Then there's the how do you test the boring components of your app, right? Use Storybook, use the standard vanilla Playwright MCP. And then you can also use these tools for end-to-end tests for extensions. They're just going to take longer, especially if you're doing multiple different browser types or multiple different browser versions. We also test against Canary, for example.

And so there even are some things that Playwright can't test, and so we use other tools that are more browser-use capabilities, like Rainforest QA, in order to test those. And then obviously the other thing you want to do is always shift left, right? You always want to be in a world where you're catching things earlier versus relying on the slower feedback loops. And then speaking of feedback loops, again, extensions, often the value prop is modifying a host page. It's not a good idea to run your automated tests or do your QA against those host pages all the time, because that's very slow and it's going to be flaky, and in some cases they'll kind of catch your robotic behavior there. So what we do is we create test pages for the different patterns we come across.

And so this screenshot is an example of one that we use for host style conflicts. Unfortunately, with extensions, even if you're using Shadow DOM, some styles can leak through. So we have a page with very extreme styles on it, so we can see which styles are coming through to our extension. And then you have other things like rich text editors, single-page applications. So the name of the game, again, is whenever you have a bug, just go ahead and create a test page for that bug so that then it's in your repertoire of regression tests, and definitely use AI to generate those test pages. And so to recap, what you want to do is you want to set your AI coding tool up for success. Use the right foundation, maximize the boring paths, create fast feedback loops, and again, create those test pages for those host page quirks. That's going to give you that stability in testing and in your agentic loop.