En mi trabajo actual ya puedo ver una escena que hace poco habría parecido extraña. Un equipo construye herramientas para analizar pull requests con IA: les entrega contexto, agentes y habilidades especializadas para que entiendan mejor el repositorio. Mientras tanto, quien abrió el PR usa sus propios agentes para interpretar los hallazgos, proponer correcciones e incluso debatir las observaciones del revisor automático.
La máquina escribe. Otra máquina revisa. La primera responde.
En medio permanece una persona que debe decidir si el cambio merece entrar al producto.
No me preocupa que exista automatización en ambos lados. La uso y encuentro valor en ella. Me preocupa algo menos visible: una conversación puede crecer hasta parecer rigurosa sin que haya crecido en la misma proporción la comprensión humana del cambio.
Un hilo lleno de comentarios, pruebas y explicaciones no es todavía un modelo mental. La actividad de revisión no equivale necesariamente a supervisión.
La escasez se movió
Durante mucho tiempo tratamos el código como la parte costosa del desarrollo. Había que traducir una intención a una implementación, recorrer el sistema y sostener suficientes decisiones en la cabeza para que el cambio funcionara.
Los agentes reducen parte de ese costo. Pueden explorar el repositorio, producir una primera versión, completar pruebas y responder observaciones con una velocidad que cambia la economía del trabajo. Pero cada cambio que generan crea una obligación posterior: alguien debe comprobar qué hace, qué podría romper y si la evidencia presentada merece confianza.
La producción se acelera. La responsabilidad no.
Por eso empecé a pensar que el recurso escaso ya no es el código. Tampoco es solamente la atención del revisor. Es la capacidad de convertir evidencia en comprensión y comprensión en responsabilidad.
Llamo deuda de verificación a la distancia que aparece cuando acumulamos cambios más rápido de lo que podemos comprenderlos y justificarlos. No es una métrica establecida ni un nuevo nombre para los bugs. Es una manera de reconocer trabajo pendiente que suele desaparecer de los tableros: reconstruir la intención, comprobar supuestos, evaluar el radio de impacto y decidir quién está dispuesto a responder por el resultado.
La paradoja no empezó con los LLM
En 1983, Lisanne Bainbridge publicó Ironies of Automation. Su argumento, formulado alrededor de procesos industriales, sigue siendo incómodo: la automatización puede ampliar los problemas del operador humano en lugar de eliminarlos. El sistema se ocupa de lo rutinario y deja a la persona las condiciones anormales, precisamente cuando resulta más difícil conservar contexto y habilidad.
Un pull request no es una planta industrial. Pero reconozco la misma estructura. Delegamos la producción y parte del análisis; después pedimos a una persona que intervenga en las decisiones ambiguas, de mayor riesgo y con menos tiempo para reconstruir cómo llegamos ahí.
La explicación automática tampoco resuelve necesariamente el problema. Un experimento presentado en ICIS 2025 estudió 3,002 decisiones de 228 personas que evaluaban innovaciones tempranas. Quienes recibieron asistencia de IA fueron 19% más propensos a coincidir con su recomendación. Las explicaciones narrativas aumentaron esa alineación, pero no mejoraron la calidad frente a una recomendación de caja negra.
El estudio no trata sobre código. Lo que me importa es el mecanismo: una explicación coherente puede convertirse en un atajo para aceptar una conclusión. La narrativa ayuda a comprender sólo cuando la contrastamos; también puede hacernos sentir que ya comprendimos.
| Contexto | Señal observada | Límite de lectura |
|---|---|---|
| 228 evaluadores, 3,002 decisiones | La asistencia de IA aumentó 19% la alineación con sus recomendaciones; explicar más no superó en calidad a la recomendación sin explicación. | Evaluaba innovaciones tempranas, no pull requests. |
| 802 desarrolladores, 196,212 PR | El volumen de cambios por persona llegó a 2.09 veces la línea base y la carga por revisor aproximadamente se duplicó. | Estudio observacional en una empresa; la adopción no fue aleatoria. |
| Más de 587 revisiones de cambios | Dos organizaciones aceptaron 8.1% y 7.2% de los comentarios generados; inspeccionarlos agregó una mediana de 43 segundos por cambio. | Los resultados pertenecen a una herramienta y a dos contextos específicos. |
La tabla no demuestra que todos los equipos estén peor con IA. Tampoco que los comentarios automáticos carezcan de valor. Muestra algo más útil: producir más cambios y más señales no elimina el costo de decidir cuáles importan.
Más revisión no siempre significa más comprensión
Hay una tentación natural: si un agente puede introducir errores, agreguemos otro agente que los encuentre. Si sus comentarios producen ruido, agreguemos un tercero que los clasifique. Si dos agentes discrepan, pidamos a ambos que argumenten.
Puede funcionar. También puede crear una simulación de independencia.
Dos agentes que reciben contexto parecido, dependen de modelos relacionados o validan el mismo conjunto incompleto de pruebas pueden coincidir por compartir puntos ciegos. Su consenso no es evidencia independiente por el simple hecho de aparecer en dos mensajes.
Algo similar sucede con la participación humana. Anthropic reportó que sus usuarios aprobaban alrededor de 93% de las solicitudes de permiso. La empresa lo interpreta como un problema de fatiga de aprobación y ha desplazado parte de la seguridad hacia límites deterministas del entorno.
Un permiso no es una revisión de código, pero ambos pueden degradarse como ceremonia. Cuando el sistema solicita demasiadas confirmaciones, la presencia de un humano deja de garantizar atención. En un PR, ese estado se parece a un teatro de revisión: hay comentarios, respuestas y un botón de aprobación, pero nadie puede explicar con claridad qué evidencia cambió la decisión.
Por eso no quiero medir la calidad de un proceso por el número de revisores, agentes o mensajes. Quiero saber qué afirmaciones fueron comprobadas, cuáles fueron contradichas y qué incertidumbre sigue abierta.
Del veredicto al contrato de revisión
La instrucción habitual para un agente es demasiado amplia: “revisa este PR”. Le entrega al sistema tanto la investigación como la definición implícita de lo que significa estar correcto.
Yo cambiaría el orden. Antes de conocer el veredicto del agente, el revisor debería formular un contrato de revisión:
- Qué espero que cambie
- Cuáles son los riesgos relevantes
- Qué evidencia necesitaría para aprobarlo
- Qué no puede quedar resuelto automáticamente
- Quién acepta la decisión final
No le pediría al agente que decida por mí si el PR está bien. Le daría un contrato para que investigue si existen las condiciones que me permitirían asumir responsabilidad por el cambio.
| Cambio esperado | Procesar una sola vez cada evento aunque el proveedor lo reintente. |
|---|---|
| Riesgos | Descartar eventos legítimos, introducir una condición de carrera o conservar claves de deduplicación para siempre. |
| Evidencia necesaria | Pruebas concurrentes, una restricción de unicidad efectiva, comportamiento observable ante reintentos y un límite explícito de retención. |
| Incertidumbre | El proveedor no documenta el intervalo máximo entre reintentos. |
| Responsable | El revisor humano decide si la evidencia y la incertidumbre permiten integrar el cambio. |
El ejemplo es ficticio, pero la diferencia es concreta. “Busca bugs” produce una lista abierta de posibilidades. El contrato dirige la investigación hacia las propiedades que sostienen la decisión.
- 01IntenciónEl autor explica qué debe cambiar y qué queda fuera.
- 02ContratoEl revisor define riesgos y evidencia antes del veredicto.
- 03InvestigaciónEl agente inspecciona el cambio, su contexto, las pruebas y el comportamiento en ejecución.
- 04HallazgosSepara evidencia, contradicciones, faltantes e incertidumbre.
- 05DecisiónUna persona determina si puede responder por el cambio.
Esta secuencia introduce fricción a propósito. La investigación sobre funciones de esfuerzo cognitivo muestra que pedir a las personas construir un juicio antes de ver la recomendación de la IA puede reducir la dependencia excesiva, aunque también hace que la experiencia se perciba menos favorable.
No aplicaría esa fricción por igual a todos los cambios. Corregir un texto no exige el mismo contrato que modificar autorización, dinero, concurrencia o un esquema de datos. El rigor debe crecer con el radio de impacto y la dificultad de revertir.
El agente entrega evidencia, no el veredicto
El contrato también cambia la forma de la respuesta. Un buen resultado no termina en “LGTM” ni en una calificación abstracta. Debería distinguir al menos cuatro categorías:
- Confirmado: propiedades respaldadas por código ejecutado, pruebas, invariantes o comportamiento observable.
- Contradicho: condiciones del contrato para las que existe evidencia en contra.
- Faltante: afirmaciones plausibles que todavía no cuentan con una comprobación suficiente.
- Desconocido: preguntas que el repositorio y las herramientas disponibles no permiten resolver.
Esta separación importa porque no toda evidencia pesa igual. Una explicación generada puede ayudarme a navegar. Una prueba ejecutada, una restricción de base de datos o una observación del comportamiento en ejecución pueden sostener una afirmación más fuerte. Ninguna elimina la necesidad de revisar si la prueba cubre la propiedad correcta.
También devuelve una responsabilidad al autor. Quien abre el PR debería poder explicar intención, decisiones, límites, radio de impacto y evidencia, aunque un agente haya escrito cada línea. Delegar la escritura no debería permitir delegar la comprensión al revisor.
El contrato no resuelve el problema profundo
Sería cómodo terminar aquí y convertir estas cinco preguntas en otra plantilla. Eso caería en el mismo sesgo solucionista que intento evitar.
El problema profundo es de capacidad e incentivos. Si una organización recompensa la cantidad de cambios mientras trata la revisión como una etapa que debe comprimirse, ningún prompt recuperará la atención perdida. El contrato sólo hace visible que cada PR consume un presupuesto de comprensión.
Cuando ese presupuesto se agota, la respuesta no puede ser siempre otro revisor automático. A veces debe ser:
- dividir el cambio;
- reducir trabajo en curso;
- ejecutar primero la evidencia más barata y determinista;
- reservar revisión profunda para el riesgo importante;
- rechazar cambios cuyo costo de demostración excede su valor;
- o aceptar que producir menos es la decisión técnicamente responsable.
Estudios recientes sobre revisión agéntica empiezan a reforzar esa cautela. Un análisis de 1.02 millones de PR revisados en 207 proyectos encontró decisiones más rápidas en algunos patrones con agentes, pero no una mejora consistente de calidad. Otro trabajo sobre pull requests generados por IA advierte que la actividad registrada puede estar dominada por automatización y no debe interpretarse automáticamente como supervisión humana.
Ambos son preprints recientes. No los tomo como sentencia final. Los leo como una razón para dejar de usar velocidad, número de comentarios o presencia de un reviewer como sustitutos de comprensión.
Aprobar es aceptar responsabilidad
No quiero frenar el uso de agentes. Quiero reservar su capacidad para el trabajo que hacen mejor: explorar grandes superficies, comprobar condiciones explícitas, ejecutar pruebas, relacionar cambios y hacer visibles contradicciones.
La decisión humana empieza donde termina esa evidencia.
Para mí, aprobar un PR debería significar algo más exigente que haber agotado una conversación automática:
Entiendo la intención, revisé la evidencia, conozco el radio de impacto y acepto la responsabilidad de integrar este cambio.
Ese estándar no garantiza software perfecto. Los revisores humanos también nos equivocamos. Su ventaja es otra: hace explícito quién construyó el juicio y qué lo sostuvo.
Cuando el código se vuelve abundante, revisar deja de ser una etapa administrativa del proceso. Se convierte en la capacidad que determina cuánto software puede asumir realmente una organización.
No necesitamos que un agente tenga la última palabra. Necesitamos que nos ayude a reunir la evidencia con la que una persona pueda decir la suya y responder por ella.