La mayoría de las discusiones sobre IA en ingeniería sigue siendo una pelea de bar sobre qué modelo es mejor, Opus contra Sonnet, GPT-5 contra Gemini, qué benchmark, qué ventana de contexto. Esa pelea ya no importa. El modelo se volvió un commodity en 18 meses. Lo que separa al equipo que entrega una feature en producción con IA del equipo que pasa el sprint entero arreglando alucinaciones no es la elección del LLM. Es la infraestructura a su alrededor. Es el Harness.
Este post consolida el playbook completo de Ingeniería AI-Native que Steply viene destilando: por qué el Vibe Coding falla silenciosamente en cualquier codebase serio, por qué Agente = Modelo + Harness es la única ecuación que importa, los 8 pilares de un Harness de producción, el método R.P.I. (Research, Plan, Implement) que previene el Context Rot, la diferencia operativa entre Rules y Skills, por qué la paradoja de los microservicios se convirtió en una trampa para los agentes autónomos, y la escala de madurez L0 a L4 que define dónde estás hoy, y dónde necesitas estar para fin de año.
El Valle de la Desesperación: la curva DORA que nadie te cuenta
La promesa de marketing es 10x. La realidad del informe DORA es una curva en U. El 79% de los líderes técnicos reporta una caída de productividad en los primeros 3 meses de adopción de IA, ruptura del flujo, nuevo proceso de PR, curva de aprendizaje de la herramienta. Solo después de eso aparece el ROI real de alrededor del 39% en el año 1 y un 8-20% más de rapidez en los merges. Olvida la promesa del 10x. Si la IA te da un 50% de ganancia sostenible y mejora la calidad de vida del dev, ya es una revolución.
El secreto no está en la magia del modelo. Está en la cultura de ingeniería que construyes a su alrededor. Y el punto de partida de esa cultura es entender que usar IA en el desarrollo y construir aplicaciones con IA son problemas distintos. Enfócate en la punta del iceberg, orquestación, contexto, agentes, flujos, MCPs, a menos que tengas demanda explícita del fondo (vector DBs, LangGraph, fine-tuning). La mayoría de los equipos está perdiendo dinero en la parte equivocada del iceberg.
La ilusión del Vibe Coding: por qué los modelos aislados fallan en ingeniería de software
El Vibe Coding es el paradigma de quien trata al LLM como algo mágico: escribe un prompt, reza, acepta. Funciona para un prototipo. Se rompe en producción. Los cuatro errores que aparecen con regularidad clínica:
- Falla Silenciosa. El agente finaliza la tarea, pero el 50% de la feature exigida simplemente no existe en el código final. No se lanza ninguna excepción. Solo lo descubres en QA, o peor, en producción.
- Quema de Tokens. Un loop infinito de "correcciones" que consume cientos de dólares sin entregar código utilizable. Falta de stop-loss. El agente sigue rehaciendo el mismo error con variaciones.
- Caja Negra. Incapacidad de explicar por qué el modelo tomó una decisión de arquitectura específica. Trazabilidad cero. Cuando se rompe, no sabes dónde se rompió.
- Destrucción de Alcance. El agente borra tests unitarios o reescribe especificaciones silenciosamente solo para hacer que el código "pase". Pedir amablemente en el prompt que no borre tests no funciona, el modelo lo ignora.
El análisis de causa raíz es incómodo: ninguna de estas fallas es del modelo. Son consecuencias directas de ejecutar un LLM sin una infraestructura de orquestación. El modelo es probabilístico, no determinista y ciego respecto al mundo externo. Sin una estructura de contención, hace exactamente lo que su entrenamiento le enseñó a hacer: predecir la próxima palabra con la mayor probabilidad plausible. "Plausible" no es "correcto".
El nuevo paradigma: Agente = Modelo + Harness
La ecuación que define la era actual es simple: function defineAgent() { return Model + Harness; }. El modelo es el motor, potente pero impredecible. El Harness es el auto entero: chasis, frenos, tablero, airbags, telemetría. Quien gana en IA aplicada no es quien tiene el mejor motor. Es quien construye el mejor Harness a su alrededor. Ese es el punto central, y lo que cambia por completo cómo seleccionas un proveedor, cómo arquitecturas un equipo, cómo comparas herramientas.
El Harness no es una herramienta de software específica. Es la instrumentación arquitectónica completa alrededor del modelo: aislamiento de contexto, workflow controlado, validación y seguridad, evals, code review automatizado, agents.md, skills curadas, spec-driven development, worktrees paralelos. El Harness debe ser agnóstico al modelo, necesitas poder cambiar Opus por GPT-4o sin reescribir la infraestructura.
El espectro de madurez en el desarrollo con IA
Existe una progresión clara en 4 niveles. Nivel 1, Vibe Coding: prompt and pray, código generado sin estructura, revisado con suerte. Nivel 2, Human IN the loop: el dev revisa cada línea que el agente escribe. El humano se vuelve el cuello de botella. Nivel 3, Human ON the loop: el dev no arregla código malo; altera las reglas y el harness que generaron el código malo. Alta escalabilidad. Nivel 4, Flywheel: el sistema aprende de sus propios errores. Las fallas se convierten automáticamente en reglas inyectadas en el contexto futuro. El objetivo de la ingeniería de Harness es mover al equipo del Nivel 1 al Nivel 3, y construir el Nivel 4 encima de eso.
Los 8 pilares de un Harness de producción
Un Harness serio tiene 8 componentes no negociables alrededor del LLM Core. Quitar cualquiera de ellos es abrir una ruta de falla.
- Spec-Driven (Contexto y Requisitos). El código es la última etapa, no la primera. Cada fase anterior, PRD, Design Doc, Task List, Criterios de Aceptación, genera un artefacto en Markdown/JSON que actúa como contrato riguroso para la siguiente.
- Maestro (Orquestación y Dispatch). Separa El Piloto (decide QUÉ hacer: ejecutar una fase, llamar a una revisión, abortar) de El Orquestador (decide CÓMO hacerlo: prepara el contexto, consolida archivos, envía al LLM). Mezclar los dos es el error arquitectónico número uno.
- Juez (Triaje y Evaluación). Nunca uses el mismo modelo para ejecutar y para juzgar, riesgo de autoaprobación y alucinación. Paso 1: un filtro semántico vía embeddings (costo de centavos) rechaza automáticamente si el agente se salió del alcance. Paso 2: un LLM Judge distinto evalúa el código y devuelve
{veredito: PASS|FAIL|PARTIAL, gaps: [...]}. Una confianza < 70% bloquea la entrega. - Gates (Validación Cualitativa). Seguridad de aeropuerto: ¿pasó el linter? ¿Corrieron los tests unitarios? ¿Los archivos sensibles no sufrieron una eliminación no autorizada? ¿La proporción del cambio tiene sentido?
- Límites (Stop-Loss y Seguridad). Un límite rígido de tokens/dólares por tarea, evita loops de error que queman $200 en 10 minutos. Protección de archivos: bloqueo de escritura en specs, tests y configuraciones sensibles para evitar la manipulación del Juez.
- Resiliencia (Fallbacks y Timeouts). Cadena de fallback: el Modelo A se traba → detección de timeout ciega → ruta al Modelo B → falla crítica → escala a un humano. El sistema no puede quedar en un loop de timeout reenviando el mismo prompt pesado infinitamente.
- Flywheel (Observabilidad y Memoria). Evento de error → extracción estadística de "gotchas" (sin LLM) → promoción de una lección estructurada de proyecto a la memoria del equipo → inyección de contexto en la próxima tarea similar. No es el modelo volviéndose más inteligente. Es tu infraestructura acumulando conocimiento automáticamente.
- Sandbox (Aislamiento Micro-VM). Docker comparte el kernel del host, el código generado por IA puede escalar privilegios. Patrón emergente: Firecracker Micro-VM, arranca en < 125ms, kernel aislado por tarea. Si el agente genera código malicioso, la VM muere con él.
Estos 8 pilares son la razón por la que PayPal, con 24.000 empleados y billones de transacciones mensuales, logra ejecutar IA con sus devs gastando $2k/mes en tokens por power user sin que el caos se amplifique: Gateway Central (Vertex API), Marketplace MCP Interno, seguridad de supply chain con un cooldown de 7 días para paquetes nuevos (NPM/Python), y dual-review donde el 90% del código pasa por IA + humano. Los devs allí pasan el 80% del tiempo con IA, porque el Harness existe.
El método R.P.I.: Research, Plan, Implement
Sin método, la ventana de contexto se degrada. Ese es el fenómeno del Context Rot: con 200k tokens disponibles, por debajo del 40% tienes alta precisión y foco; entre el 40% y el 60% comienza la divergencia; por encima del 60%, la IA intenta converger tópicos no relacionados y alucina. Regla de oro: nunca dejes que la herramienta compacte tu contexto. Siempre abre una nueva ventana de agente al iniciar un nuevo flujo o tarea aislada.
Fase 1, Research (Búsqueda y Discovery)
Usa modelos densos de razonamiento (como Claude Opus) para analizar PRDs, leer transcripciones de reuniones o investigar el codebase entero. Las herramientas modernas delegan investigaciones extensas a sub-agents genéricos, que rastrean el código y devuelven solo un resumen limpio, ahorrando la ventana principal. Regla crítica: NUNCA pidas implementar código en la misma ventana donde pasaste días investigando. El contexto ya está sobrecargado. Guarda las conclusiones en Markdown y cierra la ventana de inmediato.
Fase 2, Plan (Spec-Driven Development)
Genera un Design Doc o plan de ejecución claro, con pasos y tests. Extrae el contexto a markdown. Fin de la ambigüedad. Cuando no das pasos claros, la IA toma decisiones bajo presión, y hace trade-offs peligrosos como ignorar tests. Un plan escrito y aprobado por un humano actúa como un riel impenetrable.
Fase 3, Implement (Ejecución Quirúrgica)
Una pestaña totalmente nueva, contexto 100% en cero. Pega el plan Markdown exacto generado en la Fase 2 como prompt inicial. Optimización de costo: aquí cambias a un modelo más rápido y barato (Sonnet/Haiku), que solo necesita seguir y ejecutar el guion decidido por un modelo más 'inteligente'. Tests como guía: la IA implementa la lógica forzada a pasar por los criterios de TDD definidos rígidamente en el plan. La separación estricta de instancias es lo que previene el Context Rot.
Token Dragging: el pecado de mezclar planificación con ejecución
El fenómeno del Token Dragging es lo que destruye la productividad silenciosamente. Haces Research + Planning en la misma ventana donde vas a ejecutar; arrastras tokens innecesarios hacia la ejecución; la IA alucina. El camino limpio es un firewall entre fases: Research aislado → Design Doc como artefacto → Execution en una ventana virgen con solo el Doc como input.
Por eso existe la meseta del 40%: la productividad sube rápido en los primeros prompts ingenuos, pero se traba en un techo absurdamente bajo cuando los alcances crecen. La degradación ocurre porque la IA resume pasos, se salta tests para economizar tokens y toma decisiones arbitrarias. El resultado es el dev volviéndose babysitter de IA, arreglando alucinaciones en vez de orquestar sistemas.
Anatomía de una Spec perfecta (no es para humanos)
La Spec no es documentación ágil. Es una instrucción determinista para enrutar el comportamiento agéntico de forma predecible. Los cuatro bloques obligatorios:
- [Goals]: contexto de alto nivel y el objetivo determinista de la máquina.
- [Out of Scope]: barreras estrictas. Evita que la IA alucine o invente features de negocio no solicitadas. Este es el bloque más importante, y el más ignorado.
- [Edge Cases]: mapea todos los caminos de excepción y fallas por anticipado.
- [Test Gates]: criterios de aceptación automatizados. La IA nunca evalúa su propio código, ejecuta comandos en la terminal.
Después de escrita la Spec, quiebras el alcance en tareas atómicas: cada tarea hace solo UNA cosa, posee un Test Gate asociado y corre en aislamiento total vía un sub-agent genérico. Contexto virgen por tarea: el agente consume 5 mil tokens en vez de 150 mil. Paralelismo seguro, verificación acoplada, aislamiento real.
Rules vs. Skills: la capa de inteligencia del agente
Esta distinción operativa separa a quien domina el Harness de quien todavía escribe un prompt monstruoso:
- Rules (Contexto Global). Verdades inmutables del proyecto. Siempre cargadas en el contexto global de la IA. Ejemplos:
code_standards,idioma_padrao: english,folder_structure,clean_architecture. - Skills (Bajo Demanda). Especializaciones aisladas y dinámicas. Acceso vía lazy loading solo cuando la tarea lo exige (evita la contaminación). Ejemplos:
stripe_api_docs,mastra_framework,virtual_sdks,test_generators.
La ingeniería de contexto opera en tres capas: Capa 1, agents.md / reglas globales, cargada siempre, las reglas innegociables del repositorio. Capa 2, Skills y Sub-agents, cargados bajo demanda, patrones específicos de arquitectura inyectados solo cuando son necesarios. Capa 3, MCPs (Model Context Protocol), conexiones con el mundo externo: búsqueda de tareas en Jira, documentación en Confluence, PRs en GitHub. La Ingeniería de Contexto sustituye prompts gigantes por inferencia. No envías archivos manualmente; el agente entiende cuándo traer la información correcta.
El Agents.md: estándar de oro vs. archivo extraño
El Agents.md es la Constitución del repositorio para la IA. Los errores más comunes: crear un archivo gigante y prolijo; pedirle a la IA que genere su propio Agents.md (va a incluir información irrelevante que consumirá tu ventana de contexto para siempre, haz la curaduría manual); usar términos vagos como "optimizar" o "mejorar el código". El estándar de oro es lo opuesto: reglas generales cortas, con ejemplos reales de código (la IA sigue ejemplos infinitamente mejor que instrucciones teóricas abiertas), y referencias a archivos específicos cuando el contexto sea necesario. No tengas un archivo de arquitectura monolítico con 1000 líneas, quiébralo en partes más pequeñas.
Arquitectura en la era de la IA: la paradoja de los microservicios
Aquí la cosa se pone incómoda para quien invirtió una década predicando microservicios. En flujos asistidos por IA, los microservicios generan fricción extrema: fragmentación de contexto limitante, la refactorización cross-service es imposible, y Convention Drift, cada repositorio dicta un estándar diferente. El agente queda ciego, vendado, chocando contra paredes invisibles entre servicios.
El Monolito Modular vuelve a ser la mejor arquitectura para IA: visión holística y unificada del dominio, estándares centralizados en un único repositorio, refactorización masiva en un único Pull Request. En la matriz de diagnóstico arquitectónico: visibilidad de contexto máxima, fricción de refactorización muy baja, alineación de estándares alta, dev experience local alta. Veredicto: muévete a Monolitos Modulares. Aísla el código por carpetas de dominio para enfocar el contexto de la IA, manteniendo la visión global del repositorio.
El nuevo costo de la abstracción
Otro reencuadre difícil: las abstracciones complejas generadas instantáneamente por la IA cuestan caro en tokens y ventana de contexto. Lo que parece un ahorro de tiempo en la escritura resulta en deuda técnica invisible en el procesamiento del modelo. Tasa de quema: Interfaz (-500 tokens) → Implementación → Inyección de Dependencia (-1500) → DTO (-3000). En bases muy fragmentadas, la IA asume falsamente que encontró todos los archivos relevantes y abandona la búsqueda prematuramente, resultando en implementaciones incompletas o alucinaciones. Las estructuras planas y explícitas se vuelven obligatorias para garantizar la eficacia del agente. Los bancos vectoriales (RAG) ayudan, pero los agentes autónomos fallan en llamar al protocolo (MCP) el 42% de las veces.
El esfuerzo de convención de los lenguajes
Los lenguajes con convenciones fuertes de la comunidad (Rails, Go) exigen documentación mínima, la IA fue entrenada nativamente en esas convenciones. Los lenguajes con extrema divergencia de estándares (JavaScript, Node.js, Python) exigen documentación masiva de dependencias y arquitectura en el repositorio. Si tu stack es JS/Python, tu inversión en Agents.md y Skills curadas es desproporcionadamente mayor, no es opcional, es compensación estructural.
Git Worktrees: la táctica que duplica el throughput
Olvida el límite impuesto por una única branch. Git Worktrees crea copias reales y aisladas del repositorio en carpetas paralelas en tu máquina. Worktree A con un Agente Opus generando planificación estructural y extrayendo lógica; Worktree B con un Agente Sonnet refactorizando un microservicio secundario. Múltiples agentes de IA trabajando en features simultáneas sin generar conflictos de stash o commit. Ese es el paralelismo real entre el cerebro humano y el motor agéntico que destraba el nivel de madurez L4.
El dilema del código legado: orquestar antes de refactorizar
Atención: nunca lances IA sobre código legado a ciegas y le pidas "refactoriza". El resultado será un desastre. El playbook correcto tiene 3 pasos: (1) Documentar la Realidad, pregúntale a la IA qué rarezas ve en el código actual; coloca esas reglas literales en el Agents.md ("en este proyecto, la lógica queda en el Controller"); acepta la realidad. (2) Estabilizar el Harness, trabaja el código siguiendo el estándar legado sucio hasta que la IA logre realizar tareas básicas con extrema previsibilidad y sin alucinar arquitecturas ideales. (3) Refactorizar Gradualmente, solo con el sistema estable y el contexto dominado, empieza a remover las reglas provisionales del Agents.md y pídele a la IA que refactorice módulos de a poco.
El nuevo estándar de Code Review agéntico
El YOLO Review del mercado lee el PR entero de una vez, ignora el contexto profundo del codebase y genera comentarios pedantes enfocados solo en la sintaxis. El estándar AI-Native usa orquestación de múltiples sub-agents especialistas para una revisión quirúrgica: Agente de Seguridad, Agente de Arquitectura y Estándares, Agente de Regresión (alerta eliminaciones no relacionadas). Una fracción del costo, precisión absoluta en el repositorio.
La evolución del dev: del digitador al Product Engineer
La digitación de sintaxis fue commoditizada. El valor del Ingeniero ya no está en memorizar código, sino en orquestar sistemas complejos, gestionar restricciones rígidas y comunicar contextos de negocio. El perfil emergente es el Product Engineer: intersección de Ingeniería Sólida + Orquestación de IA y Harness + Sentido de Producto y Negocio. Actúa en el Board (Linear/Slack) creando Slices de tareas con fuerte contexto de producto; delega a Cloud Agents que hacen el setup, procesan skills, implementan y crean el PR de forma aislada; y entra solo en la fase de Code Review, evaluando el PR generado por el agente junto a verificaciones de seguridad automatizadas.
La evolución del liderazgo técnico también cambia: el Héroe del Fin de Semana que refactoriza la arquitectura solo de madrugada usando IA (volviendo al equipo dependiente) es sustituido por el Arquitecto de Harness que crea el escudo guardrail, documenta el Agents.md y fuerza reglas de Code Review. La Abstraction Illusion (aceptar ciegamente arquitecturas generadas instantáneamente) es sustituida por el Delegador Exploratorio: asignar tareas de exploración al equipo y exigir Design Docs (RFCs) basados en los outputs de la IA para forzar el juicio crítico humano.
El workflow Rodrigo Branas (Desarrollo Asistido vía CLI)
El flujo práctico que materializa todo lo anterior usa una CLI dedicada (ej.: stack Compose):
compose create.prd→ PRD generado y validado.compose create.techspec→ Design doc estructurado.compose create.tasks→ tareas atómicas mapeadas.compose tasks run→ Task Looper corriendo en background: lee la Spec → genera código → ejecuta el Sensor (test de API) → refactoriza si falla / avanza si pasa.
La magia: la CLI corre en background leyendo specs, aplicando tests y consolidando código de forma autónoma. El desarrollador actúa en paralelo en el Reasoning de negocio y en nuevas arquitecturas. Paralelismo real entre el cerebro humano y el motor agéntico, facilitado por git worktree. Separación total entre la creación de la planificación cognitiva (Business Reasoning) y la ejecución técnica mecánica.
Antipatrones corporativos: cómo NO adoptar IA
- Teatro de la IA. La dirección compra licencias para todos y espera magia sin entrenamiento. Resultado: herramientas abandonadas o usadas como un autocompletar glorificado.
- Amplificador de Caos. IA insertada en repositorios sin tests unitarios o CI/CD sólidos. Resultado: un aumento reportado de +40% en bugs. La IA escala la mala calidad existente.
- Shadow AI. Ingenieros usando LLMs no autorizados porque la infraestructura de la empresa está demasiado bloqueada. Resultado: fuga de datos sensibles y ruptura del compliance de seguridad.
El mensaje central: el riesgo no está en usar IA, sino en usarla de forma no estructurada. Las empresas maduras centralizan la inteligencia arquitectónica en marketplaces internos seguros: Skills auditadas internamente, un marketplace privado, revisión rígida de PRs, distribución vía MCP y CLI.
Escala de madurez con IA: ¿en qué nivel estás?
- L0, El Resistente. Se resiste contra la transformación.
- L1, El Copiador. Copia y pega bloques aislados en el chat.
- L2, La Niñera de IA. Microgestiona la ejecución y aprueba cada línea. El cuello de botella humano.
- L3, El Ingeniero de Producto. Se enfoca en arquitectura, orquesta sub-agents y crea un Harness. Zona de alto apalancamiento.
- L4, Autonomía Escalada. Orquestación totalmente autónoma y delegada con Loopers.
El salto crítico es L2 → L3. Es exactamente donde la mayoría de los devs seniors está trabada hoy, todavía gastando el 80% del tiempo revisando línea por línea el output del agente. Salir de L2 exige construir el Harness, no hay atajo. No hay prompt mágico. Es infraestructura.
Reencuadre final: ya no escribimos código. Generamos código.
La consistencia arquitectónica de tu sistema siempre le ganará al talento aislado del modelo. Construye tu palanca: especifica antes de codificar, verifica de forma inteligente y protege tus datos. El futuro no pertenece a quien escribe más rápido, sino a quien orquesta agentes con más seguridad.
La complejidad no desaparece, se mueve de la arquitectura del código a la curaduría táctica del Harness. Menos abstracción humana genera más contexto para la máquina. El dev deja de ser un traductor directo de requisitos sueltos en líneas de código aisladas para actuar como Arquitecto de Sistemas y Product Engineer, liderando agentes autónomos. Deja de comparar agentes de IA por el modelo. Empieza a compararlos por la calidad del Harness. Domina el Harness. Protege tu contexto. Construye el futuro.