Cognition integra el agente Devin en la plataforma de MongoDB: migraciones entre 4 y 5 veces más rápidas

Cognition y MongoDB han conectado el agente Devin a la Application Modernization Platform (AMP), la herramienta de MongoDB para migrar aplicaciones legacy a Atlas. El producto se llama Devin for MongoDB Modernizations y ya está disponible para los clientes de ambas compañías. En las primeras pruebas conjuntas, las tareas que antes llevaban de cinco a seis horas ahora ocupan poco más de una hora, es decir, se ejecutan aproximadamente entre 4 y 5 veces más rápido. La promesa de los proveedores es ambiciosa: migrar décadas de aplicaciones acumuladas en meses, no en años.

Dónde se atascan realmente las migraciones

La formulación del anuncio es reveladora: las migraciones a MongoDB rara vez se atascan por la base de datos en sí. El problema está en el «cableado» alrededor del código antiguo: miles de consultas, procedimientos almacenados y capas de acceso a datos que durante años han ido acumulando lógica de negocio. Un script no puede desentrañar eso: hay que entender por qué una consulta concreta está escrita de una forma determinada y qué se rompe si se sustituye.

Ese es el terreno al que apunta Cognition con Devin. El agente trabaja con toda la base de código: planifica los cambios, reescribe la lógica de negocio y la data access layer, y analiza cada caso por separado. Es precisamente el tipo de trabajo que suele devorar la capacidad de los equipos de ingeniería, algo que el CEO de Cognition, Scott Wu, señala de forma explícita: incluso los equipos más ambiciosos dedican una parte considerable de sus recursos a mantener sistemas antiguos.

Cómo se reparten el trabajo Devin y AMP

La arquitectura se basa en separar responsabilidades entre un componente no determinista y otro determinista. En la migración de datos, el riesgo de alucinación es inaceptable, de modo que el traspaso y la verificación de cada registro en MongoDB corren a cargo del instrumental ya probado de AMP. El código, donde hace falta flexibilidad, se deja al agente. Devin se conecta directamente a las herramientas de AMP y orquesta el proceso de principio a fin, de modo que el cliente ve una única migración coherente y no un conjunto de scripts y traspasos manuales entre equipos.

Los parámetros clave del anuncio:

• Papel de Devin: planificación, reescritura de la lógica de negocio y de las capas de acceso a datos.
• Papel de AMP: migración determinista y validación de registros en MongoDB Atlas.
• Sigue en manos de las personas: el diseño del modelo de datos de destino y la secuencia del cutover.
• Resultado de las pruebas iniciales: de 5–6 horas a poco más de una hora por tarea.
• Disponibilidad: inmediata para los clientes de MongoDB y Cognition; ya se ha publicado la documentación para conectar Devin a MongoDB.

El límite a partir del cual las decisiones quedan en manos humanas está bien elegido. El modelo de datos de una base documental es una decisión de arquitectura con consecuencias durante años, y el orden de la conmutación, que depende de los riesgos de negocio, no conviene delegarlo en un agente.

Qué se sabe de los resultados y qué no

La única métrica publicada es la de «las primeras pruebas conjuntas». La metodología no se ha revelado: se desconoce qué se contó como tarea, en qué bases de código se midió y cómo se contabilizó el tiempo de revisión humana. El material apareció en el blog de Windsurf, que está vinculado a Cognition, por lo que se trata de una autodescripción del proveedor y no de una evaluación independiente.

Una voz más concreta en el anuncio es la de Bilt. Su director técnico, Kosta Krauth, cuenta que la compañía escribe la mayor parte de su software con Devin y despliega en producción a diario. La búsqueda por barrios en bilt.com, lo primero que ve el usuario, funciona sobre MongoDB; con Devin, Bilt traslada el resto de sus cargas de búsqueda a la misma base en plazos imposibles con trabajo manual. Es un cliente y un escenario, pero muestra cómo se aplica la combinación en un producto real.

MongoDB tiene su propio motivo. Su CEO, Dev Ittycheria, lo formula así: el valor está en modernizar a la vez la mayor parte posible del parque de aplicaciones de una empresa, y no de una en una. Al mismo tiempo, la compañía vende la tesis de una data foundation moderna para aplicaciones de IA y agentes que trabajan con datos operativos en vivo. La migración es aquí el embudo hacia Atlas.

Cómo aplicarlo en la práctica

Si tiene aplicaciones legacy sobre bases relacionales y una migración a MongoDB pendiente en el backlog, tiene sentido solicitar un piloto con un servicio no crítico. Mida no solo la velocidad de generación de código, sino el tiempo total hasta producción, incluidas la revisión y la validación de datos.

Fije de antemano el modelo de datos de destino y el plan de cutover: son las decisiones que siguen en su lado y las que determinan cuánto acelerará el trabajo el agente. Y compruebe cómo valida AMP los registros: de lo completa que sea esa verificación depende la confianza en el resultado más que de cualquiera de las cifras del anuncio.