Mi Agente de IA Falló el Mismo Clic de LinkedIn 30 Veces. Camoufox lo Logró al Primer Intento.

8 min read

A veces la IA simplemente hace algo estúpido. No importa cómo la instruyas.

Ilustración de oficina dividida comparando desarrollador frustrado con intentos fallidos de automatización versus desarrollador confiado con resultado exitoso de automatización de navegador
30 intentos fallidos vs. éxito al primer intento. Herramienta equivocada, amigo.

El Mismo Clic, 30 Veces

Mi agente falló el mismo clic de LinkedIn 30 veces, presionando el mismo botón en la misma página en un bucle infinito de reintentos. Los perfiles de LinkedIn muestran "Seguir" como acción principal y "Conectar" escondido dentro del menú desplegable "Más" (los 3 puntos). Tocas el desplegable, aparece el menú, haces clic en "Conectar", se abre el diálogo de conexión. Pan comido.

El Chrome MCP toma una captura de pantalla para leer la posición del elemento, luego envía el clic. Esa secuencia tiene un retraso. Corto, pero incompresible. Para cuando se dispara el evento de clic, el menú desplegable animado ya se ha cerrado solo. El agente no lo detecta. Toma otra captura, no ve el diálogo "Conectar", vuelve al bucle. En el intento 14 los logs muestran exactamente la misma secuencia. El intento 20 es puro ruido.

En algún momento me quedo ahí leyendo los logs pensando que esta cosa me va a hacer que me baneen. (Energía Dark Souls: moriste, lo intentaste, moriste otra vez. Excepto que ser baneado de LinkedIn no es una situación de respawn.)

El Chrome MCP no es una mala herramienta. Quiero ser exacto sobre eso antes de continuar, porque es fácil caer en espiral hacia "la herramienta apesta" después de una sesión así. Para el 80% de las tareas de automatización del navegador es la opción predeterminada correcta. El problema era que el caso del menú desplegable de LinkedIn no estaba en ese 80%, y la señal para cambiar ya estaba ahí en el intento 2.

Lo Que Chrome MCP Realmente Hace Bien (El 80%)

Reutilizar una sesión existente es donde Chrome MCP es difícil de superar. El navegador ya está autenticado, cookies cargadas, 2FA despejado. El agente entra en ese contexto sin tocar flujos de login o verificación.

La navegación y extracción de texto son confiables. Leer contenido DOM, hacer scraping de páginas estructuradas, extraer texto de layouts estables: sólido.

Los formularios HTML estándar funcionan limpiamente. Campos de texto, desplegables, checkboxes: el MCP los llena sin ceremonias, sin gimnasia JavaScript requerida.

La depuración frontend es el caso subestimado. El agente puede leer errores de consola, cascada de red y estado de página en vivo. Útil cuando estás construyendo algo y quieres que el agente verifique su propia salida en el navegador sin crear un harness de prueba separado. Piénsalo como programación en pareja donde 1 compañero solo se comunica a través de capturas de pantalla. Ineficiente para la mayoría de conversaciones, sorprendentemente bien para revisión de código.

Estos 4 casos cubren la mayoría de lo que cualquier flujo de automatización de navegador necesita día a día. Los casos extremos surgen cuando la acción requiere timing preciso o manejo de eventos nativos.

Las 4 Formas en Que Se Rompe

El caso de LinkedIn produjo 4 modos de falla distintos en la misma acción. Cada uno se desarrolla diferente.

El menú se cierra antes de que llegue el clic. La sobrecarga entre tomar una captura de pantalla y despachar el clic es incompresible. Para una transición CSS que se cierra en 150ms, esa sobrecarga es suficiente. El menú desaparece antes de que llegue el clic.

Los clics sintéticos son ignorados silenciosamente. La biblioteca de componentes artdeco de LinkedIn escucha eventos de puntero confiables, del tipo generado a través de entrada de hardware real. Un clic despachado programáticamente no lleva la bandera isTrusted. El componente no responde. Sin error, sin feedback, nada.

El elemento está oculto por el header pegajoso. La navbar de LinkedIn se mantiene fija en la parte superior del viewport. Si el menú desplegable se abre cerca de la parte superior de la página, la navbar intercepta el clic. Chrome MCP no realiza hit-test para detectar esto.

La pestaña se desvía. Después de suficientes clics parásitos, algo se activa: una tarjeta, un enlace de perfil, un panel lateral. El agente pierde la página objetivo y comienza a automatizar confiadamente lo que sea en lo que aterrizó. (Evento de networking patrocinado aceptado. Gracias, agente.)

Cada uno de estos es manejable por separado. Los 4 juntos en la misma acción es una pared estructural.

Por Qué Se Rompe (No Es el Prompt)

El Chrome MCP opera desde arriba del navegador. Se sienta como una extensión, observa a través de capturas de pantalla, despacha 1 acción por ciclo, y espera. Este modelo tiene una ventaja real: no requiere instalar nada dentro del motor de renderizado, reutiliza tu sesión Chrome existente sin modificación, y puedes apuntarlo a cualquier instancia Chrome en ejecución sin configuración. El compromiso es que cada acción involucra un round-trip con suficiente latencia para perder estados de UI sensibles al tiempo, y los clics que despacha no se originan desde dentro del pipeline de eventos confiables.

Los frameworks JavaScript modernos verifican la propiedad isTrusted en eventos de puntero entrantes, y React, Vue, y bibliotecas de componentes como artdeco de LinkedIn todas hacen esta verificación. Un clic de Chrome MCP llega al DOM pero falla la validación interna del componente. La falla es silenciosa, no surge error, y tendrías que leer el código fuente del componente para siquiera saber que la verificación existe.

Pasé 3 semanas tratando de arreglar específicamente el lado del timing: wait_for_element, aumentando brechas de reintento, diferentes valores de retraso entre captura y clic. El menú siguió cerrándose. El problema isTrusted era completamente separado y solo lo descubrí después de leer el código fuente de artdeco. Ese fue un jueves divertido.

Por qué los CLIs a menudo superan a MCP para trabajo de agentes cubre el lado del costo de tokens de este compromiso, pero el lado de eventos confiables es lo que realmente muerde en producción.

Un clic de Chrome MCP es técnicamente un clic. El componente lo trata como un email educado que nadie pidió.

La Señal de Cambio: 2 a 3 Fallas

La regla es 1 línea: después de 2 a 3 fallas en la misma acción específica, para y cambia de herramientas. Agregar otro bucle de reintento no cambia el resultado cuando la falla es estructural.

Después del 3er intento fallido en el mismo gesto, no estás depurando el enfoque. Estás mejorando tu archivo de log.

Las situaciones que disparan el cambio:

  • Un menú u overlay se cierra antes de que llegue el clic
  • 2 gestos necesitan encadenarse dentro de una ventana de tiempo ajustada (abrir menú, luego hacer clic en ítem)
  • El elemento no responde a clics y no muestra error
  • Un botón React o Vue permanece gris a pesar de que el formulario parece válido
  • La misma acción necesita ejecutarse docenas de veces en modo headless

Creo que este umbral de 2-a-3 se mantiene para la mayoría de UIs web estándar. Menos confiado de que se aplique de la misma manera a frameworks completamente personalizados donde los modos de falla se ven diferentes.

Lo Que Camoufox Cambia (Y Lo Que Cuesta)

Camoufox es un navegador Firefox endurecido contra detección de bots, manejado por Playwright. Donde Chrome MCP opera desde arriba del navegador, Playwright inyecta eventos desde dentro del motor de renderizado, a través del mismo camino que toma la entrada de usuario real.

En el caso del desplegable de LinkedIn:

Eventos confiables reales. Playwright despacha la cadena completa de eventos de puntero con isTrusted: true. El menú desplegable se abre. El ítem "Conectar" registra el clic. Primer perfil hecho.

Localizadores basados en ARIA. En lugar de coordenadas de píxeles de captura: page.getByRole('menuitem', { name: 'Connect' }). Determinístico, legible, y no se rompe cuando LinkedIn ajusta su padding por 2 píxeles en una ventana de mantenimiento de lunes. Todos los equipos han tenido ese deploy 😅

Sin round-trip entre acciones. Abrir el menú y hacer clic en el ítem en la misma ejecución de script. Sin ciclo de captura entre los 2 pasos. Sin condición de carrera.

Validación de estado React. Para un botón de envío que permanece gris hasta que la entrada tiene un valor: Playwright emite tanto los eventos input como change para despertar el estado del componente, luego hace clic en el botón desbloqueado. Chrome MCP hace clic en el botón gris. No pasa nada.

Advertencias de inmediato. La sesión no se transfiere: el primer lanzamiento requiere un login manual, ya que Camoufox no hereda las cookies de Chrome. Una nueva huella digital de navegador dispara la verificación de "nuevo dispositivo" de LinkedIn. El script de Playwright es código de producción que necesita ser mantenido. Y la limitación de velocidad de LinkedIn no le importa qué navegador estés usando si la cadencia de acción parece automatizada.

El cambio tiene un costo de configuración real. Vale la pena cuando Chrome MCP ya ha mostrado 2 a 3 fallas en una acción específica. No antes. Playwright está construido sobre Chrome DevTools Protocol, que es parte de por qué el modelo de eventos termina siendo mucho más cercano a la entrada de usuario real que cualquier cosa operando desde arriba del navegador.

Cuándo Usar Qué

TÍTULO "Chrome MCP vs Camoufox: Cuándo Cambiar" + subtítulo "8 escenarios, 1 regla de decisión". Metáfora: panel de sala de control de 2 columnas, lado izquierdo etiquetado CHROME MCP (verde), lado derecho etiquetado CAMOUFOX (naranja), con 4 tarjetas de situación en cada lado. Estilo: plano de ingeniero en papel cuadriculado, líneas de cuadrícula limpias, estilo de anotación técnica, sin elementos decorativos. Paleta: gris pizarra #334155, verde terminal #22c55e, naranja advertencia #f97316, blanco roto #f8fafc, negro #0f172a. Contenido: Tarjetas columna verde: NAVEGAR Y EXTRAER, LLENAR FORMULARIO ESTÁNDAR, REUTILIZAR SESIÓN EXISTENTE, DEPURACIÓN FRONTEND. Tarjetas columna naranja: MENÚ O OVERLAY, 2 GESTOS ENCADENADOS, CLIC SINTÉTICO IGNORADO, VOLUMEN HEADLESS. Destacado: banner inferior de ancho completo en naranja con texto blanco en negrita: REGLA DE CAMBIO: 2 A 3 FALLAS EN LA MISMA ACCIÓN. Leyenda: tarjeta verde = territorio Chrome MCP, tarjeta naranja = territorio Camoufox. Pie: copyright rentierdigital.xyz abajo-derecha, pequeño. NO dashboard corporativo plano, NO plantilla genérica de comparación lado a lado.
Guía de Decisión Chrome MCP vs Camoufox

Chrome MCP para:

  • Tareas rápidas de una sola vez en sitios donde ya estás logueado
  • Leer contenido de páginas estables
  • Llenar formularios en entradas HTML estándar
  • Depurar problemas frontend en una sesión existente

Camoufox + Playwright para:

  • Acciones repetidas que necesitan ser confiables
  • Elementos interactivos que requieren eventos confiables
  • Secuencias de timing ajustado (menús, desplegables, modales)
  • Automatización de producción que no puede permitirse bucles de reintento

El disparador de cambio: 2-3 fallas en la misma acción específica. No 30.


La sesión de 30 intentos costó 40 minutos y una reescritura de script Playwright. Camoufox obtuvo el primer perfil en 12 segundos. Los 29 después corrieron al mismo ritmo.

La señal estaba ahí en el intento 2. Solo necesité 28 intentos más para leerla. 🤦‍♂️

Fuentes

Este post puede contener enlaces de afiliado. Si los haces clic, podría ganar una pequeña comisión. No te cuesta nada, y me ayuda a seguir enviando artículos de calidad todos los días para tu placer de lectura.