Playbook de agentic SDLC: el build se encogió. Ahora arregla los dos lados.

Durante décadas el ciclo de vida del software se construyó alrededor de un paso lento y caro. Los agentes volvieron barato ese paso. Todo lo que se apoyaba en él se cayó.

El build se encogió. Lo que a un equipo le tomaba semanas de escribir código, a un agente le toma horas. Paso mis días de trabajo con equipos de ingeniería que están viviendo esto, y lo primero que todos esperan resulta equivocado. Nada sale diez veces más rápido. El build se volvió barato, y se rompieron los dos lados.

Este playbook trata de esos dos lados. Está escrito en el orden en que lo adoptas, así que si lo lees de arriba abajo ya tienes la secuencia: qué arreglar primero, cómo se ve cada paso en disco, cómo saber dónde estás y hasta dónde vale subir. Funciona con cualquier harness.

El build se encogió. El calendario casi ni se enteró

Guarda una pregunta en el bolsillo durante todo el artículo: si el agente escribe el código diez veces más rápido, ¿por qué la feature no sale diez veces más rápido?

Esta es la medición que me hizo tomarme la pregunta en serio. Una feature de un equipo con el que trabajo: diez tareas, trece merge requests, seis repositorios, cinco lenguajes, con pruebas y documentación. Antes de los agentes, el equipo la estimó en 10 a 15 días hábiles para cinco devs a tiempo completo. Con agentes tomó tres días hábiles y seis horas y media de trabajo humano, sumando a todos, más US$67 en tokens.

Una feature, antes y después de los agentes

• Sin agentes (estimación del equipo)
• Con agentes (medido)

Esfuerzo humano÷ 60 o más

Sin agentes (estimación del equipo): 5 devs a tiempo completo durante 10 a 15 días hábiles

Con agentes (medido): 6,5 horas, sumando a todos

Tiempo de calendario÷ 4

Sin agentes (estimación del equipo): 10 a 15 días hábiles

Con agentes (medido): 3 días hábiles

El esfuerzo humano cayó unas 60 veces. El calendario cayó unas 4. Misma feature, mismo equipo. Es una sola medición, tomada en retrospectiva, en una feature elegida porque le encajaba al agente, así que léela como un orden de magnitud y nada más fino. Pero la forma lo dice todo. El trabajo dejó de ser lo que consumía el tiempo.

Imagina una línea de producción construida alrededor de una prensa lenta. Cada estación está ajustada a su ritmo. Quienes la alimentan tienen tiempo de preparar el próximo lote. Quienes vienen después inspeccionan una pieza cada pocos minutos. El operador está junto a la prensa mientras trabaja y piensa en el próximo trabajo. Ahora pon una prensa diez veces más rápida. Quienes la alimentan no dan abasto, los inspectores se ahogan, y el operador, que descansaba mientras la máquina trabajaba, ahora está pegado a ella todo el día. La producción casi no se mueve. La línea nunca estuvo limitada solo por la prensa. Estaba ajustada a ella.

Eso es un equipo de software después de los agentes.

El build lento hacía tres trabajos que nadie escribió

Antes de los agentes, el build era el paso caro, así que todo lo que lo rodeaba existía para protegerlo. Requisitos, refinamiento, estimaciones, sprints, review: todo estaba armado para que las semanas de gente escribiendo código salieran lo más lisas posible. El cuello de botella era el build, y el build pagaba tres cosas que nadie puso jamás en un documento de proceso.

Le daba tiempo al upstream para prepararse. Mientras ingeniería pasaba dos semanas construyendo, producto tenía dos semanas para resolver lo siguiente. Un requisito vago se aclaraba en una charla de pasillo a mitad del sprint, antes de que alguien lo necesitara.

Le daba al downstream un goteo que podía absorber. Review, QA y deploy estaban dimensionados para la cantidad de código que produce la gente. Quien revisaba podía leer cada línea porque una persona había tecleado cada línea.

Le daba tiempo de pensar a quien desarrolla. Teclear era tiempo de pensar. Mientras escribías el código y estabas en las reuniones, ibas armando el contexto en la cabeza. Devs con experiencia en un rollout me contaron que ahora terminan el día más cansados que antes de usar IA. El contexto llega listo, hay mucho que filtrar, y la parte lenta en la que solían pensar desapareció.

Cuando el build se aplanó, los tres trabajos desaparecieron a la vez. Se rompieron los dos lados.

Lo que el build lento te daba gratis

El resto de este playbook es cómo construir la columna de la derecha, en orden.

El build lento te daba	Cuando se encogió	Lo que ahora construyes a propósito
Tiempo para que el upstream se preparara	Las specs llegan vagas o tarde, y el agente llena cada hueco con una suposición segura de sí misma	Contexto escrito antes del ticket: el problema, el alcance, los criterios de aceptación
Un goteo que el downstream podía absorber	Colas de review, merge requests demasiado grandes para leer, aprobaciones que no significan nada	Unidades pequeñas, checks determinísticos y review de intención y riesgo
Tiempo de pensar para quien desarrolla	El contexto llega listo, la gente termina el día agotada, y lo que aprendió muere con la ventana del chat	Tiempo de spec antes de ejecutar, sesiones con límite y work logs que guardan lo aprendido

Entonces el cuello de botella se movió. Antes era el build. Ahora está en los dos lados: contexto a la izquierda, verificación a la derecha. A la izquierda, la pregunta es si el agente sabe qué construir y bajo qué reglas. A la derecha, la pregunta es si alguien puede decir que lo que volvió está bien. Cada paso de abajo ataca uno de los dos.

Qué es en realidad un agentic SDLC

Un agentic SDLC es un ciclo de vida de software en el que cada etapa deja un artefacto versionado que la siguiente puede leer, sea una persona o un agente quien lo lea. El ticket alimenta el plan. El plan alimenta el código. Los checks juzgan el código. Lo que el ciclo te enseñó vuelve al repositorio, así que el siguiente ciclo empieza más inteligente.

Hay tres cosas distintas al ciclo de vida que conoces. Las personas dejan de revisar líneas y pasan a revisar intención y evidencia. Las reglas que una máquina puede verificar las verifica una máquina, siempre. Y el repositorio se vuelve el lugar donde todos se encuentran: producto, diseño e ingeniería escriben en él, cada uno en su idioma, y el agente lee todo.

El agentic SDLC como una cadena de artefactos

1. 01

   Upstream

   Qué construir, y por qué.

   • Un problema escrito detrás del épico
   • Un ticket con criterios de aceptación
   • Alcance visto por ingeniería

   ◆ Gate: Una persona acepta la spec

   ↓→
2. 02

   Build

   El agente escribe; el repositorio pone los límites.

   • AGENTS.md en la raíz
   • Un plan con unidades del tamaño de un review
   • Código y pruebas

   ◆ Gate: El comando único pasa

   ↓→
3. 03

   Verificar

   Las máquinas revisan lo que ya nadie lee.

   • Reglas de lint y de tipos
   • Pruebas que bloquean el merge
   • Review de intención y riesgo

   ◆ Gate: Un responsable con nombre aprueba

   ↓→
4. 04

   Entregar

   Sacar en pequeño, observar, deshacer rápido.

   • Canary con abort
   • Un rollback que ya se ejecutó
   • Un registro de lo que hizo el agente

   ◆ Gate: Release autorizado

   ↓→
5. 05

   Aprender

   Lo que el ciclo enseñó vuelve a entrar.

   • Work logs
   • Hallazgos repetidos de review se vuelven reglas
   • Los incidentes se vuelven casos de eval

   ◆ Gate: Alguien cura antes de que se vuelva verdad

Los siete pasos que siguen construyen esta cadena, en el orden que se sostiene en la práctica.

1. Prepara el repositorio para recibir trabajo

Empieza por el build, no por la spec. Es la decisión que más importa, y el instinto natural va para el otro lado.

Algunos grupos cerca del mío empezaron por el upstream. Uno de ellos automatizó primero el camino de los requisitos de producto a la spec técnica y planeó resolver el resto después. No creo en ese orden. Una spec perfecta entregada a un repositorio sin archivo de contexto, sin un comando único que pruebe que el trabajo terminó y sin pruebas que bloqueen el merge sigue produciendo mal código. El agente adivina. Quien desarrolla termina haciéndole de niñera, prompteando y pegando. El equipo concluye que la herramienta no funciona, y la culpa se la lleva la spec bonita.

Como se lo dije a un líder de ingeniería: si el build no está listo cuando el upstream acelera, te llega una avalancha de devs estresados y molestos que ya no escriben código. Le hacen de niñera al agente.

Hay una segunda razón, y tiene que ver con la confianza. Cuando el build está endurecido, la gente empieza a confiar en lo que produce el agente, porque sabe lo mucho que se martilló un merge request antes de salir. Esa confianza no la consigues con un prompt mejor.

El repositorio necesita dos cosas antes que nada. Un archivo de contexto que el agente lea siempre, y un comando que le diga que el trabajo terminó.

# AGENTS.md

## Done means

Run `make check` and paste the output. It runs lint, types, unit and
integration tests, and exits non-zero on any failure. Fix the code, not
the test.

## Conventions the linter does not cover

- Money is integer cents, never floats.
- Every new endpoint gets an integration test in tests/integration/.

## Where the why lives

- Specs and decisions: docs/specs/ and docs/adr/
- Work logs: docs/worklogs/ (unofficial notes; verify before trusting)

## Mistakes we have seen twice

- The billing client retries on 409. Stub it in tests.

Mantén AGENTS.md como fuente única y haz que cada archivo específico de herramienta apunte a él. En Claude Code, un CLAUDE.md con la única línea @AGENTS.md lo importa. Los equipos cambian de harness. Tus convenciones no deberían tener que mudarse con ellos.

2. Convierte cada regla verificable en un check que falla

Una línea en AGENTS.md es un pedido. El modelo la lee y, según cuánto más haya apilado en su contexto, puede saltársela. Un modelo es una máquina estadística. Determinístico es todo lo que no es estadístico, y ahí es donde van tus reglas siempre que puedan vivir ahí.

Entonces, cuando un hallazgo de review aparece dos veces, no debería convertirse en una línea más de Markdown. Si una máquina lo puede verificar, se vuelve una regla de lint, un tipo o una prueba, y el mensaje de error apunta a dónde está escrita la solución.

// eslint.config.js
export default [
  {
    rules: {
      "no-restricted-imports": [
        "error",
        {
          paths: [
            {
              name: "moment",
              message: "Use date-fns. Why and how: docs/conventions.md#dates",
            },
          ],
        },
      ],
    },
  },
];

Esa regla antes era una frase que el agente seguía casi siempre. Ahora se cumple en cada ejecución, y el agente solo necesita saber una cosa: corre el check, lee el error, y el error le dice dónde está la respuesta. Le quitas al modelo el trabajo de juzgar, y el modelo mejora en el trabajo que le dejaste.

Un archivo de contexto sano se achica con el tiempo. Cada regla que se puede verificar baja una capa, al linter, a los tipos o a las pruebas, y lo que queda en Markdown es criterio. El pipeline hace cumplir el resto: pruebas en rojo y secretos expuestos no entran al merge, sin importar quién o qué abrió el merge request.

3. Deja de tirar el contexto a la basura

Cada vez que alguien cierra una ventana de chat, la organización pierde lo que esa sesión aprendió. La regla que hubo que explicar a mano, el callejón sin salida que apareció, la razón para separar la migración: todo estaba en la sesión, y la sesión se fue. Ahí se fueron el token, el tiempo y el razonamiento de quien hizo el trabajo.

El contexto es el nuevo cuello de botella, y sale caro de tres maneras. Hay que capturarlo, porque casi todo vive en la cabeza de la gente. Hay que curarlo, porque lo que se escribe muchas veces está mal o se contradice. Y hay que conectarlo, porque una gran base de conocimiento que un equipo guarda para sí no se capitaliza.

La captura empieza con un work log. Al final de una unidad de trabajo, antes de limpiar la sesión, pídele al agente que extraiga lo que necesitó y no encontró, y que lo escriba en un archivo Markdown.

# Work log: invoice retry, 2026-09-18

## Context I had to add by hand

- Invoices to public-sector customers must not retry on weekends.
  The rule is not written anywhere; finance confirmed it in chat.
- The email provider returns 202 before validating the address.

## Decisions taken in the session

- Moved the migration to its own merge request to keep review small.

## Promote?

- [ ] Weekend rule to docs/specs/invoicing.md (ask finance to sign off)
- [ ] Provider behavior to AGENTS.md, under mistakes seen twice

Un work log no es documentación. Es materia prima. La curaduría decide qué se promueve a la spec, al archivo de contexto o a un check, y es un trabajo paciente y sin brillo: etiqueta lo que sabes como verde, amarillo o rojo según cuánto confías en ello, y nunca dejes que una nota roja se vuelva la verdad sobre la que construye un agente.

Lo que está en juego es más de lo que parece. En un rollout, la mitad de una regla de negocio vivía en la cabeza de una persona de producto y la otra mitad en la de una persona de gestión de ingeniería, y no estaba escrita en ningún lado. En sistemas más viejos sigo escuchando la misma queja: nadie se atreve a cambiar una regla, porque un día alguien tuvo una razón para ella, y hoy nadie sabe dónde quedó esa razón. La deuda técnica muchas veces es exactamente eso, una decisión cuyo porqué nunca se escribió. La wiki, cuando existe, cuenta quizás una décima parte de cómo pasó la historia de verdad.

Cada ciclo que alimenta el repositorio abarata el siguiente. Esa es la parte acumulativa de un agentic SDLC, y es la parte que un build lento nunca obligó a nadie a construir.

4. Mueve la spec antes de la ejecución

Me senté con una persona desarrolladora que hacía lo que hace casi todo el mundo en los primeros meses con agentes. Leyó el requisito de producto, leyó el ticket y empezó a promptear, completando los detalles que faltaban a medida que el agente preguntaba o fallaba. Eso es especificar en tiempo de ejecución. Se siente como productividad. Es la señal más clara de un equipo trabado entre el nivel 2 y el nivel 3.

El agente cambió la economía de un ticket vago. Un dev con una tarea vaga se traba, se levanta y pregunta, y esa pregunta era una revisión de spec gratis que nadie contaba. El agente nunca se traba. Llena el hueco con una suposición y entrega tan rápido que nadie ve la suposición hasta que aparece dentro de un diff demasiado grande para leer. El modelo va a satisfacer cualquier spec, buena o mala.

Esto no requiere un formato nuevo. Un ticket con problema, alcance y criterios de aceptación ya es el artefacto que el agente necesita leer. Lo que cambia es quién lo lee: ahora lo escribes también para la máquina.

# Show why an invoice failed to send

## Problem

Customers open support tickets to ask why an invoice never arrived.
Written problem: docs/problems/invoice-visibility.md

## Scope

- Billing page, read-only. Out of scope: resending.

## Acceptance criteria

- An invoice that failed shows the reason and the last attempt time.
- An invoice that was delivered shows no badge.
- `make check` passes, with one integration test per criterion.

## Context

- Failure reasons: docs/specs/invoicing.md#failures
- Design: link to the approved mock

Dos cosas tienen que ser ciertas antes de que exista un ticket así. El épico apunta a un problema escrito: qué es, a quién afecta y cómo vas a saber que funcionó. E ingeniería vio el alcance antes de que se escribiera el ticket, porque ahí es donde se hacen las preguntas baratas.

El flujo también corre hacia atrás. Si no tomas lo que aprendió el build y se lo das al próximo requisito, empujas el problema a la izquierda, y el próximo requisito de producto sale roto. Los work logs del paso 3 son la forma en que el build le habla de vuelta al upstream.

5. Cambia lo que llega al review

Volvamos a la pregunta del principio. El tiempo que ahorró el agente no desapareció. La mayor parte se mudó al review. Los devs de los equipos que adoptan agentes se quejan de eso primero: la cantidad de merge requests que tienen que leer no para de crecer, y la cola es ahora el paso más lento.

Revisar más rápido no lo arregla. Una aprobación obligatoria por merge request, prometida dentro del día, se dimensionó para la cantidad de código que produce la gente. Multiplica los merge requests y o se rompe la promesa o la aprobación deja de significar algo. Leer cada línea tenía sentido cuando una persona escribía cada línea. No le sigue el ritmo a un agente.

Arregla lo que llega. Limita el tamaño de una unidad de trabajo cuando se aprueba el plan, antes de que exista el código, para que alguien pueda leer el resultado de una sentada: separa por endpoint, dale a la migración de base de datos su propio merge request. Después cambia lo que mira quien revisa. El paso 2 ya bloquea los problemas mecánicos, así que el review puede ser sobre intención y riesgo: ¿esto hace lo que el ticket quería decir, y qué se rompe si está mal? Ponle a cada comentario su peso, blocking, major o minor, para que el autor sepa cuáles frenan el merge. Escribí cómo un equipo salió del atasco de review en por qué AI-DLC te hace más lento primero.

Quien revisa es la parte más escasa del sistema, y la más frágil. En un rollout que acompañé, la gente aprobaba documentos después de sesiones largas, ya sin capacidad para leerlos, y alrededor de una hora por sesión resultó ser el límite práctico. La falla opuesta es más silenciosa. El décimo artefacto que produjo el agente se aprueba con menos cuidado que el primero, porque los nueve anteriores se veían bien, y quien revisa simplemente aprieta el botón. Un gate que pasa una persona cansada o demasiado confiada es un sello de goma. Los gates son una función de pérdida cubre las cuatro formas en que fallan.

6. Pon el gate humano donde está el trabajo

Hay dos tipos de gate humano. Un gate de review viene después del trabajo: está hecho, una persona lo valida antes del merge. Un gate de inicio viene antes: nada arranca porque la única persona que podría revisarlo está ocupada. El segundo es circular. Nada arranca porque no hay quien revise, y no hay nada que revisar porque nada arrancó.

Estuve en una reunión sobre un equipo que tenía el requisito de producto escrito, un trabajo autocontenido y un repositorio con sus contratos mapeados, y nada se movía, porque la persona de ingeniería que lo iba a revisar estaba asignada a otra cosa. Alguien en la sala dijo que habían armado el auto y seguían caminando.

El agente trabaja de forma asíncrona. Deja que el gate humano viaje con el trabajo en vez de pararse delante de él. Un equipo con el que trabajo dibujó su tablero así.

Un tablero donde la persona aparece dos veces

Entrada

Un problema escrito con alcance

↓

1. personaSpec

   Un dev valida el ticket y sus criterios de aceptación antes de que corra cualquier agente.

   ↓
2. colaListo para el agente

   Cualquiera lo puede arrastrar aquí. El agente lee la columna y el ticket.

   ↓
3. agenteEn progreso

   El agente planifica, implementa y corre el comando único hasta que pasa.

   ↓
4. personaReview

   Un responsable con nombre revisa intención y riesgo. Los comentarios en el ticket vuelven al agente.

   ↓
5. aprenderHecho

   Mergeado, y el work log queda archivado para curar.

↓

Salida

El trabajo del agente y el de las personas corren en paralelo en lugar de en secuencia

El sprint carga el mismo supuesto escondido que el gate de inicio. Dos semanas tenían sentido cuando la entrega estaba limitada por lo rápido que teclea la gente: juntas el trabajo en un paquete coherente. Cuando el código toma horas, esperar dos semanas para empezar algo nuevo cuesta más que hacerlo. Acortar el sprint no lo arregla, porque su duración nunca fue el problema. Meter al agente en las ceremonias que ya tienes tampoco. Eso automatiza la fábrica en vez de rediseñarla, y automatizar un flujo que todavía no funciona solo acelera el cuello de botella.

7. Gánate el loop

El último tramo es la entrega y el loop cerrado, y va al final por una razón: cada paso anterior es lo que lo vuelve seguro.

La entrega tiene que ser aburrida antes de que un agente se le acerque. Cualquier persona del equipo levanta el mismo entorno con un comando. Cada cambio sale detrás de un canary con abort. Y el rollback ya se ejecutó de verdad, hace poco, por alguien del equipo. Sin eso, cada cambio autónomo es todo o nada en producción.

Después al agente se lo evalúa como a alguien que nunca deja de aprender: con una suite. Junta veinte o más tareas reales de tu propio historial, cada una con el resultado que aceptaste, y córrelas en CI cada vez que cambie un prompt, una skill o el modelo. Cada incidente se vuelve un caso nuevo. Sin evals, “autónomo” significa “no verificado”, y el proyecto se queda en el nivel 3 por bueno que sea el modelo.

Corre el agente en un sandbox con credenciales acotadas, guarda un registro de los comandos que ejecutó y dale a cada equipo un presupuesto de tokens visible. Sin sandbox, un error se vuelve un incidente. Sin registro ni presupuesto, las fallas son silenciosas y la factura es una sorpresa.

Recién ahí cierra el loop. Un script determinístico observa producción. Cuando una métrica se sale de su rango normal, llama al agente, el agente diagnostica y escribe el próximo ticket, y una persona lo prioriza. La detección sigue siendo determinística y el modelo hace la parte que necesita un modelo, que es la misma división que recorre todo el playbook. También es la misma división que hace funcionar a AI-DLC 2: el motor enruta, el modelo ejecuta.

La escalera no tiene atajos

Esos siete pasos se mapean en una escalera de autonomía. Define cada nivel por lo que asume el agente, lo que queda con la persona y quién hace la verificación. La mía está adaptada de un framework interno, y los niveles te van a sonar si viste alguno de los públicos.

La escalera agéntica

1. L1

   Asistido

   "El agente escribe borradores y completa. El dev escribe y decide todo."

   → Verificado por ojos humanos

2. L2

   Supervisado

   "El agente cambia archivos cuando se le pide. Una persona revisa cada diff."

   → Verificado por ojos humanos, con apoyo de pruebas

3. L3

   Pull request

   "El agente toma una tarea completa, edita varios archivos y abre el pull request. Una persona revisa el pull request."

   → Verificado por pruebas en capas y CI

4. L4

   Autónomo

   "El agente planifica, implementa, se evalúa y entrega detrás de un gate de aprobación. Una persona aprueba en el gate."

   → Verificado por un gate de evals

5. L5

   Totalmente agéntico

   "De la spec a producción, volviendo a entrar al loop por su cuenta. La persona define la intención y está de guardia."

   → Verificado por evals autónomos

El salto que importa es de L2 a L4. Ahí el trabajo pasa de operar a juzgar, de mover las manos a declarar la intención. En L2 el agente es un autocompletado mejor. En L3 le das una tarea como se la darías a un colega. Un modelo mejor no produce ese salto.

No puedes saltarte peldaños. Un equipo en L2 que se fuerza hasta L5 sin pruebas en capas, sin contexto en el repositorio y sin escribir specs tiene casi un cien por ciento de probabilidad de que algo salga muy mal, porque lo que está haciendo en realidad es vibe coding a escala. Un nivel solo se sostiene cuando la automatización es lo bastante confiable como para asumir la supervisión que la persona dejó de hacer. Subir sin eso es ausencia de control.

Cuidado también con la meseta. Los equipos que todavía promptean están entre L2 y L3, y el riesgo es que se acostumbren. Promptear se siente como progreso. Es el paso antes del paso.

Dos cosas más sobre la escalera. Un puntaje describe preparación, no práctica: un repositorio en L3 está listo para recibir trabajo agéntico, lo que no significa que el equipo lo esté haciendo. Y la escalera corre en tres carriles. Los repositorios son infraestructura, los equipos de desarrollo son el downstream, los equipos de negocio son el upstream, y cada uno tiene su propio L1 a L5.

Tu techo es tu línea más débil

Para saber dónde está un proyecto, puntúalo. Estas son las once líneas que les pido a los equipos que puntúen, cada una atada al nivel que destraba. Cada línea recibe de 0 a 3: 0 ausente, 1 ad hoc, 2 establecido, 3 automatizado y obligatorio. Hazlo con todo el equipo, en una retro, y repítelo cada ciclo. Casi todo se puede leer directo del repositorio; les doy a los equipos una skill que lee el repo y propone el puntaje, y el equipo lo corrige.

Once líneas para puntuar, de 0 a 3

Puntúa el proyecto, no el equipo: un servicio en el camino crítico y un experimento descartable son dos proyectos con dos puntajes.

Línea (nivel que destraba)	Cómo se ve un 2
AGENTS.md en la raíz del repo (L2)	En los repos principales, con comandos y convenciones, tocado en este ciclo, apuntando a la spec cuando vive en otro lado
Un comando que corre todo (L2)	Un lugar que el agente lee declara todo lo que tiene que pasar antes del merge, y cada check sale con código distinto de cero si falla
Criterios de aceptación en el ticket (L3)	El ticket lleva un criterio verificable antes de que alguien arranque el agente
Pruebas automatizadas (L3)	Unitarias, de integración y end-to-end, con el pipeline bloqueando el merge ante una prueba en rojo o un secreto expuesto
Setup del agente versionado (L3)	Skills, hooks y el punto donde el agente se detiene a pedir aprobación viven en el repo, y corren igual en cualquier harness
Acoplamiento de deploy (L3)	Puedes hacer merge y deploy de una parte sin sacar otra, y el contrato entre ellas está versionado
Disciplina de review (L3)	Los reviews usan prefijos de severidad y miran intención y riesgo, no formato
Entorno y entrega (L4)	Cualquiera levanta el mismo entorno, el canary tiene abort y el rollback ya se ejecutó de verdad
Eval harness (L4)	Una suite de 20+ tareas reales corre en CI con resultados esperados versionados
Sandbox y registro (L4)	El agente corre en sandbox, con secret scanning, costo visible por equipo y un registro de los comandos que ejecutó
Convenciones en el linter (L4)	Las convenciones que más aparecen en review son reglas de lint, y el mensaje de error dice dónde está escrita la solución

Después aplica la única regla que cambia la conversación.

Un barril hecho de duelas de madera retiene agua hasta la altura de su duela más corta. Haz más altas las otras duelas y habrás construido un barril más alto que retiene exactamente la misma agua.

En un proyecto ilustrativo, tres servicios y siete personas, con la forma de los que veo: las pruebas sacan 3, con unitarias, de integración y end-to-end bloqueando el merge. La entrega saca 3, con canary por defecto y un rollback ejecutado en el último incidente. El equipo se ve en L3. Su techo es L1, decidido por una sola línea: AGENTS.md existe en uno de los tres repositorios, tocado por última vez hace cinco meses. Sin contexto en el repositorio el agente trabaja por suposición, y una buena cobertura no lo compensa.

La percepción sigue a la mejor herramienta. El techo sigue a la que está trabada. Los números más llamativos de ese puntaje son los ceros del gate de L4, tres niveles más arriba. La tarea efectiva es la más barata: un archivo de contexto en tres repositorios, que por sí solo lleva el proyecto de L1 a L2.

Sube solo hasta donde te permite el costo del error

El mismo puntaje aplica para todos. Lo que cambia es hasta dónde vale la pena subir, y eso lo decide el costo de un error. Cada proyecto es un equilibrio entre contexto de un lado y velocidad, seguridad y confiabilidad del otro.

Nivel objetivo según el costo del error

Lo que mantiene a salvo a un trasatlántico hundiría una moto de agua.

Perfil	Qué es	Un error cuesta	Objetivo
Plataforma core	Camino crítico, profundidad técnica, muchos consumidores	Un incidente en producción	L5
Producto base	De cara a clientes y partners, sólido, menos profundo que una plataforma	Una regresión recuperable	L3
Experimento	Una o dos personas, mucha incertidumbre, una hipótesis descartable	Tirarlo y rehacerlo	L2

El valor de un experimento es la velocidad, así que se puede permitir más errores que una plataforma. Pero el tamaño no hace que un proyecto sea un experimento. Lo hace el radio de daño. Dos personas trabajando con dinero, datos personales o el camino del checkout no son un experimento, por chico que sea el equipo.

Cruza el techo con el objetivo. Debajo del objetivo, la brecha es tu roadmap. En el objetivo, deja de gastar en harness ahí y pon el esfuerzo en la entrega. Por encima del objetivo, construiste lo que no necesitabas, lo que casi siempre significa que el perfil estaba mal clasificado. Invierte en la línea más débil debajo del objetivo, y solo en esa. Un experimento trabado en L1 no necesita un eval harness. Necesita un archivo de contexto.

El repositorio se vuelve la sala de reuniones

El cambio más grande que vi no está en el código. Cuando generar código cuesta casi nada, la disciplina de la que vienes deja de ser lo que organiza el trabajo. La entrega común es siempre un repositorio, y ahora todos escriben en él en su propio idioma: producto escribe el problema, diseño escribe el mock y las reglas detrás, ingeniería escribe la arquitectura y los checks. El agente lee todo. Las organizaciones armadas como cajas de especialistas van a tener que asumir trabajo multidisciplinario, lo planeen o no.

El trabajo de ingeniería sube un nivel de abstracción, igual que cuando dejamos de manejar registros a mano. Menos teclear, más dar contexto, diseñar arquitectura, integrar sistemas y decidir qué vale la pena construir. Medio en broma, les digo a los devs que el futuro de programar es escribir archivos Markdown. Es solo medio en broma.

Ese cambio tiene un costo, y alguien tiene que gestionarlo. El tiempo de pensar que el build lento les daba a los devs ahora hay que agendarlo a propósito, como tiempo de spec antes de ejecutar. Las sesiones necesitan un límite. Lo que funcionó en el rollout que acompañé fue un manager que se sentó en las primeras sesiones, calibró el ritmo y evitó que las aprobaciones se volvieran automáticas. Sin alguien cerca cuidándolo, cada gate se vuelve un trámite.

Y no toda tarea debería ir al agente. Cuando el cuello de botella es conocimiento que ya está en la cabeza de quien hace el trabajo, no hay nada que el agente pueda destrabar, y describir la solución cuesta más que escribirla. Un ensayo aleatorizado de METR encontró que devs con experiencia, trabajando en código que conocían bien, eran más lentos con IA mientras creían ser más rápidos. La inversión es contexto y verificación. Esperar a que el próximo modelo lo resuelva no lo es.

Mide lo que se encogió y lo que no

El costo de la IA se mide solo. Tu factura de tokens llega todos los meses sin que nadie la pida. El retorno no. Cuando un lado del libro se llena solo y el otro necesita que alguien lo llene, cada conversación de presupuesto se tiene con la mitad de los números.

Mide el costo de entregar una feature contra lo que el equipo habría gastado sin el agente. Esa es la medición del principio de este playbook, y así sale cada número.

Cómo reproducir la medición de una feature

El número	Quién responde	De dónde sale
Tamaño de la feature, en la escala del propio equipo	Tech Lead, manager o el equipo en una retro. Nunca el agente	Tu tracker
Personas y tiempo que el equipo necesitaría sin el agente	Derivado del historial; el equipo confirma o corrige	Épicos cerrados antes de que llegara el agente
Tiempo de calendario hasta el merge	Nadie	Tracker y host de git
Horas humanas, por persona	Quienes hicieron el trabajo	Solo preguntando
Costo de tokens	Nadie	El export de uso de tu proveedor

Nunca dejes que el agente dimensione su propio trabajo. En una feature, el agente estimó más del doble de los puntos que la persona responsable del proyecto creía que valía. Saca el contrafáctico del historial: cuántos puntos gasta el equipo en cada tipo de trabajo ya está en los épicos cerrados. Usa una ventana anterior al agente, o la base llega desinflada y la ganancia parece menor de lo que es.

Una línea se resiste a la automatización. Las horas humanas no se deducen del calendario. En la medición de arriba, deducirlas dio dos devs a medio tiempo durante tres días, contra seis horas y media trabajadas de verdad: un factor de ocho, directo al denominador. Pregúntale a la gente, el día que cierra el épico, mientras todavía se acuerda.

Líneas de código, commits y merge requests eran proxies razonables mientras escribir código dominaba el costo del ciclo. Con un agente crecen sin ningún cambio equivalente en el resultado. La guía de qué medir en AI-DLC tiene las cuatro métricas que yo pondría en el dashboard en su lugar.

Cada proceso que agregas necesita fecha de retiro

Puntúa antes de prescribir. Un tablero, un rol o una etapa nueva es una prescripción, y las prescripciones vienen después del diagnóstico. Un proceso creado para encontrar dónde se traba el trabajo es un instrumento, y un instrumento tiene fecha de retiro. Un proceso creado para quedarse, en un proyecto cuyo techo todavía es L1 o L2, se vuelve el techo: lo que no se puede automatizar termina definiendo hasta dónde sube el equipo.

Escribe la fecha de retiro al lado del proceso el día que lo creas. “Revisamos cada spec en mob hasta que los criterios de aceptación dejen de volver mal” es un instrumento. “Revisamos cada spec en mob” es una ceremonia, y las ceremonias sobreviven al problema para el que se crearon.

El playbook en una página

El agentic SDLC, en el orden en que lo adoptas

• ✓Obligatorio:
  Dale a cada repositorio un AGENTS.md y un comando que pruebe que terminó.Los archivos de cada herramienta apuntan a él. Esto solo sube un nivel completo a la mayoría de los proyectos.
• ✓Obligatorio:
  Pasa cada regla que una máquina pueda verificar a un check que falla.Lint, tipos, pruebas. Pruebas en rojo y secretos expuestos nunca entran al merge. El archivo de contexto se achica.
• ✓Obligatorio:
  Lleva un work log por cada unidad de trabajo, y cúralo.Captura lo que aprendió la sesión antes de limpiarla. Promueve lo que te da confianza.
• ✓Obligatorio:
  Escribe la spec antes de que corra el agente, no durante.Un problema escrito detrás del épico, criterios de aceptación en el ticket, ingeniería en el alcance.
• ✓Obligatorio:
  Dimensiona las unidades para el review en el plan, y revisa intención y riesgo.Limita las sesiones, pon peso a cada comentario, cuidado con la décima aprobación fácil.
• ✓Obligatorio:
  Deja que el gate humano viaje con el trabajo.Personas en la spec y en el review. El agente trabaja en el medio, en paralelo.
• ✓Obligatorio:
  Gánate el loop: entrega aburrida, evals, sandbox, registro.Después deja que una detección determinística llame al agente, y que una persona priorice.
• ✓Obligatorio:
  Puntúa las once líneas cada ciclo y ataca la más débil debajo del objetivo.El gate más débil es el techo. El objetivo sale del costo de un error.
• ✗Anti-pattern:
  Empujar la spec al agente y saltarse el puntaje.Así es como un equipo termina prompteando en tiempo de ejecución y culpando a la herramienta.

El build se encogió. Esa parte está hecha, y era la fácil. El agente volvió barato el código. No volvió barato el criterio, ni volvió barato el contexto. Constrúyelos a propósito, en este orden, y el calendario también empieza a moverse.

FAQ

¿Qué es un agentic SDLC?+

Es el ciclo de vida del desarrollo de software rehecho para un mundo donde los agentes de IA escriben la mayor parte del código. Cada etapa deja un artefacto versionado que la siguiente puede leer, las personas revisan intención y evidencia en lugar de cada línea, las reglas verificables por máquina las hace cumplir una máquina, y lo que aprende cada ciclo vuelve al repositorio. También lo vas a ver como AI-native SDLC o AI SDLC.

Si nuestros agentes escriben código más rápido, ¿por qué no bajó nuestro lead time?+

Porque el build era solo una parte de tu lead time, y el resto del ciclo estaba ajustado a que fuera lento. Cuando el build se encogió, el trabajo se mudó a los dos lados: contexto a la izquierda, review y verificación a la derecha. Hasta que reconstruyas esos dos lados, el calendario casi no se mueve.

¿Por dónde debería empezar un equipo?+

Por el repositorio, no por los requisitos de producto. Un AGENTS.md en la raíz y un comando que corra todo lo que tiene que pasar antes del merge. Las specs mejores rinden recién cuando el repositorio puede recibir trabajo; antes de eso producen código equivocado y seguro de sí mismo, y devs frustrados.

¿Cómo se relaciona el agentic SDLC con AI-DLC y Spec-Driven Development?+

AI-DLC es el método de AWS para el mismo cambio, con su propio vocabulario y un motor que lo ejecuta. Spec-Driven Development es la práctica de escribir la spec antes de que corra el agente, que es el paso 4 de este playbook. Este playbook es el orden y el techo que aplican a cualquiera de ellos.

¿Todo equipo necesita llegar a la autonomía total?+

No. Define el objetivo según el costo de un error. Un experimento descartable se detiene en L2, un producto de cara al cliente en L3, una plataforma core en el camino crítico apunta a L5. Gastar en harness por encima de tu objetivo no compra nada.

¿Cómo mido el ROI de los agentes de IA para programar?+

Mide el costo de entregar una feature contra lo que el equipo habría gastado sin el agente. Saca el contrafáctico de épicos cerrados antes del agente, pregúntale a la gente sus horas reales cuando cierra el épico y suma la factura de tokens. La respuesta es un orden de magnitud, que es lo que necesita una decisión de presupuesto.