Qué encuentra un revisor automático y qué sólo ve un humano
Las herramientas atrapan lo que se puede describir con una regla: formato, complejidad, dependencias vulnerables. Lo que no pueden ver es si el cambio hace lo que el ticket pedía. Cómo se reparte el trabajo para que la review humana valga la pena.
En un equipo con linter, formateador, tipos, tests en el pipeline y un analizador de seguridad, sigue apareciendo la misma pregunta: ¿para qué sirve que otra persona mire el código?
La respuesta corta es que las herramientas responden “¿está bien escrito?” y la persona responde “¿es esto lo que había que hacer?”. Son dos preguntas distintas, y la segunda es la que rompe producción cuando nadie la hace.
Quién encuentra qué
| Lo encuentra | Ejemplos | Por qué |
|---|---|---|
| La herramienta | Formato, imports sin usar, tipos, complejidad ciclomática, dependencia con vulnerabilidad conocida, cobertura que baja | Se describe con una regla y se verifica igual siempre |
| Sólo la persona | El cambio resuelve otro problema que el del ticket, el nombre miente, falta el caso de una marca, ese helper ya existía | Requiere saber qué se pedía y cómo funciona el resto del producto |
| Las dos, con distinto alcance | Duplicación: la herramienta ve copias literales, la persona ve la misma lógica escrita distinto | La regla detecta la forma, no la intención |
La consecuencia práctica es una regla de higiene del equipo: todo comentario que se repite y se puede automatizar, se automatiza. Discutir comillas simples o dobles en una review es gastar la atención más cara del proceso en lo más barato de resolver.
Lo que una herramienta no puede saber
Un analizador ve el código; no ve el producto. Estos son comentarios que aparecieron en revisiones reales y que ninguna regla iba a levantar:
Cuatro cosas que sólo ve alguien que conoce el dominio
- El cambio es correcto y resuelve otra cosa. El código compila, los tests pasan, y lo que hace no es lo que el ticket describía.
- Falta un caso del negocio. Anda para tres marcas y la cuarta tiene una regla distinta que no está escrita en ningún lado, sólo en la cabeza de quien la implementó hace dos años.
- El nombre miente. Una función llamada como si validara, que además guarda. El tipo está bien, el nombre no.
- Esto ya existía. Un helper equivalente en otro módulo, con otro nombre. Ninguna herramienta lo ve porque el código no se parece: lo que se repite es el propósito.
Los revisores automáticos que leen el cambio
La generación de herramientas que comenta en lenguaje natural corre el límite, sin borrarlo.
Detectan bastante bien lo local: un nulo posible, un await que falta, un caso del switch sin
cubrir, una condición invertida.
Lo que siguen sin tener es el contexto de por qué se pidió el cambio, qué acordó el equipo hace seis meses y qué está por migrarse el mes que viene. Sirven como primera pasada —barata, inmediata, sin pudor de señalar lo obvio— y no como aprobación.
Antes de seguir, predecí
Cómo queda el proceso
El orden que hace rendir la review
- Automático primero: formato, tipos, tests y análisis corren antes de pedir review. Llegar con el pipeline en rojo es pedirle a una persona que haga de compilador.
- Descripción del pull request: qué se pidió, qué se hizo y qué quedó afuera. Sin eso, el revisor no puede responder la única pregunta que le corresponde.
- Review humana: intención, dominio, nombres, reuso, casos faltantes.
- Lo que se repitió, a una regla: si el mismo comentario salió tres veces, el cuarto lo hace la herramienta.
Más a fondo · nivel seniorCuando el equipo revisa sólo lo que la herramienta no cubre
En equipos maduros, la review humana se parece más a una conversación de diseño que a una corrección: “¿por qué acá y no en el servicio?”, “esto lo va a necesitar el otro equipo, ¿lo exponemos?”. Ese tipo de comentario es el que justifica el costo del proceso, y es imposible de automatizar porque depende de información que no está en el repositorio.
Qué encuentra cada uno
Hay 4 problemas en este cambio. Tocá la línea donde creas que está.
| 5 | 5 | ||
| 6 | 6 | ||
| 7 | 7 | ||
| 8 | |||
| 8 | |||
| 9 | |||
| 10 | |||
BloqueaAhora manda un correo por cada contacto Antes salía un recordatorio; ahora salen tantos como contactos tenga el cliente. Ninguna herramienta puede saber si eso es lo que se quería: es la pregunta «¿es esto lo que había que hacer?», y sólo la contesta alguien que entiende el producto. Si la respuesta es sí, falta decidir qué pasa con los contactos que no tienen que recibir facturación. | |||
| 11 | |||
SugerenciaUn await adentro de un for Esto sí lo marca el linter, y con razón: los envíos van uno tras otro en vez de en paralelo. Es exactamente el tipo de comentario que no conviene que haga una persona, porque lo hace una regla, sin discusión y sin gastar la atención de nadie. | |||
| 12 | |||
| 13 | |||
| 14 | |||
BloqueaSe marca como recordado aunque algún envío haya fallado El markReminded corre siempre, incluso si el mailer rechazó la mitad de los correos. Nadie se entera y la factura queda marcada. Es una pregunta sobre qué significa «recordado» en este negocio, y por eso la tiene que hacer una persona. | |||
| 9 | 15 | ||
De los cuatro, uno lo marca el linter. Los otros tres necesitan a alguien que sepa para qué es el sistema.
Cómo queda el reparto
Cierre
Autoevaluación
¿Lo entendiste?
Práctica
BloqueaLa consulta no filtra por cuenta
Esto lo encuentra una persona, no una herramienta: sintácticamente es impecable y el tipo está bien. Sólo alguien que sabe que este sistema es multiempresa se da cuenta de que byId sin el filtro de cuenta permite traer un cliente ajeno si el id se filtra por otro lado.