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

1. Acota cada PR a una sola cosa

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

• Un arreglo 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 resuelva un problema claro está bien. Un PR de 300 líneas con tres asuntos no. Si te vas bastante por encima de 1.000 líneas, es una señal clara de que debes dividirlo.

• Usa PR apilados para cambios más grandes.

• Compruébalo 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 del borrador es una señal para el equipo de que has hecho tu debida diligencia y de que merece el tiempo de otra persona. Si esa señal no es fiable, todo el sistema de revisión se desmorona.

Quita el borrador solo si puedes responder que sí a todo esto:

• Hiciste una autorevisión

• Todos los tests pasan, incluidos los e2e

• Cero comentarios sin resolver (incluido el de Devin)

• Lo probaste en local para cambios de UI/UX

• Para cambios que pueden cubrirse con tests automatizados, verificaste que estén cubiertos al 100%

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

Si alguno es no, déjalo como borrador. Los borradores que piden revisión contaminan 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, entre borrador y no borrador, no empieces nada 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 que estar escrita por ti al completo. La IA está bien para estructurar y resumir el diff. El problema con lo que vemos ahora son las descripciones enormes generadas por IA que suenan como una lista genérica a la que nadie prestó atención. Les falta el elemento humano que de verdad necesita quien revisa.

• Una nota del autor en una sola frase sobre el compromiso que elegiste, o por qué este arreglo 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 ninguna parte, dilo.

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

5. Demuestra que el arreglo funciona

Un PR que dice "arregla el bug X" sin pruebas está pidiéndole a quien revisa que se lo crea sin más. No le hagas hacer eso.

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

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

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

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

• EXPLAIN ANALYZE sobre un conjunto de datos parecido al de producción

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

• Despliegue con feature flag para cambios de riesgo

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 trabajo de pensar sigue teniendo que venir de ti.

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

• Después de que el agente genere el código, léelo de verdad. La autorevisión 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 al usuario? ¿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 aplica a cómo usamos el código. Los PR de "arregla la vulnerabilidad X" que tocan rutas sensibles pueden introducir más riesgo que el informe original.

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

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

• Los PR muy centrados en un dominio (enrutamiento de Salesforce/CRM, migraciones de perfiles de equipo, etc.) pertenecen a la persona dueña de ese dominio, no a Foundation poniendo un sello de aprobación a un conjunto de tests generado por IA.

• Los cambios en rutas core/foundation (infra de consultas, hasTeamAccess, etc.) merecen una rápida alineación con el equipo responsable antes de abrir el PR.

10. Las conversaciones de arquitectura ocurren pronto

Parchear la misma zona tres veces es una señal, no una casualidad. Si vuelves a rodear la misma limitación, lo correcto es hablarlo y valorar una reescritura, no otro parche.

Habla con Foundation/Head of Engineering antes de implementar. Así se construyeron los módulos de infra, y la coherencia se multiplica.

11. Camino más ligero para arreglos triviales

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

Ajustes de toast, tamaño de botones, renombres mecánicos, cambios de copy, funciones de la línea principal: todo eso puede pasar por revisión de 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 otras personas

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