Uncle Bob apenas lee el código de su IA. Leerlo todo tampoco prueba que lo hayas revisado.

Dentro del expediente

En este cuaderno he defendido que un humano que se limita a pulsar «aprobar» es un adorno caro. Lo sigo pensando. Lo que no quiero es que alguien saque de ahí la conclusión contraria, que trabajar bien con IA consiste en leer cada línea que produce la máquina. Se puede llegar a la última página de un informe sin haber contrastado la afirmación de la que depende todo lo demás, y salir convencido de haberlo revisado.

Lo que Martin cuenta que hace

Robert C. Martin explicó su manera de trabajar en una entrevista con Aviator publicada el 24 de septiembre de 2026. Dice que apenas lee el código de sus agentes, aunque todavía abre algún módulo de vez en cuando. Examina la arquitectura, ejecuta la aplicación y se apoya en pruebas automáticas Fuente primaria ↗. Es su relato. Yo no he auditado su sistema ni tengo datos sobre cuántos errores se le escapan.

Aun así, su planteamiento me resulta más útil que la mayoría de declaraciones sobre IA, porque se puede discutir. Ante un método que nombra sus controles cabe preguntar qué errores atrapa cada uno y cuáles deja pasar. La misma pregunta vale para quien presume de revisarlo todo a mano, y la respuesta no puede ser el número de horas que pasó delante de la pantalla.

Leerlo entero puede ser una coartada

Pongamos un ejemplo inventado. Un revisor recibe un informe y lo lee de principio a fin. Corrige una repetición, mueve dos comas y lo da por bueno. En la página doce, el texto atribuye una conclusión a un documento que nadie ha abierto. La conclusión es plausible y coincide con lo que el revisor esperaba encontrar, así que no le llama la atención. El informe sale firmado.

Aquí nadie ha aprobado sin mirar. Hubo lectura completa, y el error que importaba sobrevivió a ella.

Ahora el mismo informe en otro circuito, también inventado. Una herramienta cuadra las sumas y avisa de los anexos que faltan. La persona que revisa no relee toda la prosa, pero localiza el pasaje del que cuelga la conclusión, abre la fuente citada y ve que trata de otro asunto. Devuelve el informe. Ha leído bastante menos que el primer revisor y ha encontrado lo que a él se le pasó.

Los casos son sintéticos y están hechos para aislar esa diferencia, no para medir qué circuito gana. Un revisor que leyera todo y además abriera la fuente también encontraría el fallo. Discuto la lectura como prueba suficiente de revisión, no la utilidad de leer.

Cuando nos pregunten cómo supervisamos, ¿vamos a defender el tiempo invertido o la verificación concreta que hicimos? «Lo ha revisado una persona» no me basta como respuesta, y «me lo he leído entero» tampoco. Quiero saber qué buscaba quien revisó y con qué podía encontrarlo.

Una batería de pruebas en verde también puede engañar

El argumento corta igual en la otra dirección, y ahí incomoda a quien quiere quitarse la lectura de encima. En un test con un resultado esperado se compara lo que hace el programa con un resultado que alguien dio por correcto. Si ese resultado está mal elegido, el programa aprueba un examen equivocado y la pantalla se llena de verde.

Martin lo reconoce en la misma entrevista. Advierte que los agentes pueden escribir pruebas que pasan aunque hayan entendido mal el encargo, y explica cómo intervienen las personas sobre las especificaciones, que es donde se decide qué debe hacer el programa Fuente primaria ↗.

Hay herramientas pensadas para vigilar a las propias pruebas. Las de mutación, como Stryker, introducen cambios deliberados en el código y ejecutan la batería para ver si alguna prueba falla. Si el código alterado sigue pasando, puede haber un hueco en lo que se está verificando Fuente primaria ↗.

Mi objeción empieza ahí. Que las pruebas reaccionen cuando se altera el código no garantiza que midan lo que se encargó. Sigue habiendo que decidir qué comportamiento se esperaba, qué casos faltan y quién aceptó como bueno el resultado de referencia. Encargar al agente el programa y, acto seguido, las pruebas que confirman lo bien que lo ha hecho se parece demasiado a dejar que el alumno redacte el examen y luego lo corrija.

Ignoro si eso pasa en el sistema de Martin, y su propia advertencia sugiere que lo tiene presente. Mi crítica va para quien adopte la frase «ya no leo código» y se ahorre el trabajo de decidir qué hay que verificar.

Hay errores que no admiten revisión posterior

En datos.gob.es, Jose Luis Marín distingue entre validar decisiones una a una, vigilar el sistema mientras funciona y gobernarlo en su conjunto. También advierte de la presión para reducir la intervención humana cuando la IA mejora. Es divulgación, no un experimento que mida cuánto falla cada modalidad Fuente primaria ↗.

La distinción me sirve para una pregunta práctica. ¿En qué momento tiene que enterarse alguien de que algo ha ido mal?

En el informe del ejemplo, cuadrar las sumas al final puede bastar, porque un descuadre se corrige antes de entregar. Si el sistema ya ha enviado el documento a quien no debía, cualquier revisión posterior llega tarde. Ahí la cuestión deja de ser cuánto confías en la tecnología y pasa a ser qué le permites ejecutar antes de que nadie lo mire.

Yo separaría los fallos que se pueden repetir y corregir de los que no se deshacen con un botón, y pondría controles distintos a cada grupo. Es el criterio desde el que diseñaría un circuito de trabajo, sin pretender que sea una regla jurídica.

La prueba que haría antes de dejar de mirar

Antes de recortar una revisión, prepararía una copia del trabajo con datos ficticios y le metería un error conocido, uno que de verdad importe en ese tipo de encargo. En el informe, sustituiría la fuente por otra que no sostiene la conclusión y dejaría la redacción impecable.

Después pasaría la copia por una réplica aislada del circuito habitual, con envíos y acciones externas bloqueados. El equipo sabría que estamos ensayando la revisión, pero no qué error contiene la copia. Miraría si alguna persona o herramienta lo detecta antes de autorizar la salida simulada. Si el error llega al final, ya sé qué control tengo que arreglar antes de repetir el ensayo.

Que el error se detecte una vez tampoco me permitiría declarar seguro el sistema. Un ensayo así revela un hueco o aporta una evidencia limitada, y deja fuera los errores que todavía no se me han ocurrido. Su ventaja es que obliga a enseñar algo más útil que el nombre del modelo o las horas de lectura.

Revisaría también un permiso concreto. Si el agente puede modificar el resultado esperado de una prueba para que pase, quiero saber cuándo lo hace y por qué. A veces la prueba estaba mal y corregirla es lo correcto. Si lo hace sin dejar rastro, el verde que me enseñan no demuestra que siga cumpliéndose el criterio acordado.

Esto también corrige mi propia consigna

En la portada de este cuaderno pone «Tu IA no firma. Tú sí». La frase es mía y la mantengo, pero no significa que debas repetir a mano todo lo que hace la máquina. Si la única forma de fiarte de una tarea automatizada es rehacerla entera, lo honesto es preguntarse si compensa automatizarla.

Lo que significa, tal como lo entiendo aquí, es que tienes que poder explicar por qué aceptaste ese trabajo. Según el encargo, tocará bajar a una línea, abrir una fuente o probar el caso que falta. A veces tocará negarse a entregar. Comparar esos controles no vuelve equivalentes un programa y un dictamen, ni elimina los deberes de revisión del profesional. Ningún contador de páginas leídas hace eso por ti.

Martin puede estar equivocándose al decidir cuánto deja de mirar. Yo puedo equivocarme exigiendo una lectura completa que tranquiliza al revisor y no encuentra nada. Su prestigio no zanja la primera duda, y el mío, bastante más modesto, tampoco zanja la segunda.

Así que si me dices que has dejado de leer el código, no te voy a llamar irresponsable. Te voy a pedir una prueba que falle cuando el programa haga lo que no debe, y el nombre de quien decidió qué significa «lo que no debe».

Lo que me preguntan cuando cierro el portátil.

¿Uncle Bob ha dejado de revisar el código generado por IA?

Dice que apenas lo lee, no que lo acepte sin controles. La distinción importa porque este artículo discute qué se comprueba al supervisar, no si basta con confiar en el agente.

¿Pasar todas las pruebas demuestra que el programa es correcto?

No da una garantía general. Las pruebas que planteo aquí comparan comportamientos con criterios elegidos de antemano. Queda justificar esos criterios, los casos que faltan y qué errores relevantes pueden escapar.

¿Cómo comprobar una revisión sin arriesgar un expediente real?

Propongo una réplica aislada, con datos ficticios y envíos o acciones externas bloqueados. El equipo conoce que participa en un ensayo, aunque no el error concreto. Se observa si el circuito detecta el fallo antes de autorizar la salida simulada. Un acierto no demuestra que vaya a detectar todos los demás.

El expediente detrás del artículo.

Uncle Bob explica por qué dejó de leer código y de construir arneses ↗Robert C. Martin · entrevista de Aviator del 24 de septiembre, transcripción publicada por el anfitrión comercial · 2026
Entrevista directa; método autodescrito, no auditoríaQué son las pruebas de mutación ↗Stryker Mutator · documentación oficial consultada el 23 de octubre de 2026 · s. f.
Documentación técnica del proyectoMecanismos de supervisión de sistemas de inteligencia artificial ↗Jose Luis Marín · datos.gob.es · 7 de mayo · 2026
Divulgación firmada; no norma ni evaluación experimental

Fuentes consultadas hasta el 23 de octubre de 2026. Las recomendaciones y ejemplos son elaboración editorial y no se atribuyen íntegramente a estas fuentes. Comprueba versión y ámbito antes de aplicar una norma.

Divulgación general. Ninguna herramienta de esta web certifica la revisión, seguridad o conformidad de un proceso.