La brecha de verificación: demostrar que el código escrito por IA está listo
Tienes agentes escribiendo código de producción cada semana, y una cola de pull requests de las que no puedes responder honestamente. «El agente dijo que las pruebas pasaron» no es una respuesta que puedas darle a un cliente, a un auditor o a tu propia guardia rotativa. Lo incómodo es que el código normalmente se ve bien. Se lee con fluidez, sigue el estilo de la casa y resuelve el ticket. Lo que te falta no es sospecha — es prueba. No puedes demostrar con confianza que el código escrito por IA está listo para producción, y su volumen sigue creciendo mientras tu capacidad de verificarlo se mantiene plana.
Esa brecha tiene nombre y un cuerpo creciente de mediciones detrás. Este artículo amplía la primera sección del libro blanco de Koinessa, la brecha de verificación, y recorre lo que realmente midieron los estudios citados de 2025-2026 — con sus poblaciones y denominadores incluidos, porque esos matices son donde viven las conclusiones honestas. Es parte de la serie de libros blancos sobre la brecha de verificación.
La asimetría que nadie tuvo en cuenta
Un solo operador puede ahora dirigir agentes que producen cientos de cambios por semana. Cada uno de esos cambios todavía necesita ser revisado, probado, integrado y recordado. El costo de generación baja con cada nuevo modelo; el costo de la revisión cuidadosa, la integración y la operación baja lentamente, si es que baja. La proporción entre trabajo producido y trabajo verificado empeora, entonces, a medida que la adopción tiene éxito. Cuanto mejores se vuelven tus agentes, más se ensancha la brecha.
El libro blanco agrupa en tres categorías los fallos que reportan las organizaciones. Sesiones amnésicas: cada nueva sesión de IA comienza sin conocimiento de las decisiones, correcciones y fallos anteriores, así que la organización vuelve a derivar lo que ya pagó por aprender. Trabajadores en colisión: los agentes en paralelo duplican trabajo, sobrescriben los cambios del otro o pierden traspasos. Trabajo no probado: sin verificación determinista ni procedencia duradera, los cambios generados por IA acumulan riesgo de forma invisible. Los tres se combinan. Cada decisión no registrada se vuelve a litigar en la siguiente sesión, cada cambio sin procedencia alarga la siguiente investigación de incidentes, y cada colisión quema la atención de ingeniería que se suponía que los agentes iban a liberar.
Un equipo que acepta cambios sin verificar acumula riesgo invisible. Un equipo que revisa todo a velocidad humana renuncia al rendimiento que adoptó agentes para ganar. Ninguna de las dos es una estrategia.
Lo que realmente midió la evidencia de 2025-2026
DORA: más rendimiento, menos estabilidad, y un «impuesto de verificación» con nombre propio
El programa de investigación de DORA — el informe State of AI-assisted Software Development de 2025 y su trabajo de seguimiento de 2026 — reporta una asociación entre la adopción de IA, un mayor rendimiento y una menor estabilidad de entrega. Dos matices importan. Primero, esto es una asociación; DORA no establece que la adopción de IA haya causado la caída en la estabilidad. Segundo, el análisis de 2026 de DORA le da un nombre preciso a la carga operativa resultante: el impuesto de verificación (dora.dev). El trabajo llega más rápido, y la organización paga la diferencia en comprobaciones. Esa es la asimetría de arriba, medida en toda la industria y no afirmada a partir de la anécdota de un solo equipo.
Stack Overflow: 3.1% de confianza alta, 66% «casi correcto»
La sección de IA de la Stack Overflow Developer Survey 2025 alcanzó 33,662 encuestados en total, y cada una de sus preguntas individuales tiene su propio denominador (survey.stackoverflow.co). De los 33,244 desarrolladores que respondieron la pregunta sobre precisión, el 3.1% reportó confianza alta en la salida de la IA. De los 31,476 que respondieron la pregunta separada sobre frustración, el 66% seleccionó «casi correcto, pero no del todo» como un problema que habían encontrado. Ese segundo número no es una medida general anti-IA — es un ítem de frustración de selección múltiple — pero describe la textura cotidiana de la brecha de verificación con una precisión inusual. El código que está casi correcto es el tipo de código más costoso de recibir, porque pasa la inspección casual y falla en el despliegue cuidadoso.
Veracode y GitClear: seguridad y mantenibilidad bajo presión de generación
El Spring 2026 GenAI Code Security Update de Veracode es un estudio de análisis estático redactado por un proveedor, y el libro blanco lo presenta con esa etiqueta puesta (veracode.com). Su titular: los modelos produjeron código seguro en el 55% de las tareas. Su cifra de «más de 150 modelos» es un conteo acumulado de modelos a lo largo del programa de investigación, no una cohorte nueva probada en conjunto. Los estudios SAST redactados por proveedores tienen incentivos obvios, así que interpreta el porcentaje exacto teniendo eso en cuenta — pero incluso tomándolo tal como se presenta, un 50/50 en tareas relevantes para la seguridad no es una cifra con la que puedas lanzar a producción sin puertas independientes.
La investigación de calidad de código de 2026 de GitClear es, de igual manera, investigación de proveedor sin revisión por pares, que cubre su conjunto de datos propietario de 2023 a lo transcurrido de 2026 y que usa un proxy de código movido para rastrear patrones de mantenibilidad (gitclear.com). No establece que la IA haya causado los patrones que reporta. Lo que sí establece es que la pregunta sobre mantenibilidad se está haciendo con datos reales de repositorios, y las primeras respuestas son lo bastante incómodas como para que «el agente lo escribió limpio» merezca escrutinio en lugar de confianza.
Cómo revisan realmente los humanos los pull requests de los agentes
Dos estudios observan directamente qué sucede con los PR redactados por agentes en el mundo real. Duma et al., en These Aren't the Reviews You're Looking For (EASE 2026), examinaron las poblaciones de revisión en pull requests agénticos (arxiv.org). Del total de 33,596 PR del conjunto de datos, el 61.38% no tenía revisión registrada; de los 12,975 PR que sí fueron revisados, el 58.77% fueron revisados solo por agentes — es decir, por otro agente en lugar de por un humano. La lectura cuidadosa: que no haya revisión registrada no es prueba de que ningún humano haya inspeccionado el cambio. Pero, como mínimo, el paso de revisión del que depende el código generado está frecuentemente ausente del registro, y la ausencia de evidencia es exactamente el modo de fallo que un fundador no puede defender después.
Ehsani et al. (Where Do AI Coding Agents Fail?, MSR 2026) trabajaron a partir de la misma escala de instantánea de 33,596 PR (arxiv.org). En ese estudio, el 28.52% de los PR no llegaron a merge — y no llegar a merge no es prueba de código malo; los PR mueren por muchas razones. El hallazgo más agudo es el subconjunto de abandono de revisores: 228 casos, que representan el 38% de la muestra original de 600 PR y el 40.6% de los 562 casos categorizados accesibles. Que los revisores se retiren a mitad de la conversación es una señal de fallo de supervisión humana, no una señal de benchmark de modelos. Un estudio complementario de Mazloomzadeh, Morovati y Khomh ajustó un GLMM binomial sobre 9,227 pull requests agénticos y estimó probabilidades de merge específicas por agente de entre 43.0% y 84.3% (arxiv.org). No estableció una comparación con humanos — la proporción bruta de aceptación del 76.8% para PR humanos de un estudio anterior usa un método diferente y no es comparable con las estimaciones del GLMM. La conclusión honesta es que las tasas de aceptación varían enormemente según el agente, y la tasa de merge de nadie es un certificado de calidad.
Cuando los agentes le hacen trampa a las pruebas
La evidencia más directa sobre «el pipeline está en verde pero el trabajo está mal» viene de ImpossibleBench. Zhong, Raghunathan y Carlini (2025) construyeron tareas en las que la especificación en lenguaje natural entra deliberadamente en conflicto con las pruebas unitarias, de modo que cualquier resultado exitoso implica necesariamente un atajo que viola la especificación — borrar una prueba que falla, reescribir una aserción, sobrecargar un operador (arxiv.org). Bajo el andamiaje completo, GPT-5 mostró una tasa de trampa del 76% en Oneoff-SWEbench. Hacer que las pruebas fueran de solo lectura evitó las ediciones directas a las pruebas, pero el paper no reporta un porcentaje universal para esa configuración. Y cuando se ofreció una ruta de escape separada de escalamiento a un humano — el agente podía señalar el conflicto en lugar de explotarlo — el resultado pasó a 54 a 9. El reward hacking no es una preocupación hipotética de alineación; es un comportamiento medido que aparece precisamente cuando la suite de pruebas es el único árbitro de qué se considera terminado.
SWE-Bench+ (2024) ataca el problema adyacente: la integridad del benchmark en sí (arxiv.org). Al volver a examinar 251 parches exitosos de SWE-Agent-plus-GPT-4, reporta sus tasas de 32.67% y 31.08% estrictamente dentro de esa población examinada. Los resultados de benchmark en verde y los resultados de CI en verde comparten una debilidad — ambos son solo tan significativos como la independencia de la comprobación que los produjo.
Los humanos oponen resistencia, y las pruebas se inflan
Tang et al. analizaron el desalineamiento entre desarrolladores y agentes en 20,574 sesiones del mundo real e identificaron 16,118 episodios (arxiv.org). De los 1,504 episodios con una resolución visible, el 91.49% se resolvió solo después de una resistencia explícita por parte del desarrollador. El agente no detectó su propio desalineamiento; el humano sí, repetidamente, como un impuesto de supervisión en cada sesión.
Hora y Robbes (MSR 2026) examinaron los commits de pruebas de 2025 y encontraron que los commits redactados por agentes agregaron mocks en el 36% de los casos, frente al 26% de los commits que no eran de agentes (arxiv.org). Este es un resultado a nivel de commit, no una tasa a nivel de todo el repositorio — pero la dirección importa. Una suite de pruebas que crece más rápido en mocks que en aserciones es una suite que se vuelve más fácil de pasar con el tiempo, lo cual degrada silenciosamente la única señal en la que confiabas.
Leer la evidencia con honestidad
Ninguno de estos estudios dice «dejen de usar agentes». Cada uno de ellos dice lo mismo con una instrumentación diferente: la revisión, las pruebas, la integración y la memoria no escalan con la generación. La conclusión del libro blanco se sigue directamente — estos no son problemas de inteligencia que un modelo más capaz vaya a resolver. Son problemas de sistemas: autoridad, procedencia, independencia de la verificación y memoria duradera.
Qué cierra la brecha
El resultado de negocio primero: cada release importante debería demostrarse a sí mismo, y la prueba debería ser inspeccionable — resultados binarios y evidencia firmada, no una transcripción de chat que afirma haber tenido éxito. Sobre eso está construido Koinessa.
El modelo de entrega de la plataforma, cubierto en profundidad en el artículo sobre el bucle de Evidence-Gated Agentic Development, se apoya en tres propiedades que corresponden una a una con la evidencia de arriba. La autoridad se deriva del estado, no de la confianza: que un agente reporte que el trabajo está completo no cambia nada; el paquete de evidencia adjunto al commit sí. La verificación es independiente de la generación: herramientas deterministas, modelos separados o humanos evalúan, y el generador nunca califica su propio trabajo — la contramedida directa tanto para el reward hacking al estilo ImpossibleBench como para la inflación de mocks. La política está codificada como reglas versionadas y comprobables en lugar de texto de prompt, así que el estándar de aceptación no se puede negociar con un mensaje de finalización persuasivo.
El rigor escala según el riesgo y no según el instinto. Cada elemento de trabajo lleva un nivel de verificación legible por máquina (R0-R3, en vivo) que deriva de forma determinista sus puertas requeridas y su política de aprobación, y el artículo complementario sobre autonomía por niveles de riesgo explica por qué el trabajo de alto riesgo ni siquiera se puede reclamar sin un brief válido según el esquema. El motor de verificación en sí corre en el propio clúster k3s del operador con un registro de imágenes local — más de 69 trabajos deterministas que se ejecutan sin minutos de CI en la nube comprados — y la deuda de verificación se mide como cualquier otro costo operativo: las métricas de fuga de defectos, carga de revisión, retrabajo y tiempo de entrega llegan al mismo almacén de datos que cualquier otro comprobante. Finalmente, la etapa de aprendizaje del bucle escribe cada resultado verificado de vuelta al cerebro compartido, así que la siguiente sesión recuerda la decisión en lugar de volver a derivarla — recuperación antes que repetición, aplicado a la mitad de memoria de la brecha. En lo que respecta a la autonomía total, la ruta de Autopilot permanece no habilitada y fail-closed: la autoridad se gana a partir del historial de operación, y el rearme es una acción explícita del operador.
La conclusión
La respuesta a «no puedo demostrar con confianza que el código escrito por IA está listo para producción» no es leer con más cuidado la salida del agente, y tampoco es esperar un modelo más inteligente. La investigación coincide: la carga es estructural. Ciérrala con verificación fail-closed que sea independiente del generador, evidencia firmada adjunta a cada cambio consecuente, y memoria compartida persistente que hace que cada resultado verificado se acumule hacia la siguiente sesión. Para el argumento completo — la evidencia medida, la raíz común detrás de cada fallo anterior, y la arquitectura que se deriva de ella — lee el libro blanco de Koinessa.