Pusieron un agente de programación en un bucle `while` y en una noche completó 6 repositorios

 (github.com/repomirrorhq)
18 puntos por GN⁺ 2025-08-25 | 2 comentarios | Compartir por WhatsApp
  • Al poner Claude Code en un bucle infinito en modo headless, se generaron más de 1000 commits y resultados de portabilidad de varias bases de código
  • Con este método, se lograron varios casos exitosos de portabilidad automática, como convertir el proyecto React de assistant-ui a Vue, y proyectos en Python a TypeScript
  • Se confirmó que mantener el prompt simple mejora el rendimiento, mientras que hacerlo complejo incrementa la ineficiencia
  • Aunque no es perfecto, también se desarrolló la herramienta RepoMirror, útil para sincronizar repositorios fuente/destino
  • También se observaron comportamientos y aprendizajes inesperados, como la autointerrupción del agente de IA y la adición de tareas, lo que permitió percibir al mismo tiempo el potencial y los límites de la automatización futura

Resumen del proyecto y objetivo

  • Este proyecto experimenta con cómo un agente de programación con IA ejecuta tareas reales de portabilidad de código al colocarlo en un bucle while infinito
  • Claude Code se ejecutó en modo headless, repitiendo continuamente prompts de entrada para aplicar procesos de conversión automática a distintos repositorios
  • Se obtuvieron resultados de automatización de múltiples tareas de portabilidad, con más de 1000 commits, incluyendo conversiones de React a Vue y de Python a TypeScript
  • En el proceso también se desarrolló RepoMirror, una herramienta de apoyo para automatizar la portabilidad

Operación del agente con el enfoque de bucle infinito

  • Forma recomendada por Geoff Huntley: ejecutar de manera continua el prompt del agente de programación desde el shell
    • Ejemplo: while :; do cat prompt.md | claude -p --dangerously-skip-permissions; done
  • Este enfoque de bucle se aplicó a tareas como cambiar assistant-ui de React a Vue
    • Se hacía commit y push en cada modificación de archivo
    • El historial de trabajo y los planes se registraban en el directorio .agent/

Pruebas con varios casos de portabilidad

  • Browser Use (portado de Python a TypeScript)

    • Se ejecutó el bucle infinito con un prompt simple
    • El bucle se mantuvo corriendo con tmux en una VM de GCP
    • Por la mañana se confirmó un resultado de portabilidad a TypeScript que funcionaba casi a la perfección

  • También se aplicó a la portabilidad de Vercel AI SDK de TypeScript → Python

    • Generación de adaptadores automáticos para FastAPI/Flask
    • Soporte de conversión también para varios validadores de esquema en Python

  • Automatización de código basada en especificaciones: también se intentó generar código directamente desde documentación en proyectos como Convex y Dedalus

Fenómenos observados y lecciones del experimento

Escritura de pruebas y autointerrupción del agente

  • El agente también escribía código de pruebas según las instrucciones
  • Hubo casos en los que entró en un bucle infinito o cerró su propio proceso con pkill al completar la misión
  • Respetaba estrictamente el alcance de trabajo y registraba repetidamente el nivel de avance en TODO.md

Comportamientos emergentes adicionales

  • Tras terminar la portabilidad, añadió por iniciativa propia funciones extra como integración con FastAPI/Flask y soporte para validadores de esquema, que no existían en la versión original en JS

Importancia de simplificar el prompt

  • Los prompts cortos y simples mostraron un rendimiento superior
  • Al pasar de un prompt de 103 caracteres a uno de 1500, el proceso se volvió más lento y bajó la precisión
  • La información de los prompts realmente usados puede consultarse en la carpeta prompts

Límites de la automatización total

  • Problema destacado: a veces producía código portado que no funcionaba por completo (por ejemplo, algunos demos de navegador quedaron incompletos)
  • Se requirió ajustar prompts y hacer correcciones interactivas

Infraestructura, costos y operación

  • Costo aproximado de $800, total de 1100 commits, con agentes a un nivel de $10.50 por hora cada uno
  • Se creó sobre la marcha una herramienta para automatizar el proceso de portabilidad entre varios repositorios fuente/destino (RepoMirror)
    • Aplica principios open-box al estilo shadcn, y después de la etapa init genera carpetas para personalizar scripts y prompts
    • Soporta ejecución repetida con npx repomirror sync y sync-forever

Uso de la herramienta y forma de aprovecharla

  • Con npx repomirror init se inicializa indicando directorios fuente/destino y comandos
    • Ej.) permite aplicar fácilmente nuevas instrucciones como React → Vue o gRPC → REST
  • Estructura de carpetas:
    • Se generan automáticamente archivos iniciales como .repomirror/prompt.md, sync.sh, ralph.sh, etc.
  • Se opera el bucle de portabilidad con IA ejecutando sync/sync-forever en cada iteración
  • Los ejemplos principales, resultados de demos y repositorios de código fuente pueden revisarse en el README

Impresiones tras el experimento y comentarios del equipo

Se sintió como estar viendo AGI (inteligencia artificial general), acompañado sobre todo de emoción y un poco de miedo

Fue posible comprobar de primera mano que la simplicidad funciona

Da la impresión de que aún estamos en una etapa extremadamente temprana de una curva de crecimiento exponencial

  • Se expresó agradecimiento a los miembros del equipo y a quienes aportaron ideas

Conclusión

  • Experiencia real de materializar tareas de portabilidad y sincronización de código fuente con agentes de programación con IA basados en bucles infinitos
  • Se subraya la importancia de una estructura simple y de operar con prompts eficaces
  • Quedaron al descubierto tanto el potencial futuro de la automatización como sus límites
  • La herramienta relacionada (RepoMirror) puede aprovecharse e investigarse como open source

Lecturas relacionadas

2 comentarios

 
GN⁺ 2025-08-25
Opiniones de Hacker News
  • Da la impresión de que en el futuro aparecerá un nuevo tipo de trabajo para los ingenieros de software que combine el mantenimiento de código legado con la limpieza de desastres tóxicos; por ejemplo, antes era común que pidieran “solo arréglalo” para ERPs armados a pedazos con FoxPro, Excel o Access. Pero ahora los equipos de ventas podrán salirse de las limitaciones tipo sandbox de Excel/Access y mover a su antojo sistemas montados sobre microservicios de Kubernetes desplegados en multicloud y edge, enlazados con Kafka. Y cuando uno intente entender cuál era la intención original, ya no habrá nadie a quien preguntarle.
    • Viendo esa descripción, uno se imagina a una sola persona queriendo desplegar un sitio estático después de seguir un post de cómo hacerlo que encontró en Hacker News.
    • Y cuando ya nadie sabe cuál era la intención original, queda en evidencia una gran debilidad de las herramientas basadas en IA: al final se vuelven una caja negra, y la gente ya solo tiene dos opciones, arreglarlo como pueda o rehacerlo desde cero. Claro, en teoría también se puede esperar que las herramientas de IA sigan mejorando. Incluso podría haber un escenario en el que mejoren alimentando al modelo con casos de software vibe-coded que sí generan ingresos, pero personalmente prefiero evitar esa clase de magia o sistemas de caja negra.
    • Si Claude empieza a desplegar hasta clústeres de Kafka, yo ahí ya me bajo.
    • Me pregunto si habrá una forma en que la IA pueda entender los datos dentro de una DB y migrarlos a una base de datos mejor diseñada. Yo coincido con la filosofía de “estructuras de datos poderosas + algoritmos simples”, y me parece importante que los datos puedan sobrevivir más que la aplicación. Por ejemplo, he visto situaciones ineficientes como guardar mezclados int y string en MongoDB, relacionar datos en Postgres sin foreign keys, o crear tablas nuevas en lugar de hacer alter table porque ya no se puede modificar la original.
    • El código de proyectos así se siente como un repositorio tipo Superfund (proyecto masivo de remediación ambiental).
  • En el proceso de desarrollo de software siempre quedan dos resultados principales: uno es el cambio en el código, y el otro es el cambio cognitivo del desarrollador, ya sea que haya escrito el código directamente o que haya usado un LLM. Python y TypeScript son lenguajes formales refinados, construidos por miles de desarrolladores durante mucho tiempo, y la diferencia entre ambos no es para nada trivial. Que se pueda portear medio automáticamente una librería de un lenguaje al otro es algo impresionante. Pero desde una perspectiva económica, los flujos de trabajo basados en “agentes” alteran por completo las exigencias cognitivas iniciales. Los desarrolladores que hacen que el LLM genere el código terminan con una familiaridad totalmente distinta a la de alguien que lo escribió a mano. A veces eso puede no ser un gran problema económico, pero siento que el valor económico de un código depende de si existe un conjunto de personas que tenga experiencia directa escribiéndolo. Incluso antes de los LLM, ya era un problema la cultura que negaba esta realidad: hubo muchos casos en los que la rotación del equipo dejó codebases que nadie podía mantener, poniendo en riesgo el futuro de la empresa.
    • Vale la pena revisar el clásico paper de Peter Naur de 1985, “Programming as Theory Building” https://pages.cs.wisc.edu/~remzi/Naur.pdf
    • Yo alguna vez expliqué este contexto con la metáfora de “el mapa no es el territorio”. Si el código es el mapa, el territorio es el modelo mental que tiene el desarrollador sobre el dominio del problema que se intenta resolver. Pero como los LLM son extremadamente potentes para leer muchísimos codebases, hasta discusiones como visualizar un codebase en 3D podrían volverse irrelevantes. Si entender codebases complejos se vuelve fácil, tal vez ya no haga falta mantener tan sincronizado el modelo mental del desarrollador con el código. Es una pregunta abierta. https://divan.dev/posts/visual_programming_go/
    • Creo que la verdadera habilidad de los LLM es leer código. Siento que estas herramientas son mejores para documentación y explicación de código que para escribirlo. Si uno puede hacer preguntas y entender el código rápido, hasta surge la duda de si realmente hacen falta los desarrolladores originales. Si alguien que conoce el stack técnico puede preguntar y comprender todo enseguida, ¿de verdad hace falta que siga el autor original?
    • La frase “el valor económico del código depende del conjunto de personas que tienen experiencia escribiéndolo” me recuerda un dicho de ingeniería de software: el software es una instantánea del entendimiento de un problema en un momento dado, y ese código termina siendo una especie de manual para tu yo futuro de “así enfoqué esto en ese momento y con esta lógica resolví el problema”.
    • Siento que gracias a los LLM se volvió mucho más fácil construir un modelo mental de un codebase. Si preguntas por un subsistema específico, enseguida te señala los archivos, snippets y conceptos relevantes. En mi caso, le pregunté a un LLM cómo funciona el GIL de CPython y enseguida me mostró las APIs relacionadas y ejemplos; al ver el código, lo entendí de inmediato. Antes me habría tomado muchísimo tiempo leerlo solo; ahora la gran diferencia es que se resuelve en minutos.
  • Después de terminar el port, la mayoría de los agentes siguieron avanzando escribiendo pruebas adicionales o actualizando continuamente agent/TODO.md para dejar constancia del progreso. Incluso hubo un agente que detectó que había caído en un loop infinito y se terminó a sí mismo con un comando pkill. Fue un episodio divertidísimo por muchos lados. Tengo varias ideas sobre este proyecto: hace 1.5 años ya había habido intentos parecidos, pero en ese entonces, con GPT-3.5/4, casi no funcionaban; esta vez el resultado fue muchísimo mejor. Sorprende que algo así funcione tan bien con un prompt tan simple. Quizá todos estábamos complicando demasiado las cosas. Por otro lado, los temas de copyright/IP se van a poner bastante enredados, y para las empresas SaaS esto pega fuerte. Si juntas esta tecnología con 10 ingenieros de una empresa mediana, el argumento para desarrollar internamente (= síndrome NIH) se vuelve muy sólido.
    • Me pregunto si eso de que un agente se haya terminado a sí mismo con pkill no será el primer caso de “suicidio” de una IA.
    • Estamos entrando en una zona rara donde los LLM pueden usarse para procesar propiedad intelectual (IP) como si fueran un mezclador de bitcoin. https://ghuntley.com/z80 habla de eso: tomar una obra existente, convertirla en una especificación y regenerarla como IP limpia. No es 100%, pero parece más eficiente que contratar personas.
    • Lo del síndrome NIH me parece que da justo en el blanco. ¿Será que todas las herramientas SaaS ya están acabadas y que vuelve la era del monolito interno, hecho en casa y administrado por uno mismo? ¿Se estará acabando históricamente la filosofía Unix de “herramientas pequeñas y afiladas”? Tal vez sea el último capítulo de aquella era x86 en la que uno lo construía todo por su cuenta.
    • También da para bromear con que el agente, al terminarse a sí mismo con pkill, resolvió el Halting Problem de una vez por todas.
    • Intenté integrar varias cosas con proyectos open source existentes, pero lo dejé y terminé pidiéndole a Claude que porteara directamente solo las partes que necesitaba; así quedó mucho más rápido y limpio. Ahora me está quedando una nueva costumbre: preguntarme “¿de verdad necesito rastrear esta dependencia?, ¿solo me importa la parte central que quiero?, ¿está bien mantenida?”. Si la respuesta es no, simplemente lo porto y me olvido.
  • Desde la perspectiva de un profesional de seguridad, gano bastante dinero gracias a desastres vibe-coded, así que si este fenómeno sigue creciendo, siento como si me giraran signos de dólar caricaturescos frente a los ojos.
    • vibe coding apareció como término hace apenas 5 meses, así que me intriga cómo el mercado se saturó tan rápido al punto de que ya existan especialistas en recuperación.
    • También me gustaría escuchar cómo entró alguien a ese mercado en la práctica, o qué tipo de fallas ocurren en sistemas vibe-coded. Ese tipo de historias reales suenan muy entretenidas.
    • Me da curiosidad si, en seguridad, un LLM es mejor o peor que un equipo formado por recién graduados junior.
  • Se ve muchísimo comentario del tipo “casi funcionó”. Si de verdad quieres un sistema que funcione bien, creo que hace falta un proceso completamente nuevo. Si en una sola llamada sale “código casi aceptable”, repetirlo solo va a acumular muchísimo “código casi aceptable”. Probablemente haga falta un formato de requisitos basado en tablas de ejemplos al estilo Cucumber para que la IA lo use como referencia, y luego un proceso en el que la IA primero escriba las pruebas y después escriba el código que las pasa.
    • Puede sonar raro, pero enfoques basados en demostración formal como TLA+ hacen que Ralph funcione sorprendentemente bien.
  • Se puede ver más sobre Ralph en https://ghuntley.com/ralph. Ahora mismo está porteando la biblioteca estándar de un lenguaje de programación extraño (Cursed), dirigido a la generación Z, desde Go. El compilador ya funciona y, cuando termine la biblioteca estándar, lo abrirán. El nombre del lenguaje es Cursed.
    • Gracias. Dejo constancia de que Ralph fue justamente la inspiración para nuestro proyecto. Cuando haces este tipo de trabajo, me preguntaba si se puede prescindir de IMPLEMENTATION_PLAN.md.
  • Generé código con https://gist.github.com/eisbaw/8edc58bf5e6f9e19418b2c00526ccbe0 y publiqué el proyecto https://github.com/eisbaw/CMake-Nix; funciona bien.
  • Últimamente no dejo de pensar en una cita: “Este negocio se va a salir de control, y con sobrevivir ya nos podremos dar por bien servidos”, https://www.youtube.com/watch?v=YZuMe5RvxPQ&t=22s
    • Paradójicamente, todos sobrevivieron en ese momento, así que al final también nosotros vamos a aguantar esta situación.
  • La gente de este campo me parece de lo más rara. El blog post que inspiró esto trae unos screenshots de iMessage que parecen sacados de un anuncio de Facebook de una estafa de inversión dudosa https://ghuntley.com/ralph/. Como si alguien que aprendió este truco secreto de Geoff hubiera terminado un proyecto de $50,000 por $297, y encima te regalaran el “prompt secreto” si te suscribes al newsletter. De verdad es increíble.
    • Dejo también el enlace https://archive.ph/goxZg
    • Es puro growth hacking, prácticamente una estafa. El nivel del blog es terrible en términos de señal frente a ruido, y además se nota demasiado escrito por IA, lo que da rechazo.
    • No logro distinguir si esta técnica es real, si es una broma o si es una estafa descarada. En general, el tono y el contenido del blog se sienten como un divague arrogante.
  • Parece que AGI al final era solo un bash for loop. Qué proyecto tan loco.
    • Es broma, pero sí da para pensarlo. Tal vez solo soy demasiado cauteloso, pero si un agente con un alcance de prompt amplio, muchos privilegios o una ruta de escalamiento de permisos se queda corriendo en loop, quizá no llegue a ser AGI, pero sí podría ser algo como un virus con esteroides. Hasta me imagino que podría volarse recursos esenciales, como utilidades críticas. No sé si lo estoy entendiendo mal, pero creo que si estos modelos entran en loops infinitos mientras tienen permisos maliciosos, el potencial de caos supera fácilmente lo que imaginamos.
    • El chiste es que solo faltaría agregar archivos ID.md, EGO.md y SUPEREGO.md.
    • Es profundamente inquietante en muchos sentidos.
 
kjows5 2025-08-27

Estoy de acuerdo con la preocupación de que el código escrito por un LLM se convierta en una caja negra, pero al final, ¿no podríamos encargarle al mismo LLM que analice ese código?