El ABC de la Programación con IA

Desarrollar soluciones de software es mucho más que programar. Requiere saber qué hacer y por supuesto mantener lo hecho. Es un trabajo intelectual al que le toca el turno de ser automatizado.

LA IA puede manifestarse en diferentes formas: como un simple chat, un asistente, o un agente autónomo. Pero siempre es algo más que una herramienta. Me resulta útil verlo como un miembro más del equipo, pero con distintas perspectivas.

El ciclo del desarrollo

La ingeniería de software ha evolucionado mucho desde hace más décadas de las que me cuesta aceptar recordar. Pero, en general, he comprobado que una serie de tareas y metodologías se han mantenido comunes a todos los desarrollos.

Tareas

Sabemos que desarrollar software es un proceso complejo que requiere una serie de pasos. De los cuales, uno de ellos es codificar. Por ahí hemos empezado todos. Y por ahí hemos empezado con la IA; auto-completado de código más o menos inteligente.

Pero más allá de codificar están otras tareas tan importantes como la planificación, análisis, diseño, pruebas y mantenimiento. Y todas ellas, como trabajos white-collar, son susceptibles de ser automatizadas, impulsadas o mejoradas con IA.

Metodologías

No todos los proyectos son iguales. Dependen de las necesidades (más o menos complejas) y de las personas (más o menos expertas) que los desarrollan. Las diferentes metodologías de desarrollo se adaptan mejor a unos que a otros.

Seguramente conozcas algunas de ellas: waterfall, agile, lean, big-bang, etc. Pero, ¿qué es lo que tienen en común?

Todas ellas envuelven de alguna la manera al proceso de programación, definiendo qué hacer y verificando que sea mantenible.

Herramientas, procesos, personas y roles

Para llevar a cabo el desarrollo de software (en realidad de cualquier otro proyecto complejo), necesitamos herramientas, procesos, y personas que cumplan roles.

La llegada de la IA, nos plantea la duda de qué es. ¿Es una herramienta, o es algo o alguien más?

La analogía de la edificación

Una analogía muy manida en el mundo del software es su comparación con la edificación. El arquitecto diseña el edificio, el constructor con su equipo de albañiles lo construye, y los manitas de turno lo mantienen. No es uno para uno, pero claramente identifica los roles que dan respuesta a las preguntas de cualquier proyecto: ¿qué hacer?, ¿cómo hacerlo?, ¿cómo mantenerlo?.

En una obra, uno puede olvidarse o desconocer algo, pero nunca confundir un martillo con un electricista.

Para mí, la IA es más que una herramienta. Es al menos un asistente, y puede ser un agente autónomo. Uno más en el equipo. Y por tanto le asigno un rol.

En un esfuerzo por abordarlo de la forma más simple posible, he identificado los tres roles que, en mi opinión, son el ABC de la programación, y por extensión, del desarrollo con IA. Además, en la lengua del imperio, me encaja con el acrónimo simplón pero resultón ABC: Architect, Builder, Craftsman. Veamos qué es cada uno.

🧑‍🔬 Architect

Bajo este paraguas meto todas aquellas tareas que definen el proyecto. Desde su objetivo, funcionalidad esperada, hasta la arquitectura de la solución. En concreto esto me lleva a dos tareas principales para el asistente: planificación y análisis.

📐 Para este rol, escojo como herramienta principal un modelo de lenguaje. Cuanto más avanzado, mejor. Así que si te lo puedes permitir, elige un modelo con capacidades de razonamiento o pensamiento profundo. ChatGPT, Claude y Gemini son los que mejor se adaptan a este rol.

Planificación

El asistente debe ayudarme a definir el proyecto. Mediante una serie de preguntas, debe entender el problema y las expectativas. Y generar un documento que sirva como briefing para empezar a trabajar.

En proyectos muy simples, pruebas de concepto o MVP, esto puede ser suficiente para un sar como prompt de one-shot Builders como Lovable, v0 o Bolt.

Pero en proyectos reales, hace falta más. Al menos, una lista detallada de las funcionalidades como user-stories y algún diagrama mermaid de alto nivel.

Análisis

En esta tarea, el asistente debe aplicar toda su inteligencia, si es que la tiene… Porque aquí es donde más la necesitamos para pasar del problema a la solución.

Los modelos más avanzados ofrecen capacidades de razonamiento, o pensamiento profundo que no pueden proponer una arquitectura del sistema y las tecnologías que lo soportan.

También puede detallar las funcionalidades al nivel de use-cases que sirvan tanto para implementar como para probar la solución.

Cualquier diagrama de flujo, contexto o arquitectura que ayude a entender el problema y la solución es bienvenido.

👷 Builder

La construcción de la solución es la razón de ser de la ingeniería de software. Independiente de métodologías más lineales o cíclicas, estos suelen ser los procesos centrales y que más recursos y tiempo requieren. La IA, también les presta la debida atención.

🏗️ En esta fase se difuminan las barreras entre herramientas. En principio sería un caso de uso para editores inteligentes como Cursor, Windsurf, aider, etc. Pero en realidad, un buen LLM puede ayudarte, especialmente en la fase de diseño, previa a la implementación. Ojo, que los agentes online tipo Bolt o Lovable son excelentes para crear el scaffold de un proyecto, aunque se quedan cortos para implementar funcionalidades. También puedes usar Copilot, Continue o cualquier extensión que complete el código, pero no son agentes.

Diseño

Cualquier proyecto no trivial requiere un diseño. Especificaciones de usabilidad, modelos de datos, estándares de codificación, etc. Todos son documentos que pueden ser generados por el asistente y adjuntados al proyecto.

Puedes ir más allá e incluso pedirle que genere las funcionalidades al nivel de use-cases como pseudo-código. Cualquier paso intermedio es una oportunidad de revisión humana para corregir o refinar el proyecto.

Implementación

Aquí empezó todo. Hace ya unos años que me quedé perplejo viendo como GitHub Copilot me leía la mente y completaba código ante mis ojos. A día de hoy eso me parece una proceso superficial y me avergüenzo de mi pasado naif tratando a Copilot como un ente pensante.

Con todo lo generado por el Arquitecto y la fase de diseño usada como contexto, los actuales generadores de código como Cursor/Composer pueden crear carpetas, ficheros y hasta proyectos enteros. Lo dicho, un completador de código no es un agente y se queda corto para considerarse un Builder.

Como el tamaño importa, el Builder hará un mejor trabajo si le pides funcionalidades concretas y pequeñas. Y aún mejor, si le pides que te genere un plan previo, antes de que escriba el código definitivo. Sí lo sé, es una tarea más con su coste de recursos y tiempo, pero, créeme que mejora mucho la calidad resultante y reduce las alucinaciones que aún hoy en día se dan en los modelos estocásticos.

Antes de pasar al nivel de artesanía, recordarte que el Builder, debe escribir buen código (te guste limpio, funcional o procedimental) con sus pruebas y su documentación (por más que después lo podamos mejorar).

🧑‍🏭 Craftsman

El software se llama así para denotar su naturaleza evolutiva y distinguirlo del hardware inmutable. Todo lo que se desarrolla es susceptible de ser mejorado, modificado, extendido, etc. En definitiva hay que mantenerlo. Y además hacerlo con el cuidado y atención a los detalles que haría un artesano.

🪛 Para este rol, ya no aplica tanto el LLM en solitario. Es un trabajo muy de refinado inmediato. Los agentes de los editores inteligentes como Cursor, Windsurf, aider, etc. son excelentes para este caso. Eso sí, asegúrate de usar un modelo de servicio que admita la mayor cantidad de contexto posible.

Pruebas

Como vimos, durante la fase de implementación se puede, y deben, exigir pruebas unitarias como parte de la generación de código. Pero, como también te dije, cuanto más abarques menos apretarás, y suele ser necesario completar la verificación del sistema con pruebas de usabilidad, e2e o de integración.

Partiendo de las especificaciones y escenarios de uso, es muy fácil automatizar el desarrollo de pruebas. Sin excusas, buscando los casos límites y fomentando que el software evolucione, se corrija y se refactorice.

Si el proyecto y el equipo lo requieren, puedes aprovechar para pedirle al asistente que aplique patrones de diseño o principios de codificación que pudieran haberse omitido en una fase anterior. Por ejemplo, hacer el código más funcional o más sólido. Lo que quieras.

Estas mejoras son muy importantes porque influyen en la implementación de nuevas funcionalidades, creando un ciclo de retroalimentación que mejora la calidad del código. Recuerda, tu base de código es un contexto para tu agente. Mejor contexto, mejor trabajo.

Mantenimiento

Mantener siempre es algo a futuro. No se sabe cuándo, pero ocurrirá. Y para entonces, todo el conocimiento que se tenga del proyecto se habrá perdido en la memoria de las personas que lo desarrollaron. Así que mejor que esté en un soporte más accesible y fiable.

Ya sé que todo buen código es su mejor documentación. Pero, ¿qué pasa cuando el código es tan complejo que no se entiende fácilmente? ¿Qué pasa cuando el proyecto es realmente grande que no sabes por dónde empezar? ¿Qué pasa cuando quien lo va a mantener es un agente cuya especialidad es leer?

Pues que cuanto más contexto escrito disponga mejor será. Y para ello, el Craftsman debe documentar todo lo que haga. Puede empezar con un obligatorio README, y un convenio de mensajes de commit para la trazabilidad de cambios.

Y esto es solo el principio. Puedes ir hasta el final de la vida del proyecto. Pedir ayuda con el despliegue, la integración continua, etc.

Hablando de git, el agente puede gestionar el repositorio y adaptarse al flow de trabajo que se haya definido. Crear ramas, desplegar a producción y revisar código son tareas que pueden ser automatizadas.

Generar documentación y mantenerla actualizada es una tarea que siempre fue considerada como tediosa. Pero ahora es muy fácil que pueda ser asignada a un asistente. Diagramas de carpetas físicas, de componentes lógicos, de clases, etc. Todo ayuda a que el siguiente humano o agente pueda entender mejor el proyecto.

Conclusión

En definitiva, el desarrollo de software es un conjunto de actividades intelectuales a las que les ha llegado la hora de ser automatizadas. La clave está en considerar la IA como un miembro más del equipo asignándole un rol, y no sólo como una herramienta.

No es fácil anticipar cómo va a evolucionar la IA y las herramientas que nos ofrecerá. En el futuro los avances quizás nos lleven a que un único interlocutor nos baste para completar todo el ciclo de desarrollo.

Pero, por ahora, es mejor enfocarse en los fundamentos y aceptar los detalles cambiantes. Pensar en roles simples y complementarios me permite que el Arquitecto, el Constructor y el Artesano (sean lo que sean en el futuro) trabajen en equipo desde hoy.

Extra

Estoy creando un repositorio en GitHub llamado AgentBlueprints en el que voy a ir añadiendo ejemplos, prompts y configuraciones de como implementar estos roles. Desde lo más básico hasta agentes autónomos. Permanezcan atentos.