Lo que me enseñó hacer code review

June 10, 2026

Durante mucho tiempo pensé que el code review servía para encontrar bugs. Alguien revisa, encuentra el error, lo señala, se corrige. Eso es todo.

Estaba equivocado. O al menos, estaba mirando solo una parte.

Lo que aprendí revisando código de otros

Cuando empecé a revisar código de compañeros de equipo, lo primero que noté no fueron los bugs. Fue que el código me contaba cosas del estado mental de quien lo escribió.

Un nombre de variable críptico dice que el developer tenía prisa o que asumió que nadie más iba a tocar ese archivo. Una función de ochenta líneas que hace cuatro cosas distintas dice que nadie se detuvo a pensar en la responsabilidad de ese módulo. Un comentario que explica el qué en vez del por qué dice que el código necesita justificarse a sí mismo para entenderse.

No estoy hablando de código malo. Estoy hablando de código que cuesta leer, y costar leer tiene un precio real en el tiempo de todos.

Revisar código de otros me entrenó para leer con criterio. Y ese criterio después lo apliqué al mío.

Lo que aprendí cuando revisaban el mío

La primera vez que me devolvieron un PR con comentarios, lo tomé más personal de lo que me gustaría admitir. Sentía que estaban cuestionando mis decisiones, no el código.

Con el tiempo entendí que eso era exactamente el punto. Mis decisiones necesitaban sobrevivir a alguien que no tenía el contexto que yo tenía cuando las tomé. Si no sobrevivían, el problema no era el revisor.

Un ejemplo concreto. Tenía una función así:

1function handleData(arr: any[]) {
2  const result = arr
3    .filter((i) => i.active)
4    .map((i) => ({
5      ...i,
6      label: i.first_name + ' ' + i.last_name,
7    }))
8  return result
9}

El comentario fue simple: "¿Qué es arr? ¿Qué devuelve esto?"

Tenía razón. La función hacía algo concreto pero no lo decía en ningún sitio. Reescrita:

1function getActiveUsersWithFullName(users: User[]): UserOption[] {
2  return users
3    .filter((user) => user.active)
4    .map((user) => ({
5      ...user,
6      label: `${user.firstName} ${user.lastName}`,
7    }))
8}

Misma lógica. Pero ahora el nombre explica la intención, los tipos documentan la forma, y quien lo lea dentro de seis meses no necesita ejecutarlo en su cabeza para entender qué hace.

Ese tipo de feedback no lo hubiera generado solo. Necesitaba a alguien leyendo desde fuera.

El code review como comunicación

Lo que más me cambió la perspectiva fue entender que el código no solo lo ejecuta una máquina. Lo leen personas. Y esas personas tienen que mantenerlo, extenderlo, depurarlo a las dos de la mañana cuando algo falla en producción.

Escribir código es un acto de comunicación. El code review es la prueba de si esa comunicación funciona.

Cuando un compañero no entiende algo en mi PR, no es que él no sepa suficiente. Es que yo no fui suficientemente claro. Esa distinción cambia cómo respondo al feedback.

Esto cobra más sentido con la IA

Hay un argumento que antes era solo de buenas prácticas y ahora tiene consecuencias directas: el código que escribes es el contexto que consume la IA.

Cuando un agente analiza tu codebase para sugerirte algo, refactorizar una función o entender cómo está estructurado un módulo, no tiene acceso a tu cabeza. Solo tiene lo que está escrito. Un nombre descriptivo, un tipo bien definido, una función con responsabilidad clara — todo eso le da a la IA material con el que razonar bien.

Una función que se llama handleData y acepta any[] no le dice nada. No le dice si es un componente de UI, una transformación de datos, una llamada a una API. No le dice las decisiones de producto que llevaron a escribirla así. No le dice nada sobre la arquitectura del sistema.

Una función que se llama getActiveUsersWithFullName y devuelve UserOption[] le dice todo eso sin necesidad de explicación adicional. El nombre documenta la intención, los tipos documentan la forma, y juntos comunican el patrón.

El code review me enseñó a escribir código legible para personas. Lo que no esperaba es que esa misma legibilidad acabaría siendo la base para trabajar mejor con IA.

Lo que me quedo

El code review me enseñó a escribir código como si no fuera a estar ahí para explicarlo. Porque la mayoría de las veces, no voy a estar.

Me enseñó que las decisiones técnicas necesitan comunicarse, no solo tomarse. Y que recibir un comentario en un PR no es una crítica al trabajo, es una oportunidad de hacer el código más legible para el próximo que lo toque.

Que muchas veces, ese próximo soy yo.