La pregunta no es si un agente puede escribir una función. Puede, y lo hace. Casi cualquier equipo tiene ya alguna anécdota de una función que salió mejor de lo esperado. La pregunta es si un agente al que le das una tarea bien especificada, las mismas herramientas que tiene un ingeniero senior y ninguna supervisión, produce una PR que de verdad aprobarías.
Eso es otra cosa. Escribir código y desplegar código correcto son cosas distintas en cuanto falla el primer test, el log dice algo inesperado o la interfaz no coincide con la especificación. Un humano depura. Un agente, sin el bucle correcto y las herramientas adecuadas, adivina y pasa a lo siguiente.
De eso trata este artículo: de lo que hace falta para cerrar esa brecha.
Qué significa "tan bueno como un humano" hoy
La medida más rigurosa de la capacidad autónoma de programación es el estudio de horizontes temporales de METR. Midieron la duración de las tareas en las que los mejores modelos actuales aciertan el 50% de las veces, y encontraron que ese umbral se dobla aproximadamente cada siete meses. Según el artículo en arXiv, Claude 3.7 Sonnet se sitúa en torno a los 50 minutos; hay tareas de programación que ya llegan a las 14 horas. Eso son avances reales.
El ranking de SWE-bench Verified cuenta algo parecido: Claude Opus 4.5 alcanza el 80,9%. Pero si miras SWE-bench Pro, la variante más difícil de Scale con tareas que no eran públicas durante el entrenamiento, ese mismo modelo cae al 45,9%. La diferencia no es un fallo del modelo. Es un fallo de la metodología de evaluación: Verified mide la generación de parches sobre bugs conocidos; Pro mide la resolución real de problemas nuevos.
Los dos benchmarks miden un único intento de generar un parche correcto. La autonomía está en el bucle, no en el intento. Un agente que falla una vez y no tiene ningún mecanismo para aprender de ese fallo no es autónomo: es un generador de texto estocástico con suerte.
El patrón de autonomía: los bucles Ralph
El bucle Ralph es el patrón más simple que convierte un generador estocástico en un sistema con una condición de salida verificable.
Geoff Huntley acuñó el término tras observar que todos los sistemas de programación autónoma que funcionan bien comparten la misma estructura: un bucle while-true determinista, una tarea por iteración. El agente ejecuta, un evaluador comprueba el resultado y, si falla, el agente reintenta con el contexto del intento anterior. En su segundo post lo llama "Ralph Wiggum como ingeniero de software", en referencia al personaje que lo intenta, falla y lo vuelve a intentar — pero esta vez con lo que ha aprendido.
Existen implementaciones de referencia: snarktank/ralph y vercel-labs/ralph-loop-agent incluyen versiones funcionales del patrón. Los detalles difieren; la estructura es la misma.
¿Por qué importa? Porque convierte un generador probabilístico en un proceso que termina cuando se cumple una condición verificable. El agente no tiene que acertar a la primera: tiene que converger en un evaluador en verde. Eso es un problema resoluble, no una apuesta.
La crítica honesta también merece decirse: Ralph es fuerza bruta. El coste escala de forma lineal con los reintentos. La convergencia depende por completo de la calidad del evaluador. Si tu evaluador es "¿han pasado los tests?" y los tests solo cubren el happy path, el bucle converge en código que pasa los tests y despliega el bug. El patrón es tan fiable como la señal en la que termina.
El stack que da ojos y manos a un agente
Cada paso de una sesión de depuración humana tiene su equivalente en MCP.
Un humano abre DevTools, revisa la pestaña de red, sigue los logs del servidor, consulta la base de datos, pone un breakpoint y vuelve a lanzar el test que falla. Un agente con las herramientas MCP adecuadas hace exactamente la misma secuencia: simplemente no abre un portátil.
El Playwright MCP de Microsoft le da al agente acceso al navegador. No capturas de pantalla: un árbol de accesibilidad estructurado, más de 20 herramientas de control del navegador y la capacidad de hacer clic, escribir, navegar y verificar el estado de la interfaz. Consulta la documentación de Playwright MCP para la configuración. Es lo más parecido que existe a "el agente abre la aplicación y navega por ella".
Los logs están cubiertos por la especificación de logging de MCP. La especificación define notifications/message con niveles de severidad controlados por el servidor. Combinado con las herramientas del repositorio de referencia modelcontextprotocol/servers, un agente puede leer la salida de logs estructurados igual que un humano lee tail -f.
El acceso a bases de datos sigue el mismo patrón. El repositorio de referencia incluye MCPs para Postgres y SQLite. El agente puede consultar el estado en el momento del fallo, compararlo con lo que el código espera y encontrar la divergencia: el mismo movimiento que haría un ingeniero senior cuando los logs no cuentan toda la historia.
El contexto del repositorio es donde aplica directamente el artículo anterior de IBERANT sobre preparación del código para IA. Un agente que no entiende los límites de tus módulos, las convenciones de nomenclatura o los patrones de tests producirá código que compila y falla en producción. AGENTS.md y CLAUDE.md son requisitos previos, no adornos. La guía de ingeniería de contexto de Anthropic lo dice sin rodeos: el presupuesto de atención del agente es finito, y el contexto denso en señal supera al contexto exhaustivo siempre.
El evaluador del bucle Ralph es la pieza final. Puede ser npm test, una suite de tests end-to-end con Playwright, un typecheck o los tres en secuencia. La única restricción: tiene que ser determinista y legible por una máquina. "La build ha pasado pero hay warnings" no es un evaluador. "Exit 0 o exit 1" sí.
Un caso real: corrección autónoma de bugs
La mayoría de los informes de error reales no llegan como tests fallidos. Llegan como un mensaje de un usuario: "el botón de pago no hace nada después de poner el código promocional". Quizás una captura. Eso es todo.
El primer trabajo del agente es convertir eso en un flujo reproducible. Con Playwright MCP puede hacer exactamente lo que hizo el usuario: abrir la aplicación, navegar al carrito, introducir el código promocional, pulsar el botón y observar qué ocurre. El flujo de clics es la reproducción. No hace falta un test fallido para empezar.
A partir de ahí, el agente toma una decisión. Si el comportamiento erróneo es visible en la interfaz (estado incorrecto, elemento que no aparece, respuesta mal renderizada), escribe una aserción de Playwright que lo captura. Eso se convierte en el evaluador del bucle Ralph: un script que falla hasta que el bug se corrige. Si la interacción apunta a un fallo en el backend (un 500 en la pestaña de red, un campo ausente en la respuesta de la API, una línea de log inesperada), el agente reduce la reproducción a la llamada a la API que está fallando realmente. El script de Playwright se contrae a un equivalente de curl, o a una llamada directa al endpoint relevante. Más simple, más rápido y más barato de ejecutar en cada iteración.
Cuando el fix se aplica y el bucle termina, el agente tiene todo el material para un test real: los pasos exactos, el comportamiento real frente al esperado, la capa donde ocurrió el fallo. Lo escribe como un test automatizado de verdad — no un script desechable, sino algo que vive en la suite de tests y detectaría una regresión. Luego escribe un postmortem breve: qué se rompió, dónde, cuál fue el fix y qué cubre el nuevo test.
Los requisitos de entrada son menos de lo que podría parecer:
- Un entorno de desarrollo activo al que el agente pueda acceder. Un solo comando:
docker compose up,npm run devcon una base de datos con datos de prueba. Nada de "pregúntale al senior". - La descripción del usuario y, si es posible, una captura de pantalla o grabación de pantalla para anclar el flujo de clics.
- Acceso de lectura a los logs y a las respuestas de red durante la reproducción.
- Una forma de resetear el estado entre iteraciones del bucle para que cada intento empiece desde cero.
El bucle se ejecuta: reproduce mediante Playwright, inspecciona logs y respuestas de la API, identifica la capa (renderizado frontend, contrato de API, estado de la base de datos), reduce la reproducción a la aserción mínima fallida, propone y aplica un fix, vuelve a ejecutar, evalúa. En verde, sale con una PR que incluye el fix, el nuevo test de regresión y el postmortem. En rojo, itera de nuevo con la evidencia actualizada en contexto.
Los requisitos que no son opcionales:
Un entorno estable es el punto de partida. Si la aplicación se comporta de forma diferente en el tercer reintento porque quedó estado residual en la base de datos o una sesión en caché, el bucle no puede converger. El aislamiento por iteración importa más de lo que parece.
Un tope de gasto es innegociable. Fija un número máximo de iteraciones. El bucle debe abortar, informar de dónde se quedó atascado y devolver el control a un humano — no gastar indefinidamente en un bug que no puede cerrar solo.
La revisión humana ocurre en el límite de la PR. El diff, el nuevo test y el postmortem van a un humano antes de que se fusione nada. La autonomía termina ahí, no en main.
Los modos de fallo son reales: bugs que solo se reproducen con datos de producción a los que el agente no tiene acceso, problemas de concurrencia que el flujo de Playwright no puede provocar de forma fiable, y bugs cuya corrección requiere una decisión fuera del alcance de la tarea. En este último caso, el bucle converge en algo — pero puede que en algo incorrecto si el evaluador lo acepta. El bucle Ralph no protege frente a una tarea mal especificada. Protege frente a un único intento en una tarea bien especificada.
Donde se complica: el problema de los datos de producción
El flujo que acabamos de describir asume algo en silencio: que el bug se puede reproducir con los datos del entorno de desarrollo o QA. Normalmente no es así.
Un usuario reporta que al enviar un pedido con varios artículos y un código promocional aplicado a un producto de suscripción, la operación falla sin mostrar nada. Tu base de datos de QA tiene códigos promocionales. Tiene productos de suscripción. No tiene el estado concreto de esa cuenta, el caso límite de facturación ni la combinación de flags que dispara el fallo en producción. El flujo de Playwright se ejecuta sin incidencias. El agente no encuentra nada. El bucle termina en verde y el bug sigue ahí.
Para reproducir el bug fielmente necesitas una copia de la base de datos que refleje el estado que tenía el usuario cuando falló. Es decir, un snapshot de producción. Y ahí es donde la complejidad operativa empieza a acumularse.
El primer problema es el cumplimiento normativo. El Artículo 32 del RGPD exige medidas técnicas adecuadas para proteger los datos personales, y copiar registros reales de clientes en un entorno de desarrollo que los desarrolladores pueden consultar libremente no cumple ese requisito. HIPAA, PCI DSS y la mayoría de normativas nacionales equivalentes dicen lo mismo con reglas distintas. La sanción por incumplimiento no es una advertencia: puede llegar al 4% de la facturación anual global según el RGPD. La mayoría de empresas que tienen un snapshot de producción en un entorno de desarrollo están en incumplimiento y no lo saben.
El segundo problema es el tamaño. Una base de datos de producción que refleja el uso real suele pesar cientos de gigabytes o más. El portátil de un desarrollador, un runner de CI o un entorno de desarrollo por rama no pueden absorber eso ni rápido ni barato. Un snapshot que tarda cuatro horas en restaurarse no sirve como estado inicial por iteración en un bucle Ralph. El aislamiento entre iteraciones exige que cada bucle empiece desde un estado limpio y conocido, y "restaurar 400 GB antes de cada intento" no es un enfoque viable.
El tercer problema es la deriva. Un snapshot tomado en el momento del incidente es correcto una sola vez. En el momento en que lo restauras y el agente empieza a escribir en él, el estado diverge. Ejecuta el bucle cinco veces desde el mismo snapshot y cada ejecución se aleja un poco más. Sin un mecanismo para restablecer el estado exacto de producción antes de cada iteración, la reproducibilidad se degrada a medida que el bucle avanza.
Estos tres problemas — cumplimiento, tamaño y deriva — significan que no puedes simplemente hacer un pg_dump de producción y darlo por resuelto. La buena noticia es que existen soluciones reales, cada una con sus propios compromisos.
La ramificación de bases de datos es la opción más cómoda si tu infraestructura lo permite. Neon implementa branching copy-on-write a nivel de almacenamiento: crear una rama desde un snapshot similar al de producción tarda segundos independientemente del tamaño de la base de datos, y cada rama diverge de forma independiente. El bucle del agente puede cambiar a una rama limpia antes de cada iteración sin necesidad de una restauración completa. Xata adopta un enfoque similar y añade enmascaramiento de datos personales integrado mediante pgstream, de modo que la rama que consulta el agente ya tiene las columnas sensibles transformadas antes de la primera query. El problema de cumplimiento y el de tamaño desaparecen en gran medida.
Los snapshots anonimizados son el punto medio pragmático para equipos con PostgreSQL o MySQL tradicional. El patrón: toma un snapshot de producción, aplica un proceso de enmascaramiento antes de que ningún desarrollador ni agente pueda consultarlo y usa el resultado como base reproducible. Tonic.ai gestiona el paso de enmascaramiento en el extremo empresarial: preserva la integridad referencial y las distribuciones de datos mientras sustituye los datos personales por valores sintéticos realistas, de modo que el bug que se activó con un caso límite real a menudo sigue activándose con el equivalente enmascarado. Para opciones de código abierto, pgcopydb combinado con postgresql-anonymizer ofrece una copia rápida y una capa de enmascaramiento declarativa que puedes revisar en una pull request. El resultado es un snapshot seguro para usar en desarrollo y suficientemente representativo para reproducir la mayoría de los bugs que dependen de datos concretos.
Los datos sintéticos funcionan cuando el bug tiene que ver con patrones y no con registros concretos: una cuenta que lleva más de 36 meses como cliente, o un pedido donde el descuento supera el coste de envío. Herramientas como MOSTLY AI y Gretel.ai generan conjuntos de datos sintéticos estadísticamente representativos que reproducen la distribución de producción sin contener un solo registro real de clientes. No reproducirás un bug vinculado al estado exacto de la cuenta de un usuario concreto, pero sí reproducirás clases enteras de bugs que nunca aparecen en datos de prueba escritos a mano porque nadie pensó en incluirlos.
La extracción de subconjuntos suele pasarse por alto. Rara vez necesitas la base de datos de producción completa para reproducir un bug. Necesitas los registros relevantes y sus dependencias. pgcopydb admite copias filtradas; un pg_dump personalizado con --table y una cláusula WHERE que aísle la cuenta, el pedido o la sesión afectados suele ser suficiente. Una base de datos de 400 GB se convierte en un fragmento reproducible de 200 MB que se restablece en segundos y puede incluirse en el repositorio como fixture de prueba.
Ninguna de estas opciones elimina la necesidad de tomar una decisión deliberada sobre qué datos puede ver el agente. Esa decisión hay que tomarla antes de construir el bucle, no después del primer incidente de cumplimiento. El límite de aislamiento del bucle y la estrategia de enmascaramiento o ramificación son parte de la infraestructura, igual que el tope de gasto y el restablecimiento de estado limpio. Hay que construirlos desde el principio.
Recomendaciones de IBERANT
Esto es lo que merece la pena hacer antes de ejecutar el primer bucle.
Conecta todo el stack de herramientas antes de escribir el bucle. Un agente sin Playwright, logs y acceso a la base de datos no es autónomo: es un generador de parches con reintentos. Las herramientas no son extras opcionales; son la diferencia entre que el bucle converja en una solución real o en una suposición que parece plausible.
Trata el evaluador como la parte más importante del sistema. Un evaluador débil es peor que no tener bucle, porque produce respuestas incorrectas con total confianza. Antes de ejecutar nada, pregúntate: si el agente despliega el fix equivocado pero los tests pasan, ¿lo detectaría el evaluador? Si la respuesta es no, arregla primero el evaluador.
Parte de informes reales de usuarios, no de tests sintéticos. Un bug descrito por un usuario real, con su flujo de clics, es la entrada correcta. No reconstruyas una reproducción artificial de memoria. Deja que Playwright siga lo que hizo el usuario: ese camino es más fiel que un test que escribiste esperando capturar el fallo.
Fija un tope de gasto antes de la primera ejecución, no después. Un límite de iteraciones no es una restricción pesimista; es lo que convierte un bucle infinito en un proceso acotado. Diez iteraciones es un punto de partida razonable. Si no ha convergido para entonces, el problema probablemente sea el evaluador o el entorno, no el modelo.
Aísla el estado entre cada iteración. El agente corromperá cosas: escribirá datos parciales, dejará sesiones abiertas, producirá efectos secundarios que alteran el resultado de la siguiente ejecución. Una base de datos nueva y un estado limpio de la aplicación por iteración no es perfeccionismo innecesario; es lo que hace que los resultados sean reproducibles.
No te saltes el paso del postmortem. El test de regresión y el postmortem que escribe el agente al salir del bucle no son burocracia. El test entra en la suite y detecta la misma clase de bug la próxima vez. El postmortem le da al siguiente ingeniero (o agente) el contexto necesario para entender por qué el fix tiene la forma que tiene. Los dos tardan segundos en generarse y su valor se acumula con el tiempo.
Mantén los ficheros de contexto al día. AGENTS.md y CLAUDE.md tienen que describir cómo funciona el código hoy, no como funcionaba hace seis meses. El bucle no compensará a un modelo que trabaja con contexto obsoleto. Revisa estos ficheros después de refactorizaciones importantes, igual que revisas los tests.
Dónde está realmente la frontera
Para tareas bien especificadas, reproducibles localmente y con un evaluador real, los agentes autónomos ya despliegan código que un humano habría desplegado. Eso no es optimismo: es lo que muestran los datos de METR y las implementaciones funcionales del bucle Ralph.
El cuello de botella no es el modelo. Es la infraestructura que lo rodea: entornos reproducibles, evaluadores deterministas, permisos de herramientas bien delimitados, límites de coste y ficheros de instrucciones densos en señal. El modelo tiene capacidad suficiente para cerrar la mayoría de bugs e implementar la mayoría de funcionalidades bien delimitadas. La pregunta es si el stack que lo rodea le da la misma superficie de trabajo que tiene un humano.
La mayoría de equipos no están bloqueados por la capacidad del modelo. Están bloqueados porque no tienen un entorno de desarrollo con datos de prueba que el agente pueda levantar, una suite de tests con cobertura real o un evaluador en el que merezca la pena confiar. Resuelve eso y no estarás esperando un modelo mejor: ya estarás en marcha.
En IBERANT, estos son los problemas de ingeniería en los que trabajamos con los equipos con los que construimos. Si quieres explorar cómo serían los flujos autónomos para tu stack, escríbenos.