Últimamente, mis tuits tratan casi exclusivamente sobre LLM. Estoy completamente enganchado. Si tengo tiempo libre, inmediatamente le pido algo o le hago preguntas a una LLM. Especialmente, hacer que un agente escriba código es como estar absorto en un juego social recién comenzado, aprovechando cada momento libre.
Es divertido usar agentes para escribir código. Estoy creando un RDBMS y, con una sensación de "¿Qué hago ahora?", "¿Añado una interfaz compatible con PostgreSQL?", "¿Eh? ¿Se puede hacer?", "¡Listo!", las implementaciones surgen una tras otra. Por supuesto, no es perfecto desde el principio, y a medida que escribo pruebas unitarias, se revelan muchos defectos, pero aun así, la velocidad de desarrollo que obtengo lo compensa con creces. Sobre todo, es asombroso, incluso aterrador, que casi 100,000 líneas de código aparezcan como si nada, con la misma carga que tener un compañero de chat adicional mientras hago otras cosas.
Como saben quienes han seguido mis comentarios en las redes sociales, durante muchos años no confié en la ingeniería de software. No es algo que un simple programador pueda aprender y aplicar, sino una disciplina para la ingeniería del comportamiento grupal al programar en equipo, y tenía serias dudas sobre si podría aplicarse en todos los entornos de programación, que son muy diversos. Sin embargo, al emplear múltiples agentes, me doy cuenta de que adopto un enfoque de ingeniería de software, como adivinar la existencia de errores sin leer el código o expandir gradualmente las áreas de confianza. No es que esté incorporando la densidad de errores o las curvas de convergencia, pero soy consciente de que, visto desde una perspectiva general, no estoy muy lejos de eso.
Incluso en situaciones en las que un aficionado podría gritarle a un agente: "¡¡Haz un software sin errores!!", la mayoría de los problemas se resuelven dando instrucciones persistentes con conocimientos de software, analizando los trabajos abandonados a través del diálogo y volviendo a dar instrucciones. Al repetir este tipo de trabajo, me siento aliviado de que la intuición que he cultivado hasta ahora no sea inútil, pero al mismo tiempo siento fuertemente que es solo cuestión de tiempo antes de que los agentes puedan resolver este tipo de cosas de forma autónoma. En este sentido, tengo una visión bastante pesimista sobre el futuro del trabajo de los programadores.
El código escrito por los agentes es honestamente como algo salido del valle inquietante, y no me inspira a querer mantenerlo, pero la premisa básica es que los ingenieros de software no quieren mantener el código. Simplemente lo mantenemos porque el código genera dinero en el trabajo, y leer el código es la última opción como método de mantenimiento para un programador profesional (creo que los programadores artesanos pueden jugar con el código que les gusta tanto como quieran, y yo también me inclino hacia ese lado en el fondo). La programación es el trabajo de construcción, mientras que la ingeniería de software es un esfuerzo continuo para garantizar que siga generando valor, y, sin temor a ser malinterpretado, es la culminación de décadas de esfuerzo para garantizar la calidad sin tener que leer código que no quieres leer.
x.com
Las reglas han cambiado mucho, por lo que algunas cosas se pueden aplicar y otras no. Escribiré los consejos que siento que son efectivos actualmente, hasta donde pueda recordar.
La ingeniería de contexto es teoría organizacional
Ya sea que la IA lo escriba o no, la verdad universal del software es que el código siempre seguirá creciendo enormemente. Creo que la longitud del contexto de LLM seguirá aumentando en el futuro, pero la velocidad de crecimiento del código de software siempre la superará. Incluso si LLM pudiera evitar el problema del contexto, el rango de contexto en el que puede enfocarse con éxito es finito, y el problema de encontrar una aguja en un pajar siempre estará presente. Por supuesto, ningún miembro del equipo puede meter todo el contenido del código de producción en su cabeza, por lo que la división de roles se realiza sin que nadie lo diga. Esta división de roles es ingeniería de contexto desde una perspectiva diferente. En resumen, lanzar toda la imagen del proyecto al contexto es demasiado grande para pensar en algo, por lo que la forma de dividir el trabajo de "Quiero agregar esta función a este módulo en este trabajo, y no necesito saber nada innecesario para completar esa tarea" es lo que se hace con los nuevos empleados en la mayoría de las profesiones, y no se limita a los agentes de IA. Creo que entiendes al usar agentes de IA, pero son patológicamente rápidos para convertir 0 en 1. Han sido criados en un conjunto de puntos de referencia como ese, y resolver los molestos errores que los humanos tienen que resolver es solo una ventaja adicional. La razón por la que es rápido para convertir 0 en 1 es porque hay muy poco código existente que deben tener en cuenta para realizar esa tarea, por lo que hay muy poca preocupación por el contacto. Los programadores con poco contexto también quieren crear microservicios, porque los microservicios reducen la cantidad de contexto que deben tener en cuenta. Los microservicios son un ejemplo extremo, pero dividir internamente el software es limitar el alcance que otros deben tener en cuenta, y la "separación de preocupaciones" es también la separación de la información que se debe poner en la cabeza del agente. Todavía no se ha llegado a un consenso completo sobre qué es la "arquitectura de software", pero mi sensación es que es la separación del contexto que se debe poner en el cerebro de las personas que trabajan en él. Incluso si se introduce un objeto de valor por orden de un superior, si el contexto que los programadores de nivel inferior deben meter en sus cabezas no cambia, no se puede decir que el arquitecto haya hecho un buen trabajo. Creo que dividir las tareas de una manera que sea fácil para los agentes trabajar es bastante similar a dividir internamente el software de una manera que sea fácil para los humanos trabajar. Mi intuición actual es que la capa que debemos considerar es más grande de lo que imaginamos, por lo que utilizamos modelos de gama alta que son grandes e inteligentes, pero tal vez se puedan utilizar modelos más baratos si los descargamos correctamente a agentes de investigación, etc.
LLM es caro
Todos dicen que los modelos de gama alta producen un código claramente mejor, pero los modelos de gama alta cuestan entre 10 y 20 dólares por 1 millón de tokens. El trabajo que se realiza con ese contexto tomará varias horas a un programador, así que creo que vale la pena, pero sería mejor si pudiéramos confiar tareas a modelos más baratos. Es posible que la competencia de precios avance hasta el punto en que los modelos actuales de gama alta sean extremadamente baratos y se utilicen como agua, pero para entonces habrá modelos de gama alta que se promocionarán como capaces de resolver problemas difíciles que no se pueden resolver en otros lugares. Como resultado, creo que en el futuro continuará el estado en el que las tareas que no son tan difíciles al escribir programas se escribirán con modelos más baratos. Además, el LLM local, que es el extremo de los modelos baratos, es atractivo como destino de descarga, y creo que un grupo de agentes locales que subcontratan tareas que han sido definidas utilizando modelos de gama alta es algo realista. No sé hasta qué punto los LLM locales pueden realizar tareas complejas de codificación en este momento, pero la historia de escribir con los baratos y escalar a un modelo inteligente con el conocimiento que adquirimos cuando no podemos depurar y abandonar el proyecto probablemente se convertirá en algo común. Los locales y los de gama alta trabajarán juntos en forma de llamadas a subagentes, y el estado final de una empresa de desarrollo de software podría ser un equipo de unas pocas personas que ejecutan una gran cantidad de LLM locales. Es probable que la serie Ryzen AI Max de AMD suba de precio en el futuro, porque su producto competidor es un programador humano de carne y hueso.
El agente de IA es inestable
No sé exactamente qué implementación es mala, así que no haré ninguna declaración definitiva, pero las paradas inexplicables, los errores intermitentes y las cosas que no entiendo ocurren constantemente. Incluso es común que la velocidad de respuesta del editor sea de minutos, aunque el kernel no se bloquee. Además, la calidad de la reescritura es muy variable, y los números de línea del destino de la reescritura son un desastre y a menudo destruyen el código de manera terrible. Se dan cuenta de que está roto y van a arreglarlo de forma autónoma, así que no es tan fatal, pero el truco para usar cosas inestables como son es el bucle de Ralh y el seguimiento del progreso que lo acompaña.
x.com
En pocas palabras, un bucle de Ralh significa poner el lanzamiento del agente en un bucle. Sin embargo, indíquele que escriba el progreso actual en algún lugar del mensaje y que lea el progreso al comienzo del bucle. De esta manera, el agente recibirá el "progreso anterior" como contexto y luego realizará la "tarea actual". Lo bueno de esto es que se ejecuta incluso si el agente se detiene en el medio o muere por falta de memoria. Se convierte en un problema si la nota de progreso se vuelve demasiado grande, pero se puede hacer algo al respecto escribiendo un mensaje para resumirla y comprimirla según sea necesario. Sin embargo, si se trata de un solo bucle, todas las tareas se realizan con un solo modelo caro, por lo que la fase de diseño y división de tareas se deja a un modelo caro, y las tareas que parecen fáciles se dejan a un agente barato, etc. El contenido del bucle en sí puede volverse tan complejo como quieras agregando cosas como esta, así que programar si llamar o no a un agente de codificación es una metaprogramación excelente. Todavía no he llegado a esta etapa... Será natural que el bucle en sí sea mejorado por LLM en el futuro.
bsky.app
Es interesante que antirez haya dado la instrucción "5. Use this file to track progresses" en el mensaje que emitió para acelerar el código. Dado que la tarea continúa haciendo referencia al mismo texto incluso si se detiene en el medio, es muy razonable que el progreso anterior esté incluido en el texto.
5 autorrevisiones
El 90% del código producido por los agentes de codificación funciona bien, pero cuando se trata de una cantidad considerable, se encuentran mejoras cada vez que se autorrevisa. Quiero que escriban un código perfecto que no necesite revisión desde el principio, pero dado que eso es difícil incluso para los humanos, debe haber defectos que LLM no puede encontrar a menos que lo revise en un contexto diferente. A los humanos a veces les lleva tiempo reflexionar sobre el código que han escrito, pero los ingenieros extranjeros han escrito que el agente de codificación llega a la convergencia en 5 veces en muchos casos.
Por supuesto, es muy costoso, pero aun así es mucho más barato que los humanos, y si se incluye como mecanismo, no hay lugar para que los humanos intervengan. No sé si el número 5 tiene algún significado específico, y creo que será un número diferente en el futuro, pero incluso con la experiencia, hay muchas mejoras que se pueden encontrar incluso si el código escrito por el agente se revisa varias veces. La especialidad de LLM es la reflexión. (También se pueden ver comentarios de revisión que se hacen como un defecto solo para establecer un diálogo, por lo que puede ser necesaria una revisión de los comentarios de revisión en sí). Parece que continuará durante un tiempo que los humanos revisen el código escrito por el agente de codificación si se va a utilizar en producción, pero como está, parece que se convertirá en algo común que la propia máquina lo revise N veces antes de que lo revisen los humanos. Parece que el lado de la creación y el lado de la acusación se mejoran mutuamente. Revisar con los agentes de varias empresas también puede aportar nuevas perspectivas.
Me he extendido demasiado, así que publicaré esto aquí por ahora.