Los tests son la nueva documentación. Y la IA lo sabe primero.
La IA aprende de tu codebase via tests más que via docs. Si tus tests están mal, tu output AI estará mal — sin importar el modelo que uses.
Hubo una época —2015 a 2022 más o menos— donde la conversación sobre tests se estabilizó. “Cubre la lógica crítica con tests unitarios. No persigas 100% de coverage. Tests integration para los flows importantes. Hecho.”. Consenso aburrido.
En 2026 esa conversación se reactivó por una razón inesperada: tu agente de coding lee tus tests para entender qué hace tu sistema. Si los tests están débiles, el agente improvisa. Si están bien diseñados, el agente extrapola correctamente.
Los tests dejaron de ser solo “red de seguridad para refactor”. Pasaron a ser el contrato legible por máquina de tu codebase.
Lo que cambió
Antes, la documentación servía a humanos. Los tests también servían a humanos (CI los corría, los devs los miraban cuando fallaban). Dos artefactos en paralelo, ambos opcionales en la práctica.
Ahora hay un tercer lector: el agente. Y ese lector tiene una preferencia clara — prefiere tests sobre docs.
¿Por qué? Tres razones:
- Los tests no mienten. Una doc dice “esta función valida X”. Un test demuestra qué pasa con input X (y con input no-X). El agente confía en lo demostrable.
- Los tests están actualizados (si CI pasa). Si la doc dice una cosa y el código hace otra, no hay señal automática. Si el test dice una cosa y el código hace otra, CI rompe.
- Los tests son ejecutables. El agente puede generar variantes, probarlas, y validar contra el contrato. Las docs son texto sin forma de validar.
Implicaciones prácticas
Tests débiles = output AI débil. Si tu suite cubre 30% del comportamiento, el agente improvisa el 70% restante. Esa improvisación es lo que produce slop (ver AI slop detection).
Tests con buena nomenclatura ayudan al agente.
test_user_signup_with_invalid_email_returns_400 le dice al agente
qué validar al re-implementar. test_signup_2 le dice nada — el
agente improvisa.
Tests que documentan intent > tests que documentan implementación.
test_pricing_includes_tax_when_address_is_intra_state describe
business rule. test_pricing_calls_calculate_tax describe
implementación interna. El primero sobrevive refactors, el segundo
no.
Property-based tests para invariantes críticos. Cuando la IA implementa lógica nueva, los tests basados en propiedades (invariantes que SIEMPRE deben holding) son la única forma de detectar que algo se rompió de forma sutil.
El reframe para tu suite
Si tus tests fueron escritos pensando “esto evita que un humano distraído rompa el código”, están optimizados para el lector viejo.
Si los reescribieras pensando “esto le enseña a un colaborador nuevo (humano o agente) cómo funciona el sistema”, lo cual incluye intent + edge cases + invariantes, se vería distinto.
El upgrade:
- Nombres descriptivos de business rule, no de unidad técnica
- Describir intent en docstring del test
- Cubrir edge cases con property-based testing donde aplique
- Tests integration con flujos completos, no solo unidades
- Coverage NO como métrica principal — branch coverage + mutation testing son señales mejores
Lo que NO debería hacer la IA con tus tests
Aquí hay una trampa. Si la IA puede generar tests Y generar implementación, hay un caso degenerado donde:
- El agente genera la implementación
- El agente genera los tests
- Los tests pasan (porque están de acuerdo)
- Tu suite “verifica” que el código está correcto
Pero esa verificación es circular. Tests y código están de acuerdo con sí mismos, no con el intent humano.
El fix: el humano define los tests críticos PRIMERO, sin ver la implementación. O al menos los aprueba con criterio crítico independiente del código. TDD con un giro: el humano declara intent, el agente implementa, los tests del humano son el contrato no negociable.
La pregunta para tu suite
Si despides hoy a todo tu equipo, y un dev nuevo (humano o agente) abre el repo, ¿tus tests le explican qué hace el sistema y por qué?
Si la respuesta es no, tu documentación nunca fue tu documentación. Tus tests siempre lo fueron, solo que no lo sabías. Y ahora la IA está leyendo lo mismo que ese dev nuevo va a leer — con las mismas confusiones que tú no documentaste.
Si tu equipo está repensando la estrategia de tests para AI coding era, conversemos — el chat está abierto.