AI SDLC: un compendio de buenas prácticas para desarrollar con IA

Hay mucho hype alrededor del desarrollo asistido por IA. Claude, Copilot, Cursor,… la lista crece cada semana. Y sí, estas herramientas son poderosas. La IA es excelente para un PoC, pero shipear a producción es otra historia.

¿Qué es el AI SDLC?

El AI SDLC es la integración de herramientas y sistemas de IA en cada fase del ciclo de desarrollo de software tradicional —planning, analysis, design, coding, testing, deployment y maintenance— para potenciar al desarrollador humano y mejorar velocidad, calidad y toma de decisiones. Como lo resume IBM en este artículo, la idea no es reemplazar al dev sino sumarle una capa inteligente a lo largo de todo el proceso. Y advierten algo clave: el código generado por IA «may look correct, but can contain subtle problems» — puede parecer correcto y esconder problemas sutiles. Por eso el enfoque human-in-the-loop es casi obligatorio en cualquier proyecto serio.

Este post no busca cubrir las siete fases. Es un compendio de buenas prácticas durante el AI SDLC, enfocado en la parte donde el dev está más en el loop: diseño, construcción y revisión. No es la verdad absoluta; vas a encontrar muchas más prácticas y estándares a medida que profundices. Es lo que a mí me funciona.

La IA es genial para un PoC — pero un PoC no es prod-ready

Las AI dev tools son fantásticas para arrancar de cero y tener algo funcionando rápido. Le decís qué querés, lo deja correr, y en minutos tenés un PoC. El problema es que ese código no necesariamente sigue buenas prácticas de diseño, arquitectura o coding. En la mayoría de los casos, lo que sale no es un producto listo para producción.

Y acá viene lo incómodo: necesitás entender el código. El vibe coding está bien para un mockup, pero no para algo prod-grade. Y esto sigue siendo cierto incluso con el último modelo y las mejores herramientas.

Los escenarios: dónde la IA brilla y dónde se complica

Crear un PoC full funcional desde cero — muy bien. Es el terreno donde más brilla.
Agregar features simples a un codebase — bien. En general no requiere mucha más ayuda.
Agregar features complejas a un codebase complejo — medio. Acá ya necesita bastante más guidance del dev.
Modificar features existentes en un codebase simple — bien. En general menos guidance.
Modificar una feature existente en un codebase grande — bien. Sigue sin requerir demasiada guía.
Implementar una feature compleja en un codebase grande — acá se pone difícil. No importa cuánto contexto, skills, hooks tengas, ni lo bueno que sea tu prompt: acá necesitás un buen plan. Es muy fácil que el agente genere código no ideal — probablemente código que funciona, pero no escalable, propenso a errores, poco legible, etc.
Codebases grandes en general, y migraciones de código — la cosa se vuelve realmente delicada.

La conclusión: cuanto más grande y complejo el codebase, y cuanto más compleja la feature, más cae la utilidad de la IA dejada sola — y más sube la importancia del dev en el loop.

Cuando vas a shipear a prod: mi flujo de AI SDLC

Cuando querés llevar algo a producción, el vibe coding no es la respuesta — al menos no si pensás que el agente lo haga todo. Estas son las buenas prácticas que aplico, basadas en mi experiencia personal:

1. Diseñá antes de promptear

Antes de escribir un solo prompt, vos decidís la arquitectura, el diseño y el lenguaje. Podés brainstormear con la IA, pero deberías tener diseñado de antemano cada aspecto de la aplicación y la infra.

2. Pedile un plan detallado

Usá ese diseño y pedile a la IA que genere un plan detallado, con tus instrucciones y decisiones ya tomadas como input.

3. ¡Revisá el plan!

Con cuidado. Pedile las modificaciones que hagan falta. Yo normalmente le pido que cree un archivo .md que tanto la IA como yo podamos modificar y revisar — no lo dejo solo en el prompt.

4. Dividí y avanzá

Cuando el plan está OK, partí las tareas más grandes en tareas pequeñas y arrancá.

5. Nunca lo dejes hacer todo sin preguntar

Revisá cada cambio. Completá un commit. En esta etapa me gusta revisar los cambios del commit una vez más. El código generado por IA se ve bien, y es fácil pasar por alto problemas en una sola pasada. Cuando estás conforme con ese commit, seguís con el siguiente paso.

6. Revisión final, por triplicado

Cuando está todo listo, pedile a la IA que revise una vez más para encontrar problemas potenciales. Y hacé vos una inspección manual rápida de tu código nuevo. Esa es la tercera revisión.

Más prácticas que vale la pena tener en cuenta

Testing como guardrail

Pedile a la IA que escriba tests, pero con ojo crítico. A veces genera tests que pasan trivialmente, o que testean la implementación en vez del comportamiento real. Los tests son tu red de seguridad cuando dejás que el agente modifique código, pero hay que revisarlos con la misma desconfianza que el resto. Un test que no falla nunca no te protege de nada.

Seguridad: nunca confíes a ciegas

La IA mete con facilidad secrets hardcodeados, dependencias inseguras, validaciones faltantes o vulnerabilidades de inyección. Funciona, pero deja la puerta abierta. Revisá siempre el código generado desde el ángulo de seguridad: qué datos toca, qué valida, qué expone.

Herramientas determinísticas en el loop

No todo tiene que pasar por tu criterio o el del modelo. Linters, type checkers, formatters y CI atrapan automáticamente un montón de cosas que ni vos ni el agente deberían estar revisando a mano. Dejá que las herramientas determinísticas hagan su trabajo y reservá tu atención para lo que de verdad requiere juicio.

Cuidado con el scope creep

El agente tiende a «mejorar» cosas que no le pediste, o a tocar archivos fuera del alcance de la tarea. De repente un cambio simple vino con tres refactors sorpresa. Mantenélo enfocado en lo que pediste; los cambios fuera de scope son una de las formas más fáciles de introducir bugs que nadie estaba esperando.

Sabé cuándo escribirlo vos

A veces explicarle a la IA cómo hacer algo cuesta más que hacerlo a mano. Reconocer ese punto es una skill en sí misma. La IA es una herramienta, no una obligación: si vas a tardar menos escribiendo el código vos mismo, escribílo.

Elegí el modelo y el effort correcto para cada tarea

No todo amerita el modelo más potente al máximo effort. Para tareas simples — renombrar, refactors mecánicos, boilerplate — un modelo más liviano alcanza y sobra. Reservá los modelos grandes y el reasoning alto para lo que de verdad lo necesita: arquitectura, features complejas, debugging difícil. Economizar costos y tokens no es solo una cuestión de plata: matchear el modelo y el effort a la complejidad real de la tarea te da mejores resultados y menos ruido.

Algunas reglas importantes

Asegurate de tener configurados tus skills, hooks, commands, rules y el code styling dentro del contexto del agente, listos antes de empezar.
Aprovechá las rules para fijar comportamientos no negociables del agente: «nunca asumas nada», «siempre consultá o preguntá si algo no está del todo claro», «no toques archivos fuera del scope de la tarea», «no inventes APIs ni librerías». Una buena rule te ahorra repetir lo mismo en cada prompt.
Hacé adversarial reviews de tu proyecto.
En general, las soluciones simples son las mejores. Desconfiá de las soluciones complejas que genera la IA — muchas veces hay un camino más directo que el modelo no eligió.
Si no estás seguro de cuál es la mejor forma de implementar algo, volvé a la fuente: documentación oficial, specs, el código original. No te quedes con la primera respuesta del agente.
No shipees nada que no entiendas.