Usando IA para modernizar un proyecto Java

Si has seguido las últimas palabras de moda en la industria del software, probablemente te has encontrado con el término desarrollo guiado por especificaciones (SDD, por sus siglas en inglés). Ahora hay muchas herramientas y procesos que usan este término, a menudo con significados distintos a nivel de implementación. Algunos promueven metodologías en las que los desarrolladores solo trabajan con especificaciones y nunca tocan el código. Otros proponen un proceso más laxo, donde las especificaciones se parecen más a prompts desechables. He estado experimentando con algunos de estos frameworks/herramientas/metodologías para encontrar lo que mejor se adapta a mis proyectos y (como siempre) la respuesta sobre qué elegir es “depende”. Probé algunas de estas herramientas y decidí usar un enfoque “ad-hoc” basado en AGENTS.md para uno de mis proyectos unipersonales (CrudUI Add-On).

Herramientas SDD (que he probado)

#

Estas son algunas de las herramientas SDD que he probado en proyectos pequeños para experimentación:

• Kiro (de AWS) parece relativamente fácil de adoptar e incluye herramientas y un proceso simple para definir requisitos (un conjunto de historias de usuario), diseño de software y tareas (pasos de implementación). Una vez creas las especificaciones, prácticamente te olvidas de ellas.

• Spec-kit (de GitHub) sigue un proceso de múltiples fases: Constitución (principios del proyecto, reglas no negociables), especificación (historias de usuario), plan (stack tecnológico, arquitectura), tareas (pasos de implementación). Aunque no me quedó 100% claro, parece proponer el uso de especificaciones como “fuente de la verdad” del proyecto: Evolucionas los documentos de especificación a medida que avanza el proyecto. Sin embargo, también usa ramas independientes para cada especificación creada, lo que dificulta (¿imposibilita?) usarlas como una especificación viva y siempre actualizada.

• Tessl (de un startup del mismo nombre) parece apuntar a convertir las especificaciones en el punto principal (¿único?) de interacción para los desarrolladores y habilitar el enfoque de “simplemente deja que la IA escriba el código”. El flujo de trabajo incluye varios pasos: Entrevista (un agente te entrevista, un poco más amigable que esto), especificación (el agente redacta documentos que se convierten en la fuente de verdad definitiva), revisión (revisas y validas la especificación), implementación (el agente escribe código). Si necesitas cambios, no editas el código; editas la especificación lo que hace que el agente actualice el código en consecuencia.

• AI Unified Process (de mi amigo Simon Martinelli) plantea el desarrollo asistido por IA como un proceso disciplinado e iterativo. Me gusta que trata a la IA como un colaborador dentro de un flujo de trabajo estructurado y no como una caja mágica que reemplaza la ingeniería crítica.

Mi proceso con CrudUI Add-On

#

Recomiendo probar y seguir alguna de las herramientas anteriores en proyectos con multiples desarrolladores. Para equipos de una sola persona (como mi proyecto personal CrudUI Add-On) un proceso liviano funciona bastante bien. Mi plan era crear una nueva versión de la API de la librería para moverla de un estilo clásico imperativo/basado-en-setters a uno fluido. Esto requiere una reescritura y yo ya venía trabajando en las partes principales de la nueva API, diseñándolas a mano sin asistencia de IA. Una vez convencido de que la nueva API luciría bien, funcionaría bien y mantendría la filosofía del proyecto, empecé a implementar las partes faltantes con agentes de codificación.

Esto fue lo que hice:

1. Implementé las principales interfaces Java que forman el núcleo de la librería. Este paso tuvo un alto valor, ya que evitó que los LLM se desviaran demasiado del diseño de software que tenía en mente. Si podría simplemente haber escrito una especificación en lugar de hacer yo mismo el diseño de software, es debatible. ¡Sería interesante leer sus opiniones!

2. Creé un archivo AGENTS.md (que la mayoría, si no todos, los agentes de codificación leen automáticamente) y definí el proyecto a alto nivel, el stack tecnológico, la organización del código fuente, el rol del agente, las instrucciones para compilar/construir el projecto y lo que no debía hacer.

3. Inspirado por AI Unified Process, creé un archivo vision.md y añadí un enlace en AGENTS.md. La visión define el problema que resuelve la librería, la solución a alto nivel, los usuarios, los objetivos y no-objetivos, y la API central que diseñé manualmente (en su mayoría, interfaces Java).

4. Usé un agente de codificación para escribir especificaciones que usan una plantilla predefinida. Como este era un proyecto de modernización y yo ya había codificado manualmente parte de la nueva API, le indiqué al agente que escribiera especificaciones para la funcionalidad faltante que sí tiene la API antigua pero no la nueva. El agente generó alrededor de una docena de archivos de especificación.

5. Tomé una especificación a la vez, la revisé, la edité y se la pasé a un agente para su implementación. En la mayoría de las especificaciones, fue necesario guiar al agente. A veces fue por ambigüedad en la especificación; otras veces, por esos descubrimientos que surgen cuando realmente ves la funcionalidad implementada y cambias de opinión; y en ocasiones, simplemente porque la IA se desviaba un poco. Para algunas especificaciones, regresé y las edité para dar más claridad o introducir cambios, y en otras las dejé intactas incluso si tuve que guiar al agente.

Conclusión

#

Logré completar la implementación de la nueva API en pocos días. Aún hay algunos detalles por pulir, además de pruebas y validación en aplicaciones reales. Sin embargo, el salto en productividad fue claro y difícil de rebatir.

Si te da curiosidad y quieres ver los detalles, el código está disponible en GitHub.