Addy Osmani parte de una observación: dar a un agente una forma de verificar su propio trabajo mejora notablemente la calidad de lo que produce. Lo que hacía costoso el "buen código" — tests, benchmarks, especificaciones, rutas reales de extremo a extremo — ahora puede delegarse al agente. El trabajo humano pasa entonces de la revisión línea por línea a la construcción de bucles que el agente ejecuta por su cuenta, y el criterio se capitaliza: cada error se convierte en una configuración compartida, un hook o un test. Un humano sigue siendo responsable de lo que se publica, pero revisa evidencia en lugar de diffs.
En su opinión, los modelos ya son suficientemente buenos como para que la verificación sea el cuello de botella. Un agente que no puede comprobarse a sí mismo adivina, y la corrección requiere entonces un intercambio humano lento, costoso y no escalable. Un agente que se testea a sí mismo escribe, comprueba, lee el resultado y vuelve a intentarlo antes de que intervenga ningún humano. Los tests cambian de función: se convierten en la forma en que el agente percibe el mundo y sabe que ha terminado.
Los tests de extremo a extremo son el oráculo preferido: describen lo que hace el usuario y son difíciles de engañar, a diferencia de un test unitario basado en mocks, que puede compartir la propia incomprensión del agente. Deben señalar el paso que falla, convirtiendo una instrucción vaga en un objetivo. Lentos y poco fiables, deben mantenerse en poco número.
Los tests basados en propiedades (property-based tests) enuncian lo que nunca debe ocurrir; herramientas como fast-check, Hypothesis o proptest generan miles de entradas y reducen los fallos a un caso mínimo. Propiedades habituales: ida y vuelta (round-trips), invariantes, idempotencia, equivalencia con una versión simple. Impiden que el agente elija ejemplos que simplemente confirman su propia lógica y sirven de especificación.
Para una reescritura, los tests diferenciales convierten el sistema antiguo en el oráculo: entradas idénticas, aleatorias o extraídas de tráfico real, comparación de salidas, normalizando lo insignificante, y una lista justificada de cambios previstos, hasta que el sistema antiguo pueda retirarse.
El bucle debe ser rápido y determinista: un agente frente a tests lentos o inestables aprende a reintentar en lugar de corregir, o espacia sus ejecuciones y pierde de vista las causas. Osmani recomienda un bucle central de menos de un segundo, aleatoriedad controlada, exclusión inmediata de los tests inestables, salida concisa y tests más pesados antes de la integración. Su conclusión: escribir la comprobación antes del código.