N-TECH · SDD + Sistema Multiagente · Alta exigencia
El 70% de código generado
con IA no es el techo.
Es el piso donde el sistema
empieza a mostrar su valor real.
En un equipo de 8 devs backend sobre microservicios hexagonales en Go llegamos ahí con vibe coding. Sin especificación formal. Con ciclos de corrección que consumían el tiempo que la IA supuestamente ahorraba. SDD invierte el orden: primero la spec, después el código. Eso es lo que lleva el porcentaje del 70% al 90%+ sin acumular la deuda técnica que hace colapsar el primer número.
≥70% mínimo · 90%+ objetivouptime 99%+<200ms p99100k+ RPMcoverage 95%+SDD cierra la brechaCursor · Windsurf · Claude · GeminiAgnóstico al lenguaje y al stackHexagonal · Clean Arch · Design Patterns
// Agente Analista — spec generada
SPEC PaymentUseCase.ProcessRefund
domain : payments.core
pattern : hexagonal · repository
coverage: ≥90% unit + integration
perf : p99 <150ms · 100k RPM
security: OWASP · injection-free
// Agente Ejecutor — generando código
func (uc *PaymentUseCase) ProcessRefund(
ctx context.Context,
req RefundRequest,
) (*RefundResponse, error) {
// Agente QA — validando
✓ hexagonal boundaries · OK
✓ unit coverage 94% · OK
✓ no SQL injection vectors · OK
✓ p99 benchmark 142ms · OK
✓ PR ready · spec compliant
70% → 90%+
código IA. El 70% es el punto de partida donde el sistema empieza a diferenciarse del vibe coding.
95%+
cobertura de tests. Validada por el agente QA antes de cada PR, no después del incidente.
<200ms p99
de respuesta sostenible. Definido como criterio de aceptación en la spec, no como meta de producción.
6 semanas
de 0 a sistema operativo. Con acompañamiento semanal y entregable al cierre de cada semana.
el problema real
La IA genera código rápido.
El sistema sin estructura lo rompe igual.
La mayoría de los equipos que no llegan al 70% no tienen un problema de herramientas. Tienen un problema de sistema: usan la IA como un autocomplete glorificado en lugar de como un ejecutor de especificaciones precisas. Y los que sí llegan al porcentaje mínimo acumulan deuda técnica que explota en producción. El 90% es posible cuando el sistema que rodea a la IA está diseñado para eso desde el principio.
Sin SDD — patrón que falla modo actual
El dev pide código sin specLa IA genera algo que funciona en el happy path. Las edge cases, los contratos de la arquitectura hexagonal y los patrones de la base de código quedan a interpretación del modelo.
El reviewer rechaza el PRLa capa de dominio filtra hacia la infraestructura. No hay unit tests con cobertura adecuada. El naming no sigue la convención del repositorio. Vuelta a fojas cero.
Lo que llega a producción introduce latenciaUna query sin índice. Una llamada síncrona que debía ser async. Un retry sin backoff exponencial. La plataforma de observabilidad lo detecta. El incidente se abre. El equipo pierde el sprint.
La métrica de IA no subeEl dev deja de usar IA para tareas complejas porque el rechazo tiene costo. El porcentaje se estanca en 30-40%. La exigencia persiste.
Con SDD + Multiagente — patrón que funciona objetivo
El agente de especificación genera la spec antes de ejecutarContratos de arquitectura, criterios de cobertura, restricciones de seguridad, benchmarks de performance. Todo definido antes de escribir una línea.
El agente de generación construye contra la specCódigo que respeta la arquitectura hexagonal, el clean code del repositorio, los design patterns acordados y las restricciones de seguridad. Sin interpretación libre.
El agente de validación verifica antes del PRCobertura de tests, análisis estático, benchmark de latencia, verificación de inyección de dependencias, ausencia de vectores OWASP comunes. El PR llega limpio al reviewer.
El porcentaje sube porque el ciclo es confiableEl dev usa IA en tareas complejas porque el sistema garantiza que el output va a cumplir los estándares. La adopción se vuelve hábito, no riesgo.
<30%
Porcentaje de uso real de IA en equipos sin metodología estructurada.La herramienta está instalada. El modelo está disponible. El presupuesto se aprobó. Pero sin un sistema que defina cómo se genera, cómo se valida y cómo se integra el código producido por IA, el porcentaje no sube y la calidad no se mantiene. El 70% es el mínimo exigido. El 90% es donde el sistema empieza a mostrar su verdadero potencial. El problema no es acceso a la tecnología: es el sistema que la rodea.
el sistema
SDD + Sistema Multiagente
para ingeniería de producción
SDD (Specs Driven Development) invierte el orden: primero se especifica con precisión qué construir, cómo se verifica y cuándo está terminado. Recién entonces la IA ejecuta. Un ecosistema de agentes especializados —cuya cantidad y roles varían según la complejidad de cada tarea— reemplaza el ciclo especulativo de "generar, revisar, rechazar, regenerar" por un ciclo determinístico de "especificar, generar, validar, entregar". Cualquier miembro del equipo puede ejecutar el proceso completo, desde el análisis hasta el despliegue.
AGENTE BASE · 01Especificaciónsiempre presente
El primer agente de cualquier pipeline SDD. Recibe el requerimiento en lenguaje de negocio o técnico y produce un documento de especificación ejecutable antes de que cualquier otro agente escriba código. Sin esta especificación, el pipeline no arranca. Es el contrato que todos los agentes siguientes van a respetar.
↓ según complejidad: uno o más agentes intermedios ↓
AGENTES OPCIONALESSegún la complejidad de la tarease suman según necesidad
El pipeline escala verticalmente con la complejidad. Una tarea simple puede resolverse con 3 agentes. Una funcionalidad con integraciones externas, requisitos de seguridad específicos, lógica de despliegue propia o comportamiento complejo puede requerir 6, 7 u 8 agentes encadenados. El sistema se diseña para la tarea, no al revés.
↓ agente de ejecución ↓
AGENTE BASE · 02Generación de códigoactivo
Construye contra la especificación del primer agente y contra los outputs de cualquier agente intermedio que haya participado. El modelo de IA que ejecuta (Claude, Gemini u otro) recibe como input la spec completa: no interpreta libremente ni toma decisiones de diseño no acordadas. El lenguaje, el framework y las convenciones del repositorio están en la spec, no en el criterio del modelo.
↓ validación ↓
AGENTE BASE · 03Validación de criteriosvalidando
Valida el código del agente de generación contra los criterios definidos en la especificación. El criterio central es objetivo: la cobertura de tests debe superar el 95%. Si algo no cumple, el ciclo vuelve al agente de generación con la discrepancia documentada. No hay subjetividad en la validación: o cumple los criterios o no los cumple.
──── PR listo para reviewer ────
OUTPUTPR listo para reviewer humanoentregado
El PR llega al reviewer humano con el código que cumple la spec, tests con cobertura verificada ≥95%, documentación del approach técnico y resultados del análisis del pipeline. El revisor evalúa decisiones de negocio y arquitectura, no corrige errores estructurales evitables. Cualquier miembro del equipo puede ejecutar este proceso completo: no hay agentes configurados por perfil.
accesible para cualquier miembro del equipo
Un dev ejecuta el pipeline completo, de la spec al despliegue
No hay agentes configurados por perfil ni flujos distintos para seniors y juniors. El pipeline SDD es ejecutable por cualquier integrante del equipo: el sistema hace el trabajo pesado de validación. Lo que varía según la complejidad de la tarea no es quién ejecuta el pipeline, sino cuántos agentes intermedios participa entre la spec y el código. Una tarea simple activa 3 agentes. Una funcionalidad con integraciones externas, seguridad o lógica de despliegue compleja puede activar 6 u 8.
por qué funciona
La calidad viene del sistema, no del modelo de IA
Cualquier modelo de IA —Claude, Gemini u otro— en un sistema sin estructura produce los mismos problemas: interpreta libremente, toma decisiones de arquitectura no acordadas, no cubre edge cases que no se le pidieron explícitamente. Con la spec del primer agente como input, el mismo modelo genera código que pasa la validación en el primer ciclo el 80%+ del tiempo. La diferencia no está en el modelo. Está en lo que le dás para trabajar.
arquitectura y patrones
Las capas se respetan porque están en la spec, no en la memoria del dev
El problema más común con código generado por IA en proyectos con arquitectura definida es que el modelo mezcla capas o viola los contratos entre componentes. La spec del primer agente define los boundaries explícitamente —cualquiera sea la arquitectura del equipo— y el agente de validación verifica que no se cruzaron. No hay PRs rechazados por violaciones de contrato que el sistema podría haber detectado antes.
seguridad
Los vectores de seguridad se verifican antes del merge, no después del incidente
En entornos con alto tráfico o datos sensibles de usuario, la seguridad no puede quedar para la revisión manual del reviewer. El agente de validación verifica —con las herramientas de análisis estático del stack del equipo— que el código no introduce vectores conocidos antes de que el PR llegue al reviewer humano. El reviewer humano se enfoca en las decisiones de arquitectura y negocio que sí requieren criterio.
make vs. buy
El sistema SDD no es un secreto.
La curva de aprendizaje sí lo es.
La lógica es pública: especificar antes de ejecutar, generar contra la spec, validar antes del PR. Cualquier equipo con un Senior motivado puede leerlo y decidir hacerlo interno.
Lo que no está en la documentación de Cursor es esto: los primeros templates de spec que generamos eran demasiado genéricos. El agente de generación los usaba para producir código que pasaba el análisis estático pero no los contratos de la arquitectura. Encontrar el nivel de granularidad correcto para que las specs sean ejecutables —ni tan abstractas que el modelo interprete libremente, ni tan detalladas que el proceso sea más lento que escribir el código a mano— tomó semanas de iteración con tipos de tareas reales.
Eso está incorporado en el engagement. No como teoría. Como configuración específica para tu stack y tu arquitectura, validada en el piloto de la semana 4 antes del rollout.
Si tenés un Senior con tiempo real disponible para investigar y absorber esa curva sin impactar el sprint, puede hacerlo. Si ese tiempo sale del equipo que está entregando, el costo es otro.
Eso está incorporado en el engagement. No como teoría. Como configuración específica para tu stack y tu arquitectura, validada en el piloto de la semana 4 antes del rollout.
Si tenés un Senior con tiempo real disponible para investigar y absorber esa curva sin impactar el sprint, puede hacerlo. Si ese tiempo sale del equipo que está entregando, el costo es otro.
implementación
De cero a sistema operativo
en 6 semanas. Sin freezar sprints.
El engagement está diseñado para funcionar en los márgenes del trabajo real del equipo, no en el centro. La carga máxima es 1 hora diaria de interrupción al sprint, concentrada en las semanas del piloto y la adopción. El resto del tiempo, el trabajo es propio del engagement. Cada semana cierra con un entregable concreto. Si al finalizar la semana 4 el piloto no cumple los criterios definidos al inicio, el engagement se detiene y no hay fee de cierre.
01
Auditoría
Mapeo de uso actual de IA, análisis de PRs rechazados, identificación de alucinaciones que llegaron a producción.
3–5 h totales del Tech Lead. Sin impacto en el sprint.
Sem. 102
Relevamiento
Arquitectura, stack, patrones, protocolos del repo. Trabajo sobre código y documentación real.
2–3 h totales del Tech Lead + 1 h del equipo para revisión.
Sem. 203
Configuración
IDE con reglas del proyecto, MCPs, Skills, templates de spec por tipo de tarea, pipeline de validación.
2 sesiones de 45 min con el Tech Lead. El resto es trabajo propio del engagement.
Sem. 304
Piloto
Ciclo completo sobre una tarea real del sprint: spec → generación → validación → PR. Si el sistema no cumple los criterios, el engagement se detiene sin costo adicional.
1 dev + Tech Lead, máx. 1 h/día durante 5 días hábiles.
Sem. 4 — PUNTO DE CANCELACIÓN05
Adopción
Capacitación práctica del equipo completo. Cada persona ejecuta el pipeline sobre una tarea real con el sistema configurado.
1 sesión de 60 min por persona. Único día de carga concentrada del engagement.
Sem. 506
Métricas y cierre
Dashboard de métricas, baseline sem. 1 vs. resultados, ajustes finales, plan de optimización continua.
Revisión semanal de 30 min. Sin otro impacto en el sprint.
Sem. 6Etapa 01 — Auditoría del flujo actual · Sem. 1
El sistema no se puede mejorar si no se sabe exactamente cómo funciona hoy
La auditoría inicial mapea tres dimensiones: cómo usa IA el equipo hoy —qué hace bien, dónde el output no pasa el pipeline—, dónde se producen los rechazos de PR —violaciones de contrato, cobertura insuficiente, problemas de diseño, convenciones rotas— y dónde la IA produce alucinaciones o errores que llegan a producción. Este tercer punto es el más crítico: hay una diferencia entre código que el reviewer detecta y rechaza, y código que pasa el review y falla en producción. Con ese mapa completo, la configuración del sistema multiagente se ajusta exactamente a los gaps del equipo.
mapa de uso actual de IAanálisis de PRs rechazadosregistro de alucinaciones en produccióngap report de calidad
Etapa 02 — Relevamiento de funcionamiento y protocolos · Sem. 2
Sin entender la arquitectura real del equipo, el sistema de agentes no puede respetar sus contratos
El relevamiento cubre la arquitectura del sistema, las funcionalidades del dominio, el stack técnico, la estructura del repositorio, los patrones de diseño adoptados y los protocolos de desarrollo del equipo. Este relevamiento es el insumo principal para el agente de especificación: sin él, el agente genera specs genéricas que no respetan los contratos reales del sistema. Con él, las specs son precisas para ese repositorio, ese equipo y esa arquitectura. No es un relevamiento teórico: se trabaja sobre el código y la documentación real del equipo.
mapa de arquitectura relevadainventario de patrones y protocoloscontratos de interfaz documentadosbase para templates de spec
Etapa 03 — Configuración de agentes y herramientas · Sem. 3
El sistema se configura para el equipo, no el equipo para el sistema
La configuración cubre: Cursor, Windsurf o Antigravity con las reglas del proyecto que incorporan los contratos del relevamiento anterior, MCP servers para las librerías internas del equipo —accesibles desde el entorno del dev sin exponer código propietario—, Skills para los patrones y protocolos más frecuentes del repositorio, y templates de spec por tipo de tarea: un endpoint de API tiene una spec distinta a un worker asincrónico, que tiene una spec distinta a un componente de UI. Cualquier miembro del equipo puede ejecutar el pipeline completo con esta configuración.
IDE configurado con reglas del proyectoMCP servers activosSkills del equipo cargadastemplates de spec por tipo de tareapipeline de validación integrado
Etapa 04 — Tarea real con SDD · Sem. 4
El sistema se valida con código de producción real, no con ejercicios de demo
Se toma una tarea del sprint actual del equipo y se ejecuta el ciclo completo: especificación, generación, validación, PR. El objetivo es que el pipeline de validación apruebe el código en el primer ciclo. Si no lo hace, se identifica dónde falla la cadena —en los templates de spec, en las reglas del IDE o en la configuración del pipeline de validación— y se corrige antes de extender el sistema al equipo completo. El piloto no se considera exitoso hasta que el pipeline pasa sin intervención manual en el primer ciclo para la tarea elegida.
primera tarea entregada con SDDinforme de ciclos del pipelineajustes post-piloto documentadossistema listo para rollout
Etapa 05 — Adopción en todo el equipo · Sem. 5
Cualquier miembro del equipo debe poder ejecutar el pipeline completo, de la spec al despliegue
La capacitación es práctica, no teórica. Cada integrante del equipo ejecuta el pipeline sobre una tarea real con el sistema ya configurado. No hay flujos distintos por perfil: un dev junior y un tech lead usan el mismo pipeline. Lo que cambia con la experiencia no es el proceso sino la calidad de los inputs al agente de especificación. La capacitación incluye: cómo formular el requerimiento para que el agente de especificación produzca una spec ejecutable, cómo leer y validar la spec antes de pasarla al agente de generación, y cómo interpretar los resultados del agente de validación.
capacitación práctica del equipoplaybook del pipeline por tipo de tareaguía de troubleshooting del sistemaprimer sprint con adopción completa
Etapa 06 — Métricas y ajuste fino · Sem. 6 a 8
El sistema se ajusta con datos del equipo real, no con intuición
Las métricas que importan: porcentaje de código generado por IA por PR (¿el porcentaje sube consistentemente?), tasa de primer-pass en el pipeline de validación (¿el código pasa sin ciclos de corrección?), tiempo de ciclo por tipo de tarea (¿el sistema acelera donde debe acelerar?) y tasa de rechazos de PR por calidad estructural (¿está bajando?). Con esas métricas, el ajuste de los templates de spec, las reglas del IDE y la configuración del pipeline es empírico. Al final de la semana 8, el equipo tiene el sistema operativo, las métricas establecidas y la capacidad de mantenerlo sin soporte externo.
dashboard de métricas del equipobaseline sem. 1 vs resultados sem. 8ajustes finales documentadosplan de optimización continuasistema autónomo del equipo
para quién
Quién necesita esto
y quién todavía no.
// tiene sentido si
✓Tu equipo tiene la exigencia de superar el 70% de código generado con IA y hoy está estancado entre 20% y 40% porque el flujo sin estructura produce demasiados rechazos o alucinaciones que llegan a producción.
✓Llegás al porcentaje mínimo pero la calidad no acompaña: el código IA pasa el review en el happy path y falla en los casos borde, los timeouts o los contratos entre capas. El objetivo de 90% parece inalcanzable con calidad.
✓Trabajás con arquitectura definida con contratos entre capas —hexagonal, clean architecture u otra— y el código generado por IA viola esos contratos de forma consistente en los PRs.
✓Operás en entornos con 100k+ RPM y uptime 99%+ y necesitás que el sistema de generación de código sea tan riguroso como las exigencias de producción.
✓Tenés observabilidad instalada pero el código nuevo no llega con los instrumentos necesarios porque no forman parte del contrato de generación. Lo corregís post-deploy.
✓Querés que cualquier miembro del equipo —no solo los seniors— pueda ejecutar el pipeline completo de generación de código de calidad de producción, desde la spec hasta el despliegue.
// no tiene sentido si
✕Tu equipo no tiene una arquitectura definida con contratos claros entre componentes. SDD amplifica la calidad del proceso existente: si el proceso no existe, primero hay que diseñarlo.
✕Ya superás consistentemente el 90% de código generado con IA con cobertura 95%+ verificada y el pipeline de primer-pass es estable. En ese caso tenés el sistema resuelto.
✕Buscás una solución de una sesión de capacitación. El engagement requiere auditoría, relevamiento, configuración, piloto y ajuste. El cambio de hábito toma 6 semanas reales, no una tarde.
✕Tu equipo nunca instaló ni probó las herramientas de generación de código con IA. El punto de partida mínimo para implementar SDD es que el equipo haya experimentado con ellas, aunque sea informalmente.
garantía
Lo que se compromete
y lo que no.
Garantía de adopción medible
Cada semana del engagement cierra con un entregable concreto. No con un informe de avance: con algo que el equipo puede usar desde el lunes siguiente.
Al cierre de cada semana:
Semana 1: mapa de uso actual de IA del equipo + lista de fricciones identificadas.
Semana 2: arquitectura relevada + contratos documentados + base para los templates de spec.
Semana 3: IDE configurado con reglas del proyecto + MCPs activos + templates de spec por tipo de tarea.
Semana 4: primera tarea entregada con SDD + informe del piloto + sistema ajustado para rollout.
Semana 5: equipo completo operando el pipeline + playbook del proceso.
Semana 6: dashboard de métricas + baseline sem. 1 vs. resultados + sistema autónomo entregado.
Si al cierre de la semana 4 el pipeline no pasa los criterios de aceptación definidos al inicio, podés cancelar el engagement sin costo adicional. Si al cierre de la semana 6 el equipo no supera el 60% de código IA con primer-pass >70%, el fee de cierre se reduce proporcionalmente a la diferencia.
El riesgo de que el sistema no funcione es mío. El tiempo de tu equipo es tuyo.
Semana 1: mapa de uso actual de IA del equipo + lista de fricciones identificadas.
Semana 2: arquitectura relevada + contratos documentados + base para los templates de spec.
Semana 3: IDE configurado con reglas del proyecto + MCPs activos + templates de spec por tipo de tarea.
Semana 4: primera tarea entregada con SDD + informe del piloto + sistema ajustado para rollout.
Semana 5: equipo completo operando el pipeline + playbook del proceso.
Semana 6: dashboard de métricas + baseline sem. 1 vs. resultados + sistema autónomo entregado.
Si al cierre de la semana 4 el pipeline no pasa los criterios de aceptación definidos al inicio, podés cancelar el engagement sin costo adicional. Si al cierre de la semana 6 el equipo no supera el 60% de código IA con primer-pass >70%, el fee de cierre se reduce proporcionalmente a la diferencia.
El riesgo de que el sistema no funcione es mío. El tiempo de tu equipo es tuyo.
Entregable semanal
Cada semana cierra con algo concreto que el equipo puede usar, no con un reporte de estado.
Check-in semana 4
Después del piloto, punto de decisión. Si el sistema no cumple los criterios definidos al inicio, cancelación sin costo desde ese punto.
Reducción de fee
Si al cierre de la semana 6 no se alcanzan los objetivos pactados, el fee final se reduce en proporción a la brecha.
Criterios definidos antes de empezar
El baseline se mide en la auditoría inicial. El objetivo se define en la semana 1, antes de cualquier configuración.
Sistema autónomo al cierre
Al terminar la semana 6, el equipo tiene el playbook, las reglas y las guías para operar sin depender de soporte externo.
preguntas frecuentes
Lo que se pregunta
antes de la primera sesión.
¿SDD funciona con cualquier lenguaje o solo con ciertos stacks?
SDD es agnóstico al lenguaje y al stack. Lo que varía es la configuración del agente de especificación y del agente de validación según el contexto técnico del equipo. Un servicio con arquitectura hexagonal tiene una spec distinta a un componente de frontend, que tiene una spec distinta a un worker asincrónico. Los templates de spec, las reglas de análisis estático y los criterios de cobertura se configuran en la etapa de relevamiento y configuración, a partir de la arquitectura real del equipo, no de una plantilla genérica.
¿Cuántos agentes tiene el sistema? ¿Es siempre 3?
El mínimo son 3 agentes —especificación, generación y validación— que cubren el caso base de cualquier tarea. Pero el sistema escala con la complejidad: una funcionalidad con integraciones externas, requisitos de seguridad específicos, lógica de despliegue propia o troubleshooting de comportamiento complejo puede requerir agentes adicionales para diseño de contratos, análisis de seguridad, preparación de despliegue, diagnóstico de dependencias externas y otros roles. El número de agentes no es fijo: se determina en la etapa de especificación de cada tarea.
¿Cualquier dev puede ejecutar el pipeline completo o solo los seniors?
Cualquier miembro del equipo. No hay agentes configurados por perfil ni flujos distintos para juniors y seniors. Lo que cambia con la experiencia es la calidad de los inputs al agente de especificación, no el proceso en sí. Un dev con más contexto técnico va a formular el requerimiento con mayor precisión y la spec resultante va a ser más rica. Pero el pipeline completo —de la spec al despliegue— es ejecutable por cualquier integrante del equipo desde la semana 5.
¿Cómo se integra con el proceso de review humano existente?
SDD no reemplaza el review humano: lo complementa. El reviewer recibe PRs que ya pasaron el pipeline de validación automatizado: cobertura ≥95% verificada, análisis estático limpio, benchmark de performance aprobado, contratos de arquitectura verificados. Eso libera al reviewer para enfocarse en decisiones que sí requieren criterio humano: coherencia con la visión del producto, trade-offs de arquitectura, comportamiento en casos de negocio no contemplados en los tests. El tiempo de review baja y su calidad sube.
¿Qué pasa con el MCP y las librerías internas que no son públicas?
El setup del MCP server se hace sobre el entorno del equipo, sin que las librerías internas salgan del entorno corporativo. El agente de generación accede a la documentación y las interfaces de las librerías internas a través del MCP server configurado localmente. El proceso de configuración no requiere exponer código propietario a ningún servicio externo. Cursor, Windsurf y Antigravity funcionan con el MCP server corriendo en la máquina del dev o en el entorno de CI del equipo.
¿Cuánto tiempo requiere del equipo durante las 6 semanas?
El criterio de diseño del engagement es claro: máximo 1 hora diaria de interrupción al sprint. En la práctica, la carga se distribuye así:
Semanas 1 y 2 (auditoría y relevamiento): 3 a 5 horas totales del Tech Lead, distribuidas en la semana. Sin impacto en el sprint del equipo.
Semana 3 (configuración): 2 sesiones de 45 minutos con el Tech Lead. El resto es trabajo propio del engagement.
Semana 4 (piloto): 1 dev + el Tech Lead, máximo 1 hora por día durante los 5 días hábiles de la semana. Es la semana de mayor carga concentrada.
Semana 5 (adopción): 1 sesión de 60 minutos por persona del equipo. Es el único momento en que todo el equipo se detiene al mismo tiempo.
Semana 6 (métricas y cierre): revisión semanal de 30 minutos. Sin otro impacto en el sprint.
Semanas 1 y 2 (auditoría y relevamiento): 3 a 5 horas totales del Tech Lead, distribuidas en la semana. Sin impacto en el sprint del equipo.
Semana 3 (configuración): 2 sesiones de 45 minutos con el Tech Lead. El resto es trabajo propio del engagement.
Semana 4 (piloto): 1 dev + el Tech Lead, máximo 1 hora por día durante los 5 días hábiles de la semana. Es la semana de mayor carga concentrada.
Semana 5 (adopción): 1 sesión de 60 minutos por persona del equipo. Es el único momento en que todo el equipo se detiene al mismo tiempo.
Semana 6 (métricas y cierre): revisión semanal de 30 minutos. Sin otro impacto en el sprint.
¿El sistema funciona igual si el equipo usa herramientas de observabilidad distintas?
Sí. El sistema es agnóstico a la plataforma de observabilidad. La spec define qué instrumentar —métricas, trazas, alertas— y el agente de generación implementa esos instrumentos usando las librerías y los patrones de la plataforma que el equipo ya usa. No se requiere cambiar de herramienta de observabilidad ni agregar dependencias nuevas. Si el equipo ya tiene APM configurado, la spec incluye cómo el código nuevo se integra a ese APM existente.
¿Hay diferencia entre implementar esto para un dev individual y para un equipo completo?
Sí, hay dos modalidades. Para un dev o tech lead individual que quiere aplicar SDD en su flujo personal antes del rollout al equipo: el proceso se acota a 3 o 4 semanas, se enfoca en el stack que usa esa persona y produce las configuraciones y guías que luego puede propagar al equipo por su cuenta. Para el equipo completo (la modalidad estándar de 8 semanas): el proceso incluye la auditoría del flujo grupal, el relevamiento de arquitectura, la configuración de herramientas compartidas, la capacitación del equipo y las métricas de seguimiento. Si tenés dudas sobre cuál aplica a tu caso, la primera sesión de diagnóstico lo aclara.
próximo paso
30 minutos para saber
si SDD es la solución
para tu equipo.
En la primera sesión hacemos una auditoría rápida de tres puntos: dónde está hoy el porcentaje de uso de IA en el equipo, dónde se producen los rechazos de PR o las alucinaciones que llegan a producción, y qué tan definida está la arquitectura para que el sistema multiagente la pueda respetar. Con esos tres datos, confirmamos si SDD cierra la brecha o si el problema tiene otro origen. Si la conclusión es que no aplica, lo decimos en esa misma sesión y no hay siguiente paso.
→
SDD nació de un problema concreto: liderar un equipo de 8 devs backend sobre múltiples microservicios con arquitectura hexagonal en Go, con la exigencia de llegar al 100% de adopción de IA y un mínimo de 70% de código generado —sin una metodología formal que lo hiciera posible.
Llegamos al objetivo. No con un sistema. Con prueba y error, vibe coding, y muchos rechazos de PR antes de encontrar el orden correcto. La pregunta que me quedó después de eso fue la que generó SDD: ¿cuánto tiempo y cuántos ciclos de corrección se ahorra un equipo cuando especifica antes de ejecutar?
Eso es lo que viene a instalar este engagement en tu equipo.
Quién validó este liderazgo
“En Darío encontré a una persona enfocada en dar soluciones. Un líder de gestión que adquirió mucho conocimiento del producto y un background técnico que le empodera y lo enfoca a resultados. Le gusta documentar, dejar traza de su trabajo, convirtiéndose en referente natural de su entorno.”
Project Leader · Mercado Libre · Trabajó en el mismo equipo · 4 feb 2026
“Me resultó muy valioso su interés por la innovación, especialmente su manejo de la IA, ayudándonos a entender cómo aprovechar estas herramientas en el día a día. Tiene facilidad para entender procesos complejos y estructurarlos de forma sencilla.”
Project Leader · Mercado Libre · Trabajó en el mismo equipo · 2 feb 2026
“Darío se destacó por su sólido entendimiento del negocio, su versatilidad y su capacidad para liderar equipos en contextos regionales complejos. Impulsó y acompañó la implementación de nuevas features, asegurando entregas en tiempo y forma alineadas con los objetivos del negocio.”
Software Engineer · Mercado Libre · Darío lo supervisaba · 2 feb 2026
Primera sesión sin costo
30 min · Remoto · Sin compromiso
integración técnica
Todo tu stack existente.
Sin reemplazar nada.
SDD se integra al flujo de trabajo existente del equipo. No reemplaza las herramientas ni los procesos. Los potencia con la capa de especificación que hace que la IA genere código que pasa el proceso, no que lo trabe.
IDE + Modelos IA
Agnóstico al proveedor
Cursor — agent mode con context del proyecto
Windsurf — Cascade para flujos multi-archivo
Antigravity — pipelines multiagente complejos
Claude / Gemini / GPT — cualquier modelo compatible
Reglas de proyecto en
.rules con spec del equipoMCP servers para librerías internas del repo
Lenguajes y Arquitectura
Agnóstico al stack
SDD funciona con cualquier lenguaje que tenga herramientas de análisis estático
La spec define las convenciones: el modelo las respeta
Hexagonal · Clean Arch · CQRS · Event-driven · y otros
Los patrones de diseño van en la spec, no en el criterio del modelo
Monolito · Microservicios · Serverless · cualquier topología
El agente de generación adapta su output al contexto del repo
Observabilidad y CI/CD
Agnóstico a la plataforma
Cualquier plataforma de APM y trazado distribuido
Cualquier sistema de dashboards y alertas
GitHub Actions · GitLab CI · Jenkins · o el pipeline existente
La spec define qué instrumentar: el equipo usa su plataforma
Rollback policy y feature flags documentados en la spec de deploy
El agente de validación integra con el CI/CD existente del equipo
hexagonal_spec_example.go — agente de especificación · output
hexagonal · SDD spec · cualquier lenguaje
// SDD Spec — generada por agente de especificación antes de ejecutar
// Agente de generación lee esta spec. Agente de validación valida contra esta spec.
// No hay otro contrato. Cualquier dev del equipo ejecuta este pipeline.
// Domain: payments.refund
// UseCase: ProcessRefund
// Pattern: hexagonal · port+adapter · repository
// ACCEPTANCE CRITERIA:
// 1. RefundPort.Process nunca toca infra directamente → debe usar RefundRepository (interface)
// 2. Coverage ≥ 95% incluyendo error paths y timeouts (unit + integration)
// 3. p99 latency ≤ 150ms @ 100k RPM — medido con benchmark table-test
// 4. No direct DB calls en domain layer — todos via repository interface
// 5. ctx.Done() handled → no goroutine leaks en cancelación
// 6. Structured logging con trace_id para correlación en plataforma de observabilidad
// 7. Sin strings hardcodeados con datos financieros en logs
type RefundPort interface {
Process(ctx context.Context, req RefundRequest) (*RefundResponse, error)
}
type RefundRepository interface { // infra adapter — NUNCA importar impl aquí
FindByID(ctx context.Context, id string) (*Payment, error)
UpdateStatus(ctx context.Context, id string, status PaymentStatus) error
}
// Agente de validación verificará:
// ✓ ProcessRefund recibe RefundRepository por inyección, no instancia concrete
// ✓ Coverage: go test -coverprofile → mínimo 95% en todas las capas
// ✓ Análisis estático: zero warnings en herramienta del equipo
// ✓ Benchmark: p99 ≤ 150ms bajo carga simulada
// ✓ Observabilidad: span iniciado al entry, closed en defer
// Agente de generación lee esta spec. Agente de validación valida contra esta spec.
// No hay otro contrato. Cualquier dev del equipo ejecuta este pipeline.
// Domain: payments.refund
// UseCase: ProcessRefund
// Pattern: hexagonal · port+adapter · repository
// ACCEPTANCE CRITERIA:
// 1. RefundPort.Process nunca toca infra directamente → debe usar RefundRepository (interface)
// 2. Coverage ≥ 95% incluyendo error paths y timeouts (unit + integration)
// 3. p99 latency ≤ 150ms @ 100k RPM — medido con benchmark table-test
// 4. No direct DB calls en domain layer — todos via repository interface
// 5. ctx.Done() handled → no goroutine leaks en cancelación
// 6. Structured logging con trace_id para correlación en plataforma de observabilidad
// 7. Sin strings hardcodeados con datos financieros en logs
type RefundPort interface {
Process(ctx context.Context, req RefundRequest) (*RefundResponse, error)
}
type RefundRepository interface { // infra adapter — NUNCA importar impl aquí
FindByID(ctx context.Context, id string) (*Payment, error)
UpdateStatus(ctx context.Context, id string, status PaymentStatus) error
}
// Agente de validación verificará:
// ✓ ProcessRefund recibe RefundRepository por inyección, no instancia concrete
// ✓ Coverage: go test -coverprofile → mínimo 95% en todas las capas
// ✓ Análisis estático: zero warnings en herramienta del equipo
// ✓ Benchmark: p99 ≤ 150ms bajo carga simulada
// ✓ Observabilidad: span iniciado al entry, closed en defer
cómo se cumplen las exigencias
Cada métrica tiene
un mecanismo concreto.
Las exigencias de producción no se cumplen con buenas intenciones ni con prompts creativos. Se cumplen diseñando el sistema de generación de código para que produzca, por default, outputs que las cumplan. Esto es lo que SDD + multiagente hace de forma sistemática.
exigencia mínima · objetivo real
70% → 90%
código generado por IA
El 70% es el piso. El 90% es donde el sistema empieza a mostrar su potencial real.
El dev evita usar IA en tareas complejas cuando el ciclo de corrección es costoso. Con SDD, el costo de corrección baja porque el agente de especificación aclara qué construir antes de que el agente de generación lo construya. Cuando el PR pasa el pipeline en primer intento consistentemente, el dev adopta el flujo para todo y el porcentaje sube naturalmente, sin forzarlo.
cómo se logra
Spec precisa elimina la interpretación libre del modelo
IDE en agent mode con reglas del proyecto en el contexto
Ciclo spec→generación→validación reduce rechazos a <20% en semana 3
El dev mide su ratio en cada PR — visible en los insights del repo
exigencia · calidad del código
95%+
cobertura de tests
El agente de validación verifica cobertura real antes de cada PR, no después del incidente.
La cobertura nominal y la cobertura real son cosas distintas. Un 95% de coverage que incluye los error paths, los timeouts y las condiciones de borde es cualitativamente diferente a un 95% de coverage en el happy path. La spec define qué paths deben estar cubiertos. El agente de validación no acepta el PR si no los están.
cómo se logra
Acceptance criteria en spec incluye paths de error y casos borde
Agente de validación ejecuta análisis estático con tolerancia cero
PR bloqueado si cobertura <95% o si análisis reporta issues críticos
Violaciones de contrato entre capas detectadas antes del merge
exigencia · disponibilidad
99%+
uptime objetivo
La disponibilidad se diseña en la spec, no se reza en el deploy.
El uptime cae por timeouts sin circuit breaker, retries sin backoff, recursos que no se liberan y deploys sin fallback. La spec incluye todos los patrones de resiliencia requeridos para el servicio. El agente de validación verifica que el código los implementa correctamente, no solo que compile.
cómo se logra
Spec incluye circuit breaker, retry policy y timeout por servicio
Agente de validación verifica manejo de contexto y graceful shutdown
SLO dashboards configurados en la spec de cada servicio
Política de rollback documentada en el agente de despliegue si aplica
exigencia · performance
<200ms
p99 · 100k+ RPM
El benchmark no es una prueba final. Es un criterio de aceptación desde el principio.
Un servicio que pasa la validación funcional pero introduce una query ineficiente, una llamada bloqueante o un lock contencioso puede destruir el p99 bajo carga real. La spec define el budget de latencia por operación. El agente de validación ejecuta el benchmark antes del merge, no después de que la plataforma de observabilidad reporta la degradación.
cómo se logra
Performance budget por endpoint en spec (p50 / p95 / p99)
Benchmarks generados por agente de generación, validados por agente QA
Verificación de queries ineficientes y llamadas bloqueantes en análisis estático
Distributed tracing activo desde primer deploy a staging