Cómo auditar el código generado por agentes de IA antes de adoptarlo: la prueba de DoltLite

Estás decidiendo si adoptar un componente que un agente escribió, y las notas de versión están llenas de recuentos de pull requests. El recuento no es la evidencia. DoltLite es una base de datos basada en SQLite con control de versiones estilo Git, y su desarrollo involucró aproximadamente 2,000 pull requests generados por agentes de IA. Alcanzó el estado beta en la versión 0.50.0 cinco meses después de su lanzamiento. Un comentarista de Hacker News objetó que el estado beta fue una decisión humana y no demostraba la calidad del código sin revisar. Esa objeción es el punto de partida correcto: el volumen puede ocultar deuda de revisión, por lo que la auditoría debe separar la producción de la evidencia.

El volumen de PRs necesita un rastro documental

El blog de DoltHub publicó una entrada del 22 de junio de 2026 que decía que DoltLite había superado las 1,000 pull requests en 100 días. El artículo de DoltLite fue citado en Hacker News diciendo que se involucraron aproximadamente 2,000 pull requests y que la primera PR se fusionó el 17 de marzo. La página de inicio de DoltHub listaba DoltLite como un producto SQLite con control de versiones y estado Beta. Esos detalles describen la historia del lanzamiento, no la historia de la revisión. Un líder técnico necesita ver cómo se separaron las PRs de agentes de las PRs humanas y qué notas de revisión sobrevivieron.

La auditoría comienza donde el fork se diverge

DoltLite es un fork de SQLite en el que el analizador SQL, el analizador, la capa de interacción con el sistema de archivos y el arnés de pruebas permanecen sin cambios respecto al SQLite upstream. Eso importa porque la superficie modificada es donde las PRs de agentes pueden introducir riesgo. Si el arnés de pruebas upstream sigue en su lugar, puedes comparar el comportamiento contra una línea base conocida en lugar de confiar en una suite nueva. Una entrada del blog de DoltHub del 8 de junio de 2026 dijo que DoltLite usa un Prolly tree en lugar de la interfaz B-tree de SQLite y que compara ambos en sysbench. La suite de pruebas de 5.7M de consultas de SQLite3 fue descrita en Hacker News como un oráculo para DoltLite, con la suite de pruebas de Dolt adaptada para funciones de control de versiones.

Cinco verificaciones convierten el volumen de PRs en evidencia

Realiza estas cinco verificaciones antes de adoptar o mantener una base de código con alta participación de agentes.

• Revisión del historial de PRs: abre la lista de PRs fusionadas y confirma que las PRs de agentes están etiquetadas, separadas o vinculadas a notas de revisión, porque la velocidad sin etiquetas oculta deuda de revisión.
• Delta upstream: compara el árbol de nivel superior contra el lanzamiento upstream y anota qué capas cambiaron, porque un fork puede parecer seguro mientras la ruta de datos cambia.
• Divergencia de pruebas: abre el último informe de pruebas upstream y registra la tasa de éxito, los fallos y las excepciones conocidas, porque una tasa de éxito solo es tan buena como la suite que la respalda.
• Cambios de formato de almacenamiento: lista los cambios de formato desde el último lanzamiento estable y anota cuánto tiempo ha estado estable el formato actual, porque un formato nuevo puede pasar las pruebas y aun así romper migraciones.
• Rendimiento de referencia: abre el último informe de benchmark y registra los deltas de lectura/escritura respecto a upstream, porque las cargas de trabajo intensivas en lectura y las intensivas en escritura pueden moverse en direcciones opuestas.

Los artefactos son los mismos en cualquier fork, biblioteca o servicio interno: un flujo de PRs, un diff contra upstream, un informe de pruebas, un historial de formatos y un benchmark. Si falta un artefacto, el artefacto faltante es el hallazgo.

DoltLite pasa el 100% de la suite sqllogictest, que contiene 5.8 millones de consultas complejas. También pasa el 99.46% de las 892,277 pruebas de aceptación basadas en TCL de SQLite, con 4,809 divergencias conocidas. Esos números son útiles, pero solo significan algo si sabes qué suite es upstream y qué excepciones están documentadas.

Se necesitaron 12 cambios de formato de almacenamiento para alcanzar el beta, y el formato actual se había usado durante 57 lanzamientos, o más de tres meses calendario. Esa estabilidad importa antes de confiar un fork con datos locales.

En un informe de benchmark nocturno estilo sysbench, las bases de datos DoltLite en memoria eran un 10% más lentas en lecturas y un 60% más lentas en escrituras que SQLite. Un comentarista de Hacker News afirmó que DoltLite era de 1.2x a 4x más lento que SQLite y que sus pruebas y validación serían diferentes a las de SQLite. La auditoría debe comparar el informe de benchmark con la afirmación externa y luego ejecutar la carga de trabajo que coincida con tu caso de uso.

Si el proyecto no puede nombrar la suite upstream, el historial de formatos o el benchmark, haz que eso sea el primer punto en la revisión de adopción.