Cómo gobernar PR de agentes y mantener la confianza en el código abierto

Una beta rápida es una prueba de gobernanza

Leo la cola como el número que importa, no la versión. DoltLite llegó a Beta en la versión 0.50.0 cinco meses después del lanzamiento. Ese es un dato: que DoltLite llegue a Beta muestra que un equipo de agentes pudo realizar el trabajo

DoltLite se construye como un fork de SQLite, con la capa B-tree reemplazada por un Prolly Tree respaldado por un almacén de fragmentos de un solo archivo. Esa decisión de arquitectura importa porque está pensada para que la decisión de fusión sea aburrida.

El umbral de gobernanza de PR de agentes

Uso un umbral de cuatro puertas. Un pull request de un agente no es un borrador hasta que supera las cuatro. Si falla una, va a una cola de cuarentena, no a la bandeja de entrada de un revisor humano como una tarea normal.

Puerta uno: clasificación del radio de impacto

Etiqueto cada PR de agente antes de revisarlo. La etiqueta debe responder a una pregunta: si este cambio está mal, ¿qué se rompe? El almacenamiento central, la ejecución de consultas, la API pública, la configuración, las pruebas y la documentación no son el mismo riesgo. Un parche que toca el formato de almacenamiento merece más evidencia que un parche que reescribe un comentario. En un fork de un motor de confianza, el radio de impacto no es solo tu repositorio; es cada usuario aguas abajo que asume que el formato de archivo se comporta como algo en lo que ya confía.

Puerta dos: evidencia de corrección

No acepto que el agente diga que funciona. Exijo evidencia que corresponda al riesgo. Para un motor de consultas, eso puede significar una prueba de regresión dirigida, una prueba basada en propiedades, una diferencia contra el comportamiento esperado o una parte de la suite de pruebas existente. Para un PR de agente de alto riesgo, exijo el tipo de evidencia de corrección que puede mostrar que un motor de consultas sigue funcionando; DoltLite supera una suite de pruebas de consultas complejas.

Puerta tres: salvaguardas de rendimiento

El trabajo de agentes puede comprimir el tiempo de compilación, pero también puede desplegar una ruta lenta que nadie nota hasta producción. Un informe de rendimiento nocturno mostró que las bases de datos de DoltLite en memoria eran más lentas que SQLite tanto en lecturas como en escrituras. El punto es que la regresión era visible. No llamaría completo un umbral de revisión sin un informe de rendimiento que se ejecute automáticamente. Define un umbral para latencia, ancho de banda, memoria o tiempo de inicio, e incluye el informe en la decisión de fusión. Un parche que supera las pruebas pero empeora mediblemente la ruta crítica no debería fusionarse sin una nota explícita de compensación.

Puerta cuatro: revisión de mantenibilidad

Los agentes pueden producir código que funciona hoy y confunde al siguiente humano mañana. La puerta de mantenibilidad debe revisar nombres, estructura, comentarios, código muerto, configuración oculta y propiedad. Un cambio que es correcto pero no explicado es un incidente futuro. En el código abierto, la mantenibilidad también es confianza. Los contribuyentes y usuarios necesitan ver que la base de código sigue siendo legible, no solo verde.

Mantén visible la confianza en el código abierto

La confianza en el código abierto no es una afirmación de marketing. Es un conjunto de hábitos observables. En Beta, el formato de almacenamiento de DoltLite se describe como estable después de 12 cambios previos de formato. Si estás construyendo con agentes, publica el mismo tipo de señal. Indica qué áreas son estables, cuáles son experimentales y qué evidencia se requiere antes de que un cambio se incorpore.

Haz visible la gobernanza en el repositorio. Un breve manual de ingeniería en la documentación puede listar las puertas, el proceso de cuarentena y los umbrales de rendimiento. Cuando un revisor humano pregunta por qué se fusionó un parche de agente, la respuesta debe ser una lista de verificación, no una intuición. Cuando un usuario pregunta por qué un cambio rompió su flujo de trabajo, la respuesta debe ser una entrada del changelog, un problema vinculado y una prueba que demuestre la corrección.

La cola de cuarentena es la parte que la mayoría de los equipos omiten. Debería ser un lugar de primera clase: una etiqueta, un tablero o una carpeta de parches que fallaron una o más puertas. Cada PR en cuarentena necesita un responsable, una razón y una fecha límite. Algunos se corregirán. Otros se descartarán. El punto es mantener limpia la cola de fusiones sin fingir que el trabajo generado es todo seguro o todo inútil.

El trabajo de agentes cambia la economía del desarrollo. Puede comprimir el tiempo de la idea a la beta, pero también aumenta el costo de una mala fusión. El trabajo del fundador es convertir ese costo en un umbral: clasificar el radio de impacto, exigir evidencia de corrección, proteger el rendimiento y revisar la mantenibilidad. Las señales concretas de DoltLite respaldan la afirmación de confianza: su formato de almacenamiento se describe como estable después de 12 cambios previos de formato, y el informe de rendimiento nocturno mostró que las bases de datos de DoltLite en memoria eran más lentas que SQLite tanto en lecturas como en escrituras. Si un parche pasa, fúsionalo. Si no, ponlo en cuarentena. Así se mantiene la velocidad sin gastar la confianza que el código abierto tarda mucho en construir.