La empresa Anthropic ha lanzado su AI-Native SDLC Playbook, un manual que marca un antes y un después en la forma en que se concibe el ciclo de vida del desarrollo de software cuando se trabaja con inteligencia artificial. Su premisa fundamental es que «el código ya no supone un cuello de botella»: gracias a que agentes automatizados pueden generar implementaciones en cuestión de minutos, las limitaciones se desplazan a fases externas al desarrollo de código, como la planificación, la revisión, la verificación, el despliegue y la gobernanza.
Esto conlleva el riesgo de generar diez veces más cambios con la misma calidad o peor, sin métodos claros para identificar cuáles de esos cambios son problemáticos. Tradicionalmente, la solución ha sido la revisión humana detallada de cada cambio, un enfoque que resulta inviable dada la escala y velocidad actuales.
El manual de Anthropic marca bases sólidas, pero todavía no aborda que cada organización no sigue un único proceso rígido, sino que en realidad maneja una familia de flujos que se adaptan según la naturaleza del cambio. No todos los ajustes, migraciones o correcciones deben someterse al mismo recorrido formal, un aspecto nada trivial que debe respetarse para evitar la invisibilidad del verdadero proceso de desarrollo. 
La apuesta por el desarrollo dirigido por especificaciones
Este manual forma parte de una corriente más amplia orientada al desarrollo basado en especificaciones, donde herramientas como Kiro de Amazon o Spec Kit de GitHub comparten un planteamiento común: los documentos escritos, que reflejan la intención y las especificaciones, guían todo el trabajo. De esta forma, las políticas se implementan mediante mecanismos deterministas, como hooks, en lugar de instrucciones abiertas en prompts de inteligencia artificial, y los agentes revisan su propio trabajo antes de que otro humano intervenga para aprobarlo.
El problema es que estas herramientas a menudo exigen seguir un proceso único, con etapas fijas y artefactos predefinidos que cada cambio debe atravesar. Adoptar la herramienta implica necesariamente aceptar su procedimiento estándar, algo que no se ajusta a la diversidad de situaciones que una empresa afronta.
La realidad: una organización con múltiples procesos
En la práctica, ninguna organización se rige por un solo proceso. El camino correcto depende del riesgo y la responsabilidad asociados a cada cambio. Por ejemplo, corregir un error en la documentación, actualizar una dependencia o realizar una migración en la base de datos de un servicio de pagos representan niveles de riesgo y compromiso muy diferentes y requieren verificaciones, aprobaciones y registros diferenciados. En áreas reguladas, el proceso en sí mismo forma parte del cumplimiento y debe dejar constancia precisa de quién aprobó cada modificación y con qué evidencias.
Cuando una herramienta impone un único proceso, los equipos acaban eludiéndolo para casos que no encajan, generando invisibilidad sobre las prácticas reales o convirtiendo la herramienta en una maraña de configuraciones compleja e ininteligible. Por ello, una solución óptima no debería dictar el proceso, sino permitir que la organización defina el suyo propio.
Modelar procesos como máquinas de estados
Una forma más eficaz de gestionar los procesos es a través de máquinas de estados. Aquí, cada estado refleja un hecho comprobable sobre un cambio: que ha sido revisado, validado con sus dependencias o aprobado para producción. Estos hechos existen en sistemas variados —repositorios, integración continua, clústeres o sistemas de seguimiento— que no controla una única herramienta.
Por tanto, un proceso no es un programa secuencial sino un conjunto de reglas que reaccionan a la observación de esos hechos. Cada regla define:
- Los hechos necesarios para activarse.
- El tipo de puerta de acceso: automática o con supervisión humana.
- Los permisos que concede, como la autorización para fusionar código o desplegar en producción.
Estas reglas se almacenan como datos y se tratan con el mismo rigor que el código fuente. Así, una organización gestiona múltiples «máquinas» pequeñas que corresponden a diferentes clases de riesgo.
En ejecución, este modelo difiere de un motor de flujo tradicional: no se rastrea un «paso cuatro» porque el proceso avanza con la aparición de hechos nuevos en el sistema que los gestiona, y las reglas actúan en función de ese estado actualizado. Esto permite manejar eventos tardíos o repetidos sin complicaciones, y controlar la ejecución mediante «puertas» que pueden retrasar activaciones en situaciones como incidentes o congelaciones de lanzamientos.
La aplicación rigurosa de las puertas es crucial. Mientras que una sencilla instrucción en un prompt puede ser ignorada, un sistema que gobierna estas máquinas de estados y controla la infraestructura puede detener al agente antes de pasar a la siguiente acción hasta recibir una aprobación explícita.
El proceso se adapta al cambio
Un único proceso para todo el repositorio resulta insuficiente, porque todos los cambios seguirían una misma senda sin importar su riesgo. En cambio, el recorrido debería definirse según la clasificación que la organización haga del cambio, basada en señales como el conjunto de archivos involucrados, el repositorio o la etiqueta del ticket asociado.
Además, las definiciones de estos procesos deben poder evolucionar de forma segura. Dado que son datos, cualquier cambio en la definición sigue un proceso de gateo con aprobaciones, similar a los cambios que regulan el propio software; así, flexibilizar una puerta de aprobación requiere revisión exhaustiva, no una mera edición de configuración.
Veamos casos concretos para un mismo servicio:
- Corrección de documentación: Clasificada por rutas afectadas, su proceso simplemente exige que la compilación sea exitosa y luego se fusiona sin intervención humana.
- Actualización de dependencia: Omite revisión de diseño, pero exige pruebas de compatibilidad, como tests de integración usando las dependencias reales. En caso de un salto mayor de versión, se añade la aprobación humana.
- Migración del esquema en un servicio de pagos: Se clasifica según el componente afectado, derivando en etapas adicionales: revisión por un responsable de pagos, validación con datos en formato de producción y aprobación final de alguien responsable del dominio.
Cada transición queda registrada con la identidad del aprobador y la evidencia en la que se basó, garantizando trazabilidad absoluta.
Principios clave
- Autonomía creciente por acción y con el tiempo: Las transiciones pueden ser automáticas, requerir aprobación o estar en espera. Conforme los agentes demuestren su fiabilidad en ciertos tipos de cambio, se reducen las supervisiones humanas sin necesidad de replantear el proceso.
- Atención humana solo donde es imprescindible: La supervisión es un recurso costoso frente a agentes cada vez más económicos, por lo que las personas intervienen únicamente cuando el juicio humano realmente aporta valor y con toda la información contextual necesaria.
- La evidencia proviene de fuentes externas al agente: Nunca basta con el propio informe del agente para avanzar un cambio. Las señales válidas surgen desde sistemas externos inmutables para el agente, como resultados de tests o validaciones en entornos realistas.
- El registro del proceso es la auditoría: La definición del proceso constituye la política escrita; el historial de transiciones documenta quién aprobó qué paso, con qué pruebas y bajo qué versión de la política.
Calidad a gran escala
El enfoque de Anthropic y sus semejantes establece cimientos sólidos para el desarrollo nativo en IA, pero falta la flexibilidad indispensable para que cualquier organización defina sus procesos propios, los adapte según riesgo y los actualice de forma segura. El objetivo no es reducir la presencia humana per se, sino focalizar su criterio donde realmente se requiere, con evidencias fiables que los agentes no pueden generar sobre sí mismos, para mantener la calidad a medida que se multiplica la productividad.
En Signadot estamos implementando estas ideas y aplicándonos el cuento, sometiendo nuestro desarrollo a estos modelos para validar su eficacia. Si estás experimentando en esta dirección, estaremos encantados de compartir experiencias y avanzar juntos.
