Rachel Laycock, CTO de Thoughtworks, publica una respuesta en martinfowler.com el 2 de septiembre de 2026 a la edición de Engineering Enablement firmada por Brian Houck un mes antes. Ambas autoras se enfrentaron públicamente en un panel de Code Remix organizado por Moderne, y Houck la animó a escribir este texto. El desacuerdo queda acotado desde el principio: quieren lo mismo, ella simplemente no cree que la revisión de código sea la mejor manera de conseguirlo.
Acepta el diagnóstico. La IA produce más código del que los humanos pueden revisar razonablemente, y las cifras de Houck —un aumento del 106% en líneas significativas por diff en Meta, un tamaño mediano de pull request del 64% en DX— se toman al pie de la letra. Comparte también su preocupación: automatizar la revisión arriesga perder todo lo demás, ya que la revisión nunca ha servido solo para encontrar errores. Su pregunta está en otra parte: ¿por qué esperar hasta la revisión para hacer todo eso?
De verdad que no deberíamos seguir discutiendo sobre espacios en blanco en 2026.
Nunca le ha gustado ver la pull request en el centro del proceso. Construir algo, terminarlo, empaquetarlo, lanzarlo por encima del muro y solo entonces tener la conversación importante sobre si lo construido es correcto le parece un orden invertido. El principio que opone a esto es uno aprendido pronto en Thoughtworks: si la retroalimentación tiene valor, no se elimina, sino que se acerca a la decisión que informa.
Sigue una reasignación sistemática. Explorar alternativas ocurre antes de implementar una. La transferencia de conocimiento ocurre mediante pairing, que enseña más que leer una solución terminada. El aprendizaje de los junior requiere trabajar junto a los senior mientras piensan. La propiedad colectiva proviene de la organización en equipo, el mob programming y las sesiones de diseño en pizarra. La alineación arquitectónica surge del diseño compartido y luego de las fitness functions. El formateo, el linting, los problemas de seguridad conocidos y todo lo determinista se automatizan.
Lo que queda es la revisión basada en excepciones: un cambio arquitectónico fundamental, un límite de seguridad sensible, un radio de impacto amplio, un área poco conocida de un sistema crítico, o un equipo que declara carecer de confianza. Eso es distinto de exigir la inspección de cada cambio en nombre de la ceremonia. También descarta al agente de IA que imitaría al revisor humano: eso automatiza la ceremonia en lugar de cuestionar su razón de ser.
Concede un punto: la deuda cognitiva y de intención que describe Houck es un problema real. Pero la PR obligatoria es una defensa débil frente a ella. Lo necesario es diseño colaborativo, pairing, buenos límites, arquitectura ejecutable y responsabilidad operativa compartida — porque los ingenieros necesitan entender los sistemas, no los diffs.