De IA suelta a desarrollo agéntico: cómo adoptamos SDD en un equipo de YPF

Cuando me sumé a un equipo de desarrollo de YPF, la IA ya era parte del trabajo diario: todos la usábamos, pero cada persona con su propio criterio, sus propios prompts y resultados difíciles de comparar. Propuse adoptar SDD (Spec-Driven Development) como marco común y lo fuimos implementando junto con el equipo. En este artículo cuento cómo fue ese proceso: de qué situación partimos, qué pasos dimos y qué cambió en nuestra forma de trabajar. No incluye código ni información interna de YPF, pero sí el detalle de proceso necesario para que pueda servirle a otros equipos en una situación parecida.

El problema: IA suelta, sin proceso

Antes de SDD, la situación era la típica de un equipo que adoptó IA generativa de forma orgánica: cada developer tenía su propio flujo con Copilot, ChatGPT, Claude o el asistente de turno. Algunos pegaban prompts gigantes en el chat, otros dejaban que el agente tocara medio repo sin revisión, otros ni lo usaban para nada crítico por desconfianza.

Los síntomas eran claros:

Sin documentación del "por qué". El código cambiaba, pero no quedaba registro de qué se decidió y por qué. Cuando alguien volvía a tocar esa parte tres semanas después, tenía que reconstruir el contexto de cero.
Sin medición de costos. Nadie sabía cuánto se estaba gastando en tokens, ni si ese gasto se traducía en velocidad real o en más retrabajo.
Calidad dispar. Un PR generado con IA podía estar impecable o podía traer una regresión silenciosa, dependiendo de qué tan buen prompt había escrito esa persona ese día.
Poca trazabilidad entre equipos. Backoffice de operaciones, dispersión de fondos y catálogo de plataforma —los tres frentes donde después incorporamos SDD— vivían con sus propias convenciones informales, sin un estándar compartido.

En resumen: la IA estaba generando valor, pero también entropía. Y la entropía en un equipo de ingeniería, tarde o temprano, se paga con incidentes o con deuda técnica invisible.

La propuesta: Spec-Driven Development como proceso

SDD no es "escribir un documento antes de codear". Es un proceso donde la especificación es la fuente de verdad, el ciclo de trabajo está definido y los agentes de IA operan dentro de roles específicos, con gates que impiden avanzar si algo no está listo.

En la práctica, esto se traduce en tres piezas:

Specs. Cada cambio relevante arranca con una spec: qué problema resuelve, qué alcance tiene, qué criterios de aceptación aplican. No es burocracia porque la spec es corta y vive en el repo, versionada junto al código. Es el contrato entre lo que se pidió y lo que se construye.

Ciclos. El trabajo se organiza en ciclos con etapas claras —diseño, implementación, validación— y cada etapa tiene una salida concreta que la siguiente puede consumir. Esto le da a la IA un contexto acotado en lugar de "todo el repo a la vez".

Agentes por rol. En lugar de un agente genérico que hace de todo, definimos agentes con responsabilidades específicas: uno que ayuda a redactar y refinar la spec, otro que implementa dentro del alcance definido, otro que revisa contra los criterios de aceptación, otro que documenta. Cada rol tiene su propio contexto y sus propias restricciones.

Y acá viene la parte que más cambió el comportamiento del equipo: los gates. Un gate es un punto de control que frena el flujo si algo no cumple una condición mínima —una spec incompleta, criterios de aceptación ambiguos, falta de revisión— y no deja avanzar a la siguiente etapa hasta que se resuelve. No es un "por favor revisá esto", es un bloqueo real en el flujo de trabajo. Eso nos ayudó a reducir la variabilidad: el resultado ya no dependía de la disciplina individual de cada persona, sino del proceso.

Flows full, reduced y lite: no todo cambio pesa igual

Uno de los errores más comunes al adoptar SDD es aplicar el mismo rigor a un cambio de una línea que a una funcionalidad nueva de punta a punta. Eso complica la adopción rápido, porque el equipo empieza a sentir que el proceso es más pesado que el problema que resuelve.

Por eso trabajamos con tres flows según el tamaño del cambio:

Full: para features nuevas o cambios con impacto transversal. Ciclo completo, spec detallada, todos los agentes por rol, todos los gates.
Reduced: para cambios de alcance medio, donde el riesgo existe pero es acotado. Spec más liviana, menos etapas, gates críticos igual activos.
Lite: para fixes chicos, ajustes puntuales, tareas de bajo riesgo. Spec mínima, ciclo corto, gates justos para no perder trazabilidad sin frenar la velocidad.

Esta segmentación fue clave para que SDD no se sintiera como una capa burocrática impuesta desde arriba, sino como un proceso que se adapta al tamaño real del problema.

Varios devs, mismo repo: IDs por autor y contexto aditivo

Otro desafío concreto: cuando varios developers trabajan en paralelo sobre el mismo repositorio usando agentes, el contexto se puede pisar. Si dos personas están en ciclos distintos y el agente de una arrastra contexto de la otra, aparecen respuestas contaminadas y decisiones que no corresponden a esa rama de trabajo.

La solución que implementamos fue simple: IDs por autor. Cada developer tiene su propio identificador de contexto, así el agente sabe de qué ciclo y de qué spec está hablando en cada momento, sin mezclar sesiones de trabajo distintas.

Sobre eso, usamos fragmentos aditivos de contexto: en lugar de reescribir todo el contexto cada vez que algo cambia, se van agregando fragmentos incrementales que documentan decisiones y avances. Esto evita dos problemas típicos: perder historial (si se sobrescribe todo) y sobrecargar al agente (si se le manda el historial completo en cada interacción). El agente consume solo los fragmentos relevantes para la etapa en la que está.

Dónde lo aplicamos en YPF

Implementamos SDD en tres frentes con distinto nivel de exigencia, según el riesgo y la madurez de cada equipo:

Backoffice de operaciones: ahí SDD es obligatorio. Es un dominio donde los errores tienen costo alto y la trazabilidad de decisiones es fundamental, así que no dejamos margen para trabajar por fuera del proceso.
Dispersión de fondos: aplicamos agentes por rol de forma estricta, dado que es un dominio sensible donde cada etapa —diseño, implementación, revisión— necesita un agente especializado y acotado a su función, sin superposición de responsabilidades.
Catálogo de plataforma: un dominio con menor riesgo relativo, donde pudimos iterar más rápido y usar los flows reduced y lite con más libertad, validando el proceso antes de llevarlo a los frentes más críticos.

Esta combinación —obligatoriedad donde el riesgo lo exige, flexibilidad de flow donde no— ayudó a que la adopción no se sintiera como una imposición uniforme, sino como un proceso calibrado a la realidad de cada equipo.

SDD-Harness: la herramienta detrás del proceso

Para que todo esto no quedara en metodología abstracta, usamos SDD-Harness, un proyecto open source que publiqué en npm (versión actual 0.15.1). Incluye 8 agentes especializados por rol y 19 skills que cubren las distintas etapas del ciclo: desde la redacción de specs hasta la validación contra criterios de aceptación. Es la capa que operacionaliza specs, ciclos, gates y flows sin que cada equipo tenga que reinventar la rueda.

Al ser open source, cualquier equipo puede instalarlo, adaptarlo a su propio dominio y empezar a medir resultados sin depender de una plataforma cerrada.

Cómo arrancar: diagnóstico, piloto y extensión

Para equipos que estén en la posición en que estábamos antes de esto —IA suelta, sin proceso, sin visibilidad de costos—, la secuencia que mejor nos funcionó fue:

Diagnóstico. Antes de tocar nada, entender cómo usa IA cada persona hoy: qué herramientas, qué tipo de tareas, qué nivel de revisión existe. Sin este paso, cualquier proceso que se proponga va a chocar con hábitos invisibles.
Piloto en un repo. Elegir un dominio acotado, no el más crítico ni el más trivial, y correr SDD ahí primero. Definir specs, ciclos, agentes por rol y el flow correspondiente (full, reduced o lite según el tamaño de los cambios que se hacen en ese repo).
Extensión. Con resultados del piloto —velocidad, calidad, trazabilidad— extender a otros repos, calibrando la obligatoriedad y el rigor según el riesgo de cada dominio, tal como hicimos entre backoffice de operaciones, dispersión de fondos y catálogo de plataforma.

No hace falta convertir todo el equipo de un día para el otro. Lo importante es que el proceso exista, que sea medible y que los gates frenen de verdad lo que no está listo.

Qué me llevo

Los gates reducen la variabilidad mejor que pedirle disciplina a cada persona: el proceso sostiene lo que el criterio individual no alcanza.
El rigor tiene que ser proporcional al cambio; un solo nivel de exigencia para todo hace que el equipo lo abandone.
Empezar con un piloto en un dominio acotado permite validar el proceso antes de llevarlo a donde el riesgo es mayor.
Con varios developers en el mismo repo, separar el contexto por autor y registrarlo de forma aditiva evita que los agentes mezclen decisiones.
Adoptar un marco común es, sobre todo, un trabajo de equipo: se ajusta en el camino y no se impone de un día para el otro.

Cierre

Pasar de "cada uno usa la IA a su manera" a un proceso con specs, ciclos, agentes por rol y gates cambió cómo documentamos, cómo medimos y cuánto confiamos en lo que la IA produce. Si estás trabajando en algo parecido o tu equipo está evaluando cómo incorporar IA, me interesa intercambiar experiencias: podés escribirme por LinkedIn. Si te sirve como referencia, en mi web cuento cómo acompaño a equipos en este tipo de adopción: Adopción de SDD agéntica.