# laycock-thoughtworks-reviewing-all-this-code-2026-09-02

## Veille

Post de **Rachel Laycock**, CTO de **Thoughtworks**, publicado el **2 de septiembre de 2026** en *Rachel's Ramblings*, la sección de martinfowler.com que dirige, de aproximadamente **8.000 caracteres**. El texto es una **respuesta deliberada** a [[houck-dx-what-are-code-reviews-for-2026-08-05]], tras un desacuerdo público entre ambas autoras en un panel de **Code Remix** organizado por **Moderne**. Laycock acepta el diagnóstico cuantificado de Houck (+**106%** de líneas por diff en **Meta**, +**64%** de tamaño mediano de PR en el lado de DX) y la lista de funciones de la revisión que no consisten en detectar defectos, y a continuación desplaza la pregunta: *« ¿por qué esperamos hasta la revisión de código para hacer todo eso? »* (A) El principio rector es el acortamiento de los bucles de retroalimentación aprendido en Thoughtworks — si la retroalimentación tiene valor, no se elimina, se acerca a la decisión que informa. Cada función atribuida a la revisión se reasigna aguas arriba: exploración de alternativas antes de la implementación, transferencia de conocimiento mediante **pair programming**, propiedad colectiva mediante **mob programming** y sesiones de diseño en equipo, alineación arquitectónica mediante diseño compartido seguido de **fitness functions**, y automatización de todo lo determinista — *« De verdad que no deberíamos seguir discutiendo sobre espacios en blanco en 2026. »* (B) La revisión basada en excepciones sustituye a la revisión sistemática: 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 simplemente la falta de confianza declarada por un equipo. (1) Automatizar la revisión con un agente que imita al revisor humano se descarta por *« automatizar la ceremonia en lugar de cuestionar por qué existe la ceremonia »*. (2) La deuda cognitiva de Houck se reconoce como real, pero la PR obligatoria se considera una defensa débil: *« Necesitamos que los ingenieros entiendan los sistemas, no los diffs. »*

## Titre Article

Maybe We Shouldn't Be Reviewing All This Code

## Date

2026-09-02

## URL

https://martinfowler.com/rachels-ramblings/code-review.html

## Keywords

revisión de código, revisión basada en excepciones, pull request, bucle de retroalimentación corto, desplazar el juicio hacia la izquierda, shift left, pair programming, mob programming, sesión de diseño en equipo, desarrollo basado en trunk, fitness functions, arquitectura evolutiva, análisis estático, pruebas automatizadas, análisis de seguridad, ceremonia, cuello de botella, radio de impacto, límite de seguridad, deuda cognitiva, deuda de intención, propiedad colectiva, transferencia de conocimiento, entender los sistemas, no los diffs, Thoughtworks, Code Remix, Moderne

## Authors

Rachel Laycock, CTO de Thoughtworks, sur *Rachel's Ramblings* (martinfowler.com).

## Ton

Perfil: post de respuesta breve firmado por una directiva técnica, voz en primera persona plenamente asumida, registro argumentativo y personal, nivel técnico medio, público objetivo de líderes de ingeniería y practicantes ágiles. El texto se presenta como tal desde la apertura —panel, desacuerdo, la invitación de la otra autora a escribir la respuesta— y fija sus términos de cortesía antes de atacar: acuerdo sobre los hechos, acuerdo sobre los objetivos, desacuerdo sobre los medios. *« Creo que en su mayoría queremos las mismas cosas. Simplemente no creo que la revisión de código sea la mejor manera de conseguirlas. »* La concesión es explícita y se duplica con humor (*« Brian es encantador, por cierto »*, *« Pero estaría mintiendo si dijera que no quiero que al final pienses que tengo razón :) »*), igual que la admisión de una postura sostenida desde hace tiempo: la autora nunca le ha gustado la pull request en el centro del proceso, y lo dice con una digresión deliberada sobre los conflictos de fusión. La construcción es una refutación punto por punto que recoge la lista de su oponente y la reasigna, con una cifra repetida hasta la autoironía (*« No voy a repetirme sobre el pairing y las sesiones de diseño en equipo, ah espera... »*). La reserva se coloca donde corresponde, sin dramatizarla: la deuda cognitiva y de intención se concede como *« un problema muy real »*, solo se discute el remedio. Citable tal cual: *« Si la retroalimentación es valiosa, no la elimines. Acércala a la decisión que está informando »*; *« Necesitamos que los ingenieros entiendan los sistemas, no los diffs »*; *« automatizar la ceremonia en lugar de cuestionar por qué existe la ceremonia »*; y la frase final, *« quizás la pregunta no es cómo conseguir que el código se revise más rápido. Quizás es por qué esperamos hasta la revisión de código para tener, en primer lugar, todas las conversaciones importantes. »*

## Pense-betes

- **El desacuerdo es sobre los medios, no sobre el fin.** Laycock acepta las cifras y la lista de Houck —la revisión también sirve para compartir conocimiento, formar a los junior, generar propiedad colectiva y difundir comprensión arquitectónica— y no concluye que la revisión deba preservarse, sino que hay que dejar de esperar a la revisión para hacer todo esto. La tesis descansa en una inversión de calendario, no en una disputa sobre los datos.
- **El principio importado: acortar el bucle, no eliminar la retroalimentación.** *« Si la retroalimentación es valiosa, no la elimines. Acércala a la decisión que está informando. »* Tabla de reasignación función por función: exploración de alternativas → antes de la implementación, no después; transferencia de conocimiento → **pair programming**, porque razonar junto a alguien enseña más que leer su solución terminada; aprendizaje de los junior → trabajar con los senior *mientras* piensan; propiedad colectiva → organización en equipo, **mob programming**, sesiones de diseño en pizarra; alineación arquitectónica → diseño compartido seguido de **fitness functions** que codifican las restricciones; formateo, linting, problemas de seguridad conocidos y todo lo que se pueda probar de forma determinista → automatización.
- **La «revisión basada en excepciones» es el mecanismo de salida propuesto**, y está explícitamente acotado: un cambio arquitectónico fundamental (posiblemente revisado en equipo tras una sesión de diseño), el cruce de un límite de seguridad sensible, un cambio con un radio de impacto amplio, una parte poco conocida de un sistema crítico, o un equipo que declara carecer de confianza. La distinción es entre *« exactamente los lugares donde el juicio humano es valioso »* y exigir la inspección humana de cada cambio en nombre de la ceremonia histórica de producir confianza.
- ⚠️ **El argumento anti-cuello de botella es independiente del pedagógico** y se sostiene por sí solo: si un agente produce diez veces más código pero cada línea sigue terminando en cola frente a un ingeniero senior, no se ha construido una organización diez veces más rápida — se ha construido una acumulación pendiente y un nuevo cuello de botella. Es el mismo mecanismo que el coste del cambio aceptado en [[staples-gitlab-when-code-is-abundant-2026-08-24]]: eliminar una restricción expone la siguiente.
- **La revisión por IA que imita al revisor humano se rechaza explícitamente** — no porque funcionaría mal, sino porque preserva un proceso cuya razón de ser no se ha reexaminado: *« Eso es automatizar la ceremonia en lugar de cuestionar por qué existe la ceremonia. »* Nota para la práctica: esta reserva apunta a la sustitución equivalente, no a los agentes que participan en los bucles aguas arriba, que el texto acepta (cuestionar diseños, probar hipótesis, verificación continua), manteniendo a la vez que el razonamiento proviene de humanos experimentados.
- **Lo que se concede, y lo que se rebate**: la deuda cognitiva y de intención se califica de *« problema muy real »*; lo que se discute es la PR obligatoria como defensa frente a ella. La contrapropuesta no es un único mecanismo sino una lista —diseño colaborativo, pairing, buenos límites, arquitectura ejecutable, responsabilidad operativa compartida—, junto con la admisión de que probablemente se necesitarán prácticas aún no inventadas.
- **El diagnóstico subyacente, que vale la pena conservar fuera del debate**: años acumulando una cantidad extraordinaria de responsabilidades sobre la revisión de código —control de calidad, control de seguridad, revisión de arquitectura, mecanismo de mentoría, sistema de transmisión de conocimiento, modelo de propiedad. Esto se sostuvo solo mientras los humanos podían producir código a cierta velocidad; esa restricción es la que está desapareciendo, y con ella toda la pila.
- **Relacionado**: [[monperrus-end-of-code-review-agents-supersede-2026-06-11]] (la misma conclusión sobre la inspección humana, alcanzada mediante la automatización en lugar del desplazamiento hacia la izquierda) y [[boeckeler-harness-engineering-coding-agents-2026-04-02]] (herramientas de verificación aguas arriba, también de Thoughtworks).

## RésuméDe400mots

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?

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.

## GrapheDeConnaissance

- Rachel Laycock —a_créé→ Maybe We Shouldn't Be Reviewing All This Code (DOCUMENT, 0.97)
- Rachel Laycock —dirige→ Thoughtworks (ORGANISATION, 0.95)
- Maybe We Shouldn't Be Reviewing All This Code —s_oppose_à→ What are code reviews even for? (DOCUMENT, 0.96)
- Rachel Laycock —affirme_que→ le problème n'est pas que l'IA ait cassé la revue de code, mais qu'on utilisait la revue pour résoudre les mauvais problèmes (AFFIRMATION, 0.95)
- boucle de rétroaction courte —recommande→ ne pas supprimer un retour de valeur, mais le rapprocher de la décision qu'il informe (CITATION, 0.94)
- pair programming —remplace→ revue de code (METHODOLOGIE, 0.92)
- pair programming —surpasse→ la lecture d'une solution achevée pour apprendre le raisonnement d'un ingénieur expérimenté (AFFIRMATION, 0.91)
- mob programming —permet→ propriété collective par construction, au lieu d'une notification de l'équipe après coup (AFFIRMATION, 0.89)
- session de design d'équipe —permet→ explorer les alternatives avant l'implémentation plutôt qu'après (CONCEPT, 0.91)
- fitness functions —permet→ encoder les contraintes architecturales importantes après un design commun (CONCEPT, 0.92)
- analyse statique —s_applique_à→ formatage, linting, problèmes de sécurité connus et tout ce qui est testable déterministiquement (CONCEPT, 0.92)
- revue par exception —s_applique_à→ changement architectural fondamental, frontière de sécurité sensible, large rayon d'impact, zone inconnue d'un système critique, inconfiance déclarée de l'équipe (CONCEPT, 0.94)
- revue par exception —s_oppose_à→ exiger l'inspection humaine de chaque changement au titre de la cérémonie historique de production de confiance (AFFIRMATION, 0.93)
- Rachel Laycock —prédit→ un agent produisant dix fois plus de code devant une file de revue senior ne crée pas une organisation dix fois plus rapide mais un backlog et un nouveau goulot (AFFIRMATION, 0.93)
- revue de code par agent imitant le relecteur humain —s_oppose_à→ interroger la raison d'être de la cérémonie plutôt que l'automatiser à l'identique (CITATION, 0.92)
- agents IA —permet→ participer aux boucles amont en contestant des designs, testant des hypothèses et vérifiant en continu, la pensée restant humaine (AFFIRMATION, 0.88)
- Rachel Laycock —soutient→ la dette cognitive et d'intention est un problème réel (AFFIRMATION, 0.92)
- pull request —réduit→ faiblement la dette cognitive et d'intention lorsqu'elle est rendue obligatoire, contre l'usage qui lui est prêté (AFFIRMATION, 0.9)
- Rachel Laycock —affirme_que→ il faut que les ingénieurs comprennent des systèmes, pas des diffs (CITATION, 0.95)
- revue de code —est_instance_de→ empilement de responsabilités (CONCEPT, 0.93)
- abondance du code générée par l'IA —s_oppose_à→ la contrainte de vitesse humaine qui rendait cet empilement tenable (AFFIRMATION, 0.9)
- Code Remix —observé_dans→ le désaccord public entre Rachel Laycock et Brian Houck, à l'origine du billet (AFFIRMATION, 0.9)
- Moderne —publie→ Code Remix (EVENEMENT, 0.88)
- Rachel Laycock —recommande→ maintenir la compréhension humaine par design collaboratif, pairing, bonnes frontières, architecture exécutable et responsabilité opérationnelle partagée (AFFIRMATION, 0.92)

---
Canonical: https://www.thekb.eu/es/fiches/laycock-thoughtworks-reviewing-all-this-code-2026-09-02/