Problema
Un agente entrega una modificación extensa que mezcla una función nueva, ajustes de estilo, dependencias y correcciones descubiertas por el camino. Todo parece razonable, pero el revisor no puede distinguir qué parte resuelve la petición y qué parte amplía el riesgo.
La producción acelerada desplaza el cuello de botella hacia la comprensión. Tener más código disponible no ayuda si aceptar un cambio exige reconstruir toda la exploración que lo produjo.
Tesis
Define la unidad de cambio por una hipótesis verificable. Cada entrega debe explicar el comportamiento anterior, el resultado esperado y la evidencia que permite aceptarla. La propuesta editorial es reducir el coste de revisión, no imponer un tamaño arbitrario de diff.
Git permite trabajar con varios árboles del mismo repositorio. Anthropic describe artefactos y progreso incremental para agentes de larga duración. Ambas ideas resultan útiles si el trabajo se divide en entregas que pueden comprobarse por separado.
Framework
Recorta por comportamiento
Una modificación coherente cambia una decisión del sistema: cómo se valida un dato, qué ocurre ante un error o qué puede hacer un usuario. Puede afectar a varios archivos sin dejar de ser una unidad. Lo que la vuelve difícil de revisar es mezclar motivos independientes.
Antes de delegar, identifica lo necesario y lo incidental. Si el agente descubre una mejora ajena al objetivo, puede registrarla con evidencia y continuar. Incorporarla automáticamente vuelve menos clara la prueba de aceptación.
Deja una explicación que sobreviva al chat
El commit y la descripción de revisión deben incluir el problema concreto y el efecto del cambio. «Mejoras varias» obliga al revisor a interpretar intención desde el código. Una descripción útil permite elegir qué casos mirar y qué riesgo queda pendiente.
Conserva la relación entre la versión probada y la versión entregada. Si otro cambio se añade después de las pruebas, determina qué validación sigue siendo aplicable. Un resultado anterior no certifica modificaciones posteriores.
Diseña una reversión comprensible
Pregunta qué se tendría que retirar si el comportamiento falla. Si la respuesta exige separar cambios entremezclados, la unidad probablemente está mal delimitada. Las migraciones y los efectos externos pueden requerir compensación; un revert del código no los deshace por sí solo.
Dividir una corrección sin romper su contrato
Supuesto: el formulario admite un dato inválido porque cliente y servidor usan validaciones distintas. El cambio completo puede requerir la validación compartida, sus consumidores y una prueba de regresión. Separar cada archivo en una entrega distinta dejaría versiones intermedias incoherentes.
| Parte del trabajo descubierto | Relación con el defecto | Tratamiento |
|---|---|---|
| Regla compartida y llamadas de cliente y servidor | Necesarias para corregir el comportamiento | Misma entrega |
| Prueba que reproduce la entrada inválida | Demuestra la corrección | Misma entrega |
| Cambio general de formato | No explica el comportamiento | Fuera del cambio |
| Renovación de dependencias sin relación causal | Introduce otro riesgo | Revisión independiente |
Una descripción suficiente para revisión podría decir: «La entrada vacía se aceptaba al llamar al servidor directamente. Ahora cliente y servidor aplican la misma regla. La prueba reproduce la llamada directa y comprueba que una entrada válida sigue aceptándose». El texto explica el motivo de cada pieza sin obligar a leer el chat del agente.
Antes de integrar, aplica la prueba de regresión sobre la versión anterior: debe detectar el defecto. Después ejecútala sobre la revisión entregada. Conserva ambos resultados vinculados a sus commits. Si el agente ha relajado la expectativa para conseguir verde, la prueba ya no sirve como evidencia del arreglo.
La reversión se evalúa sobre el efecto real. En este ejemplo puede bastar con retirar código; si el cambio migrase datos, habría que diseñar recuperación o compensación adicional. Una unidad pequeña no es automáticamente reversible y una entrega de varios archivos no es automáticamente excesiva.
Por qué importa ahora
La concurrencia de agentes facilita abrir más frentes de los que un equipo puede integrar. Reducir la unidad de cambio permite priorizar, revisar y detener trabajo sin bloquear toda la entrega. La capacidad útil es la que llega a una versión aceptada.
Anti-ejemplo
Caso hipotético: una corrección del formulario incluye una actualización general de dependencias. En producción aparece una regresión visual. El equipo no sabe qué retirar sin perder también el arreglo urgente y termina rehaciendo la integración bajo presión.
Protocolo (3 pasos)
| Paso | Entregable | Criterio |
|---|---|---|
| Acotar | Comportamiento que cambia y exclusiones | Una razón principal para aceptar |
| Explicar | Diferencia observable y prueba | Revisión sin leer el historial del agente |
| Integrar | Versión comprobada y recuperación | El cambio puede localizarse y retirarse |
Relacionado
- Factory 2.0: el ingeniero ya no escala solo código, escala fábricas de software
- JetBrains Central: el control plane para equipos que ya usan varios agentes de coding
Fuentes consultadas
Próximo paso
Abre una entrega reciente y escribe su motivo en una frase concreta. Si necesitas unir problemas independientes con «y además», considera separarlos antes de pedir revisión.