Publica PRs de agentes como DoltLite: controla pruebas, registra divergencias y deja a los humanos las excepciones

DoltLite es un caso de estudio útil para gerentes de ingeniería e ingenieros de plataforma. Es una bifurcación de SQLite que conserva los componentes estándar de SQLite por encima de la capa B-tree. Su desarrollo involucró aproximadamente 2.000 solicitudes de extracción y un equipo de agentes. Alcanzó la versión Beta 0.50.0 aproximadamente cinco meses después del lanzamiento.

La lección no es que los agentes puedan reemplazar la ingeniería de software. La lección es que los PRs de agentes pueden fusionarse cuando el repositorio tiene una puerta de fusión estricta. La puerta debe probar el comportamiento, medir el rendimiento, registrar excepciones y mantener a los humanos responsables de la arquitectura, la seguridad y la migración.

Lo que DoltLite realmente publicó

DoltLite aprueba el 100% de sqllogictest, descrito como un conjunto de 5,8M de consultas complejas. Supera el 99,46% de las 892.277 pruebas de aceptación de SQLite basadas en TCL, con 4.809 divergencias conocidas. Es un resultado sólido. También es una advertencia.

Una tasa de aprobación del 99,46% no es lo mismo que una compatibilidad del 100%. Las 4.809 divergencias son el verdadero artefacto. Definen el límite entre lo que el equipo de agentes puede publicar y lo que un humano debe asumir. Un repositorio de producción necesita el mismo límite, hecho explícito.

En un benchmark reportado, las bases de datos en memoria de DoltLite fueron un 10% más lentas en lecturas y un 60% más lentas en escrituras que SQLite. El impacto en el rendimiento no es una nota al pie. Es una condición de fusión. Si un agente modifica una ruta crítica, el PR debe mostrar el costo. Si el costo es aceptable, el registro explica por qué.

En la versión Beta, el formato de almacenamiento de DoltLite se describe como estable, y se espera que los futuros cambios rompedores cuenten con una ruta de migración soportada. Esa es una decisión en manos humanas. Los agentes pueden proponer cambios de almacenamiento. Los humanos deciden si se permite un cambio rompedor, cómo se gestiona la migración y qué ventana de soporte aplica.

La puerta de fusión para PRs de agentes

Usa una puerta de cinco partes para el código generado por agentes en repositorios de producción. La puerta debe aplicarse mediante CI, no por la buena voluntad del revisor.

1. La tarea debe ser pequeña y verificable. Divide el trabajo de agentes en PRs acotados. Un PR que toca esquema, planificación de consultas, manejo de errores e interfaz de usuario es demasiado grande. Un PR que corrige una rama del analizador, añade una prueba y actualiza una entrada del registro es fusionable.
2. Aprobar la suite de regresión o documentar la divergencia. No se debe permitir que el agente debilite la suite. Si una prueba falla, el PR debe incluir un registro de divergencia: nombre de la prueba, comportamiento esperado, comportamiento real, riesgo, responsable y estado de revisión.
3. Medir el impacto en el rendimiento. Ejecuta un conjunto fijo de benchmarks para el subsistema afectado. Reporta la latencia de lectura y escritura, el rendimiento, la memoria y la tasa de errores donde corresponda. Un PR que mejora la corrección pero degrada una ruta crítica necesita una excepción de rendimiento explícita.
4. Actualizar el registro de divergencias. El registro es un documento vivo. Enumera las diferencias conocidas con el sistema de referencia, la razón, el responsable y los criterios de salida. Las divergencias deberían reducirse con el tiempo. Si aumentan, el equipo debe detener las fusiones e investigar.
5. Un humano posee las decisiones de arquitectura, seguridad y migración. Los agentes pueden proponer cambios. Los humanos aprueban cambios que alteran el formato de datos, la autenticación, la autorización, la exposición de red, la ruta de actualización o los manuales operativos. Esto no es un cuello de botella. Es el punto de control.

Cómo ejecutar flujos de trabajo de agentes sin perder el repositorio

Comienza con una rama protegida y una política de fusión. Los PRs de agentes deberían abrirse contra una rama staging, no contra main. CI debe ejecutar la suite completa de regresión, la suite de benchmarks y una comprobación divergence-lint. La comprobación divergence-lint verifica que cada prueba fallida tenga una entrada en el registro y que cada entrada del registro tenga un responsable.

La revisión de código debería dividirse. La revisión automática comprueba el estilo, la cobertura de pruebas y las violaciones de política. La revisión humana comprueba la intención, el riesgo y la calidad de las excepciones. No pidas a un humano que lea cada línea de código generado. Pídele al humano que verifique que el PR está dentro del alcance permitido y que la evidencia es suficiente.

Mantén el alcance del agente estrecho. Para un motor de base de datos, eso podría significar correcciones del analizador, pistas del planificador de consultas o generación de pruebas. Para un servicio web, podría significar validación de API, mapeo de errores o documentación. Cuanto más estrecho sea el alcance, más fácil se vuelve la puerta. La puerta debe ser específica para el subsistema, no genérica.

Registra tres números. Primero, la tasa de aprobación de regresión. Segundo, el número de divergencias abiertas. Tercero, la diferencia de benchmark. Si la tasa de aprobación baja, detente. Si las divergencias aumentan sin una razón clara, detente. Si la diferencia de benchmark supera el umbral acordado, detente. El objetivo no es demostrar que los agentes son seguros. El objetivo es hacer el riesgo visible y reversible.

DoltLite muestra que el software construido por agentes puede publicarse cuando el sistema está acotado. La restricción no es más generación de código. La restricción es una puerta de fusión, un registro de divergencias y la responsabilidad humana de las excepciones que importan.