Cognition integra o agente Devin à plataforma da MongoDB: migrações de 4 a 5 vezes mais rápidas

Cognition e MongoDB conectaram o agente Devin à Application Modernization Platform (AMP), ferramenta da MongoDB para migrar aplicações legadas para o Atlas. O produto se chama Devin for MongoDB Modernizations e já está disponível para clientes das duas empresas. Em testes conjuntos iniciais, tarefas que levavam de cinco a seis horas agora levam pouco mais de uma hora, ou seja, são executadas cerca de 4 a 5 vezes mais rápido. A promessa dos fornecedores é ambiciosa: migrar décadas de aplicações acumuladas em meses, e não em anos.

Onde as migrações realmente emperram

O texto do anúncio é revelador: migrações para o MongoDB raramente travam por causa do banco em si. O problema está na "fiação" em torno do código antigo — milhares de consultas, stored procedures e camadas de acesso a dados que, ao longo dos anos, foram acumulando lógica de negócio. Um script não dá conta disso: é preciso entender por que determinada consulta foi escrita de certa forma e o que quebra se ela for substituída.

É esse o território que a Cognition mira com o Devin. O agente trabalha com a base de código inteira: planeja as mudanças e reescreve a lógica de negócio e a data access layer, analisando cada caso separadamente. É justamente esse tipo de trabalho que costuma consumir a capacidade das equipes de engenharia, como diz o próprio CEO da Cognition, Scott Wu: mesmo as equipes mais ambiciosas gastam uma parcela significativa de seus recursos mantendo sistemas antigos.

Como Devin e AMP dividem o trabalho

A arquitetura se baseia na separação de responsabilidades entre um componente não determinístico e outro determinístico. Na migração de dados, o risco de alucinação é inaceitável; por isso, a transferência e a verificação de cada registro no MongoDB ficam a cargo das ferramentas já consolidadas do AMP. O código, onde é necessária flexibilidade, fica com o agente. O Devin se conecta diretamente às ferramentas do AMP e orquestra o processo do início ao fim, de modo que o cliente vê uma única migração coesa, e não um conjunto de scripts e repasses manuais entre equipes.

Principais parâmetros do anúncio:

• Papel do Devin: planejamento, reescrita da lógica de negócio e das camadas de acesso a dados.
• Papel do AMP: migração determinística e validação dos registros no MongoDB Atlas.
• Continua com as pessoas: o projeto do modelo de dados de destino e a sequência do cutover.
• Resultado dos testes iniciais: de 5–6 horas para pouco mais de uma hora por tarefa.
• Disponibilidade: imediata para clientes da MongoDB e da Cognition; a documentação sobre como conectar o Devin ao MongoDB já foi publicada.

A fronteira em que as decisões ficam com o humano foi bem escolhida. O modelo de dados de um banco de documentos é uma decisão de arquitetura com consequências por anos, e a ordem da virada, que depende dos riscos de negócio, não deve ser delegada a um agente.

O que se sabe sobre os resultados e o que não se sabe

A única métrica divulgada é a de "testes conjuntos iniciais". A metodologia não foi revelada: não se sabe o que foi contado como tarefa, em quais bases de código as medições foram feitas nem como foi considerado o tempo de revisão humana. O material saiu no blog da Windsurf, que é ligada à Cognition; portanto, trata-se de uma autodescrição do fornecedor, e não de uma avaliação independente.

A voz mais concreta no anúncio é a da Bilt. O CTO Kosta Kraut conta que a empresa escreve a maior parte do software com o Devin e faz deploy em produção diariamente. A busca por bairros no bilt.com, a primeira coisa que o usuário vê, roda no MongoDB; com o Devin, a Bilt migra as demais cargas de busca para o mesmo banco em prazos impossíveis com trabalho manual. É um único cliente e um único cenário, mas mostra como a combinação é aplicada em um produto real.

A MongoDB tem um motivo próprio. O CEO Dev Ittycheria o formula assim: o valor está em modernizar, ao mesmo tempo, a maior parte possível do parque de aplicações de uma empresa, e não uma por vez. Paralelamente, a companhia defende a tese de uma data foundation moderna para aplicações de IA e agentes que operam sobre dados operacionais em tempo real. Aqui, a migração funciona como um funil para o Atlas.

Como aplicar na prática

Se você tem aplicações legadas em bancos relacionais e a migração para o MongoDB está parada no backlog, vale pedir um piloto em um serviço não crítico. Meça não apenas a velocidade de geração de código, mas o tempo total até a produção, incluindo revisão e validação dos dados.

Defina antecipadamente o modelo de dados de destino e o plano de cutover: são essas as decisões que ficam do seu lado e determinam o quanto o agente vai acelerar o trabalho. E verifique como o AMP valida os registros: a confiança no resultado depende mais da completude dessa verificação do que de quaisquer números do anúncio.