Ir al contenido
← Volver al blog

La brecha entre lo que dice un PR y lo que hace

·4 min de lectura

Tu equipo mergea 50 PRs a la semana. ¿Cuántos alguien realmente leyó línea por línea? La respuesta es incómoda. Y la brecha entre lo que los PRs afirman y lo que el código realmente hace es donde los bugs llegan a producción.

La anatomía de un cambio perdido

Un PR dice "Fix login timeout." El diff muestra un cambio de timeout en el servicio de auth. Se ve bien, aprobado. Pero enterrado en la línea 247 de un diff de 300 líneas, también hay un cambio en la duración de sesión de 24 horas a 7 días. Nadie lo mencionó. Nadie lo detectó.

Esto no es malicioso. El desarrollador arregló el timeout y, ya que estaba en el archivo, ajustó la duración de sesión también. Olvidó mencionarlo en la descripción. El reviewer vio "Fix login timeout" y se enfocó en la lógica del timeout. Ambos humanos hicieron su trabajo — y un cambio llegó a producción sin documentar.

Con escala, empeora

Equipos pequeños con 5 PRs a la semana pueden detectar esto manualmente. Con 50 PRs a la semana, nadie lee cada línea. Con 200 PRs — común en equipos usando agentes de IA — la matemática es imposible.

Cada PR que llega a producción con cambios no documentados es una futura sesión de debugging. "¿Cuándo cambió la duración de sesión?" "¿Por qué hay esta nueva dependencia en nuestro lock file?" "¿Quién agregó esta variable de entorno?" Las respuestas están enterradas en el PR #847 de hace tres semanas.

Cómo se ven los cambios no documentados

Hemos analizado miles de PRs. Los cambios no documentados más comunes caen en categorías predecibles:

Nuevas dependencias
La descripción del PR habla de una feature. El diff agrega un paquete npm nuevo. Sin mención de por qué se necesita o qué hace.
Detectado por: signal Undocumented Changes
Variables de entorno
Una nueva variable API_TIMEOUT aparece en el código. El PR dice "mejorar manejo de API" pero no menciona el nuevo requisito de configuración.
Detectado por: signal Undocumented Changes
Cambios de schema
Una migración agrega una columna nullable. El PR es sobre una feature de UI. El cambio de schema habilita la feature pero no se documenta.
Detectado por: signal Undocumented Changes
Cambios de comportamiento
Valores por defecto cambian. El manejo de errores pasa de throw a return silencioso. La lógica de retry se elimina. Todos cambios legales, ninguno mencionado.
Detectado por: Claims Verifier + Undocumented Changes

Cerrando la brecha

La solución no es "escribir mejores descripciones" — los humanos siempre olvidarán cosas, y los agentes de IA siempre serán confidentemente incompletos. La solución es verificación automatizada.

Vigil lee cada descripción de PR, extrae las afirmaciones, verifica cada una contra el diff, y detecta todo lo que la descripción no mencionó. Se ejecuta en cada PR automáticamente — sin config, sin paso manual, sin memoria humana requerida.

La brecha entre lo que dice un PR y lo que hace no tiene que ser un misterio. Puede ser un reporte.