Convierte 2.000 PR de agentes en un fork publicable con 5 compuertas

DoltLite alcanzó la versión Beta 0.50.0 cinco meses después de su lanzamiento. El operador debe limitar el volumen de revisiones y aplicar compuertas. El desarrollo impulsado por agentes puede generar mucho código. También puede generar mucho ruido. La diferencia está en el control. Un fork grande puede avanzar rápido cuando la ruta de fusión es estrecha. El trabajo del operador es hacer que esa ruta estrecha sea aplicable.

Un fork hereda una superficie conocida. Los agentes pueden trabajar contra un objetivo estricto. El objetivo no es un mejor código. El objetivo es mantener la compatibilidad con el sistema subyacente, con excepciones.

Por qué el volumen no es el modo de fallo

Un alto volumen de PR no es el problema. La divergencia no registrada es el problema. Un agente puede abrir un parche limpio. También puede abrir un parche que cambia el comportamiento de una manera que ningún humano notará. La compuerta de revisión debe detectar el segundo tipo antes de que se convierta en la norma.

La señal más fuerte en el proyecto es la superficie de pruebas. DoltLite supera todas las 5,8 M de consultas de sqllogictest. Eso indica que la ruta principal de consultas sigue funcionando. La segunda señal es que las brechas restantes están contadas, visibles y asignadas.

Las cinco compuertas

Usa las compuertas como una política de fusión, no como una lista de verificación que se ejecuta una vez. Cada compuerta debe bloquear el trabajo hasta que se cumpla la condición. El objetivo es hacer que los PR de agentes sean seguros de revisar a escala.

1. Limita los PR. Limita los PR de agentes que entran en revisión por ciclo. Basa el límite en la capacidad de revisión humana. Detén la generación si la cola crece. Corrige primero el pipeline.
2. Ejecuta la suite de compatibilidad. Exige una suite de pruebas estricta contra el sistema base. Debe ejecutarse en cada PR y detectar regresiones en las rutas comunes. Una suite aprobada es la condición mínima para la revisión.
3. Actualiza el registro de divergencias. Registra cada diferencia conocida con el sistema base. Cada entrada necesita un responsable, un motivo y un estado. El registro hace visibles las excepciones y da a los revisores un mapa de las diferencias permitidas.
4. Dispara la revisión humana. Define los cambios que requieren revisión humana antes de la fusión. Incluye cambios de almacenamiento, cambios de API pública, comportamiento de errores, rutas sensibles al rendimiento y nuevas divergencias. Los agentes pueden preparar la revisión. Los humanos deciden si el riesgo es aceptable.
5. Exige una ruta de migración. Si el fork cambia un formato, un protocolo o un contrato público, exige un plan de migración antes de que el cambio se incorpore. El plan debe explicar cómo avanzan los usuarios existentes.

El formato de almacenamiento es estable para Beta, con una ruta de migración soportada para futuros cambios que rompan la compatibilidad. Les dice a los usuarios que el fork no es un objetivo en movimiento. También les dice al equipo que los cambios futuros necesitan un plan antes de producirse.

Cómo aplicar las compuertas en la práctica

Empieza por la ruta de fusión. Haz que las compuertas formen parte de las reglas de protección de ramas. Un PR no debe poder fusionarse hasta que pasen las comprobaciones requeridas. Las comprobaciones deben incluir la suite de compatibilidad, la actualización del registro de divergencias y el disparador de revisión humana. Si un cambio es pequeño, las compuertas deben aplicarse igualmente. Los cambios pequeños son donde empieza la deriva silenciosa.

Mantén el registro de divergencias visible. Pónlo en el repositorio, no en un documento aparte. Los revisores deben poder ver las excepciones actuales mientras leen un parche. Si un PR añade una nueva divergencia, la entrada del registro debe formar parte del mismo cambio. Eso hace explícita la excepción. También hace la revisión más rápida, porque el revisor no está buscando cambios ocultos de comportamiento.

Usa el límite de volumen de PR como señal de retroalimentación. Si los agentes están produciendo más PR de los que el equipo puede revisar, el sistema ya está roto. La solución no es revisar más rápido. La solución es reducir el número de cambios que necesitan revisión. Consolida los parches pequeños. Rechaza el trabajo especulativo. Exige una declaración clara del problema antes de que un agente abra un PR. El límite protege el proceso de revisión de convertirse en un cuello de botella.

Convierte la revisión de código en una decisión, no en una formalidad. El revisor debe responder tres preguntas: ¿El cambio preserva el comportamiento esperado? Si no, ¿la divergencia está documentada? Si el cambio toca una superficie protegida, ¿la ruta de migración está completa? Si la respuesta a alguna pregunta es no, el PR se detiene. Ese es el punto clave de la compuerta.

Qué hacer a continuación

Si estás publicando o evaluando código abierto construido por agentes, empieza por la suite de compatibilidad. Sin una suite estricta, las otras compuertas son débiles. La suite es el lenguaje compartido entre agentes y humanos. Le dice al equipo qué significa «funciona» antes de que alguien discuta sobre un parche.

Luego construye el registro de divergencias. Es la forma menos costosa de hacer que un fork sea auditable. Un registro no previene la divergencia. Hace la divergencia visible. También te da una base para decidir qué diferencias son aceptables y cuáles necesitan cerrarse.

Por último, establece el disparador de revisión humana pronto. No esperes a que la base de código sea grande. Define ahora las superficies protegidas. El formato de almacenamiento, la API pública, el manejo de errores y las rutas críticas de rendimiento son buenos puntos de partida. El disparador debe ser lo suficientemente simple para que los agentes puedan clasificar su propio trabajo. También debe ser lo suficientemente estricto para que los cambios de riesgo no pasen desapercibidos.

El ejemplo muestra que el desarrollo impulsado por agentes puede producir un resultado publicable cuando las restricciones son explícitas. El trabajo del operador no es confiar en los agentes. El trabajo del operador es construir una ruta donde los agentes solo pueden avanzar cuando el sistema dice que es seguro.