Liderança na era dos Agentes, Parte 1: A Pergunta Que Ninguém Estava Fazendo
No começo de 2026, os melhores engenheiros da KYP estavam fechando 8 pull requests por dia.
Não por semana. Por dia.
As melhores organizações de engenharia do mundo chegam a uma média de um PR por engenheiro por dia. Nossos melhores profissionais estavam a 8 vezes acima disso. Sem horas extras. Com mais clareza do que antes.
Quando precisamos explicar como isso era possível, percebemos que a resposta incomodava. Não era sobre ferramenta. Era sobre uma pergunta diferente — uma que a maioria das organizações ainda evita fazer.
A Conversa Errada
Existe uma cena que se repete em quase toda empresa de tecnologia hoje. Já ouvimos dezenas de vezes — em reuniões de liderança, em eventos de inovação, em alinhamentos de produto.
A pergunta é sempre a mesma: “Qual ferramenta de IA os engenheiros estão usando?”
Copilot ou Cursor? Fine-tuning no codebase interno? Deployment privado por compliance? São questões legítimas. São também o equivalente a, em 2010, perguntar qual smartphone a empresa vai adotar — e achar que isso resolvia a transformação digital.
A pergunta que ninguém estava fazendo — e que nos forçamos a responder — era esta: se agentes de IA já conseguem fazer uma parcela significativa do trabalho, o que exatamente justifica a existência de uma organização de tecnologia do jeito que a conhecemos?
Não é uma pergunta confortável. É exatamente por isso que ela importa.
Em abril de 2026, as maiores plataformas de tecnologia do mundo começaram a responder essa pergunta publicamente. Quando isso acontece, a janela de diferenciação não está na ferramenta — está em quanto antes você internalizou o modelo operacional que torna a ferramenta útil. Ferramentas convergem. Modelos operacionais, não.
O Que Muda Quando o Agente Entra
Quando começamos a rodar agentes de IA de verdade — agentes autônomos de código, pipelines de dados com IA, LLMs integrados em fluxos operacionais — descobrimos algo que não estava nos benchmarks de nenhum modelo.
O gargalo não era a capacidade do agente. Era o que estava ao redor dele.
Responsabilidade pouco clara. Contexto não documentado. Critérios de sucesso indefinidos. Sem plano de rollback.
Aqui está o que muda tudo: um humano num ambiente desorganizado pergunta, infere, negocia. Ele identifica a ambiguidade e sinaliza. Cobre a lacuna com julgamento. Às vezes mal, mas cobre.
Um agente não faz isso. Ele alucina.
E alucinação confiante é diferente de erro declarado. Ela viaja. Passa pela revisão de código, atravessa o pipeline, chega ao cliente — e só se revela quando o custo já foi pago por alguém que não tomou a decisão de deixar o contexto desorganizado.
Os agentes estavam prontos. A organização, não.
A Decisão
Poderíamos ter adotado as ferramentas, monitorado métricas de adoção e chamado de transformação. Poderíamos ter centralizado tudo isso num time dedicado e isolado do resto da engenharia.
Não fizemos isso.
A KYP opera dentro de um ecossistema mais amplo: a CERC tem um Centro de Excelência em IA com o qual trocamos informações e boas práticas regularmente. Mas construir o modelo operacional da KYP exigiu soluções próprias — adaptadas às especificidades do negócio de dados e das tecnologias que usamos aqui. O que funciona para outros contextos nem sempre serve quando você está lidando com pipelines de ingestão em escala, modelos analíticos em produção e infraestrutura crítica de mercado financeiro.
A decisão central foi diferente: dedicar pessoas seniores para essa agenda.
Não como um time separado. Como uma responsabilidade distribuída. Os engenheiros mais experientes da KYP pararam de tratar a adoção de agentes como uma tarefa paralela e passaram a tratá-la como parte central do trabalho de engenharia. Isso teve um custo real — essas pessoas saíram de projetos imediatos para investir em algo cujo retorno não era óbvio no trimestre.
Isso significou revisar toda a nossa estrutura de desenvolvimento.
Sprints, ritmo de entrega, critérios de definição de pronto, processos de revisão de código — tudo foi reexaminado com uma pergunta diferente: esse processo foi desenhado para um mundo em que apenas humanos escrevem código? Na maioria dos casos, a resposta era sim. E um processo desenhado só para humanos não acomoda bem um agente.
O processo está embarcado junto a todos os times.
Não existe um grupo de especialistas que “faz IA” enquanto o restante faz engenharia normal. Cada squad tem a agenda de automação como parte do backlog regular. A pergunta que fazemos sistematicamente em qualquer refinamento é: isso é repetitivo? Se é, é uma oportunidade de automação.
Toda atividade repetitiva é tratada como débito de automação. Geração de testes, documentação de APIs, revisão de conformidade de código, alertas de observabilidade, onboarding de novos serviços — nenhum desses é visto mais como trabalho inevitável. São candidatos a serem feitos por agentes, com engenheiros definindo os critérios e validando os resultados.
A pergunta certa não é como usar IA. É que tipo de organização você precisa ser para trabalhar com ela — e quem, dentro dessa organização, vai carregar o peso da transição quando a resposta demorar a chegar.
O que descrevemos aqui não é um projeto concluído. É um modelo em construção, testado sob pressão real. Nos próximos artigos desta série, vamos detalhar como esse modelo se traduz em decisões concretas de arquitetura, processo e liderança.
A KYP é a unidade de negócios de dados da CERC, que opera a infraestrutura do mercado financeiro brasileiro para registro de recebíveis — um sistema onde as consequências de errar se medem na estabilidade do sistema financeiro, não apenas na velocidade do sprint.
Esta série foi escrita por Sandor Caetano, Lucio Passos, e Juliano Pereira — líderes de tecnologia na KYP construindo a infraestrutura organizacional para engenharia nativa em IA.