El fin de semana leí un artículo de Boris Tane que resonó con mucha gente en la comunidad de desarrollo. La tesis: el ciclo de vida del desarrollo de software (SDLC); ese flujo de Requerimientos → Diseño → Implementación → Testing → Code Review → Despliegue → Monitoreo que todos conocemos — está muerto.
En su lugar, argumenta Tane, tenemos un loop colapsado: Intención → Construir → Observar → Repetir. Un developer le dice a un agente de IA qué quiere, el agente genera el código, el developer observa si funciona, y repite. Las fases intermedias se comprimieron o desaparecieron.
Tiene razón. Eso es exactamente lo que está pasando en la práctica. Pero hay un problema que el artículo identifica sin resolver; y que casi nadie está abordando con la seriedad que merece.
Lo que se perdió en el camino
El ciclo clásico de desarrollo no era solo burocracia. Entre esas fases "lentas" vivían capas de confianza que hacían viable llevar software a producción: code review detectaba errores de lógica, QA validaba que el software hiciera lo que el negocio necesitaba, security review atrapaba vulnerabilidades antes del deploy, y la coherencia arquitectónica se mantenía porque un humano con contexto del sistema completo tomaba las decisiones de diseño.
Cuando el loop se colapsó, esas capas fueron eliminadas. No reemplazadas; eliminadas.
El resultado es predecible, y los datos ya lo están confirmando.
Los datos que nadie quiere ver
Google publicó su reporte DORA 2025 con un hallazgo incómodo: equipos con 90% más adopción de herramientas de IA para desarrollo mostraron 9% más bugs, 91% más tiempo en code review, y 154% más tamaño de PRs.
Más herramientas de IA, más problemas.
Veracode reportó que el 45% del código generado por IA contiene fallas de seguridad. En Java la cifra supera el 70%. Checkmarx confirmó números similares con múltiples asistentes de código.
METR condujo un estudio controlado con developers open-source experimentados y encontró un 19% de ralentización neta cuando usaban herramientas de IA. No un 19% de aceleración — un 19% de ralentización. ¿La razón? "Impuestos ocultos": carga cognitiva por alternar entre codificar y prompting, esfuerzo de verificar código que parece correcto pero no lo es, y defectos sutiles introducidos que cuestan más tiempo del que ahorraron.
Anthropic, en su reporte de tendencias 2026, estimó que los developers solo pueden delegar completamente entre 0% y 20% de sus tareas a agentes. El resto requiere supervisión humana activa.
Esto no es un argumento contra la IA en el desarrollo. Es evidencia de que la velocidad sin capas de confianza no es velocidad; es deuda técnica acelerada.
Cuatro problemas que nadie está resolviendo como sistema
Cuando analizas qué se perdió al colapsar el ciclo, emergen cuatro problemas concretos:
1. Verificación semántica.
El agente genera lo que entendió, no necesariamente lo que el developer quiso. Hay un gap entre la intención original y el código producido. Los LLMs optimizan probabilidad local, no semántica global — lo dice un paper de CMU de 2025. El código resultante es plausible pero no siempre correcto.
2. Seguridad continua.
Sin security review humano, las vulnerabilidades pasan directo a producción. Los números de Veracode no son teóricos; son mediciones reales de código en producción. La solución no es volver al security review manual. Replit ya demostró que el enfoque viable es híbrido: análisis estático (tipo Semgrep) combinado con razonamiento de LLMs que entienden el contexto del proyecto.
3. Correctitud de negocio.
Que el código compile y pase los tests no significa que haga lo que el negocio necesita. Un agente puede implementar un flujo de checkout que técnicamente funciona pero cobra impuestos en estados exentos, o aplica descuentos que violan las reglas del negocio. No hay herramientas hoy que validen esto de forma automática en el loop de desarrollo.
4. Coherencia arquitectónica.
Mike Mason lo documentó bien a principios de 2026: los agentes toman decisiones localmente sensatas pero globalmente inconsistentes. Cada commit individual puede ser correcto, pero la suma de cientos de commits diarios degrada la arquitectura sin que nadie lo note hasta que es tarde. Los datos de DORA (154% más tamaño de PRs) son un síntoma directo de esto.
Lo que sí existe; y lo que falta
Hay movimiento en algunas de estas áreas. Spec-Driven Development (SDD) ya es un concepto formal con herramientas como Kiro, GitHub Spec Kit y Tessl; la idea de que las especificaciones se vuelvan artefactos ejecutables que guían la generación de código. En seguridad, papers como AgenticSCR muestran resultados prometedores con agentes detectores que logran 153% más detección que un LLM estático, con 81% menos ruido.
Pero hay dos gaps fundamentales.
-
Primero: cada solución ataca un problema aislado. Nadie está conectando verificación semántica + seguridad + correctitud de negocio + coherencia arquitectónica como un sistema integrado. Son cuatro manifestaciones del mismo problema; la ausencia de capas de confianza, y tratarlas por separado es como poner cuatro cerraduras en cuatro puertas distintas de una casa sin techo.
-
Segundo: las soluciones de observabilidad que existen (Braintrust valuada en $800M, por ejemplo) están enfocadas en observar sistemas de IA; cómo se comportan los LLMs, qué tan buenos son los outputs. Nadie está haciendo observabilidad de negocio para el código generado por agentes. La pregunta no es "¿El LLM generó buen código?" sino "¿El código que generó cumple las reglas del negocio?"
La hipótesis
Mi hipótesis es que es posible construir capas de confianza automatizadas que operen dentro del loop colapsado; sin frenar la velocidad, pero haciendo que esa velocidad sea sostenible. No se trata de volver al ciclo clásico. Se trata de reemplazar lo que se perdió con algo que funcione a la velocidad actual.
Esto implica que la spec intermedia; el documento que describe qué debe hacer una feature antes de que el agente la implemente, se convierte en el punto de integración. De esa spec se pueden derivar automáticamente: criterios de verificación semántica, restricciones de seguridad específicas del proyecto, assertions de negocio, e invariantes arquitectónicas. Un solo artefacto alimentando cuatro capas de validación.
¿Es viable? Honestamente, no lo sé todavía. Pero los componentes individuales ya existen — SDD para specs, SAST + LLMs para seguridad, patrones de orquestación multi-agente para coherencia. Lo que falta es la integración.
Y eso, creo, es donde está la oportunidad real.
Si estás trabajando con agentes de IA para desarrollo y has visto estos problemas de cerca, me interesa tu perspectiva. ¿Cómo estás manejando la calidad del código generado? ¿Qué capas de validación estás usando?
En Inteliside, creemos que la tecnología debe ser invisible, pero la confianza debe ser estructural. Si sientes que tu equipo está "corriendo más rápido" pero entregando resultados con más fricción, queremos escucharte.
¿Qué proceso operativo está frenando tu capacidad de escalar hoy? Cuéntanos tu caso en nuestro formulario de diagnóstico No buscamos venderte una herramienta, buscamos entender tu industria para diseñar la capa de confianza que tu negocio necesita.
Raúl Camacho CEO Inteliside S.A.S