Banco adota tiny teams: IA escreve 90% do código, agentes assumem 20% das tarefas

A maioria das equipes já usa IA, mas principalmente como um autocompletar inteligente: o engenheiro escreve, o modelo sugere. A equipe do Budget Tool de um banco, responsável pela gestão de despesas, foi além. Ela reorganizou o próprio processo em torno de pequenos grupos nos quais cada engenheiro responde pelo resultado de ponta a ponta, enquanto um agente cuida do trabalho rotineiro. O líder técnico Dima Vdovin contou no Habr como foi a experiência. É um relato franco, com fracassos e efeitos colaterais desagradáveis.

O primeiro sprint fracassou, e isso foi útil

O ponto de partida: duas equipes multifuncionais de desenvolvimento de funcionalidades, com 14 pessoas no total, Kotlin e Spring no backend, TypeScript e React no frontend. Para o piloto, reservaram duas pessoas, um desenvolvedor backend e um profissional de QA, e dois meses. A meta era concluir cada user story de ponta a ponta, da análise à produção.

A primeira tarefa pequena não chegou à produção nas duas semanas do sprint. A equipe gastou muito tempo entendendo os requisitos, mas o frontend consumiu a maior parte do esforço. Tentaram fornecer ao agente os layouts do Figma e depois fizeram ajustes intermináveis para atender aos comentários da revisão. Só o desenvolvedor frontend e o designer tinham licenças do Figma Dev Mode e acesso ao MCP correspondente. Por isso, às vezes era mais simples mostrar ao agente uma captura da tela já pronta.

Depois, o trabalho ganhou velocidade: o ciclo ficou mais curto a cada sprint. Mas os problemas continuaram, e todos tinham a ver com contexto:

• O conhecimento está na cabeça das pessoas. Os acordos de arquitetura se acumularam ao longo dos anos, e o agente comete erros enquanto essas informações não fazem parte do seu contexto.
• A revisão atrasa as entregas. É difícil para um engenheiro de produto avaliar código de outra área, e o código é escrito mais rápido do que é revisado.
• Não está claro como apresentar o design. É preciso um canal adequado para levar o layout ao agente, em vez de uma coleção de gambiarras.

Harness como produto

Nesta experiência, harness é o conjunto de regras, habilidades (skills), MCP e contexto que ajuda o agente a trabalhar especificamente no seu projeto. A equipe não reinventou a roda: reaproveitou o que já existia no banco e no domínio de negócio.

A ideia central é um ciclo contínuo: executar uma tarefa com IA, analisar onde o agente tropeçou, complementar as habilidades e o contexto e executar novamente. Os hubs de especialidade cuidam disso: backend, frontend, QA e análise de sistemas. Eles reúnem o feedback de todas as tiny teams, identificam lacunas e compartilham as melhores soluções com as demais.

A equipe foi dividida em quatro tiny teams e um discovery hub, que reúne o product owner, o designer e o analista de negócios. As tiny teams não têm analista por decisão deliberada: isso aumenta a motivação para usar IA. As tarefas são classificadas por cor. As verdes, pequenas, ficam com agentes autônomos. As amarelas, maiores, são executadas localmente pela equipe, com ajuda de IA. As vermelhas exigem conhecimento especializado profundo e só são resolvidas com esforço conjunto.

Agentes no servidor e o custo dos ganhos

No início, tudo era feito localmente: assim era mais fácil orientar o agente por mensagens e ganhar experiência. Mas o agente local só trabalha enquanto o notebook está aberto. A equipe quer que o agente seja mais um engenheiro: basta atribuir uma tarefa no rastreador e receber um MR pronto.

Começaram pela segurança. Quando a varredura de AppSec encontra uma biblioteca ou imagem vulnerável, o próprio agente abre uma tarefa, faz as alterações e prepara um MR. Pela manhã, há várias solicitações prontas para revisão. Agora, a equipe também encaminha pequenas tarefas de negócio dessa forma, desde que esteja claro o que alterar, como e onde.

Os resultados após meio ano: o LLM escreve 90% do código, mais de 70% das tarefas de negócio foram feitas com assistência de IA e agentes no servidor resolvem mais de 20%. Mas, no início, o número de tarefas concluídas caiu, e depois surgiram efeitos colaterais:

• aumentam a carga cognitiva e o risco de burnout;
• sem conhecimento de áreas relacionadas, não é possível nem definir a tarefa nem verificar o resultado;
• a revisão precisa mudar: avaliar a arquitetura, não a sintaxe;
• a análise e o planejamento continuam com o ser humano, que precisa tomar mais decisões.

O que aproveitar dessa experiência

Os conselhos dos autores são práticos. Comece com uma tarefa repetitiva e critérios claros de conclusão. Use agentes de programação prontos, em vez de criar o seu. Primeiro ajuste o fluxo localmente e só depois leve-o para o servidor. Encapsule tudo o que for determinístico em scripts chamados pela skill. Escreva a documentação de modo que pessoas e agentes a entendam da mesma forma.

A observação sobre métricas de avaliação é especialmente valiosa: sem elas, não dá para saber se o harness melhorou ou se você está apenas mudando configurações. Por isso, vale gerenciá-lo como um produto e registrá-lo explicitamente como dívida técnica.

As limitações também importam. Essa é a experiência de uma única equipe de um banco com uma stack bem ajustada. Os números são internos e não foram verificados por ninguém, e tarefas analíticas complexas com alto custo de erro ainda não são delegadas aos agentes. Mas a conclusão é universal: a velocidade virá da capacidade da sua equipe de explicar ao agente como vocês trabalham, não de um modelo mais poderoso.