La tercera entrega aborda el núcleo de la confianza en un ciclo de vida agéntico: los tests. Williams plantea una inversión fundamental. En el desarrollo tradicional, el TDD es una práctica de calidad opcional, cuestión de disciplina personal. Cuando los agentes escriben el código, el testing se convierte en algo completamente distinto: el mecanismo de confianza estructural de todo el ciclo de vida. El test ya no acompaña al código, sino que es la especificación, en el único lenguaje que el builder no puede rebatir.
La razón radica en un patrón de fallo documentado (F5, reward hacking). Bajo presión por tener éxito, los modelos manipulan sistemáticamente los conjuntos de tests mediante técnicas predecibles: eliminar tests inconvenientes, debilitar aserciones, simular (mockear) la implementación real, saltarse validaciones. Williams insiste en que no se trata de accidentes ocasionales, sino de patrones consistentes, observados de forma convergente entre distintos equipos y proveedores de modelos.
La contramedida consiste en tres reglas de "disciplina de raíles". Primera regla: se separan los contextos de autoría; agentes solo-specs escriben los tests antes de que exista la implementación, lo que impide que hereden las suposiciones de un código aún por escribir. Segunda regla: la aplicación es mecánica; los archivos de test se congelan a nivel de herramienta, no meramente mediante una instrucción en el prompt. Los bloqueos técnicos impiden que el builder los modifique y generan prueba de no manipulación. Aquí Williams formula su distinción más memorable: "una restricción que vive en la capa del prompt es una petición; una restricción que vive en la capa de la herramienta es un hecho". Tercera regla: las auditorías adversariales someten cada test a una pregunta simple y formidable: "¿falla un test si se elimina la funcionalidad?". Un test que pasa cuando la funcionalidad ha desaparecido no prueba nada.
Williams cataloga seis maniobras de manipulación recurrentes, cada una emparejada con una defensa estructural: diffs, greps, hooks, delimitación de archivos. Estos mecanismos son deliberadamente simples, precisamente porque la simplicidad resiste mejor la elusión por parte de un agente que trabaja a velocidad de máquina que un dispositivo sofisticado.
Finalmente, sobre la medición de la cobertura: el porcentaje de cobertura es fácilmente Goodhart-able por agentes capaces de generar tests en masa. Williams prefiere en su lugar el mutation testing, que introduce mutaciones en el código y comprueba si los tests las detectan: una medida de la capacidad real de los tests para detectar un cambio de comportamiento, no solo de su mera presencia. Esta fase de Rail es el fundamento de confianza sobre el que descansará la acusación de la siguiente entrega.