Tras el éxito en la reescritura de pycparser con ayuda de un LLM, el ingeniero Eli Bendersky comparte en un ensayo su experiencia al desarrollar desde cero watgo, un toolkit de WebAssembly para Go, utilizando agentes de IA como compañero de programación. El artículo se centra en la metodología, las lecciones aprendidas y las limitaciones observadas durante el proceso.
El autor parte de una fase de diseño exhaustiva: antes de escribir código, itera con el agente sobre un esquema de la API documentado en un archivo Markdown dentro del repositorio. A partir de ahí, solicita cambios (CL) pequeños y revisables en un orden lógico, lo que permite mantener el control del proyecto. Bendersky advierte de que, aunque los agentes pueden producir el equivalente a días de trabajo en una sola entrega, el tiempo invertido en limpieza y refactorización sigue siendo considerable, por lo que la ganancia de productividad, aunque real, no es tan abultada como a veces se sugiere.
El texto distingue dos categorías de proyectos a la hora de integrar agentes. En prototipos o código desechable es aceptable el "vibe-coding", es decir, aceptar lo que el agente produce sin revisión profunda. En proyectos de larga duración, en cambio, el programador debe revisar y guiar cada bloque de código, ya que el mantenimiento futuro exige comprensión total del mismo. Para estos casos, Bendersky recomienda un flujo de trabajo con el agente ejecutándose en la línea de comandos mientras el desarrollador revisa los cambios en VSCode antes de crear los commits manualmente.
Otro punto clave es la estrategia de pruebas. Los agentes ofrecen sus mejores resultados cuando cuentan con una suite de tests sólida contra la que validar su código. En el caso de watgo, el autor adaptó las pruebas de la especificación de WebAssembly y del proyecto wabt. Advierte, no obstante, sobre el riesgo de bucles de autorrefuerzo si se delegan al mismo modelo tanto la implementación como los tests.
Bendersky también reflexiona sobre la elección de Go como lenguaje. Su sintaxis estable, el reducido número de formas de resolver un problema, su biblioteca estándar amplia y su énfasis en la legibilidad lo convierten en una opción especialmente adecuada para revisar código generado por agentes, dado que la mayor parte del tiempo humano se invierte en leer, no en escribir.
El ensayo cierra recomendando evitar los agentes cuando se desea aprender una materia desde cero, ya que la asimilación real requiere recorrer el camino a mano.