Un PR llega a tu bandeja. El código tiene un bug real — un race condition, un antipatrón, un riesgo de performance que el autor no vio. Lo ves claramente. Sabes exactamente qué está mal.
Y entonces abres GitHub para escribir el comentario y te quedas en blanco. ¿Cómo lo dices en inglés sin sonar agresivo? ¿Sin sonar como si estuvieras pidiendo permiso?
El code review en inglés tiene una cultura específica. No es solo vocabulario — es un protocolo de comunicación. Los Tech Leads que lo dominan generan menos fricción, más confianza, y PRs que se mergean más rápido.
El problema con los comentarios directos
En español tendemos a escribir directo: "Esto está mal", "Hay que cambiarlo", "No uses este patrón". En inglés técnico, ese estilo genera fricción innecesaria — suena más a orden que a colaboración.
La cultura de code review en equipos anglosajones usa un patrón diferente: contexto + observación + sugerencia, sin imponer. No porque sean menos directos — sino porque ese patrón reduce el ego involucrado y acelera el merge.
Las cuatro categorías de comentario
Un code review profesional en inglés tiene cuatro tipos de comentario. Cada uno tiene su fórmula.
Blocker — cambio requerido antes de merge:
"This will cause a race condition when two users hit the endpoint simultaneously. We need to add a lock here before merging."
Empieza con el impacto técnico, no con el juicio. "This will cause X" es más preciso y persuasivo que "This is wrong".
Suggestion — mejora recomendada, no bloqueante:
"Consider extracting this logic into a helper function — it appears three times in this file and would make future changes easier."
"Consider..." y "You might want to..." son los prefijos estándar para sugerencias. El autor entiende que tiene autonomía para decidir.
Nit — detalle menor de estilo:
"Nit: variable name could be more descriptive —
userListinstead oful."
El prefijo "Nit:" es universal en equipos anglosajones. Señala que el comentario no bloquea el merge y que el autor puede ignorarlo.
Praise — feedback positivo explícito:
"Nice approach here — this avoids the N+1 query problem we had in the previous implementation."
El feedback positivo no es opcional en un code review profesional. Los equipos de alto rendimiento lo practican de forma sistemática porque acelera el aprendizaje del equipo.
El patrón completo: observación + impacto + sugerencia
La fórmula más efectiva combina tres elementos:
[Lo que veo] + [Por qué importa] + [Qué propondría]
Ejemplo malo:
"This is inefficient."
Ejemplo profesional:
"This query runs inside a loop, which means N database calls per request. Moving it outside and passing the results in would reduce that to one call."
La diferencia no es el nivel de inglés — es la estructura. Cualquier Tech Lead con B1 puede escribir ese comentario. El vocabulario es simple. Lo que cambia es el patrón de comunicación.
Cuando necesitas más contexto antes de bloquear
A veces el código parece incorrecto pero falta contexto. La frase más útil en esos casos:
"Can you help me understand why this was implemented this way? I want to make sure I'm not missing context before suggesting a change."
Esta frase hace tres cosas al mismo tiempo: muestra que investigaste antes de criticar, da al autor la oportunidad de explicar una decisión de diseño válida, y establece que tú eres quien decide si el cambio es necesario.
De leer las frases a usarlas bajo presión
Conocer estos patrones en teoría no es suficiente. El code review en inglés sucede con contexto técnico complejo, bajo tiempo limitado, en un idioma que no es tu primero.
El Commit Method entrena exactamente ese gap: producción oral activa en situaciones reales de liderazgo técnico. El Sprint 2 cubre feedback en reuniones y revisiones — no para que leas las frases, sino para que salgan solas cuando las necesitas.