Cómo programar con agentes

• Este texto es la segunda parte sobre cómo adaptar la experiencia previa de programación al mundo de las computadoras conversacionales (LLM, agentes)
• En la primera parte, "Cómo programar con LLM", se explicó cómo integrar los LLM en herramientas existentes para usarlos como autocompletado o como reemplazo de búsqueda
• Esta vez se comparten experiencias e ideas prácticas sobre la programación basada en agentes, que es más difícil pero también más gratificante

Definición y realidad de los agentes

• Tiene sentido definir qué significa el término "agente" en el contexto de los LLM (modelos de lenguaje grandes)
• Aunque se ha usado durante mucho tiempo como una palabra de moda en la industria de la IA, apenas recientemente se ha consolidado como una estructura realmente útil
• En ese proceso se le ha cargado mucha retórica de marketing y cierto aire de misticismo

• Desde la perspectiva de un ingeniero, ahora se puede definir de forma clara y simple: un agente son 9 líneas de código, es decir, un bucle for que incluye llamadas a un LLM
• Dentro de ese bucle, el LLM ejecuta instrucciones, puede verificar directamente los resultados y repetir el proceso sin intervención humana
• Puede sonar simple, pero en la práctica esta estructura mejora drásticamente la capacidad de programación frente al uso de un LLM puro

La diferencia entre programar en pizarrón y con agentes

• Supongamos que estás frente a un pizarrón escribiendo con marcador una función en C para validar una cadena UTF-8
  • (Es una situación de entrevista que el autor realmente vivió y también una tarea común en entrevistas)
  • El éxito o fracaso de esa tarea depende de tu experiencia como programador y de tu capacidad para disimular las limitaciones de no poder consultar fuentes externas
  • Hay que recordar las reglas de codificación UTF-8 y tener cuidado de no confundir la sintaxis de C con la de otros lenguajes de la familia C (orden nombre-tipo, tipo-nombre, etc.)
  • En el trabajo cotidiano, en cambio, puedes validar el código y encontrar errores con retroalimentación del compilador, búsqueda en documentación, printfs y muchos otros métodos
• Pedirle a un LLM que escriba código sin un agente se parece a programar en un pizarrón sin ayuda externa
  • Es un trabajo de sacar recuerdos vagos, intentar cuadrar la sintaxis de manera ineficiente y evitar errores como imaginar interfaces equivocadas
  • El logro técnico de que un LLM genere programas completamente nuevos es impresionante, pero un pizarrón virtual conectado a GPUs no aumenta tanto la productividad real de programación
• Pero, ¿qué pasa si al LLM se le da algo más que un pizarrón virtual?
  • ¿Y si puede invocar el compilador, revisar los errores de compilación y corregirse por sí mismo?
  • ¿Y si puede leer archivos existentes con grep y cat, parchear varios archivos —incluidas pruebas unitarias— y repetir las pruebas una y otra vez?
• Eso es exactamente un agente: un LLM guiado por retroalimentación.

Agente = LLM que opera en un entorno con feedback

• Un LLM que, como una persona, funciona bien en un entorno con retroalimentación puede demostrar capacidad real de programación con solo unas cuantas herramientas familiares
  • bash(cmd): ejecutar comandos de terminal (find, cat, grep, etc.)
  • patch(hunks): parchear archivos, aplicar cambios de código
  • todo(tasks): administrar lista de tareas
  • web_nav(url), web_eval(script), web_logs(), web_screenshot(): navegación web, evaluación, logs, capturas de pantalla, etc.
  • keyword_search(keywords): búsqueda por palabras clave
  • codereview(): revisión de código
• Con la herramienta bash, puede explorar eficientemente una base de código e incluso automatizar control de versiones con git add/commit
• A diferencia de un LLM que solo genera código sin estas herramientas, un agente tiene ventajas claras
  • Mayor precisión en el uso de APIs (busca documentación y la incorpora directamente al contexto)
  • Menos errores de sintaxis e interfaces gracias al feedback del compilador
  • Mejor manejo de dependencias y versiones (puede identificar características de versiones específicas)
  • Detección de errores mediante fallas en pruebas y mayor hábito de escribir código de prueba
  • Procesamiento de bases de código más allá de la ventana de contexto (lee selectivamente solo lo necesario)
  • Experimentación directa con resultados de ejecución: ejecutar código, recibir feedback de capturas de pantalla del navegador, ajustar CSS automáticamente, rastrear errores con logs del servidor y agregar pruebas
• También hay desventajas
  • Una solicitud de una sola frase puede generar decenas de miles de tokens intermedios (llamadas a herramientas, búsquedas web, repeticiones de pruebas, etc.), y el trabajo puede tardar varios minutos o más
  • También hay costo por llamadas a APIs, aunque se espera que eso vaya perdiendo peso con la mejora del hardware
• En última instancia, el trabajo intermedio lo hacen CPU/GPU, ahorrando tiempo al desarrollador y permitiéndole terminar más programas de los que quería escribir
• En la práctica, es fácil introducir agentes en un proyecto y probarlos con tareas pequeñas para revisar los resultados

Ejemplo: desarrollo de autenticación para Github App

• Este es un caso real en el que se usó un agente para implementar el flujo de autenticación de Github App en sketch.dev
  • Con solo 3 o 4 rondas de feedback se completó rápidamente todo el flujo de autenticación
  • Cuando aparecía un error o una condición nueva, bastaba explicarlo con una frase y el agente mejoraba de inmediato el código y el comportamiento
  • Ayudó mucho a mantener el impulso de productividad al reducir al mínimo el "trabajo tedioso" de la vida real: integraciones repetitivas de API, sistema de build, gestión de paquetes, configuración de librerías, etc.
• En los requisitos iniciales se incluyó “usar solo la autenticación global de la app sin guardar tokens por usuario”, y el agente lo implementó así
  • Pero como resultado apareció una vulnerabilidad de seguridad grave (cualquiera podía ver todos los repositorios)
  • Al darle feedback con una sola frase explicando el problema, introdujo de inmediato una verificación de permisos por usuario y generó un commit corregido
• Después surgió un problema de rendimiento
  • Con una estructura como la siguiente, se hacían llamadas API para todas las combinaciones usuario-repositorio, lo que causaba problemas de escalabilidad

    for install := range allAppInstallations {  
    	for r := range install.Repositories() {  
    		if r.IsCollaborator(user) {  
    			// add to available repositories  
    		}  
    	}  
    }  
    

  • Entonces se entendió que la causa de fondo era el requisito de “no guardar tokens por usuario”
  • Cuando se cambió el requisito (permitir guardar tokens por usuario), el agente rediseñó la solución con un patrón de llamadas API más eficiente
• De hecho, el número de palabras usadas para explicar este proceso en el artículo fue mayor que el total de palabras ingresadas en Sketch para obtener el código de autenticación
• En pocas palabras, hoy los agentes todavía no están al nivel de reemplazar a un desarrollador, pero sí ayudan a hacer en un solo día trabajos repetitivos que tradicionalmente tomarían varios días
• El grado de automatización llega a permitir que el desarrollador siga avanzando “mientras limpia el cuarto de su hijo”

Ejemplo: aplicar reglas SQL basadas en JSON

• Uno de los trabajos que el agente hacía con frecuencia era aplicar un estilo peculiar de SQL aprendido en Tailscale
  • En todas las tablas, solo hay una columna real (datos JSON), y el resto se maneja como generated columns derivadas de ese JSON
  • Estructura de tabla de ejemplo:

    CREATE TABLE IF NOT EXISTS Cookie (  
      Cookie   TEXT    NOT NULL AS (Data->>'cookie')  STORED UNIQUE, -- PK  
      UserID   INTEGER NOT NULL AS (Data->>'user_id') STORED REFERENCES User (UserID),  
      Created  INTEGER NOT NULL AS (unixepoch(Data->>'created')) STORED,  
      LastUsed INTEGER AS (unixepoch(Data->>'last_used')) CHECK (LastUsed>0),  
      Data     JSONB   NOT NULL  
    );  
    

  • Este enfoque cumple una especie de papel de poor man’s ORM, facilita ampliar el esquema y hace que las restricciones SQL ayuden a validar la calidad de los datos JSON
  • La desventaja es que aumenta la cantidad de datos almacenados por fila y que todos los INSERT/UPDATE deben hacerse a nivel de JSON
• Sin embargo, el agente no siempre seguía este estilo de forma consistente
  • Al crear tablas nuevas generalmente lo hacía bien, pero cuando había excepciones se confundía o cambiaba el estilo arbitrariamente
• Solución simple: agregar una explicación de 3 oraciones al inicio del archivo de esquema SQL
  • Se añadió una frase clave: “cada tabla tiene una sola columna JSON real llamada Data y todas las demás columnas derivan de ahí”
  • En las tablas que no seguían esta regla, se indicaba explícitamente en comentarios que eran excepciones
  • Después de eso, el comportamiento del agente mejoró de forma notable
• Lo interesante es que este tipo de explicación y comentarios, que los ingenieros humanos suelen ignorar o considerar de poca utilidad,
  • sí son aprovechados activamente por agentes basados en LLM al escribir código
  • con solo documentar bien, la calidad de la generación de código mejora de manera evidente

El modelo de código como “activo” y “deuda”

• Una crítica común a las herramientas de generación de código basadas en LLM es que generar código en sí representa solo una fracción mínima del costo total del software
  • En realidad, la mayor parte del tiempo se va en manejar dependencias del código existente, acoplamientos e interfaces complejas
  • En productos grandes, antiguos y con muchos usuarios, el costo de mantenimiento es abrumador
  • En ese entorno, pedirle a un LLM “escribe bubble sort en Fortran” puede sentirse como un juguete o una molestia inútil
  • A veces se compara con los conceptos financieros de “activo/deuda”, aunque esa analogía tampoco encaja del todo
• Sin embargo, no toda la ingeniería de software consiste en proyectos grandes y de largo plazo
  • La mayoría de los programas tienen pocos usuarios o una vida corta
  • No se debe extrapolar la experiencia de mantenimiento a gran escala como si definiera toda la industria
• El valor de los agentes no se limita a generar código
  • Combinan varias herramientas con LLM para automatizar el cambio mismo: leer código, editar archivos, borrar o modificar código
  • Así como agregan código, también eliminan código y refactorizan con naturalidad
• Al final, el objetivo del ingeniero es el cambio
  • Aunque el proceso exige trabajo adicional para que quien conduce entienda el cambio, los agentes ya muestran capacidad para producir cambios graduales incluso en proyectos de tamaño mediano
  • Aunque todavía no sea suficiente, están avanzando rápido en la dirección correcta
• También existe la opinión de que los lenguajes complejos y los sistemas de build actúan como barrera de entrada para un proyecto
  • Algunos sostienen que, si herramientas que facilitan escribir código (LMM, type safety, garbage collection, gestión de paquetes, agentes, etc.) reducen esa barrera, podría bajar la calidad
  • Si el objetivo es frenar el ritmo del cambio o aumentar el control, entonces herramientas de automatización como los agentes no encajan

¿Por qué agentes ahora?

• A diferencia de principios complejos de IA como los transformers, poner un ciclo de retroalimentación en un LLM es un enfoque intuitivamente claro
  • Para quien piensa en herramientas para desarrolladores, parece una dirección de evolución natural
  • De hecho, hace un año la primera versión de sketch.dev apenas conectaba herramientas de Go a un LLM, pero comparada con los agentes actuales hay una gran diferencia en utilidad práctica
  • Incluso en ML, el aprendizaje por refuerzo (aprendizaje basado en feedback) ha sido un principio básico durante más de 50 años
• La aparición real de los agentes está directamente ligada a la evolución de los LLM
  • En 2023, los LLM tenían capacidades pobres de uso de herramientas, así que su papel como agentes era limitado
  • En 2025, los LLM ya están optimizados para llamadas a herramientas y trabajo iterativo, lo que hace posible el uso práctico de agentes
  • Los modelos frontier (comerciales de última generación) llevan una gran ventaja sobre los modelos abiertos en capacidad de uso de herramientas
  • Se espera que en los próximos 6 meses los modelos abiertos los alcancen
  • La capacidad de hacer llamadas repetitivas y útiles a herramientas es el mayor cambio de los LLM modernos

Hacia dónde va esto: contenedores y ejecución en paralelo

• El campo de los agentes LLM aún está en una etapa temprana y de cambios rápidos que la mayoría de los ingenieros todavía no ha adoptado de forma real
• Por ahora, los agentes se usan sobre todo para funcionar dentro del IDE o en repositorios locales
  • Se puede empezar fácilmente instalando un fork de VSCode o una herramienta de línea de comandos
  • Pero hay dos limitaciones importantes
    • Primero, falta de protecciones: existe riesgo de exponer información sensible como credenciales de producción guardadas en la computadora real
      • Si el agente ejecuta comandos no deseados, como scripts de despliegue, puede provocar incidentes de seguridad graves
      • Aunque se pide confirmación manual para cada comando, sigue existiendo la posibilidad de exponer datos sensibles por error
    • Segundo, limitaciones para paralelismo y automatización: como cada desarrollador debe ejecutar solo un agente a la vez en su propio entorno,
      • si cada ejecución tarda varios minutos, resulta difícil avanzar varias tareas al mismo tiempo y se vuelve ineficiente
• En sketch.dev están intentando resolver esto con un entorno de contenedores
  • Se crea un contenedor de desarrollo aislado para cada tarea, se clona el código fuente y solo se extraen al exterior elementos como commits de git
  • Eso permite ejecutar varios agentes a la vez, y otros proyectos también están explorando esta misma idea
• Caso real: mientras se trabajaba en la autenticación de Github, se mejoró al mismo tiempo la UI de un formulario en una sesión separada de agente
  • Sin registrar nada en un issue tracker aparte, se dio feedback de diseño con una captura de pantalla y una sola línea de solicitud breve
  • La experiencia fue la de obtener resultados razonables con apenas 30 segundos de inversión
• Resultado de experimentos de UX durante los últimos 6 meses:
  • Se llegó a la conclusión de que los contenedores (entornos de ejecución aislados) son lo más práctico para el desarrollo basado en agentes

¿En qué se convierte el IDE?

• En un entorno de desarrollo basado en agentes, qué papel tendrá el IDE (entorno de desarrollo integrado) sigue siendo una pregunta abierta
  • El flujo real de trabajo puede llegar a ser: escribir instrucciones para el agente, ejecutarlo en un contenedor, revisar los cambios como diff y hacer push en una rama o PR
• En la práctica, la mayoría de los commits generados por el agente necesitan cierto nivel de pulido humano
  • Al principio, casi todos los commits requieren corrección manual, pero conforme mejora la habilidad para redactar prompts, la cantidad de correcciones va bajando
  • Las correcciones pueden ir desde editar comentarios o cambiar nombres de variables hasta refactors más complejos
  • La cuestión clave es cómo hacer este tipo de ajustes de forma eficiente dentro del entorno de contenedores
• Flujo de trabajo que se está probando en sketch.dev y otros
  • Interfaz que permite editar directamente la vista de diff
    • Si editas directamente el código en el lado derecho de la pantalla de diff de Sketch, el cambio se refleja en ese commit y se hace push de inmediato
    • Esto es muy eficiente para cambios pequeños de una sola línea
  • Acceso SSH al contenedor
    • Puedes entrar directamente con shell o manipular el código desde una terminal web
    • También se puede abrir con una URL vscode:// para trabajar en un IDE tradicional
  • Comentarios estilo code review directamente sobre el diff para enviar feedback al agente
    • Aprovechando la experiencia de revisión de código, se pueden comunicar explicaciones o requisitos con una entrada mínima
• Balance general
  • El entorno de contenedores integra generación, modificación, validación y revisión de código,
    haciendo posible un verdadero desarrollo basado en agentes más allá de solo escribir código
  • Antes no quería desarrollar dentro de contenedores,
    pero la experiencia de limpiar y ajustar en un contenedor los diffs generados por un agente ha resultado muy interesante y productiva

Cierre

• El proceso de aprender y experimentar con tecnología basada en LLM ha sido una lección de humildad
  • Antes también resultaba emocionante cuando cambiaba la naturaleza de la programación con cosas como multicore, SSDs o expansión de redes,
    pero los LLM, y especialmente los agentes, están rehaciendo por completo el “proceso mismo” de programar
  • A diferencia de cambios que influían en algoritmos, lenguajes o selección de librerías,
    los agentes obligan a reexaminar de raíz todos los supuestos sobre la forma de trabajar
  • A veces el cambio es tan grande que uno llega a pensar: “quizá sería mejor volver a aprender desde cero, como si no supiera nada de programación”
  • Y este cambio sigue ocurriendo ahora mismo
• La manera en que lo estamos viviendo hoy ya es totalmente distinta de hace 6 meses, y ni siquiera se ha estabilizado todavía
  • Parece probable que pronto cambien mucho también los estándares de cultura de desarrollo, como la colaboración en equipo y el review
  • Por ejemplo, el code review que se hacía de forma meramente ritual ya no está resolviendo problemas reales
    • Es momento de reinventar el proceso mismo de revisión de código
  • Lo mismo pasa con el IDE: más que seguir defendiendo su integración tradicional, llegó la hora de rehacerlo por completo
  • La industria ya reconoce este cambio, pero el enfoque centrado en agentes apenas está comenzando
  • Se anticipan cambios aún mayores,
    y la curiosidad y la humildad son probablemente la mejor forma de atravesarlos bien
  • Incluso ahora quizá sea mejor alejarse de los foros de internet sobre tecnología,
    y dejar este tipo de discusiones y resúmenes también en manos de agentes

[GN⁺]

Opinión de Hacker News

• Como yo programo principalmente solo para mis propias herramientas, no termino de ver el gran mérito de que otra persona o alguna otra cosa escriba el código por mí y luego yo tenga que leerlo, entenderlo y corregirlo; claro, pedirle a un LLM que encuentre en la documentación del API la parte que necesito sí es bastante útil y ahorra tiempo, así que independientemente de si su rendimiento futuro mejora o no, simplemente no me gusta mucho leer código ajeno

  • Para mí sí hay casos donde el LLM ayuda; por ejemplo, en código muy formalizado hace que ya no hagan falta macros o generadores de código. Eso sí, es lento y no puede actualizar todo de una como una macro, pero para estructuras de código repetitivas con pequeñas variaciones, el LLM puede ser más útil que una macro. También, cuando uso un API que conozco pero cuyo código no me sé de memoria, puedo avanzar sin tener que buscar en Google ni revisar documentación. Como uso lenguajes tipados, si el LLM dice tonterías el type checker o los tests lo filtran, así que no me preocupa demasiado. Y cuando hay que hacer cambios en más de 10 archivos, que arme un plan de cambios en Markdown sí ahorra muchísimo tiempo. Por último, cuando estoy cansado es fácil dejar pasar estilo o reglas de naming, pero el LLM mantiene bastante bien el estilo existente del proyecto, y eso me gusta
  • Últimamente me gusta cada vez más trabajar así: primero planeo el diseño general del código, luego le explico al LLM los pasos concretos, y mientras yo leo, entiendo, corrijo el código y planeo la siguiente etapa, hago que el LLM vaya adelantando el código de la siguiente sección. En otras palabras, el LLM y yo trabajamos en paralelo. Es como un chef de restaurante que, apenas entra un pedido, piensa de inmediato en todas las etapas del plato y, mientras se cocina el filete, no se queda esperando sino que avanza con otras preparaciones. El LLM se parece más a una herramienta de cocina como un horno o un procesador de alimentos. Por ejemplo, puedes rallar queso a mano, pero si lo pones en el procesador ahorras unos minutos. Los chefs profesionales suben su eficiencia usando distintas herramientas y haciendo multitarea; creo que la programación también podría pasar de ser un trabajo paso a paso, línea por línea, a una estructura más multitarea
  • Respecto a la duda de qué ventaja tiene delegar la responsabilidad de escribir mi código a otra cosa para luego volver a leerlo, entenderlo y arreglarlo yo mismo, uso la palabra “fricción”. A mucha gente le cuesta empezar algo nuevo, como un bloqueo de escritor, y si ya recibe una solución hecha por alguien más, la barrera de entrada baja muchísimo porque solo tiene que adaptarla a su manera y modularizarla. Entre mis colegas y yo, muchos sentimos una carga importante al configurar el toolchain y hacer el bootstrap de un proyecto desde cero. Si el LLM tiene suficiente contexto y recursos, también puede escanear rápido todo el codebase y detectar cosas como “ya hay dos mecanismos de auditoría en este código, saquemos la parte común”; incluso puede señalar cosas que yo mismo pasaba por alto
  • En un codebase con el que trabajo hay muchas tareas donde hay que ir tocando varios archivos con cambios pequeños y repetitivos. Ese tipo de trabajo no requiere creatividad ni es desafiante; es simplemente abrir muchos archivos y editar. Antes me tomaba 3 o 4 horas, pero si le explico la tarea a un agente de AI, resuelve el 99% por su cuenta y tarda solo 3 o 4 minutos
  • Hay gente que sin herramientas no puede hacer nada. Ese tipo de personas se vuelve early adopter y power user, y luego difunde nuevos hallazgos. El valor de GitHub fue darle al desarrollador promedio un entorno donde puede parecer productivo con PR, reviews, cuadritos verdes y listas de tareas. A los managers también les gusta el LLM porque permite que un desarrollador promedio parezca productivo ejecutando herramientas y agentes poco importantes

• Estoy completamente de acuerdo con la parte donde el autor dice que el code review es deficiente y casi nunca funciona bien. En una era donde los agentes escriben código, el cuello de botella real no es escribir sino leer código. Si la gente revisa por encima o usa el review solo para mostrar gustos personales, los agentes pueden meter fácilmente problemas graves de seguridad o de rendimiento. Sinceramente, el problema real muchas veces ni siquiera se ve leyendo el código: hace falta depurarlo a mano o validar supuestos

  • No está claro cómo el código de agentes/AI resuelve exactamente el problema de las “reviews deficientes”. A la gente no le gusta hacer code review y le parece aburrido. Me preocupa que terminemos entregándole a la AI la parte divertida, “escribir código”, para quedarnos nosotros con una revisión y validación interminables
  • Lo que más falta hoy en el mercado es cómo leer, revisar bien y entender de forma eficiente el código, los diff y el codebase completo que generan los LLM. Si dentro del proyecto quedan muy pocas personas, me preocupa si realmente leen el código o si simplemente lo dejan pasar
  • La clave de los agentes es que, si tienes suficiente cobertura de tests, la AI puede escribir el código y además recibir feedback de seguridad y rendimiento. Y esa misma AI también ayuda a escribir tests

• Por fin siento que vi un análisis realista sobre los LLM. El término “agente” me desespera un poco porque en la práctica no es mucho más que ponerle nombre a un for loop que llama recursivamente a un LLM, pero como el talento para nombrar cosas en esta industria tampoco es muy alto, lo acepto

  • Mi definición de “agente” no coincide del todo con la del autor. En realidad es una estructura donde el LLM entra en un loop y va llamando herramientas y recursos de forma iterativa. Es una diferencia sutil, pero importa porque define dónde está el actor principal
  • Me gustó la frase “un agente es una herramienta dentro de un loop”. Creo recordar que Simon lo dijo así
  • Tengo una pequeña diferencia con la definición de agente del OP. No se trata solo de que el LLM esté en un loop, sino de que sus acciones estén limitadas o guiadas por otros componentes lógicos. Algunos son deterministas y otros están basados en ML, incluyendo LMM. En otras palabras, se puede extraer utilidad adicional cuando, dentro de un sistema diseñado, se obliga al LLM a planear de cierta manera o se disparan tests, builds y ejecuciones después de editar código. Decir que “un agente se mueve por sí solo a partir de una entrada” no es totalmente falso, pero lo más esencial es la intención de que varios componentes supervisen y orienten constantemente el comportamiento del LLM
  • El nombre “Agent” me parece aceptable porque la gente lo entiende de inmediato, aunque a veces pienso si algo como LoopGPT podría haber sido una alternativa

• Sobre la parte de “todos estamos de acuerdo en que los contenedores son útiles y necesarios en programación”, esto explica por qué Solomon Hykes, creador de Docker, abrió recientemente como open source el proyecto Container Use: para que los agentes puedan ejecutarse en paralelo de forma segura. Algunas plataformas, como Sketch, ya traen entornos de desarrollo locales aislados, pero otros agentes de programación no; además recomiendo este video de YouTube

• El loop agéntico, el cerebro dentro de la máquina, me parece en esencia un reemplazo del motor de reglas. Todavía tiene desventajas propias, pero creo que varias personas importantes ya dieron en el clavo. “Conectas herramientas al agente, lo prompeas a partir de la solicitud del usuario, lo pones a correr en loop, y hasta el prompt mismo cambia dinámicamente según la situación”. Sin necesidad de imitar de forma deliberada la interacción o el razonamiento humano, eso ya resulta bastante útil para orquestación, múltiples etapas y automatización o reemplazo de tareas ambiguas. Antes había que programar la ambigüedad manualmente, y ahora quizá eso desaparezca. En producción todavía preocupa ejecutarlo sin dry run, pero supongo que las herramientas y servicios van a evolucionar. Si más de 100 servicios similares se conectan con una interfaz consistente al mundo exterior (p. ej., SMS, correo, clima, redes sociales, etc.), creo que saldrá un asistente muchísimo más potente, o incluso algo más que eso

  • Hay un toy project interesante donde conectan agentes a varios servicios como calendario y clima para crear una interfaz tipo juego: enlace
  • Si la abstracción se unifica en todas las herramientas utilizadas, podría superar por mucho a los asistentes actuales, pero también obligaría a aceptar una cantidad enorme de fallas y errores posibles. Temas como reliability engineering, aseguramiento de calidad, gestión de permisos, seguridad y privacidad van a volverse cada vez más importantes. Incluso sospecho que una razón por la que Apple no lanza un asistente de voz moderno que supere las limitaciones de Siri podría ser justamente esa gestión del riesgo

• Leer código siempre fue tan importante como escribirlo, pero ahora lo es cada vez más. Es mi pesadilla. Escribir código a veces es divertido; leerlo siempre es trabajo

  • Aun así, puede que siga existiendo —o incluso aumente— la “diversión de arreglar cosas”

• Me pregunto cuánta gente que usa agentes realmente disfruta “programar”, es decir, pensar cómo resolver problemas y la diversión misma de expresarlo en código. Cuando veo mucho trabajo actual con agentes, siento que ese proceso desaparece y se reemplaza por explicar requisitos en lenguaje natural y luego solo esperar que el LLM no meta bugs

  • A mí me gusta programar en sí, y cuando el LLM me genera de una sola vez un parser que yo habría disfrutado hacer, hasta me deja una sensación rara. Aun así, me permite enfocarme en objetivos más grandes en vez de consumir tiempo escribiendo el parser. Me impresionó lo útil que es definir solo los types o las firmas de funciones que quiero y dejar que el LLM complete los detalles de implementación para poder pasar de inmediato al siguiente paso. Antes, incluso cambios globales del tipo “estaría bien arreglarlo, pero qué flojera” eran una gran carga; ahora el LLM me ayuda con pulido del código, generación de tests, sincronización del README e ideas de refactor, así que en realidad aumentaron tanto la ambición como el nivel de acabado de mis proyectos. Si ajustas bien tu mentalidad, para los builders que disfrutan crear software esto puede ser el paraíso
  • En cambio, no tengo ganas de implementar yo mismo problemas que ya se resolvieron miles de veces. Para eso uso un diccionario; no me pongo a rehacer una hash table. Si le pidiera “hazme el compilador de este lenguaje” o “resuélvelo con DFS” y me devolviera un resultado perfecto, no creo que eso me quitara la diversión de programar. Es cierto que describir procesos computacionales en lenguaje natural tiene límites: en niveles complejos puede volverse impreciso o producir contradicciones. Pero en cualquier caso, nadie recomienda usar un LLM sin pensar, y al final la responsabilidad por el resultado sigue siendo mía
  • Como argumento de que el lenguaje natural no es adecuado para programar, cito EWD667. En la práctica, los LLM sí sirven para preguntas y respuestas estilo Stack Overflow, pero si en el futuro disminuyen los datos de SO, incluso eso podría tener límites
  • Yo no estoy de acuerdo. Gran parte de lo que hace el LLM es implementación repetitiva y aburrida. Yo sigo quedándome con la parte divertida: arquitectura del proyecto, diseño directo de las secciones creativas o difíciles que al LLM también le cuestan. Tal vez dentro de un año la situación sea otra, pero por ahora estoy satisfecho porque me permite concentrarme solo en la parte que de verdad requiere pensar
  • Soy el autor del post. Me gusta programar, y también me gustan los agentes

• Hay algunas áreas donde me gusta usar AI al programar (¡de verdad lo escribí yo!):

  • CSS: siempre odié trabajar con CSS en cualquier sitio web, pero la AI recuerda todos esos trucos complejos de CSS y me ahorra tiempo; por ejemplo, centrar un div específico dentro de un WordPress complicado se vuelve algo rápido después de unos pocos intentos
  • Unit tests: cuando los datos de código integrados de la AI no están desactualizados, generar tests también puede ser una experiencia divertida
  • Resúmenes de commits: para un primer borrador, sirve bastante bien
  • También resuelve rápido tareas muy pequeñas, de nivel de primer año
  • Curiosamente, en mi caso he sentido que la AI no escribe CSS tan bien y por eso a veces me pareció inútil. Pero sí conecto mucho con la idea de que haga por uno las tareas que no le gustan; en mi caso, por ejemplo, escribir descripciones de tickets, que la AI maneja mucho mejor que yo
  • Perdón si entendí mal, pero si no estás muy al día con las tendencias recientes de CSS, hoy CSS es bastante menos complejo y más fácil de mantener que antes, así que también recomiendo invertir unas horas en ponerse al día. Aun así, yo también uso bastante la AI para estilos

• La parte sobre “activo” y “pasivo” me pareció interesante, pero no estoy de acuerdo. Muchos programas empiezan para unos pocos usuarios y luego terminan convirtiéndose en proyectos grandes. He visto demasiadas veces código científico escrito rápidamente para un solo uso que, sin querer, acaba creciendo durante años y extendiéndose muchísimo. Por eso yo escribo mi código pensando en que dure más tiempo y abarque más, incluso por consideración hacia mí mismo y hacia otras personas. Si alguna vez viste cómo un side project personal de un colega fue ascendido por un manager a proyecto del equipo, seguro entiendes este problema

  • Aun así, queda la duda de “¿cuál es la alternativa?”. La gente es mala prediciendo qué va a terminar siendo ampliamente adoptado. De hecho, es más común que un proyecto cuidadosamente trabajado no lo use nadie, y que uno improvisado pero hecho rápido sea el que tenga éxito; la presión evolutiva del mundo real empuja hacia eso. Aquí encaja el clásico texto “worse is better” (enlace)

• Creo que usar LLM no para escribir o diseñar código sino para hacer code review podría ser la verdadera killer feature. Ahora mismo el code review está roto en muchos sentidos, y espero que en el futuro crezca mucho su utilidad para seguridad, comportamiento indefinido, mal uso de funcionalidades y doble verificación de warnings del compilador. En lo personal, uso más los LLM como si fueran un buscador para diagnosticar errores o depurar, con una tasa de acierto de alrededor del 50%, y me parece suficientemente buena

  • ChatGPT ya es bastante bueno depurando problemas que han sido muy discutidos en la web. Como resume e integra el conocimiento de Stack Overflow, ahorra mucho tiempo que antes se iba en buscar casos individuales. Eso sí, sus respuestas todavía mezclan invenciones o alucinaciones, así que sigue habiendo bastante ruido. Si revisa un codebase completo, puede detectar bien tipos de error o funciones/llamadas problemáticas, pero a cambio inevitablemente habrá muchos falsos positivos. Me pregunto si alguien ya está usando de verdad los LLM para automatizar el code review de forma adecuada
  • Si repites varias veces la petición de “revísame este código”, el chatbot puede cambiar X por Y y luego, un rato después, volver a cambiar Y por X. Tiene cierta utilidad para code review, pero uno mismo tiene que decidir cuáles sugerencias aceptar y cuáles rechazar. Para alguien con suficiente criterio, de verdad puede aumentar la productividad al proponer cambios candidatos
  • Me pregunto por qué este tema no se discute mucho más. Entre los desarrolladores que conozco hay distintos niveles de interés por la tecnología; por lo general, cuanto menos experiencia tienen, más activamente lo usan, y cuanto más senior son, menos interés muestran. Casi no escucho hablar de usar AI para review o validación de código; quizá haga falta una función que lo haga automáticamente al momento de cada commit
  • Más que para code review/design, ya existe un LLM especializado en code review dentro de GitHub Copilot, en modo revisor. Todavía no está al máximo nivel, pero tiene calidad suficiente como para usarlo dentro del loop
  • De acuerdo, en sourcery.ai estamos trabajando en eso