¿Cómo nos ponemos al día con las revisiones de PR en la era de la IA?

1. Limita cada PR a una sola cosa

La forma más rápida de matar el impulso de una revisión es un PR que hace tres cosas a la vez. Quienes revisan no deberían tener que desenredar mentalmente qué cambios pertenecen a la corrección del bug y cuáles al refactor que metiste de paso.

• Una corrección de bug, un campo, una función; no las tres cosas en el mismo PR.

• Un PR centrado de unas ~1.000 líneas que resuelve un problema claro está bien. Un PR de 300 líneas con tres temas no lo está. Si te vas mucho más allá de 1.000 líneas, es una señal clara de que deberías dividirlo.

• Usa PR apilados para cambios más grandes.

• Haz un chequeo rápido antes de abrirlo: ¿alguien puede revisarlo del tirón? ¿Hace exactamente una cosa? ¿Lo fusionarías?

2. No pidas revisión hasta que de verdad esté listo

Los borradores existen por una razón. Sacar un PR de borrador es una señal para el equipo de que has hecho los deberes y de que merece el tiempo de otra persona. Si esa señal no es fiable, todo el sistema de revisión se rompe.

Solo quítale el borrador si puedes responder que sí a todo esto:

• Hiciste una self-review

• Pasan todas las pruebas, incluidas las e2e

• Cero comentarios sin resolver (incluidos los de Devin)

• Lo probaste en local para cambios de UI/UX

• Para cambios que se pueden cubrir con pruebas automatizadas, verificaste que está cubierto al 100%

• Todos los trabajos de CI están en verde (excepto las molestas vistas previas de Vercel)

Si alguna respuesta es no, déjalo como borrador. Los borradores que piden revisión ensucian la cola y retrasan los PR que sí están listos.

3. Limita tus PR abiertos a 5 (los borradores cuentan)

Los PR abiertos son inventario. Llevan coste de cambio de contexto, riesgo de conflictos de merge y deuda de revisión. Si tienes más de cinco abiertos a la vez, las cuentas no salen. Estás produciendo más rápido de lo que el equipo puede absorber.

Si tienes 5 PR abiertos, sumando borrador y no borrador, no empieces algo nuevo. Ve a revisar los PR de tus compañeros o termina tu trabajo anterior.

4. Pon voz humana en la descripción de tu PR

La descripción no tiene por qué estar escrita al completo por ti. La IA está bien para hacer la estructura y resumir el diff. El problema con lo que estamos viendo ahora son las descripciones enormes generadas por IA, que suenan como una checklist genérica con la que nadie se ha implicado. Les falta el toque humano que de verdad necesita quien revisa.

• Una nota del autor en una sola frase sobre el compromiso que has elegido, o sobre por qué esta corrección importa ahora, aporta más que un bloque largo de "Key Review Points" / "Human Review Checklist".

• Si estás sacando código que todavía no se usa en ningún sitio, dilo.

• Si la IA redactó la descripción, recórtala y añade el contexto que solo tú tienes.

5. Demuestra que la corrección funciona

Un PR que dice "corrige el bug X" sin pruebas está pidiendo a quien revisa que se lo crea sin más. No les hagas hacer eso.

• Capturas, grabaciones de pantalla, paneles antes/después, cualquier cosa que muestre que el bug está muerto y que nada más se ha roto.

• La QA funcional es obligatoria para cambios de UX/UI, no opcional.

6. Los cambios en SQL y rendimiento necesitan validación real

La revisión de código por sí sola no puede confirmar que una reescritura de consulta aguante bajo carga de producción. Leer un diff de una consulta y decir "parece bien" no es validación. Para PR que toquen rutas de consulta o reescrituras:

• EXPLAIN ANALYZE sobre un dataset parecido al de producción

• Números de latencia antes/después o capturas de paneles

• Despliegue con feature flag para cambios arriesgados

7. La IA es un acelerador, no un cerebro

La IA puede generar código rápido. No puede decidir si ese código debería existir. El pensamiento sigue teniendo que venir de ti.

• Primero diseña. Esboza el enfoque, piensa en los casos límite, escribe una nota rápida y luego lanza el prompt.

• Después de que el agente genere, léelo de verdad. La self-review detecta llamadas a Prisma en el sitio equivocado, directrices del agente ignoradas, estructura frágil, etc.

• Antes de abrirlo, pregúntate: ¿qué toca esto? ¿Afecta a usuarios? ¿Tiene implicaciones de rendimiento o seguridad? ¿Cuál es el radio de impacto si sale mal?

8. Valida los PR de seguridad antes de abrirlos

Confirma que la vulnerabilidad realmente se aplica a cómo usamos el código. Los PR de "corrige la vulnerabilidad X" que tocan rutas sensibles pueden introducir más riesgo que el informe original.

9. Envía los PR a la persona revisora adecuada

La persona equivocada hace perder el tiempo a dos personas: a quien revisa, que no puede dar feedback útil, y a quien escribe, que tiene que esperar una segunda ronda con la persona correcta.

• Los PR muy centrados en un dominio (routing de Salesforce/CRM, migraciones de perfiles de equipo, etc.) deben ir con la persona responsable de ese dominio, no con Foundation poniendo el sello a una suite de pruebas generada por IA.

• Los cambios en rutas centrales/de Foundation (query infra, hasTeamAccess, etc.) merecen una alineación rápida con el equipo propietario antes de abrir el PR.

10. Las conversaciones de arquitectura pasan pronto

Parchear la misma zona tres veces es una señal, no una casualidad. Si vuelves a trabajar alrededor de la misma limitación, lo correcto es hablar y, si hace falta, reescribir, no meter otro parche.

Habla con Foundation/Head of Engineering antes de implementarlo. Así es como se fueron construyendo los módulos de infra, y la consistencia se multiplica.

11. Ruta más ligera para arreglos triviales

No todo necesita revisión de Foundation. Deberíamos gastar ancho de banda de revisión donde más importa.

Ajustes de toast, tamaño de botones, renombrados mecánicos, cambios de copy, funciones de la rama principal: esto puede pasar por revisión con IA y/o revisiones a nivel de equipo. Reserva la revisión de Foundation para los cambios que de verdad la necesiten.

12. No abras PR en nombre de otros

Si el Ingeniero X hace el trabajo, el Ingeniero X abre el PR. Si no, los comentarios llegan a la persona equivocada, las preguntas se quedan sin respuesta y el PR se atasca.