Si su equipo de desarrollo empezó a usar asistentes de IA para programar, es probable que haya notado algo raro: el código sale bastante más rápido, pero los proyectos no se entregan mucho antes.
No es una impresión suya. Anthropic publicó hace poco el AI-Native SDLC Playbook, una guía para rediseñar el ciclo de vida del desarrollo de software (SDLC) cuando hay agentes de IA en el proceso. Su diagnóstico cabe en una frase:
El código ya no es el cuello de botella. Lo son los pasos que lo rodean, que siguen ocurriendo a velocidad humana.
Vale la pena detenerse en esto, porque cambia la respuesta a dónde conviene invertir.
Un proceso pensado para otra época
El ciclo de desarrollo tradicional (levantar requerimientos, diseñar, construir, probar, desplegar, mantener) se diseñó cuando lo más caro y lento era escribir el código. Todo lo demás se organizó alrededor de eso: comités que aprueban requerimientos, revisiones por fase, QA al final de cada etapa.
Hoy un agente puede reducir la construcción de semanas a horas. Pero el proceso sigue igual, así que el atasco se corre a lo que está antes y después del código: la planificación, la revisión, las pruebas y el despliegue.
Pasa algo parecido a cuando se ensancha un tramo de autopista: el taco no desaparece, aparece en la siguiente salida.
El costo que no se ve: especificar tarde
De todos los pasos lentos, hay uno especialmente caro: definir bien qué se va a construir.
Es muy común que un equipo espere semanas por un requerimiento claro y, cuando por fin lo tiene, construya rápido. Los problemas de especificación aparecen al final: una regla de negocio que nadie mencionó, un módulo que ya existía, una dependencia que se rompe. Y corregir en esa etapa es lo más caro de todo el ciclo.
Programar más rápido no resuelve eso. Solo hace que se llegue antes al error.
La propuesta: de una línea a un loop
El playbook propone dejar de ver el desarrollo como una secuencia de fases y pasar a un loop en que cada etapa termina produciendo un artefacto versionado que la siguiente usa como insumo:
- Plan: Un documento de intención, es decir, qué problema se quiere resolver y por qué.
- Diseño: Una especificación que aplica las políticas de la organización.
- Construcción: Un plan de implementación, más el código y sus pruebas.
- Pruebas: Resultados y evaluaciones continuas, no un control al final.
- Despliegue: La revisión con hallazgos y aprobaciones registradas.
- Mantención: Cuando el monitoreo detecta un problema, genera una nueva intención y el ciclo vuelve a empezar.
Esto tiene una consecuencia que suele pasarse por alto: la cadena de artefactos es también la trazabilidad. Cada decisión queda registrada con autor, fecha e historial. Para una empresa que responde a auditorías internas o externas, eso ya no es un documento que alguien arma después, sino algo que se genera mientras se trabaja.
Los controles no se eliminan: se reimplementan
La objeción típica frente a la IA en desarrollo es la gobernanza: ¿quién controla lo que hace el agente?
La respuesta del playbook es la idea que nos parece más valiosa de todo el documento. Los controles no desaparecen, cambian de lugar. Dejan de ser comités semanales que revisan el trabajo terminado y pasan a ser restricciones que se aplican mientras el agente trabaja:
- Políticas como reglas: Las políticas de seguridad, cumplimiento o experiencia de usuario se escriben como reglas que el agente lee y aplica al construir.
- Bloqueos automáticos: Por ejemplo, que el agente no pueda desplegar a producción sin aprobación o que no pueda modificar las pruebas mientras corrige un error.
- Separación de funciones: El agente que escribió el código no tiene autoridad para aprobarlo.
Así, la mayoría de los errores se evitan antes de que alguien tenga que revisar.
El rol de las personas: menos ejecución, más juicio
Nada de esto saca a las personas del proceso. El artículo lo dice de forma explícita: los humanos siguen siendo responsables de cada decisión que requiere juicio.
Lo que cambia es dónde se pone esa atención. Ya no se gasta en revisar línea por línea algo que una máquina puede verificar, sino en los puntos de aprobación: ¿la intención es correcta?, ¿la especificación resuelve el problema real?, ¿el riesgo de este cambio es aceptable?
El playbook lo cierra así: el loop sigue corriendo; el juicio humano se mantiene por encima de él.
Llegamos al mismo lugar por otro camino
En Tinet leímos el playbook con una sensación particular: la de encontrar escrito, por otra persona, un diagnóstico al que ya habíamos llegado.
GenDEV, nuestra plataforma de agentes de IA para el ciclo de desarrollo, es un desarrollo interno de Tinet. Se diseñó de forma totalmente independiente, sin relación con Anthropic ni con su trabajo, y partió de la misma premisa: el mayor potencial no está en escribir código más rápido, sino en llegar al código con decisiones bien tomadas.
Cuando dos equipos que no se conocen llegan al mismo diagnóstico, suele ser porque el problema es real.
Cómo lo resolvemos: la mitad pre-implementación del loop
Suite Loica, construida sobre GenDEV, se concentra justo en el tramo donde está el costo que describimos más arriba: lo que pasa antes de escribir código. Toma una idea de negocio y la lleva por tres etapas, Discovery, PRD y Diseño Técnico, hasta una especificación lista para desarrollar.
Hay dos decisiones de diseño que nos importan especialmente.
- La especificación no parte de supuestos: Cada especificación se valida contra el repositorio real del cliente, mediante una base de conocimiento (KDB) que contiene todo el contexto del sistema: miles de archivos de código, documentación e historial. Así, la especificación dice qué componentes ya existen y se pueden reutilizar, y qué módulos se van a ver afectados. Nace conectada a un código que existe, no a una idea de cómo debería ser el sistema.
- Hay guardrails, no solo buenas intenciones: Cada paso de una etapa a otra pasa por controles automáticos de cobertura, basados en un estándar construido con más de 25 años de experiencia desarrollando software para grandes empresas. Es la misma lógica del playbook: los controles se aplican mientras se trabaja, no al final. Y en cada etapa hay una persona que revisa y aprueba. El agente propone; el criterio profesional decide.
Los resultados
En las etapas donde opera, medimos una reducción de entre 40 % y 50 % del tiempo, con un ahorro cercano al 30 % en costos a igual productividad.
Pero la cifra que más nos importa es otra, más difícil de medir: la de las decisiones que se toman bien al principio y no hay que pagar al final. Esa es la diferencia entre automatizar y delegar. Automatizamos lo que una máquina hace mejor; no delegamos el juicio. Esa línea no la vamos a cruzar.
Si quiere empezar por algún lado
Tres cosas que puede hacer esta semana, sin comprar nada:
- Mida dónde espera su equipo. Tome los últimos tres proyectos y calcule cuánto tiempo pasó entre la idea y un requerimiento aprobado, y cuánto entre ese requerimiento y el código listo. Si el primer número es mayor que el segundo, ya sabe dónde está su cuello de botella.
- Cuente los errores que nacieron en la especificación. Revise los retrabajos del último trimestre y pregúntese cuántos venían de algo mal definido o no considerado al inicio. Ese es el costo que la IA de programación no le va a resolver.
- Revise dónde viven sus controles. ¿Sus políticas de calidad y seguridad se aplican mientras se trabaja o se revisan cuando ya está todo hecho? Pasarlas de lo segundo a lo primero es el cambio de fondo, con o sin IA.
Para cerrar
La IA ya hizo más rápido escribir código, y ese avance va a estar disponible para todos por igual. La ventaja va a estar en rediseñar lo que rodea al código: definir bien qué construir, controlar mientras se trabaja y reservar el juicio humano para las decisiones que lo necesitan.
Construimos GenDEV y Suite Loica con esa convicción. Si le interesa ver cómo se aplicaría en su organización, escríbanos. La primera conversación es un diagnóstico, no una demo.
