From Prompt Engineering to Loop Engineering

Gracias. Creo que es mi segunda vez hablando en público. Así que trabajo como ingeniero de software en Google, estoy con GitNation desde 2016, ayudando con conferencias. En el trabajo, trabajo en canalizaciones de datos de IA y flujos de trabajo de desarrolladores de IA.

Así que la charla relámpago de hoy es sobre ingeniería de bucles. Así que todos conocen esta cita de Boris Chorny y yo también he estado pensando mucho en ella. He tenido algunos pensamientos de que tal vez la ingeniería de prompts está muerta y nuevos productos como Biotropic ahora se desarrollan con bucles mágicos como CloudTag y así sucesivamente. ¿Y qué es eso?

Aparentemente no lo era. Y la ingeniería de bucles fue básicamente diseñada para reemplazar esos momentos donde el juicio humano se convierte en un cuello de botella. Los modelos se volvieron súper, súper rápidos, la nube obtuvo modo rápido, los códecs obtuvieron modo rápido. Están regresando a ti muy rápidamente, esperando la próxima decisión, y básicamente estás encadenado a una máquina con el modelo esperando el próximo prompt. Así que la solución a esto es escribir bucles para automatizar decisiones en las que no necesariamente se necesita un humano, como escribir pruebas o dividir tu tarea en partes y así sucesivamente.

Así que para comenzar a hacer bucles, necesitamos preguntarnos qué decisiones podemos automatizar. Estas decisiones son qué hacer a continuación, cómo dividir el trabajo, qué contexto cargar. Hubo una investigación de Geoffrey Huntley, que por cierto es muy famoso por invitar a un modelo de bucle ralph, y concluyó que solo los primeros 146 000 tokens son significativos para el contexto, y luego el modelo comienza a desviarse y alucinar después de eso.

Entonces, ¿qué pueden construir los bucles? Con bucles, obviamente podemos mantener el repositorio, hacer migraciones, construir pequeñas características de producto, incluso podemos construir aplicaciones completas y lenguajes desde cero, y repasaré un par de casos del mundo real. Así que primero sería un lenguaje de programación Kerst. Fue desarrollado usando ingeniería de bucles. Un bucle estuvo funcionando durante tres meses, y el resultado fue un lenguaje completamente creado. Funcionó de alguna manera. También tenía un archivo prom.md, que estaba verificando un plan.md fijo y ejecutándolo, actualizando el plan por sí mismo, y ejecutándolo nuevamente durante los tres meses completos. Para hacer eso, el autor pre-creó un directorio con especificaciones, puso información básica, cómo debería funcionar el lenguaje, gramática, gestión de memoria, concurrencia, cómo debería estructurarse llvm para ello, creó un agents md con algunas pautas básicas sobre si el modelo aprende algo, cómo debería proceder, y como resultado, después de tres meses, obtuvo un lenguaje de programación completamente funcional con una sintaxis jenzy divertida. Unos segundos en la diapositiva.

Nota importante sobre este bucle. Un lenguaje fue desarrollado por un sistema que actualizaba constantemente el plan.md fijo. Estaba comparando especificaciones y archivos fuente, estaba escribiendo lo que faltaba como una lista priorizada, estaba constantemente eligiendo lo más importante y formando una nueva lista de tareas para la siguiente iteración. Entonces, una conclusión importante de aquí sería que el estado del repositorio siempre intenta hacer un bucle. Una segunda investigación terminó en la cima de Hacker News por un tiempo. Los chicos de Y Combinator crearon seis proyectos de la noche a la mañana. Tres de ellos solo estaban traduciendo código de un lenguaje a otro, y algunos experimentos solo creando proyectos a partir de archivos de especificaciones. Lograron sus objetivos. Creo que el presupuesto era de $50,000. Gastaron $800 en este proyecto. Los códigos QR para esta investigación y presentación se compartirán más tarde.

¿Y qué hay de eso? Después de este éxito obvio en la mañana, obtuvieron repositorios traducidos. Obviamente Claude fue bueno en eso. Decidieron refactorizar la base de código en un bucle. Terminaron con un gran CL, un gran PR, que tenía 20,000 líneas de código. Y ese bucle terminó creando 1.6 mil elementos de tareas, que eran básicamente no verificables. Y a la mañana siguiente, cuando se despertaron con este PR, lo revisaron. Los rumores eran que dijeron que era agradable, pero terminaron no fusionándolo, porque ningún humano puede verificar eso. Y otra conclusión fue que en realidad la velocidad de un bucle mueve el cuello de botella. Así que aparentemente estamos creando bucles para ayudarnos a avanzar en proyectos más rápido eliminando la necesidad de tomar algunas decisiones. Pero al final terminamos con qué tan rápido podemos ser para tomar ciertas decisiones para que un bucle proceda. Y este PR fue un buen ejemplo de eso.

Así que la conclusión general de ambos casos. Deberíamos tener suficiente repetición para los bucles, pero aún así, para algunos casos habrá juicio humano. Entonces, ¿qué deberíamos automatizar? Obviamente, una tarea debería ser recurrente, verificable y delimitada. Así que recurrente, obviamente no tiene sentido escribir bucles para algo como tareas únicas. Verificable, obviamente no queremos que los LLMs sean demasiado creativos. Como dijo el primer orador de Apollo, los modelos se volvieron buenos para mentir, por lo que la verificación es imprescindible ahora. Y delimitada, nuevamente el ejemplo con PR mostró que si estamos creando un bucle para algo, deberías poder hacerlo en pequeños pasos verificables. Y ahora creo que la mayor pregunta con la ingeniería de bucles es si es adecuada para crear aplicaciones completas. El ejemplo del lenguaje fue bueno, pero bastante sintético.

Y como última parte de esta presentación, quiero guiarte a través de la creación de un proyecto simple tú mismo usando ingeniería de bucles. Así que cada proyecto que se implementará usando ingeniería de bucles tiene cinco partes móviles. 4 archivos md y un archivo bash. Así que archivos md, obviamente deberíamos tener especificaciones, y la especificación siempre será una guía sobre lo que deberíamos obtener al final. Piensa en ello como un documento de diseño o documento de diseño de producto, que solo dice qué producto queremos obtener como resultado. Esto debería ser creado con la asistencia de un modelo, no se crea en un bucle. Así que deberías tener una idea, deberías pasar por LLM, deberías generar este archivo tú mismo. Luego hay un plan que se crea con la especificación. Básicamente, ir con LLM e intentar dividir en partes como qué debería implementarse primero, qué debería implementarse después y así sucesivamente. Eso sería como un plan inicial, el núcleo de tu bucle. Luego agent.md, solo debería dictar al agente cómo se ejecutará el proyecto, cómo debería construirse, cómo deberían ejecutarse las pruebas.

Hablaremos de eso un poco más tarde. Program.md, que será solo el seguimiento y ejecución del bucle. Sí, está bien. Sí, y bucle que ejecuta un bucle. Bien, desafortunadamente tenemos un minuto, así que solo pasaré por especificación, plan, agentes, progress.md, que solo rastrea el progreso. Loop.sh, que ejecuta un bucle, leyendo todos los archivos en forma cruda. Sí, nota importante sobre las pruebas. Cuando estamos haciendo ingeniería de bucles, deberíamos tener pruebas como de solo lectura porque los LLMs tienden a reescribir pruebas si se les permite hacerlo. Sí, así que eso debería ser de solo lectura. Si estás agregando pruebas al proyecto, deberían ser creadas por un paso anterior de un bucle, y cuando estás escalando el sistema... Lo siento, me quedé sin tiempo y me puse un poco nervioso.

Así que las pruebas son de solo lectura. Si necesitamos crear pruebas, las estamos creando por una iteración anterior del bucle. Luego, si estamos expandiendo nuestro proyecto y estamos pensando cómo podemos mejorar nuestro bucle, deberíamos comenzar agregando un agente verificador que básicamente toma el paso anterior, verifica que se ejecute bien, hace un veredicto si pasa o falla, y por qué si no. Y si el verificador falla, ahí tenemos una intervención humana para realmente tomar una decisión sobre cómo deberían proceder los bucles. Luego, si queremos agregar un sistema que cree nuevas tareas de backlog, podemos agregar otro agente que estará leyendo un objetivo completo de un proyecto como spec.md, y dentro de una especificación ver cómo podemos agregar más tareas. Y después de eso, si todavía... Si, por ejemplo, un proyecto involucra tareas complejas, no necesariamente tareas de larga duración, deberíamos pensar en agregar un cron o modificar planMd para tener más indicaciones a otros agentes sobre cómo deberían trabajar juntos en la base de código.

Entonces, ¿deberías usar bucles? Sí, cuando el trabajo es repetido, verificable, delimitado, y bloqueado principalmente por la atención del usuario. Y animo a todos a comenzar con bucles hoy. Solo necesitamos pensar en un trabajo que estamos re-prompting modelo constantemente y manualmente. Decisiones que siguen la misma regla y verificaciones donde simplemente decimos pasa o falla con solo mirarlas. Y, por supuesto, usar bucles solo es posible cuando tenemos una definición de hecho y buena. Si no sabemos qué estamos construyendo, si no sabemos cuál es la definición de hecho para lo que estamos construyendo, entonces el bucle no es aplicable a eso. Gracias.