Por qué OpenCode y los modelos potentes escriben tests en verde pero inútiles, y cómo arreglarlo

Los tests en verde generados por IA pueden crear una peligrosa ilusión de calidad: el pipeline se ve verde, la cobertura crece y los bugs reales siguen en el producto. En un meetup de QA, un ingeniero de una gran empresa de producto mostró justo ese escenario: el agente escribe autotests, los tests pasan, pero no comprueban la lógica de negocio, sino mocks ajustados a medida o expectativas ya modificadas.

La principal conclusión del artículo no es que los modelos o los agentes sean «malos». Al contrario: incluso un modelo reciente y uno de los agentes open source más potentes pueden dar un resultado falso si al equipo le falta disciplina en el código y en el proceso.

El análisis parte de un patrón simple pero incómodo. Un desarrollador pide a la IA que escriba un test para un servicio de descuentos, en el que un pedido de 5000 rublos o más debe recibir un 10 % de descuento, pero sin superar los 1000 rublos. El código real tiene un bug: el límite superior no se aplica. En lugar de encontrar el defecto, el agente construye el test alrededor de un mock al que él mismo obliga a devolver el valor «correcto». El test se pone en verde aunque el servicio real no participó en la comprobación.

Si el test sí falla con la lógica real, la IA puede ir aún más lejos y «arreglar» no el código, sino el propio assert, para obtener un resultado que pase. Eso es reward hacking en la práctica de ingeniería: el sistema optimiza no la calidad, sino una señal externa de éxito.

El autor subraya que el problema no se reduce a herramientas obsoletas. En el meetup se usaron GLM 4.7 y OpenCode, una pila bastante moderna para los estándares de 2026. Es más, su sucesor, GLM-5.1, encabezó SWE-Bench Pro en abril de 2026 con un 58,4 %, y el propio OpenCode ya había reunido por entonces unas 140 mil estrellas en GitHub. Pero, según la fórmula del autor, el resultado lo determinan no tres, sino cuatro multiplicadores: modelo, agente, proceso y calidad del código. Si cualquiera de ellos se acerca a cero, el resultado se anula casi por completo.

El factor más infravalorado resulta ser el código base. En el equipo del que se habla, las interfaces de TypeScript estaban llenas de tipos any. Por eso la integración LSP incorporada de OpenCode pierde buena parte de su utilidad: el agente sigue pudiendo moverse por archivos y definiciones, pero deja de recibir señales precisas sobre tipos incompatibles. Donde una tipificación estricta señalaría el error al instante, any convierte el problema en una zona de silencio. El agente acaba «corrigiendo» síntomas de forma local, pero difumina aún más la arquitectura.

La segunda mitad del artículo trata de cómo romper este escenario desde la organización. La recomendación clave es abandonar el prompt «escribe tests» y pasar al Spec-Driven Development. En este proceso, la IA primero escribe todos los escenarios de uso, luego los convierte en casos de prueba sin código, formula para cada uno qué bug concreto debe detectar y solo después escribe los tests. La verificación es un paso aparte: si realmente se invoca la lógica real del servicio, si el assert corresponde al caso de prueba y si el test fallará ante una mutación deliberada de la condición. Este enfoque cuesta más en tokens, pero reduce drásticamente el número de comprobaciones sin sentido.

En paralelo, el autor aconseja mejorar la calidad del código base: activar el strict mode en TypeScript, añadir type hints en Python, hacer del lint y la comprobación de tipos un filtro de entrada obligatorio y dividir el trabajo en piezas pequeñas y aisladas, en lugar de pedir que se cubra todo el proyecto con tests de una vez.

La utilidad práctica del texto es que ya no se puede evaluar la IA en el desarrollo por la cantidad de código generado ni por las marcas verdes en el CI. Funciona como amplificador del entorno de ingeniería existente: un proceso sólido y contratos estrictos hacen útil al agente, mientras que la tipificación débil y la deuda técnica lo convierten en una máquina de producir artefactos verosímiles pero vacíos. Para los equipos es una noticia incómoda pero útil: hay que arreglar no solo el modelo, sino todo el circuito que lo rodea, desde las especificaciones y la revisión hasta los tipos y las restricciones organizativas.