LLM16 – CONVEX, agentes, y el SDLC

La semana pasada tuve la oportunidad de asistir a CONVEX Summit, un evento organizado por el equipo de Plain Concepts que combina la clásica dotNET conference con otras dos conferencias GSAS y Singularity Tech day. A lo largo de 2 días estuvimos aprendiendo y debatiendo la temática de 2026, que es integrar agentes en el ciclo de desarrollo de software.

Tras varias olas de hype, y con modelos establecidos, la industria se está asentando en algunas buenas prácticas que, sorprendentemente, son las mismas de las que llevamos hablando muchos años, pero que los LLMs nos permiten acelerar.

Es importante mencionar que el evento fue masivo, en total fueron casi 40 sesiones y este artículo cubre poco más del 10%, ya que por una parte fueron tres tracks en paralelo y por otra, dediqué mucho más tiempo a hablar con compañeros sobre los temas que más me llamaron la atención.

Ahora podemos iterar en los requisitos

En la charla de Gisela y en conversaciones «de pasillo», el tema de curar los requisitos vino una y otra vez, y es que todo el mecanismo de prompt engineering se reduce a que «el requisito tiene que estar claro», y es por lo que llevamos luchando muchos años, siendo una fuente de conflicto entre equipos de ingeniería, producto y clientes.

Los LLMs simplifican este proceso, ya que pueden estar a la escucha de nuevos requisitos o issues, y pueden completarlas de manera autónoma o, cuando falta información, pueden parar y preguntar por la información que falta.

En la práctica, esto significa tener diferentes modelos para cada tarea, un modelo simple para reescribir los requisitos y encontrar gaps, un complejo para modelar la tarea, y un modelo simple para ejecutar en paralelo.

Los vendors no son prescriptivos en qué modelo usar para cada tarea porque dependerá del contexto de cada empresa, pero esta iteración es necesaria, y ahora tenemos las herramientas y la necesidad de pasar más tiempo aquí.

Podemos codificar las convenciones existentes

En la sesión de Andoni y Rubén, hablamos de cómo agentificar nuestros proyectos para poder usar IA de manera eficiente, ya que para poder informar los requisitos necesitamos codificar, de alguna manera, el conocimiento institucional del sistema tal y como existe hoy, y es lo que denominamos convenciones.

Spec-driven development tiene diferentes sabores, pero todos son una combinación de requisitos y convenciones. En el caso de GitHub Spec Kit, de Microsoft, se define una constitución y principios de un proyecto. En el caso de Kiro, de AWS, las convenciones se establecen en ficheros de steering, y en el caso de openspec se separa el dominio de los cambios.

Los agentes necesitan una combinación de ambas cosas, y para poder dejar sueltos a nuestros agentes en proyectos existentes, necesitamos establecer dichas convenciones lo antes posible, aunque ese proceso implique un coste inicial que no produzca resultados visibles.

Los agentes tienen… agencia?

Durante las charlas, un tema que estuvimos discutiendo en los pasillos fue qué significaba dejar a los agentes sueltos, y es ese el siguiente punto al que se está moviendo la industria, y es que los agentes no están esperando a que des órdenes, sino que tienen su propio ciclo OODA del que hablábamos en Cerrando el bucle.

Cuando tenemos las convenciones establecidas y un mecanismo de input organizado, podemos tener agentes escuchando cambios en un repositorio de Github, alarmas en AWS, y respondiendo a estos cambios de manera autónoma.

¿Y qué significa responder a cambios de manera autónoma? Pues puede significar muchas cosas, desde dar contexto a un ticket, avisar en Slack que algo ha pasado (y proporcionar contexto que una alarma por sí misma no proporciona), preparar una Pull Request con el cambio sugerido, o incluso desplegar cambios a producción sin supervisión humana.

Mi argumento es que seguimos lejos de esta última etapa, pero hay muchos experimentos en esa dirección, y la infraestructura para hacerlo posible ya existe, es una cuestión de confianza y contexto. Y con esto surgía la pregunta de cómo limitar o controlar la «agencia» que tienen nuestras herramientas, y aquí es donde vienen los hooks.

Estableciendo límites

En la sesión de Luis se discutió la idea de meta-SWE, toda la infraestructura que establecemos para que los agentes sean autónomos de una manera segura.

Para ello, además de las reglas y las convenciones de nuestro sistema, Luis mencionaba la necesidad de tener reglas fuertes en forma de hooks, que son comandos que se ejecutan en momentos clave (antes de llamar a un LLM, antes de llamar a una herramienta en concreto) y pueden limitar el impacto potencialmente negativo de los mismos.

Como están integrados en el arnés, la ejecución no depende de la respuesta del LLM con lo cual son normas que el agente no puede ignorar.

Con este último paso tenemos un sistema completamente integrado en nuestro ciclo de desarrollo de software (SDLC).

Esto no es nuevo

Nada de lo mencionado en las charlas o en las conversaciones era fundamentalmente nuevo, lo que era revelador era donde ponemos el foco. Los LLM permiten codificar de manera muy eficiente los requisitos, y son tan predecibles como los requisitos y las convenciones que tengamos.

El punto de inflexión es que los LLMs nos pueden ayudar también a contextualizar los requisitos, a establecer estas convenciones, a fabricar el arnés en el que se ejecutan.

Procesos como dar forma a una historia de usuario que es relevante pero necesita trabajo, buscar los tests mínimos y necesarios para comprobar el caso, y establecer reglas de linter que nos permitan mantener consistencia, forman parte de las cosas que podemos automatizar.

Invertir en el sistema nos permite ir más allá del chat, más allá de escribir el contexto otra vez, y más cerca de la idea de tener agentes autónomos como parte de nuestro equipo.

Esta inversión supone un reto en dos dimensiones. Por una parte los LLMs no nos imponen la disciplina para establecer las buenas prácticas, y van a intentar implementar la solución lo antes posible.

Por otra parte la empresa espera un retorno inmediato en la inversión en tokens, y esa expectativa choca con la realidad de que necesitamos adecuar nuestros sistemas para funcionar con agentes, más que adecuar los agentes para que funcionen con nuestros sistemas.

Y tú, ¿estás cambiando tu ciclo de desarrollo para aprovechar esta ola que viene?