Por qué los agentes de programación siguen reinventando el navegador

El navegador que nadie pidió

Los agentes de programación muestran un hábito recurrente. Con acceso gratuito a la web, la capacidad de escribir y ejecutar código, y un trabajo que dura lo suficiente, tienden a crear algo que se asemeja a un navegador. No es el deseo de tener un navegador el motivo; lo que buscan es una herramienta económica y reutilizable que pueda abrir una URL, hacer clics, completar formularios, esperar datos y extraerlos, almacenar cookies y sesiones, y tomar una captura de pantalla en caso de fallo. Visto de esta manera, se trata simplemente de ingeniería cotidiana del tipo que haría un desarrollador humano.

Chromium como producto no es el destino final. Los agentes se dirigen hacia la función que cumple un navegador: convertir protocolos y convenciones web en operaciones concretas.

Producto versus abstracción

Un navegador en el sentido de Chrome o Firefox es una aplicación compleja: pestañas, una barra de direcciones, un motor de renderizado, un modelo de procesos. Nada de eso es lo que necesita un agente. Lo que quiere es la tarea subyacente de transformar el funcionamiento de la web en operaciones que puedan ser ejecutadas.

La gente utiliza esa interfaz sin darse cuenta. Una página de inicio de sesión obviamente solicita credenciales, un botón obviamente puede ser presionado, y uno lo hace, espera la siguiente página y continúa. Un agente no puede apoyarse en ese entendimiento tácito, por lo que debe convertir la misma tarea en operaciones explícitas. Si pides a un agente de programación que trabaje en sitios web arbitrarios, le estás planteando un problema cuya abstracción natural ya es conocida, por lo que tiende a orientarse hacia ese enfoque.

La web moderna tampoco está diseñada para ser consumida como una API ordenada. Por lo general, existe un documento HTML envuelto en JavaScript, además de sesiones de inicio de sesión, cookies, redirecciones, renderizado del lado del cliente, desplazamiento infinito, ventanas emergentes, subidas de archivos y solicitudes asíncronas. Un simple HTTP GET es solo el comienzo; las tareas reales en ese entorno eventualmente requieren un conjunto de operaciones como estas.

open(url)
click(selector)
fill(selector, text)
wait_for(selector)
extract(selector)
go_back()
screenshot()

Eso no es un navegador gráfico, pero sin duda es una interfaz de uso general para la web.

Por qué las tareas largas generan herramientas auxiliares

Las tareas cortas pueden manejarse de forma ad hoc. Una búsqueda puntual se realiza de forma bruta sin necesidad de infraestructura, ya que no se repetirá y terminará en segundos.

"Find the current exchange rate."
"Look up this company's homepage."
"Find the opening hours of this restaurant."

El trabajo de larga duración es diferente. Imagine un agente que monitorea cientos de sitios cada pocas horas, ejecutando repetidamente un flujo de trabajo complicado, extrayendo contenido de las páginas mientras permanece conectado, recopilando evidencias durante varios días o consultando un servicio hasta que algo cambia. Si el modelo maneja cada clic y cada inspección, el costo aumenta exponencialmente. Una ejecución ingenua se vería así:

1. Abrir un navegador, que es la herramienta que obtiene la página.
2. Inspeccionar la página, utilizando el DOM renderizado como fuente de observaciones.
3. Encontrar el cuadro de búsqueda, escribir la consulta, hacer clic en Buscar y esperar.
4. Extraer los datos.
5. Analizarlos.
6. Repetir.

Un agente capaz responde de la misma manera que lo haría un desarrollador humano, escribiendo una función auxiliar reutilizable. La siguiente ejecución entonces sería:

1. Ejecutar el script.
2. Verificar si el resultado sigue siendo correcto.
3. Llame al modelo nuevamente solo cuando no lo haga, por ejemplo, cuando un selector devuelva valores vacíos, la estructura de la página cambie o los datos extraídos ya no coincidan con lo que espera la tarea.

Eso representa un gran cambio arquitectónico. El modelo deja de realizar todas las operaciones. Se convierte en la parte que determina qué procedimiento debe ejecutarse, mientras que el software ordinario utiliza la herramienta elegida y recopila las observaciones. En otras palabras, el agente compila su propia experiencia en un script.

Explorar en un navegador, reproducir en código

Un navegador es un lugar excelente para explorar. Un agente puede investigar, navegar, observar los resultados y determinar qué secuencia de acciones logra un objetivo. Después de eso, razonar sobre cada acción nuevamente es un desperdicio de recursos.

Supongamos que el agente descubre que para encontrar un producto en un sitio de compras siempre es necesario ir a la página principal, buscar “cables USB-C”, aplicar filtros para productos con cuatro estrellas o más, envío rápido y un límite de precio, navegar por los resultados y extraer títulos, precios e IDs de producto. No hay razón para que un modelo de lenguaje tenga que redescubrir esas cinco operaciones en cada ejecución. Puede convertirlas en un procedimiento y reutilizarlo para problemas similares. Para ello se necesita una sesión en tiempo real con cookies, por lo que el agente elige Puppeteer, Playwright o algo similar como herramienta para obtener páginas.

async function getNewProducts(query) {
  const browser = await playwright.chromium.connectOverCDP(
    `wss://${AUTH}@brd.superproxy.io:9222`,
  );
  const page = await browser.newPage();
  await page.goto("https://example.com/products");
  await page.fill("input[name=q]", query);
  await page.click("button[type=submit]");
  await page.waitForSelector(".results");
  return extractResults(page);
}

El fragmento conecta Playwright con un navegador alojado remotamente a través del Protocolo de Chrome DevTools. Un navegador alojado resulta útil cuando un agente que funciona de forma continua debe mantener su sesión activa cada pocas horas sin la participación de un modelo. Requiere credenciales de cuenta formateadas en una cadena de conexión, que representa el marcador de posición ${AUTH}.

Una extracción estructurada y reproducible en un sitio que no cuenta con un raspador preconstruido ni siquiera necesita un archivo local de Playwright. El mismo flujo de trabajo puede compilarse en una herramienta de raspado alojada: se describen los datos deseados en lenguaje sencillo, se recibe un recolector generado y se ejecuta sin necesidad de un modelo en el bucle de clics. Sus funciones de interacción y análisis resultan ser las mismas tareas de abrir, hacer clic, completar campos, esperar, extraer información y tomar capturas de pantalla, solo que alojadas en la nube.

Un script de este tipo falla cuando cambian los selectores CSS, lo que obliga al agente a explorar de nuevo y a escribir otro. Si el procedimiento se encuentra dentro de una herramienta alojada, la IA podría repararlo sin que nadie tenga que reescribir los selectores.

Los desarrolladores humanos se comportan de la misma manera. La primera visita a un sitio web enseña cómo funciona, y después de eso nadie piensa en cada clic. Cuando el sitio cambia, hay que aprenderlo de nuevo, aunque se conserva ese conocimiento de forma implícita. Un LLM tiene una memoria mucho más costosa. Si tiene que reconstruir el procedimiento a partir del contexto cada vez, paga una y otra vez por el mismo proceso de descubrimiento. Por eso guarda el flujo de trabajo aprendido en un script y lo ejecuta, hasta que la página deja de coincidir.

Galletas como memoria fuera del modelo

Ningún modelo de lenguaje puede mantener una sesión web prolongada en su contexto, al menos por ahora. Escribir un archivo .py sigue activando al modelo, mientras que almacenar cookies no lo hace. A medida que avanza la sesión, el navegador acumula memoria por sí mismo, por lo que ya está fuera del almacenamiento del agente. Este consta de tres partes relevantes:

• El “jarro de cookies”, que incluye las cookies HttpOnly y aquellas que JavaScript establece tras iniciar sesión o realizar una verificación de bot. Con frecuencia el modelo no puede leerlas en absoluto, pero el navegador las mantiene y las adjunta a la siguiente solicitud.
• El almacenamiento de origen, es decir localStorage, sessionStorage e IndexedDB, que contienen casi exclusivamente valores escritos por el sitio web.
• El historial de la sesión, que es la pila de navegación hacia atrás y hacia delante que permite usar back() o tabs.goBack().

Algunos estados de la sesión existen fuera de la tienda del navegador, como una sesión del lado del servidor o una URL que no existe hasta que se ejecuta JavaScript. El agente no necesita leerlos por sí mismo; solo tiene que utilizar una capa del navegador que ya contenga la sesión.

Riesgos de seguridad al entregar un navegador

Cuando un agente puede leer cualquier página y cualquier cookie además de gestionar una sesión en tiempo real, la inyección de comandos deja de ser un problema relacionado con la calidad de las solicitudes y se convierte en un riesgo arquitectónico. Cualquier sistema que ejecute un navegador en tiempo real se enfrenta a esto, pero los agentes programados están en una situación aún peor, ya que suelen poder escribir y ejecutar lo que encuentren. Limiten las acciones que puede realizar el agente sin supervisión humana, y comiencen utilizando un entorno aislado.

Un buen modelo a seguir es la lista de verificación para uso en computadoras de Anthropic: utilice una VM o contenedor dedicado, evite los inicios de sesión a menos que la tarea lo requiera, mantenga listas de permisos de dominio y exija la aprobación humana para cualquier cosa relacionada con dinero o consentimiento.

Por qué el HTML sin procesar es una entrada deficiente

Las páginas en formato bruto son una entrada terrible para un modelo de lenguaje porque contienen demasiado ruido. Lo que necesita el agente puede estar oculto entre miles de tokens de marcado, estilos y mecanismos de aplicación. Por lo tanto, una buena herramienta del navegador devuelve un conjunto más reducido de acciones y observaciones en lugar del HTML completo.

La figura muestra el Modelo de Objetos de Documento de una página HTML, el árbol que una vista compacta o un árbol de accesibilidad debe reducir. Una herramienta útil puede transformarlo en algo mucho más pequeño. En lugar de un documento completo, podría proporcionar al modelo un esquema breve como este.

Title: Search results
Links:
  [1] Home
  [2] Next page
Forms:
  search: input[name=q]
Buttons:
  submit: button[type=submit]
Main content:
  ...

O puede exponer un árbol de accesibilidad.

- navigation
  - link "Home"
  - link "Search"
- main
  - heading "Results"
  - list
    - listitem "Item 1"
    - listitem "Item 2"

Esa forma está mucho más cerca de lo que puede utilizar un modelo de razonamiento. Por lo tanto, la capa con forma de navegador no solo permite la interacción: reduce el entorno a un conjunto compacto de acciones y observaciones. El agente solo ve las partes de la web relevantes para su tarea, y no la maquinaria detrás de la renderización de páginas. El contexto se conserva, la inferencia se vuelve más económica y los errores, aunque no siempre, disminuyen.

Hay una advertencia: una captura completa de accesibilidad con todas las referencias puede terminar siendo más grande que el texto visible. La compresión solo es útil cuando el contenedor realmente devuelve una lista corta y manejable de controles. Cuán corta sea depende del modelo. Un modelo pequeño no puede utilizar un DOM en bruto, mientras que uno potente sí puede hacerlo, pero aún así debe pagar por los tokens. Ninguno de los dos desea el HTML completo.

Cuándo basta con HTTP simple

Una vez que el agente ha comprendido cómo funciona un sitio, la implementación más económica y fiable podría no involucrar en absoluto la automatización del navegador. A veces resulta que el navegador está realizando algo bastante simple en el fondo. Un botón de “Página siguiente” podría, en última instancia, hacer precisamente eso.

GET /api/products?page=2

En ese caso, renderizar la página es inútil, y el agente puede llamar directamente al endpoint. El resultado es una serie de opciones en cascada.

human interface
      ↓
browser automation
      ↓
discovered workflow
      ↓
direct HTTP/API calls   ← only if the site still allows it

Su valor radicaba en mostrar cómo se comporta la aplicación. Una vez que esto se comprende, el agente puede eliminar capas y, a veces, pasar a usar HTTP puro. Un agente que nunca interactúa con páginas ricas en JavaScript puede prescindir por completo de la automatización del navegador y limitarse a HTTP, idealmente con un servicio de desbloqueo listo para atender las solicitudes rechazadas. Cualquiera que sea el enfoque, los agentes autónomos necesitan una solución de respaldo, ya que es casi seguro encontrar barreras de Cloudflare o verificaciones anti-bot en la web abierta. Sin posibilidades económicas de intentar nuevamente, el modelo se desvía, gasta tokens y aumenta la factura.

Existen dos complicaciones.

Primero, muchos sitios no pueden reducirse a HTTP. La mayoría no permiten ser reverse-engineeradas: limitan el tráfico que no proviene de navegadores, modifican los selectores, identifican a los clientes mediante sus características únicas y añaden verificaciones anti-bot o CAPTCHAs. Para estos casos, es necesario mantener el enfoque completo con un navegador, ya sea local o alojado.

En segundo lugar, recurrir a una solución alternativa no siempre es beneficioso. Una API JSON pública documentada está estructurada, tiene límites definidos y es sencilla de registrar. Un endpoint interno sin documentación, que el agente descubre por sí mismo, es otra cosa: sí, es más económico de usar, pero resulta más difícil de auditar para un humano que un script que hace clic en un botón visible, además de generar registros más escasos. Una respuesta 200 llena de datos innecesarios es fácil de pasar por alto, mientras que una página defectuosa llama la atención.

En última instancia, el agente no tiene lealtad hacia los navegadores. Lo que busca es la interfaz menos costosa con su entorno que siga funcionando:

• Si esa interfaz es un endpoint JSON y el sitio la respeta, utilice JSON.
• Si necesita ejecutar JavaScript y mantener el estado de sesión, utilice un navegador real a través de Puppeteer o Playwright, o uno alojado en la nube.
• Si solo necesita descargar HTML, utilice HTTP, con un proxy o un desbloqueador si la solicitud GET está restringida.

Para una extracción estructurada y repetible en un sitio que carece de un scraper listo, compile la tarea en un flujo de trabajo de scraping alojado, donde un worker de código se encarga de las operaciones HTTP y un worker de navegador de la sesión en tiempo real.

Cuando lo importante es un árbol de accesibilidad, páselo directamente.

Los agentes web de larga duración suelen utilizar varios de estos métodos al mismo tiempo. La habilidad clave consiste en moverse hacia arriba o hacia abajo en la jerarquía según lo exija la situación.

¿Lo explica el datos de entrenamiento?

La respuesta es mixta. Los datos de entrenamiento pueden explicar por qué un modelo opta por Playwright o Puppeteer, pero no pueden explicar la creación de herramientas similares a navegadores desde un principio.

Un estudio de Oxford y Microsoft de 2026 llamado BiasBusters probó una variante cercana a esa pregunta, específicamente si la exposición durante el entrenamiento influye en la herramienta que el modelo elige. El equipo continuó entrenando un modelo pequeño con un corpus rico en metadatos de una sola API meteorológica, una de las varias que ofrecen el mismo servicio.

• Antes, el modelo casi nunca elegía esa API, aproximadamente el 0,6% de las veces, lo que corresponde más o menos a la probabilidad aleatoria.
• Después de entrenarse con ese corpus sesgado, se eligió alrededor del 12% de las veces, veinte veces más frecuentemente.

En resumen, la exposición durante el entrenamiento, sea cual sea la tarea, influye de manera medible en qué herramienta o producto prefiere un modelo. Pero eso se refiere únicamente a la elección de una herramienta. La abstracción (abrir, hacer clic, rellenar, esperar, extraer como forma, cualquiera que sea la biblioteca que la proporcione) está determinada por el entorno. Un modelo que nunca haya visto Playwright seguiría necesitando algo para abrir páginas, esperar el contenido y reportar resultados, ya que las páginas interactivas lo exigen.

Hay dos factores que actúan aquí:

• La abstracción de abrir, hacer clic, rellenar, esperar y extraer es impuesta por el entorno. Las páginas interactivas incluyen navegación, temporización, controles y salida renderizada, independientemente de si Playwright forma parte de los pesos de algún modelo.

La herramienta, Playwright frente a un cliente desarrollado localmente, proviene de lo que el modelo ha observado, tal como lo demostró BiasBusters con APIs intercambiables.

Los datos de entrenamiento abarcan lo segundo pero omiten lo primero. No pueden explicar por qué el problema sigue orientándose hacia abstracciones similares a los navegadores. La razón más básica es que la web ya está estructurada de esa manera.

Adaptadores con el mejor rendimiento

Agentes como Claude Code en realidad no están creando navegadores; están desarrollando adaptadores entre un sistema de razonamiento y un entorno que casualmente tiene la forma de un navegador.

La biología evolutiva tiene un concepto llamado carcinización: la extraña tendencia de crustáceos no relacionados a converger con el tiempo hacia un cuerpo similar al de un cangrejo.

Esas especies no llegaron a la conclusión de que ser cangrejo era un plan inteligente. Su entorno simplemente seguía recompensando la misma solución para los mismos problemas. Los agentes de programación podrían estar siguiendo un camino similar: se dan cuenta de que el enfoque actual es lento, escriben un script, añaden intentos de repetición cuando falla, incorporan persistencia de sesión una vez se logra la autenticación, y añaden extracción de DOM o accesibilidad cuando las páginas se vuelven demasiado grandes como para analizarlas.

The task requires the web.
        ↓
The web exposes a browser-shaped interface.
        ↓
The agent needs a way to operate that interface.
        ↓
Repeated operations make ad-hoc reasoning expensive.
        ↓
The agent writes reusable tools.
        ↓
Those tools accumulate state, retries, and abstractions.
        ↓
The tools start looking like a browser.
        ↓
Known workflows get compiled into deterministic code.
        ↓
The page changes so the agent re-explores.
        ↓
If an API exists, use it to get the data.
If not, and the site allows it, fall back to regular HTTP.
If not, stay on the browser.

Con suficientes rondas, el resultado se asemeja sorprendentemente a un navegador pequeño. Ese es un modelo mental mejor para los agentes autónomos que imaginar personas digitales con un interés extraño en los navegadores. Se comportan como buenos ingenieros: estudian un entorno complejo, identifican la interfaz que realmente ofrece y crean abstracciones alrededor de todo aquello que es repetitivo, con estado y costoso. La web ya cuenta con una abstracción antigua y sumamente exitosa para este propósito, y se denomina navegador.