El programador y matemático Mark Dominus (@mjd) cuestiona una idea muy extendida en ingeniería de software: que la revisión de código sirve principalmente para encontrar bugs. En un hilo en Mathstodon, sostiene que quien dependa de la revisión para detectar errores vive en una ilusión, porque resulta imposible demostrar que el código está libre de fallos por mera inspección. La tarea, en su lugar, debería ser comprobar si el código resulta comprensible para otra persona. Si el revisor no entiende lo que hace el código, eso indica que será difícil de mantener y debe corregirse mientras el autor original aún lo recuerda.
Dominus compara ambas aproximaciones: pedir que alguien encuentre bugs en una pila de código ajeno es una misión sin criterio claro de éxito ni de cuándo detenerse; pedir que la entienda y anote lo que no comprende es una labor con un final definido y un resultado casi siempre garantizado. El hilo incorpora además voces que amplían la propuesta: varios participantes defienden que la revisión también transfiere conocimiento, educa al autor en las convenciones del equipo, divulga buenas prácticas y, ocasionalmente, detecta errores como efecto colateral. Otros recordatorios frecuentes son la utilidad de exigir comentarios en el código cuando algo no es obvio, de pedir casos de prueba y de registrar los compromisos de diseño asumidos. En conjunto, el debate redefine la revisión como una práctica colaborativa de claridad y aprendizaje mutuo, no como una auditoría de defectos.