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 de 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 lanzamiento estaba mejor probado que el anterior.
Se supone que eso es imposible. Se supone que velocidad y calidad son opuestas. Lanza rápido, rompe cosas. Ve despacio, lanza bien. Elige una.
Ya no tienes que elegir. La clave está en un 90% de cobertura de pruebas, y los agentes de IA hicieron que llegar ahí sea 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.
(Esta es la séptima 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.
Tenías que escribir el código bien a la primera. Te perdías un caso límite y fallabas en producción. Lanzabas una mala migración de base de datos 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 la cabeza 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 de 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 parser, lo limita a 30 segundos, lanza la corrección con pruebas. ¿Un pipeline de extracción tiene un error de atribución? Una evaluación entre modelos lo detecta, el prompt se itera, se añade una validación a nivel de base de datos.
Para la mayoría de los errores a nivel de código (bugs lógicos, fallos de parsing, 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, agujeros de seguridad explotados antes de ser detectados, filtraciones de privacidad que no se pueden desfiltrar. El trinquete también ayuda aquí (las buenas pruebas detectan la mayoría de estos antes de producción), pero el verdadero cambio 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 carraca 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 añade tres cosas a la base de código:
- Pruebas que codifican lo que significa "correcto": comprobaciones 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 lanzar 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 almacenando, indexando y buscando 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 a través de 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 fuerte retención (confianza: 0.80)". Así, pero a través 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 la salida de forma independiente. En general: 6.8 sobre 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 falsa precisión 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 lanzarse 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 yo. 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 añade complejidad, pero nada evita la regresión. Cada nueva característica tiene la posibilidad de romper una antigua, 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 desde el principio. 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 los malos son igualmente invisibles. Con un conjunto de pruebas denso, 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 CAMBIES ESTO -- pregúntale a Dave y Dave se fue hace tres años.
La ventana de contexto del agente no renuncia. No es cazado. 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 falsa precisión degrada la confianza en las puntuaciones de confianza", ese conocimiento es duradero. Cualquier agente, cualquier modelo, en 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 enganchar 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 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 API 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 enganchable. Y si puedes engancharlo, puedes observarlo. Si puedes observarlo, puedes hacer afirmaciones sobre ello. Si puedes hacer afirmaciones sobre ello, 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 se saltaba toda la parte interactiva. Leía el archivo del plan, volcaba todos los hallazgos de una vez y salía, sin hacerle una sola pregunta al usuario. Todo el punto 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 dispara una pregunta interactiva antes de terminar. Si vuelca los 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 literalmente trabajar.
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 frase que cierra el vacío legal exacto que el modelo seguía explotando.
- Pruebas de piso de nivel 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 lanzó 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 del CLI, ejecuta plugins inspect para verificar que el tiempo de ejecución lo cargó, establece el slot 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. Ese es el muro de esfuerzo desapareciendo en tiempo real.
El principio se generaliza. Puedes probar a nivel de SO: ¿la migración creó las tablas correctas, se disparó el cron job, 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 piensan 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 un 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 una rodilla en la curva alrededor del 85% donde los escapes de defectos caen bruscamente.
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: cuenta cuántos defectos obtienes por millón de unidades producidas, luego expresa eso 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 escapes. 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 los caminos peligrosos están asegurados.
Ahora, debo ser honesto sobre lo que la investigación también muestra. 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 bruscamente. El último 20% de cobertura requiere desproporcionadamente más trabajo 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 llaman suficientemente bueno.
Pero algo cambió: los agentes de codificación de IA no experimentan el 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 la cobertura del 90% fuera poco práctica 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 caro 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 de lanzar) o rompe una prueba (detectado inmediatamente).
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 en solitario.
GStack ahora tiene 37 colaboradores. v1.30 incorporó 21 PRs de la comunidad en un solo lanzamiento. 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.
Los lanzamientos 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 CLI que estaban enrutando 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 añadiendo un tiempo de espera de 30 segundos
Cada lanzamiento se envió con más pruebas que el 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 volverse mucho más alto.
Solía estar limitado por la capacidad de un equipo de tener el sistema en sus cabezas. Ahora está limitado por una persona más agentes que pueden cargar toda la base de código, 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 buen gusto más un conjunto de pruebas que solo sube) ya está lanzando 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, la cobertura del 90% fue un lujo reservado para la aviónica y los dispositivos médicos: equipos con el presupuesto para lanzar horas humanas al muro del esfuerzo. Los agentes de IA demolieron ese muro. El umbral de cobertura que hace que el software sea confiable ya no es caro. Es solo una configuración. La pregunta no es si puedes permitirte el 90%. Es si puedes permitirte no tenerlo.
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. Gratuito.
- GBrain -- tu segundo cerebro para agentes de IA. 14K estrellas. Gratuito.
La serie AI Explainer:
- Fat Skills, Fat Code, Thin Harness -- la arquitectura
- Resolvers -- la tabla de enrutamiento para la inteligencia
- The LOC Controversy -- lo que realmente produjeron 600K líneas
- Naked Models Are Stupider -- el modelo es el motor, no el coche
- The Skillify Manifesto -- cada flujo de trabajo se convierte en una habilidad comprobable
- Meta-Meta-Prompting -- las habilidades compuestas producen capacidades emergentes
- El trinquete de complejidad del agente -- 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
