Harness publicó una guía de ingeniería en dos partes sobre las prácticas que adoptó después de seis meses rediseñando su SDLC en torno a agentes de IA. El objetivo es control operacional. Harness vende infraestructura CI/CD; sus clientes la miden por confiabilidad, no por velocidad de iteración.
Los cuatro pilares mapean dónde fallan los sistemas agénticos en la práctica. Pilar uno: desarrollo basado en especificaciones. Todas las especificaciones de producto, tecnología, UI y pruebas viven en repositorios con control de versiones (Harness usa su propio Code Repository). Los agentes de IA necesitan contexto estructurado y co-ubicado. Las páginas de Confluence no funcionan. Resultado: los equipos prototipos interfaces de UI en 30 minutos en lugar de semanas porque las especificaciones son legibles por máquina y siempre actuales.
Pilar dos cuantifica dónde pertenecen los agentes. Harness midió 15–20% del trabajo de ingeniería como totalmente autónomo—ticket Jira a pull request—mientras que 80% permanece asistido por IA, con desarrolladores usando agentes como herramientas en lugar de delegar flujos de trabajo completos. Cuatro de cada cinco tareas aún requieren supervisión humana en el bucle. La arquitectura combina microservicios tradicionales con endpoints de agentes expuestos a través de Model Context Protocol. Cada agente tiene permisos limitados y una única responsabilidad: un agente de revisión de código no puede implementar cambios, un agente de pruebas no puede tocar producción, un agente de especificación no tiene autoridad sobre la arquitectura. Los agentes especializados superan a los omniscientes sobrecargados en costo y confiabilidad.
Las pruebas revelan la brecha más grande. La guía especifica seis capas: verificación de front-end (Vitest, Playwright), pruebas de producto y API (unitarias, integración, funcionales), pruebas de eficacia del agente contra baselines, verificación de datos para detectar fuentes de alucinación, monitoreo continuo de eficacia en producción y bucles de retroalimentación agéntica. Capa cinco—monitoreo continuo de eficacia—es la más omitida y más dolorosa. Cambie un prompt del sistema, actualice una base de conocimiento o intercambie una versión del modelo: la calidad de salida del agente se degrada silenciosamente sin un harness de monitoreo observándola.
Harness adoptó Revisiones de Preparación Operacional del playbook de hiperscaladores. Los ORR se ejecutan inmediatamente después de la revisión de diseño, no de desarrollo, y producen una lista de verificación con evidencia documentada. La guía encuadra esta evidencia—resultados de pruebas de carga, resultados de game day, aprobaciones de auditoría de seguridad—como un template que los equipos deben seguir, no cifras de Harness. Se aplican niveles de severidad: los elementos altos bloquean el lanzamiento, los elementos medios requieren resolución en 90 días, los elementos bajos van al backlog. Post-lanzamiento, los equipos de servicio se reúnen semanalmente para revisar la salud del data-plane y control-plane, métricas de clientes y RCAs.
Forrester descubrió que las mejoras de IA enfocadas solo en codificación de 30–40% a menudo se traducen en menos del 10% de ganancia de productividad de todo el equipo cuando la planificación, las pruebas y los pipelines de lanzamiento permanecen manuales. Los cuellos de botella se desplazan en lugar de desaparecer.
Los arquitectos que expanden la autonomía del agente deben instrumentar monitoreo de eficacia desde el primer día, imponer el scope del agente en la capa de permisos, no en la capa de prompt, y tratar los ORR como una función forzante para surfacing de preocupaciones operacionales antes de que el código se envíe.