He estado programando con IA durante el último año. No solo haciendo prompts, sino construyendo software real. Dos proyectos de código abierto: GStack, que mejora los agentes de codificación con IA, y GBrain, que convierte todo lo que lees y escribes en una base de conocimiento buscable que tu IA puede usar. Entre ambos, alrededor de 970,000 líneas de código y 665 archivos de prueba. Casi todo escrito por Claude Code y Codex bajo mi dirección (15 sesiones simultáneas de Conductor la mayor parte del tiempo).
La semana pasada fusioné catorce pull requests en 72 horas. Casi 29,000 líneas de código nuevo. Cada versión estaba mejor probada que la anterior.
Se supone que eso es imposible. Se supone que velocidad y calidad son opuestas. Lanza rápido, rompe cosas. Muévete lento, lanza bien. Elige una.
Ya no tienes que elegir. La clave es el 90% de cobertura de pruebas, y los agentes de IA lo han hecho gratuito. Durante cincuenta años, ese nivel de verificación costaba demasiada fuerza de voluntad humana para mantenerlo. Ahora el agente escribe las pruebas junto con el código. El resultado es lo que llamo el trinquete de complejidad: un sistema que solo puede mejorar, nunca empeorar.
(Este es el séptimo de una serie sobre construcción con IA: 1 2 3 4 5 6
El software solía ser frágil
Durante cincuenta años, toda la disciplina de la ingeniería de software se organizó en torno a una idea: prevenir errores, porque los errores son catastróficos.
Había que escribir el código bien a la primera. Pasabas por alto un caso límite y fallabas en producción. Enviabas una migración de base de datos incorrecta y perdías datos de clientes. Escribías una función que hacía algo sutil, y cuando la única persona que la entendía se iba, nadie sabía por qué funcionaba. Todo el sistema dependía de que los humanos fueran cuidadosos, y los humanos no lo son. Así que construimos procesos elaborados (revisiones de código, entornos de staging, equipos de QA, trenes de lanzamiento) todos diseñados para detectar errores antes de que llegaran a los usuarios.
Funcionó, más o menos. Pero era lento. Y significaba que la complejidad de cualquier sistema de software tenía un techo duro: la cantidad de cosas que un equipo podía tener en mente simultáneamente.
Ahora el software es maleable
No me refiero a descuidado. Me refiero a resiliente de una manera que antes no era posible.
Cuando digo "los modelos ya están aquí", quiero decir que los agentes de codificación con IA (Claude, GPT, Codex y el ecosistema que crece a su alrededor) ahora pueden leer código, entender contexto, diagnosticar errores y escribir correcciones. No perfectamente. Pero lo suficientemente bien como para que el modelo de errores del software haya cambiado.
¿La migración falla? El agente lee el mensaje de error, entiende el historial del esquema de la base de datos a través de 45 versiones, escribe la corrección, escribe la prueba. ¿La sincronización de archivos se cuelga con un millón de enlaces simbólicos? El agente diagnostica el tiempo de espera del analizador, lo limita a 30 segundos, envía la corrección con pruebas. ¿Un pipeline de extracción tiene un error de atribución? Una evaluación entre modelos lo detecta, se itera el prompt, se agrega la aplicación a nivel de base de datos.
Para la mayoría de los errores a nivel de código (errores de lógica, fallos de análisis, casos límite rotos), los agentes ahora pueden diagnosticarlos y corregirlos en el siguiente turno. Eso es genuinamente nuevo. Los errores que siguen siendo catastróficos son los que destruyen el estado: malas migraciones en datos de producción, vulnerabilidades de seguridad explotadas antes de ser detectadas, filtraciones de privacidad que no se pueden revertir. El trinquete también ayuda aquí (las buenas pruebas detectan la mayoría de estos antes de producción), pero el cambio real es que la gran mayoría de los errores en una base de código son del tipo reparable.
Esto es un cambio de fase en cómo se construye el software. Pero solo funciona si tienes el trinquete.
El Trinquete de Complejidad del Agente
Un trinquete es un mecanismo que permite el movimiento en una sola dirección. Una llave de trinquete gira un perno hacia adelante y evita que gire hacia atrás. Esa es la metáfora.
En el software codificado por agentes, cada sesión de codificación con un agente de IA agrega tres cosas a la base de código:
- Pruebas que codifican lo que significa "correcto": verificaciones automatizadas que se ejecutan cada vez que alguien cambia el código y fallan ruidosamente si el cambio rompe algo.
- Documentación que registra por qué se tomaron las decisiones: no solo lo que hace el código, sino el razonamiento y las compensaciones detrás de él.
- Resultados de evaluación que establecen umbrales de calidad: evaluaciones estructuradas de la calidad del resultado con puntuaciones, para que sepas si la siguiente versión es mejor o peor.
La próxima vez que un agente trabaje en la base de código, carga los tres en su ventana de contexto (el texto que la IA puede ver y razonar). No puede retroceder por debajo del conjunto de pruebas: las pruebas fallarían. No puede ignorar la documentación: está justo ahí en el contexto. No puede enviar calidad por debajo de la línea base de evaluación: las puntuaciones están registradas.
El piso de calidad sube con cada turno. Movimiento solo hacia adelante. Ese es el trinquete.
Cómo se ve esto en la práctica
Lo haré concreto. GBrain es un sistema de conocimiento que estoy construyendo: le da a los agentes de IA memoria a largo plazo al almacenar, indexar y buscar en las notas, reuniones, conversaciones e investigación de una persona. Piensa en ello como un segundo cerebro que tu asistente de IA puede leer realmente.
Una de sus características es la extracción epistemológica: lee miles de páginas y extrae quién cree qué, con qué confianza, a lo largo del tiempo. "Garry cree que Bitcoin llegará a $300K (confianza: 0.45)". "Jared cree que esta startup tiene una retención sólida (confianza: 0.80)". Así, pero a lo largo de 28,000 páginas.
La primera ejecución de extracción obtuvo 100,720 afirmaciones. Usé una evaluación entre modelos para calificar la calidad: hice que GPT-5.5 y Claude puntuaran el resultado de forma independiente. En general: 6.8 de 10.
¿El mayor problema? Algo que llamo confusión del titular. Toma la afirmación "La IA reemplazará al 80% de los ingenieros de software para 2027". ¿Quién sostiene esa creencia? ¿Es la persona que la escribió? ¿Es alguien a quien están citando? ¿O es el motor de análisis del sistema, que la infirió de una transcripción de podcast? La versión 1 se equivocó en esta distinción el 35% de las veces. Eso importa: si estás construyendo un sistema que rastrea lo que la gente cree, necesitas saber QUIÉN lo cree.
Así que los resultados de la evaluación se documentaron. Se identificaron seis modos de fallo específicos. El prompt de la versión 2 abordó los seis. El redondeo de pesos (las puntuaciones de confianza) se aplicó a nivel de base de datos: no más precisión falsa como 0.74 cuando 0.75 es la respuesta honesta. Diecisiete pruebas fijaron el contrato.
Ahora ninguna versión futura de la extracción puede enviarse sin que esas 17 pruebas pasen. Nadie tiene que recordar por qué importa el redondeo de pesos o qué es la confusión del titular. Las pruebas lo recuerdan.
El piso de calidad subió permanentemente. Ese es un giro del trinquete.
Por qué la mayoría de los proyectos "vibecoded" mueren
"Vibecoding" es el término de Andrej Karpathy para programar con IA describiendo lo que quieres en lenguaje natural y dejando que el modelo genere el código. Es poderoso y así es como construyo. Pero por lo que he visto en aplicaciones de YC y repositorios de código abierto, la mayoría de los proyectos vibecoded que saltan las pruebas comienzan a desmoronarse una vez que alcanzan una complejidad moderada: unos pocos miles de líneas, un puñado de funciones que interactúan.
Saltan el trinquete. Sin pruebas, sin documentación, sin evaluaciones. El agente agrega complejidad, pero nada evita la regresión. Cada nueva función tiene la posibilidad de romper una anterior, y sin pruebas, no te enteras hasta que un usuario lo reporta. Para la versión 0.5, la base de código es una casa encantada donde cada cambio rompe algo inesperado. Entonces el desarrollador escribe una publicación de blog sobre cómo la codificación con IA no funciona.
La codificación con IA funciona bien. Simplemente no construyeron el trinquete.
Se podría argumentar que el tipo de persona que escribe pruebas también es el tipo que escribe buena arquitectura en primer lugar. Justo. Pero el mecanismo del trinquete no se trata de la persona, sino de lo que sucede en el siguiente turno. Cuando un nuevo colaborador abre un PR, o cuando cambia una versión del modelo, o cuando estás programando a las 2 a.m. y tu juicio está deteriorado, las pruebas detectan regresiones independientemente de quién las escribió. El trinquete funciona incluso cuando el humano no está en su mejor momento. Ese es el punto.
Sin pruebas, la mejora es un proceso ruidoso: los agentes intentan mejorar las cosas, pero sin señales de regresión, los cambios buenos y malos son igualmente invisibles. Con un conjunto denso de pruebas, obtienes un trinquete en la superficie probada: la calidad solo puede subir para los comportamientos que has codificado. Eso es la mayor parte del sistema, no todo. Pero es suficiente para mantener el movimiento hacia adelante a velocidad.
Las pruebas como memoria institucional
En las empresas de software tradicionales, la memoria institucional vive en los humanos. El ingeniero senior que sabe por qué existe esa capa de caché. El arquitecto que recuerda la migración que casi destruye la base de datos. El líder técnico que puede explicar el extraño caso límite en el sistema de facturación.
Los humanos se van. Se jubilan, los cazan, se agotan. Cuando se van, el conocimiento se va con ellos. Toda empresa de software ha tenido la experiencia de abrir un archivo crítico y encontrar un comentario que dice // NO CAMBIAR ESTO — pregúntale a Dave y Dave se fue hace tres años.
La ventana de contexto del agente no renuncia. No es cazada. No olvida. Cuando el conjunto de pruebas codifica "el redondeo de pesos debe usar incrementos de 0.05" y la documentación explica "porque la evaluación entre modelos mostró que la precisión falsa degrada la confianza en las puntuaciones de confianza", ese conocimiento es duradero. Cualquier agente, cualquier modelo, cualquier momento puede cargar ese contexto y entender la restricción.
Las pruebas son memoria institucional que sobrevive a la rotación de empleados. Para un proyecto de una sola persona, son aún más críticas: son la única memoria institucional que tienes.
Todo lo que se puede aprovechar es comprobable
El trinquete no funciona solo para el código tradicional. Funciona para cualquier cosa que una computadora pueda observar.
Piensa en las capas de un sistema moderno. El SO te da árboles de procesos, estado del sistema de archivos, sockets de red, programaciones de cron. La terminal te da cada pulsación de tecla, cada línea de salida, cada prompt interactivo. El navegador te da páginas renderizadas, estados de botones, eventos de navegación. Las APIs te dan respuestas estructuradas que puedes analizar y validar. Y los agentes de IA te dan comportamiento observable: lo que dicen, qué herramientas llaman, en qué orden hacen las cosas, si preguntan antes de actuar.
Todo esto es aprovechable. Y si puedes aprovecharlo, puedes observarlo. Si puedes observarlo, puedes hacer afirmaciones sobre ello. Si puedes hacer afirmaciones, puedes aplicar el trinquete.
Esta es un área de superficie mucho más grande que las pruebas unitarias tradicionales. Déjame mostrarte.
GStack es mi framework de agente de codificación de código abierto: 93,000 estrellas en GitHub, 701,000 líneas de código, 46 habilidades. Una de sus características principales es la revisión interactiva de planes: le pides que revise tu arquitectura, y recorre el plan sección por sección, haciendo preguntas, sondeando casos límite, desafiando tus suposiciones. Como tener un gerente de ingeniería que realmente lee el código.
El problema: Claude Code a veces saltaba toda la parte interactiva. Leía el archivo del plan, volcaba todos los hallazgos de una sola vez y salía, sin hacerle una sola pregunta al usuario. Todo el propósito de la revisión es el diálogo de ida y vuelta. Saltarlo anula el propósito.
¿Cómo pruebas eso siquiera? No puedes hacer una prueba unitaria de "si la IA tuvo una conversación". Ningún framework de pruebas tradicional cubre esto.
Así que usé la funcionalidad TTY de Bun para construir un arnés de prueba (PR #1354) que literalmente genera Claude Code dentro de una pseudo-terminal, le alimenta un escenario de repositorio específico, activa la habilidad de revisión y observa la salida de la terminal en tiempo real. La prueba observa si el agente lanza una pregunta interactiva antes de terminar. Si vuelca hallazgos y sale sin preguntar nada, la prueba falla.
Eso no es probar código. Eso es probar si un agente de IA sigue un contrato de comportamiento. A nivel de TTY. Observándolo trabajar literalmente.
La respuesta del trinquete fue de tres capas:
- Compuertas STOP en las instrucciones de la habilidad: reglas explícitas que dicen "DEBES preguntar al usuario antes de proceder a la siguiente sección", con cláusulas anti-racionalización que nombran el modo de fallo específico para que el modelo no pueda convencerse de saltarlo.
- Cláusula anti-atajo: "el archivo del plan es la SALIDA de la revisión interactiva, no un sustituto de ella". Una oración que cierra el vacío legal exacto que el modelo seguía explotando.
- Pruebas de piso de compuerta: las pruebas del arnés TTY que generan Claude Code en escenarios controlados y fallan si el agente no hace al menos una pregunta interactiva.
Ahora, cuando Anthropic lanza una nueva versión del modelo, o cuando cambio un prompt de habilidad, el conjunto de pruebas detecta cualquier regresión en el contrato interactivo. El agente no puede dejar de hacer preguntas silenciosamente. La prueba observa la terminal y verifica.
O toma el PR #880, que envió un nuevo plugin de OpenClaw. La prueba no solo verifica que el código compile. Construye el plugin desde la fuente, genera una instancia real de OpenClaw en un perfil aislado, instala el plugin a través de la CLI, ejecuta plugins inspect para verificar que el tiempo de ejecución lo cargó, establece la ranura de configuración, valida la configuración y ejecuta plugins doctor para confirmar cero diagnósticos. Un recorrido completo de extremo a extremo a través de dos programas separados. 359 líneas de código de prueba. El tipo de prueba que un humano casi nunca escribiría a mano porque la configuración es demasiado tediosa. Claude la escribió en unos cinco minutos. Esa es la pared de esfuerzo desapareciendo en tiempo real.
El principio se generaliza. Puedes probar a nivel de SO: ¿la migración creó las tablas correctas, se ejecutó el trabajo de cron, sigue vivo el proceso? A nivel de navegador: ¿se renderizó la página, el agente llenó el formulario correctamente? A nivel de API: ¿el modelo devolvió JSON válido con el esquema correcto? A nivel de comportamiento: ¿el agente siguió el protocolo, preguntó antes de eliminar, se detuvo cuando se le dijo que se detuviera?
Toda la pila es comprobable. El trinquete se aplica a todo. La mayoría de la gente aún no se ha dado cuenta de esto porque todavía están pensando en la cobertura de pruebas como "si mi función devolvió el número correcto". La superficie de prueba real es todo lo que la computadora puede ver.
El número 90%
Entonces, ¿qué te compra realmente el 90% de cobertura de pruebas?
Capers Jones estudió más de 10,000 proyectos de software y midió la eficiencia de eliminación de defectos (DRE): el porcentaje de errores detectados antes de que lleguen a los usuarios. Sus datos de Applied Software Measurement muestran una curva no lineal: por debajo del 70% de cobertura, la DRE se sitúa alrededor del 65-75%. Con una cobertura del 85-95%, la DRE salta al 92-97%. La relación no es lineal. Hay un punto de inflexión en la curva alrededor del 85% donde las fugas de defectos caen drásticamente.
La industria de la aviónica descubrió esto hace décadas. DO-178C, el estándar de la FAA para software crítico de vuelo, requiere cobertura de condición/decisión modificada (MC/DC) para sistemas de Nivel A, aquellos donde un error significa un accidente de avión. La cobertura de ramas por sí sola pierde del 10 al 20% de las fallas. MC/DC, que es más estricto que la cobertura de líneas, logra >99% de DRE. No lo exigen porque a los burócratas les guste el papeleo. Lo exigen porque los datos mostraron que por debajo de ciertos umbrales de cobertura, los defectos críticos escapan a tasas incompatibles con no matar personas.
El paralelo con la ingeniería de confiabilidad es claro. Las fábricas usan un sistema llamado Six Sigma para medir la calidad. La idea: contar cuántos defectos obtienes por millón de unidades producidas, luego expresarlo como un "nivel sigma": un sigma más alto significa menos defectos. Un proceso de 3 sigma produce alrededor de 67,000 defectos por millón (bastante malo). Un proceso de 4 sigma produce alrededor de 6,200 (diez veces mejor). Un proceso de 5 sigma produce 233 (otras 27 veces mejor). El salto de 4 a 5 sigma no es una mejora incremental. Es un cambio de fase.
La cobertura de pruebas sigue la misma curva. Pasar del 70% al 90% de cobertura no es un 30% mejor. Es un orden de magnitud menos de fugas. Los defectos que se cuelan al 70% se esconden en el 30% del código no probado. Al 90%, los escondites se reducen al 10% y la mayoría de las rutas peligrosas están aseguradas.
Ahora, debo ser honesto sobre lo que también muestra la investigación. Mockus, Nagappan y Dinh-Trong estudiaron Windows Vista y encontraron que, si bien la cobertura se correlaciona con menos defectos posteriores al lanzamiento, el esfuerzo para alcanzar el 90%+ aumenta drásticamente. El último 20% de cobertura requiere un trabajo desproporcionadamente mayor que el primer 70%. Esto ha sido cierto durante décadas. Es por eso que la mayoría de los equipos se detienen en el 70-80% y lo consideran suficientemente bueno.
Pero algo cambió: los agentes de codificación con IA no experimentan esfuerzo.
No se aburren escribiendo la decimocuarta prueba de caso límite. No toman atajos a las 5 p.m. de un viernes. No miran una prueba de integración espinosa y piensan "volveré a esto más tarde". La curva de esfuerzo que detuvo a los equipos humanos en el 70% no se aplica a los agentes. Puedes pedirle a Claude que escriba pruebas para cada caso límite en un módulo y lo hará alegremente, a fondo, a las 2 a.m., sin quejarse. El brutal último 20% que hizo que el 90% de cobertura fuera poco práctico para los equipos humanos es exactamente el tipo de trabajo en el que los agentes de IA son mejores.
Este es el verdadero desbloqueo. No es que la IA te permita escribir código más rápido. Mucha gente ya se ha dado cuenta de eso. Es que la IA te permite verificar a un nivel que antes era demasiado costoso de mantener. ¿El umbral del 90% que los datos dicen que es mágico? Solía costar demasiada fuerza de voluntad humana alcanzarlo. Ahora es gratuito.
Esa es la distinción clave. El trinquete no se trata de la cobertura de líneas como una métrica de vanidad. Se trata de pruebas que codifican contratos de comportamiento: la prueba de confusión del titular, la prueba de redondeo de pesos, la compuerta de revisión interactiva. Cada prueba fija una lección específica aprendida. La cobertura es el proxy que te dice cuánto del comportamiento del sistema está bajo contrato. Al 90%, casi todos los cambios de comportamiento activan una señal de prueba. El agente pasa (seguro para enviar) o rompe una prueba (detectado de inmediato).
El 10% restante son puntos de integración, tuberías de infraestructura y casos límite que son genuinamente difíciles de probar. Está bien. El 90% es lo que convierte el caos en un trinquete.
Llegar al 90% solía ser un esfuerzo heroico. Ahora es un martes. Ese es el cambio de juego.
Prueba de concepto
Empecé ambos proyectos solo. Ya no son solitarios.
GStack ahora tiene 37 colaboradores. v1.30 incorporó 21 PRs de la comunidad en una sola versión. GBrain tiene 25 colaboradores. v0.31.1.1 aterrizó 22 correcciones de la comunidad en un solo PR: flujo de autenticación, arranque de esquema, sincronización, privacidad.
El trinquete es lo que hace que esto sea seguro. Cada PR externo debe pasar el conjunto de pruebas existente. Un nuevo colaborador no necesita entender todo el sistema. Necesita hacer que las pruebas pasen.
Las versiones de GBrain de la semana pasada cuentan la historia:
- v0.31.0: una nueva tabla de hechos para memoria en tiempo real, más una fase de consolidación de sueños que promueve recuerdos a corto plazo a conocimiento a largo plazo.
- v0.31.1: corrigió 25 comandos de CLI que se enrutaban silenciosamente a una base de datos local vacía en lugar del cerebro real del usuario.
- v0.31.1.1: veintidós correcciones reportadas por la comunidad en un solo PR.
- v0.31.2: corrigió una sincronización de código que se colgaba para siempre en repositorios grandes con enlaces simbólicos agregando un tiempo de espera de 30 segundos.
Cada versión se envió con más pruebas que la anterior. El agente escribe las pruebas junto con el código. La cobertura no baja porque el esfuerzo para mantenerla ya no es una carga humana.
El nuevo techo de complejidad
El techo de complejidad para el software acaba de subir mucho.
Solía estar limitado por la capacidad de un equipo de tener el sistema en mente. Ahora está limitado por una persona más agentes que pueden cargar la base de código completa, el historial del esquema, el conjunto de pruebas y la documentación en el contexto.
Ese es un número mucho más grande. Y sigue creciendo a medida que las ventanas de contexto se agrandan y los modelos mejoran en el razonamiento sobre el código.
Toda empresa de software que no adopte este modelo (agentes más criterio más un conjunto de pruebas que solo sube) ya está enviando más lento y con menos calidad que una persona que lo tiene.
Las herramientas están aquí. El código es abierto. Las pruebas son el trinquete. 90% de cobertura, cada PR, sin excepciones.
Durante cincuenta años, el 90% de cobertura fue un lujo reservado para la aviónica y los dispositivos médicos: equipos con el presupuesto para lanzar horas humanas a la pared del esfuerzo. Los agentes de IA demolieron esa pared. El umbral de cobertura que hace que el software sea confiable ya no es costoso. Es solo una configuración. La pregunta no es si puedes permitirte el 90%. Es si puedes permitirte no hacerlo.
El trinquete, las habilidades y todo el sistema de conocimiento son de código abierto y gratuitos en GitHub. Ve a construir.
Mis proyectos de código abierto con licencia MIT:
- GStack — hace que Claude Code sea dramáticamente mejor. 93K estrellas. Gratis.
- GBrain — tu segundo cerebro para agentes de IA. 14K estrellas. Gratis.
La serie AI Explainer:
- Fat Skills, Fat Code, Thin Harness — la arquitectura
- Resolvers — la tabla de enrutamiento para la inteligencia
- The LOC Controversy — qué produjeron realmente 600K líneas
- Naked Models Are Stupider — el modelo es el motor, no el auto
- The Skillify Manifesto — cada flujo de trabajo se convierte en una habilidad comprobable
- Meta-Meta-Prompting — las habilidades compuestas producen capacidades emergentes
- The Agent Complexity Ratchet — estás aquí
https://x.com/garrytan/status/2054055071017538028
https://x.com/garrytan/status/2042925773300908103
https://x.com/garrytan/status/2044479509874020852
https://x.com/garrytan/status/2045404377226285538
https://x.com/garrytan/status/2045798603059548364
https://x.com/garrytan/status/2046876981711769720
