A medida que pasa el tiempo, una cosa está clara: una sola línea de código ya no es tan relevante.
Antes dedicaba tiempo a pensar cómo cada línea de código representaría mejor el problema del dominio, abstrayendo las piezas que reconocía que debían abstraerse juntas y aplicando patrones y convenciones a mano.
“”Ahora ese foco ha cambiado por completo.
Una sola línea de código, en el contexto de un proyecto donde está presente la programación agéntica, es insignificante.
Eso no significa que no debamos preocuparnos por cómo escribimos el código; de lo que debemos preocuparnos es de cómo le decimos a nuestros agentes que programen.
#De diseñar código a diseñar agentes que programan
He comprobado en varios proyectos que lo que va a aportar valor a los productos de software es lo inteligentes que seamos al implementar bucles agénticos autónomos que entiendan la arquitectura, sigan las convenciones del equipo y puedan validar el proyecto de forma fiable.
No vamos a programar directamente, vamos a diseñar bucles que programen a la altura de los estándares del proyecto.
Por eso entender la arquitectura y las buenas prácticas, una vez más, es lo que te va a diferenciar de cualquier otro desarrollador, o modelo de IA.
Esto es lo que hace que un arquitecto sea a prueba de futuro.
Como ha expresado Addy Osmani, la deuda de intención es algo con lo que los agentes no pueden ayudarteSe abre en una nueva pestaña; son ellos los que están causando esa deuda de intención. La Arquitectura de Software consiste precisamente en establecer la intención sobre cómo debe funcionar un sistema. Aportar intención a lo que hacemos es clave.
¿Y cómo aportamos intención en el Desarrollo de Software Agéntico? Para mí, la mejor manera es a través de skills, una arquitectura validada por humanos, documentación asistida por IA (no generada por IA) y ADRs.
Ahora bien, necesitamos una forma de validar que lo que generamos es lo que pretendemos generar.
#Harness Engineering
Con el desarrollo agéntico, no solo necesitamos decirle a nuestros agentes cómo programar, sino tener una forma de validar que el sistema funciona como se pretende.
Los tests se han vuelto obligatorios (¡por fin!). Si no escribes tests, los agentes no van a ser tan efectivos como podrían.
Creo que en algún momento, al desarrollar funcionalidades, vamos a centrarnos únicamente en escribir especificaciones. Esto también se conoce como Spec Driven Development (Desarrollo Guiado por Especificaciones).
También podemos introducir ciertas validaciones que se ejecuten de forma determinista y automática, vía CI/CD o Git Hooks:
- Linting
- Formateo
- Tests unitarios
- Tests de integración
- Tests E2E
- Comprobación de tipos
- Tests de arquitectura
Es en este último punto en el que me estoy centrando ahora mismo. Los skills son una gran forma de definir cuál debería ser la arquitectura, pero tener una manera de validar la arquitectura es lo que más me interesa.
Todas estas técnicas, que para mí son habituales, ahora forman parte de un subconjunto de la ingeniería llamado Harness Engineering. Creas un harness que valida el proyecto de forma automática y determinista para que los agentes entiendan mejor si lo que están haciendo es lo que deberían.
#Bucles autónomos
Una vez que tenemos los skills, el harness y, potencialmente, documentos de especificación que describen las funcionalidades, podemos plantearnos crear bucles de agentes autónomos.
Diseñar bucles significa que tenemos que pensar en abstracciones complejas; crear sistemas autónomos puede resultar abrumador, y con razón: podemos ganar mucho o perder mucho. Depende de cómo diseñemos este tipo de bucles, algo que exploraremos en el próximo número de esta newsletter.
Aquí es donde está el futuro del Desarrollo de Software. Únete a mí.
#Conclusión
La arquitectura aporta intención sobre la entrega de un producto de software. Los agentes pueden diluir la intención de un producto, ya que van a hacer suposiciones plausibles basándose en lo que ya existe. Podemos reducir esa deriva siendo explícitos sobre el sistema, mediante skills, convenciones y un harness en marcha.
P.D.: Gracias, Victor GuillánSe abre en una nueva pestaña, por la inspiración para el concepto de "Una línea de código ya no va a existir" en una de nuestras conversaciones recientes.
P.D. 2: Escribiendo esta newsletter desde el Albir, Alicante, España.