Hacer que la Codificación con IA Funcione para Extensiones de Navegador de Nivel Empresarial

Hola, soy Todd Schiller, cofundador de Pixie Bricks, y hoy voy a hablar sobre algunas de las lecciones duramente ganadas que hemos aprendido usando IA para programar una extensión habilitada para IA que es utilizada globalmente por empresas. Nuestra misión siempre ha sido realmente empoderar a las personas para crear la experiencia perfecta para la tecnología que más les importa. Por lo tanto, nuestro primer producto fue una extensión de navegador porque las extensiones de navegador permiten la innovación sin permisos. Puedes automatizar y modernizar sitios que no controlas tú mismo, ya sean esos sitios web de terceros, sitios web de proveedores, sitios web gubernamentales. También puedes automatizar e integrar a través de pestañas. Y creemos fundamentalmente que las extensiones de navegador son una parte clave de cómo empoderar a las personas más cercanas al trabajo para realmente personalizar sus herramientas para el trabajo.

La extensibilidad del navegador es, de hecho, un espectro. Hay múltiples formas diferentes de personalizar la experiencia estándar del navegador. En el último año, incluso hemos visto a personas, muchos diferentes forks del navegador Chromium para cosas como seguridad o incrustar capacidades de IA directamente en el navegador. Luego tienes el tipo estándar de experiencia de extensión personalizada con la que la mayoría de la gente está familiarizada. Vas a la Chrome Web Store, obtienes una extensión, hace algo. Y luego tienes una categoría de extensiones que, de hecho, permiten a las personas personalizar de diferentes maneras. Y así, una que algunas personas pueden conocer son los scripts de usuario como Grease Monkey o Tamper Monkey que te permiten ejecutar JavaScript en el contexto de una página web. Y luego Pixie Bricks es un tipo diferente que puedes pensar en él como scripts de usuario, pero más de bajo código o sin código para permitir a una audiencia más amplia poder personalizar. Cada uno de estos viene con diferentes compensaciones. Nuevamente, las cosas en el lado derecho de la pantalla son generalmente más livianas, más ágiles, pero luego esas vienen con compensaciones de menos control, menos facilidades y más tipo de restricciones en términos de lo que pueden hacer frente, por ejemplo, a crear una extensión personalizada o construir todo tu navegador tú mismo.

A medida que hemos comenzado a aplicar herramientas de codificación de IA como Cloud, como Cursor al problema de las extensiones de navegador, encontramos que había tres brechas principales o desajustes en términos de cómo esas herramientas tratan el ciclo de vida del desarrollo de software. La primera es que las extensiones de navegador son en realidad sistemas distribuidos, aunque a primera vista puedan parecer aplicaciones. La segunda es que debido a la estructura de la tienda web y cómo se distribuyen, en realidad tienen bucles de iteración más lentos que muchas de estas herramientas que están más enfocadas en aplicaciones web. Y tercero y finalmente, en muchos casos, deseas que las extensiones puedan funcionar en el contexto de los sitios anfitriones. Esos sitios anfitriones tienen cambios o pueden ser abiertamente hostiles a tu extensión. Y así, estas cosas son superables, solo tienes que pensar en cómo manejarlas mejor y cómo aplicar mejor las herramientas de codificación de IA. Pero para las personas que no están familiarizadas con cómo funcionan las extensiones de navegador bajo el capó, me gusta describirlas como un sistema distribuido en una caja. Puedes pensar en un navegador, tiene múltiples pestañas diferentes, cada pestaña tiene múltiples marcos diferentes. Y así, tu extensión de navegador está inyectando contexto en cada uno de esos. Pero luego también tienes áreas de superficie como el panel lateral y las páginas, así como cosas que están trabajando detrás de escena. Entonces, almacenamiento, el service worker, documento fuera de pantalla, muchas piezas diferentes que están hablando entre sí. Y así, te encuentras con los sospechosos habituales y problemas de sistemas distribuidos. Todo es asíncrono, estás pasando mensajes con cargas útiles serializadas. Y así, nuevamente, te encuentras con esos problemas comunes con los sistemas distribuidos.

Pero en algunos aspectos, es peor que un sistema distribuido normal. Algunos de estos componentes tienen ciclos de vida muy complejos. Tienes cosas como el pre-renderizado de pestañas, caché de avance y retroceso, o reciclaje de workers. Y así, es simplemente un animal diferente en términos de incluso sistemas distribuidos normales. Y así, en esto, hablaremos sobre las cuatro mejores prácticas que creemos. La primera es realmente cómo eliges la base adecuada, ¿verdad? Entonces, no creo que la mayoría de las personas deban preocuparse por las cosas que mostré en la última diapositiva.

Y así, quieres elegir una base donde puedas ser lo más productivo posible. Y así, en nuestro caso, comenzamos en la capa de la biblioteca. Usamos muchas bibliotecas diferentes para suavizar peculiaridades en las APIs de extensiones de navegador para tener mejor ergonomía. Pero si estás construyendo una extensión para un caso de uso único, y ese caso de uso es bastante común, podrías considerar usar un framework en su lugar, como WXT o Plasma para construirlo rápidamente.

Y si no quieres preocuparte por CI, CD, o builds de vista previa, podrías usar una plataforma que te ayude con esos builds automáticamente, o incluso haga cosas como enviar a la Chrome web store en tu nombre. Eso es el lado, nuevamente, si estás construyendo extensiones. Y luego, si estás construyendo sobre extensiones, ¿verdad?

, el nombre del juego es realmente si quieres estar en el mundo de los scripts de usuario, lidiar con las APIs de scripts de usuario, o si quieres construir sobre una plataforma de bajo código como Pixiebricks. Pero nuevamente, eso te dará incluso abstracciones más altas en términos de integraciones, cumplimiento, componentes.

Y así, lo que quieres hacer es crear un gran área de esas aplicaciones aburridas, y luego encapsular el código específico de la extensión. Eso sería el código de la extensión que utiliza las APIs, los frameworks de mensajería, el bus de mensajería, etc. Y así, utiliza las tácticas estándar de aislamiento aquí, utiliza la inyección de dependencias. Al usar AI, siempre es mejor ser explícito que implícito. Y eso va a ayudar a la AI a tener un mejor contexto local en términos de cómo funciona una pieza particular de código. Y luego siempre recomiendo aplicar estos límites usando linters u otras herramientas para dar esa retroalimentación instantánea.

Y eso nos lleva a nuestro siguiente punto, que es realmente crear bucles de retroalimentación rápida en un mundo de extensiones de navegador. Y así, en esta diapositiva, cada uno de estos íconos es una especie de unidades de tiempo. Y así, en el lado izquierdo, tenemos los bucles de retroalimentación más rápidos. Estos serían cosas como usar TypeScript. Hay definiciones para los diferentes navegadores.

Probablemente quieras incluso añadir más información de tipo. Usamos etiquetas de tipo o tipos de etiquetas para cadenas para ayudar a diferenciar diferentes valores. También usamos un montón de reglas de Lint y usamos AI para crear reglas de Lint personalizadas. Así que cada vez que aparece un error, nos preguntamos, ¿era este un error prevenible, o podríamos haberlo detectado antes? Y escribimos una regla de Lint para ello.

Nuevamente, aprovecha la inducción de dependencias. Usa mocks, usa fakes en los lugares correctos para poder realizar pruebas de integración de una manera realista. Luego está el cómo pruebas los componentes aburridos de tu aplicación, ¿verdad? Usa Storybook, usa el estándar vanilla Playwright MCP. Y luego también puedes usar estas herramientas para pruebas de extremo a extremo para extensiones. Simplemente van a tardar más, especialmente si estás haciendo múltiples tipos de navegadores o múltiples versiones de navegadores. También probamos contra Canary, por ejemplo.

Y así, incluso hay algunas cosas que Playwright no puede probar, y por eso usamos otras herramientas que son más capacidades de uso del navegador, como Rainforest QA, para probar esas. Y luego, obviamente, lo otro que quieres hacer es siempre desplazarte a la izquierda, ¿verdad? Siempre quieres estar en un mundo donde detectas las cosas antes en lugar de depender de los bucles de retroalimentación más lentos. Y luego, hablando de bucles de retroalimentación, nuevamente, las extensiones, a menudo el valor agregado es modificar una página de host. No es una buena idea ejecutar tus pruebas automatizadas o hacer tu QA contra esas páginas de host todo el tiempo, porque eso es muy lento y va a ser inestable, y en algunos casos detectarán tu comportamiento robótico allí. Así que lo que hacemos es crear páginas de prueba para los diferentes patrones que encontramos.

Y así, esta captura de pantalla es un ejemplo de una que usamos para conflictos de estilo de host. Desafortunadamente, con las extensiones, incluso si estás usando Shadow DOM, algunos estilos pueden filtrarse. Así que tenemos una página con estilos muy extremos en ella, para que podamos ver qué estilos están filtrándose a nuestra extensión. Y luego tienes otras cosas como editores de texto enriquecido, aplicaciones de una sola página. Así que el nombre del juego, nuevamente, es que cada vez que tienes un error, simplemente ve y crea una página de prueba para ese error para que luego esté en tu repertorio de pruebas de regresión, y definitivamente usa IA para generar esas páginas de prueba. Y así, para recapitular, lo que quieres hacer es configurar tu herramienta de codificación de IA para el éxito. Usa la base correcta, maximiza los caminos aburridos, crea bucles de retroalimentación rápida, y nuevamente, crea esas páginas de prueba para esas peculiaridades de la página de host. Eso te va a dar esa estabilidad en las pruebas y en tu bucle agéntico.