La Parte 1 de este playbook estableció el paradigma: Agente = Modelo + Harness, los 8 pilares de un Harness de producción, el método R.P.I., la arquitectura de contexto en 3 capas y la escala de madurez L0 a L4. Concepto cubierto. Pero el concepto sin herramienta táctica se vuelve una diapositiva de keynote. Esta Parte 2 entrega lo que quedó afuera: las herramientas analíticas y operacionales que permiten aplicar el paradigma sin improvisación.
Cinco piezas que separan a un equipo que entiende el discurso de un equipo que ejecuta: (1) el pipeline de refactorización guiada por IA en 4 etapas, (2) el análisis de acoplamiento tridimensional de Khononov (Fuerza, Distancia, Volatilidad), el framework matemático para decidir límites modulares, (3) el caso Velora como contrapunto a PayPal: workflow AI-First aplicado a equipos reducidos en vez de operación enterprise, (4) el Blueprint del Desarrollador IA-Nativo como stack vertical de cuatro capas, y (5) la costura con el Framework de Adopción Corporativa en 7 fases que ya documentamos en un post propio. Todo lo que faltaba para cerrar el ciclo.
Pipeline de Refactorización Guiada por IA: las 4 etapas
Refactorizar una codebase legacy con IA es el caso donde el Vibe Coding falla más espectacularmente. Pides "refactoriza ese módulo", el agente reescribe la mitad del sistema con una arquitectura inventada, borra tests, rompe dependencias invisibles y te entrega un PR que nadie va a poder revisar. El playbook AI-Native trata la refactorización como un pipeline de cuatro etapas estrictamente secuenciales, cada una con una salida auditable.
Etapa 1, Detección de Anomalías
Mapeo de code smells y desvíos estructurales vía IA. Antes de tocar una sola línea, usas el agente para diagnosticar: dónde están las duplicaciones reales (no solo las que aparecen en el linter), qué clases acumulan demasiada responsabilidad, qué módulos tienen acoplamiento cíclico, dónde la jerarquía se desvía de la convención del resto del repositorio. Salida: un informe en Markdown listando las anomalías con referencia a archivo y línea. Ese informe es el input de la próxima etapa, no un input directo de ejecución.
Etapa 2, Estandarización
Resolución de duplicaciones con el objetivo dual de mejorar el código y reducir el consumo de tokens futuros. El código estandarizado es más barato de procesar para el agente, no es solo estética, es ahorro de ventana de contexto en cada task posterior. Aplicas los fixes en orden de impacto: las tres o cuatro duplicaciones que aparecen en más lugares primero, porque cada una de ellas va a generar ahorro compuesto en las próximas ejecuciones del agente. Salida: un PR pequeño y quirúrgico por estandarización, con un Test Gate asociado.
Etapa 3, Consolidación (DDD)
Aplanamiento de la jerarquía y aislamiento lógico en Domain Services puros. Aquí sales del nivel de "limpieza" y entras en el nivel de "reformulación de límites". Es la etapa más arriesgada y la que más se beneficia del Spec-Driven Development: escribes el Design Doc del nuevo límite, generas una Task List de migración, y solo entonces el agente ejecuta task por task. Nunca consolides sin una Spec aprobada, esta es la etapa donde la "Destrucción de Alcance" ocurre con más frecuencia.
Etapa 4, Actualización Dinámica
Registro manual y quirúrgico de los nuevos patrones arquitecturales en el Agents.md. Esto es lo que cierra el loop: el aprendizaje de la refactorización se vuelve una regla global del repositorio. La próxima vez que alguien pida una feature similar, el agente ya parte del límite arquitectural correcto. Sin la Etapa 4, refactorizaste el código una vez, pero el conocimiento quedó en la cabeza de la persona que pidió la refactorización, y el próximo agente va a caer en el mismo hueco.
Alerta de seguridad crítica: nunca le pidas a la IA que genere tu archivo Agents.md desde cero a partir del código refactorizado. Va a incluir información irrelevante que consumirá tu ventana de contexto para siempre. La regla es innegociable: curaduría manual en la Etapa 4. El agente sugiere, tú decides qué entra.
Análisis de Acoplamiento Tridimensional: el framework Khononov
Este es el framework matemático que falta en la mayoría de las conversaciones sobre "módulo bien diseñado". Vlad Khononov propone que el acoplamiento entre dos módulos no es una dimensión única, es un vector de tres: Fuerza, Distancia y Volatilidad. Cada uno responde una pregunta diferente, y la interacción entre las tres es lo que define si el acoplamiento es estructuralmente seguro o un cuello de botella mortal esperando el próximo deploy.
Fuerza, ¿qué se comparte?
Compartir una entidad de dominio genera alto riesgo. Si el Módulo A y el Módulo B comparten la misma clase Pedido con lógica de negocio adentro, cualquier cambio en Pedido rebota. Compartir un contrato de API o una cola es estructuralmente seguro: la frontera es explícita, los cambios son versionados, los contratos son auditables. Fuerza alta = cuánto de la semántica interna está acoplada; fuerza baja = solo la interfaz está acoplada.
Distancia, ¿dónde viven?
Si el acoplamiento es fuerte y los módulos viven en repositorios distantes (microservicios separados, equipos diferentes, ciclos de release independientes), el sistema sufrirá quiebres constantes. El costo de mantener dos repositorios en sincronía con lógica fuertemente acoplada es exponencial. La distancia alta exige acoplamiento bajo; el acoplamiento alto exige distancia baja. Violar esa regla es la fuente clásica de "cada vez que hago deploy del servicio A, el servicio B se cae".
Volatilidad, ¿con qué frecuencia cambia?
Los componentes centrales de negocio que están altamente acoplados Y cambian con frecuencia crean cuellos de botella mortales. Es la combinación que destruye la velocidad: el equipo queda rehén de coordinar cambios entre módulos que evolucionan juntos pero viven separados, y cada release se vuelve una negociación. Si el módulo cambia cada semana, el acoplamiento con él necesita ser débil; si el acoplamiento es fuerte, él necesita cambiar poco.
Topología segura vs. peligrosa
Aplicando los tres vectores a la clásica descomposición DDD (Core Domain, Supporting, Generic):
- Core Domain ↔ Generic: Safe API Boundaries. Comunicación vía contrato bien definido, fuerza baja, distancia alta tolerada.
- Supporting → Generic: Safe API Boundaries. Misma lógica.
- Core Domain ↔ Supporting: ⚠ Dangerous High Coupling. Aquí es donde el sistema se rompe. Fuerza alta (comparten entidades), distancia variable, volatilidad típica (el negocio cambia). Resultado: un cuello de botella permanente.
Acción táctica: utiliza Agent Skills de Modular Decomposition para calcular límites matemáticamente seguros basados en los tres vectores. El agente puede analizar la codebase, clasificar cada módulo en las tres dimensiones y proponer límites, siempre que le proporciones el criterio como una Skill estructurada, no como un prompt abierto.
Para el tratamiento completo de este framework con ejemplos y herramientas de análisis, vale la pena el post dedicado de Steply: Coupling Tridimensional de Khononov: Strength, Distance, Volatility. Este resumen sirve como puente: el Khononov es el criterio matemático que sostiene la decisión de "Monolito Modular vs. Microservicios" que defendimos en la Parte 1.
Caso Velora: workflow AI-First en equipos reducidos
En la Parte 1 usamos a PayPal como caso enterprise: 24.000 empleados, billones de transacciones, $2k/mes en tokens por power user, dual-review en el 90% del código. Ese es el escenario de quien opera a escala extrema. Pero la mayoría de los equipos que leen este playbook no operan así. Operan como Velora: equipos de 1 a 2 devs cubriendo el ciclo completo del proyecto, con ambición de entrega continua pero una restricción real de personas. El caso Velora prueba que el paradigma AI-Native escala hacia abajo tan bien como escala hacia arriba.
El cuello de botella ágil que el workflow AI-Native disuelve
El dashboard tradicional: Backlog → Refinement → Sprint → QA → Review → Staging → Prod. Siete columnas, cada una con una fila, cada fila con latencia. El tiempo se acumula entre etapas, no en el trabajo, en la transición. Una story pasa tres días en Refinement esperando, dos días en QA esperando el review, un día en Staging esperando la aprobación. La suma de la espera le gana a la suma de la ejecución en casi todo equipo pequeño.
El flujo AI-Native de Velora
Cuatro estaciones, sin filas:
- Prototipo (Cursor). El dev valida la hipótesis rápidamente en el editor con IA. Ya no es "escribir la spec antes de validar técnicamente", es validar la viabilidad técnica en horas, y solo entonces escribir la spec de lo que va a producción.
- PRD Generado. La IA transforma el prototipo + contexto de producto en un PRD estructurado. La documentación no es overhead, es un subproducto.
- Linear Slices. Los tickets se vuelven Slices, paquetes robustos optimizados para el consumo por agentes, con suficiente contexto para la ejecución autónoma. No es una "historia de usuario" para un humano; es una especificación determinista para una máquina.
- Producción. Bots internos hacen merge automático de PRs de bajo riesgo si los Sensores (linter, tests, Test Gates) pasan. La aprobación humana queda reservada para cambios de alto impacto.
Tres consecuencias operacionales:
- Equipos reducidos. Apenas 1 a 2 devs cuidando el ciclo completo del proyecto. El equipo no crece para absorber más demanda, el Harness la absorbe.
- El fin de las Stories. Los tickets se vuelven "Slices" robustos optimizados para el consumo por agentes. Escribir el ticket se vuelve parte de la ingeniería, no de la gerencia.
- Aprobación autónoma. Bots internos hacen merge automático de PRs de bajo riesgo si los Sensores pasan. El dev humano se reserva para lo que realmente exige juicio.
La diferencia entre PayPal y Velora no es el paradigma, es la escala de la gobernanza a su alrededor. Los 8 pilares del Harness valen para los dos. Lo que cambia es el costo de implementación, y escala favorablemente para equipos pequeños: menos personas para alinear, menos políticas para versionar, menos compliance para auditar. Un equipo reducido con un Harness disciplinado supera a un equipo grande con Vibe Coding institucionalizado.
El Blueprint del Desarrollador IA-Nativo: stack de cuatro capas
Si fueras a diseñar el stack vertical del dev IA-Nativo, de lo más conceptual a lo más operacional, tendría exactamente cuatro capas. Cada una solo funciona si la de abajo está estabilizada. Saltarse una capa es la forma más común de que la adopción falle en silencio.
┌─────────────────────────────────────────────────────────────┐
│ 4. Governança: Code Reviews + Marketplaces Auditados │
├─────────────────────────────────────────────────────────────┤
│ 3. Fluxo Paralelo: Spec-Driven Development + Git Worktrees │
├─────────────────────────────────────────────────────────────┤
│ 2. Forte Convenção: Padrões nativos diretos (flat) │
├─────────────────────────────────────────────────────────────┤
│ 1. Monolitos Modulares: contexto unificado + alta vis. │
└─────────────────────────────────────────────────────────────┘
↓
O Harness Operacional
Capa 1, Monolitos Modulares
Contexto unificado y alta visibilidad. Sin eso, el agente queda ciego para el dominio del problema. No importa cuán sofisticadas sean las capas de arriba, si la 1 está fragmentada en microservicios por moda, el agente no ve lo suficiente para tomar buenas decisiones.
Capa 2, Fuerte Convención
Patrones nativos directos, estructuras flat siempre que sea posible. Si tu stack es Rails o Go, heredas la convención de la comunidad. Si es JS o Python, necesitas fabricar convención dentro del repositorio, y esa convención necesita ser rígida, documentada y auditada vía linter, no vía buena voluntad.
Capa 3, Flujo Paralelo
Spec-Driven Development + Git Worktrees. Es aquí donde vive la Parte 1 de este playbook: el método R.P.I., el ciclo de creación de Specs, el paralelismo vía worktrees. La Capa 3 es donde ocurre el trabajo diario. Sin las dos de abajo, no escala, terminas rehaciendo la misma decisión arquitectural en cada Spec porque la convención es floja.
Capa 4, Gobernanza
Code Reviews automatizados vía sub-agents, marketplaces auditados internamente, Skills curadas, MCPs verificados. La Capa 4 solo tiene sentido en organizaciones maduras, es donde "AI-Native" se vuelve "AI-Operations". Los equipos pequeños pueden pasar tres años solo con las tres primeras capas y estar perfectamente bien.
La lectura esencial: menos abstracción humana genera más contexto para la máquina. La complejidad no desaparece, se mueve de la arquitectura del código a la curaduría táctica del Harness. Construir un Harness es arquitectar dos veces: una vez el sistema, otra vez el ambiente que construye el sistema.
Costura con el Framework de Adopción en 7 fases
Todo lo que está arriba, Harness, R.P.I., 8 pilares, pipeline de refactorización, Khononov, Blueprint, es tecnología. La tecnología sin un método de adopción corporativa amplifica el caos en vez de generar productividad. Steply ya documentó este método de adopción en un post propio: el Framework de 7 Fases en 3 Movimientos (Fundación: Diagnóstico, AI Enablers, Piloto. Estructura: Cuellos de Botella, Adopción Progresiva. Sostenimiento: Gobernanza, Escala).
El puente es directo. Si el post de 7 fases responde "cómo adoptar IA en la empresa sin volverse caos amplificado", este playbook en dos partes responde "qué exactamente necesita el equipo construir y dominar técnicamente en cada fase". Las dos lecturas se complementan:
- Fundación (Fases 1-3) exige Diagnóstico + AI Enablers + Piloto. El playbook técnico que sostiene esta fase: los 4 errores del Vibe Coding (para el diagnóstico de madurez), las 3 capas de contexto (para los AI Enablers), el método R.P.I. (para el piloto).
- Estructura (Fases 4-5) exige Mapeo de Cuellos de Botella + Adopción Progresiva. El playbook técnico: los 8 pilares del Harness (la estructura de qué adoptar), Git Worktrees (paralelismo de adopción), Code Review agéntico (calidad durante la adopción).
- Sostenimiento (Fases 6-7) exige Gobernanza + Escala. El playbook técnico: un Marketplace de Skills auditadas, MCPs como gateway, monitoreo de Convention Drift, el Blueprint de 4 capas operacionalizado.
Sin el Framework de 7 fases, este playbook técnico es un arma sin manual. Sin este playbook técnico, el Framework de 7 fases es un proceso sin músculo. Los dos juntos son la oferta completa de adopción AI-Native que Steply consolida.
Reencuadre final: tres chequeos antes de cerrar el ciclo
Pregunta 1: ¿Tu repositorio pasa el test de Acoplamiento Tridimensional? Toma los tres pares de módulos que más generan bugs en producción. Clasifica cada par en los ejes Fuerza, Distancia, Volatilidad. Si algún par está en "Fuerza Alta + Distancia Alta + Volatilidad Alta", no tienes un problema de productividad, tienes un problema de topología. Ningún Harness compensa eso.
Pregunta 2: ¿Refactorizas siguiendo el pipeline de 4 etapas o todavía le tiras "refactoriza ese módulo" al agente y rezas? Si la respuesta es la segunda, estás en el Nivel 1 de madurez independientemente de lo que hayas implementado. Un pipeline disciplinado es lo que separa la refactorización asistida de la demolición asistida.
Pregunta 3: ¿Tus cuatro capas del Blueprint están estabilizadas en orden? La Capa 4 (Gobernanza) sin la Capa 1 (Monolito Modular) es teatro de proceso. La Capa 3 (Flujo Paralelo) sin la Capa 2 (Fuerte Convención) es caos paralelizado. Estabiliza de abajo hacia arriba.
Si las tres respuestas son honestas, tendrás un mapa concreto de lo que falta. No es "un modelo más". No es "un mejor prompt". Es infraestructura. Ya no escribes código, generas código. Y lo que genera código es el Harness, no el LLM.