O Comitê de IA da Bamse é um grupo que cruza times e existe por um motivo simples: a gente queria parar de adivinhar e começar a medir o que de fato muda quando você coloca agentes de código dentro de um fluxo real de engenharia. Não num demo, não numa branch de brincadeira - dentro de produto que tem cliente, prazo e gente revisando PR. Esse texto é um retrato cru do que aprendemos nos primeiros meses. Algumas coisas confirmaram o óbvio. Outras nos pegaram de surpresa. E tem bastante coisa que ainda está em aberto.
Vou ser honesto sobre o que não funcionou também, porque não adianta escrever mais um texto de hype. A gente errou bastante no caminho, e os erros ensinaram mais do que os acertos.
O que ficou óbvio
A primeira lição foi quase decepcionante de tão simples: o harness e o contexto importam mais do que a escolha do modelo. A gente entrou achando que cada release de modelo novo ia ser um salto. Não foi. O que move o ponteiro é o que você coloca em volta do modelo - as regras do projeto, as ferramentas disponíveis, os checkpoints, o contexto certo na hora certa. Trocar de modelo dá um ganho marginal. Arrumar o harness dá um ganho estrutural. Boa parte do que escrevi depois sobre context engineering e harness engineering saiu direto dessas reuniões.
A segunda lição: agentes são excelentes em tarefas bem escopadas e verificáveis, e perigosos em tarefas ambíguas. Quando o estado inicial é claro, o estado final é claro, e existe um jeito mecânico de checar se deu certo - migração, refactor repetitivo, cobertura de teste, glue code - o agente voa. Quando a tarefa exige decisão de arquitetura, ou o spec do produto ainda está mudando, o agente produz um PR confiante e errado, e você gasta mais tempo desfazendo do que teria gasto fazendo à mão. A régua mental que adotamos: se eu não consigo descrever como verificar o resultado, ainda não é tarefa de agente.
"Se eu não consigo descrever como verificar o resultado, ainda não é tarefa de agente."
A terceira foi a mais contraintuitiva pra quem não estava na trincheira: disciplina de review e guardrails importam MAIS com agentes, não menos. O agente aumenta o volume de mudança que entra na fila. Se a barra de review continua a mesma, o gargalo só muda de lugar - sai do código e vai pro humano que precisa ler tudo. A gente sentiu isso na pele: PR gerado por agente esperando muito mais tempo por review do que PR escrito à mão. A resposta não foi confiar mais, foi blindar mais: teste como porteiro, hooks que rodam sozinhos, checkpoint humano nos pontos de risco, PRs pequenos em vez de diffs gigantes.
O que nos surpreendeu
A surpresa boa foi de onde veio o valor. A gente apostava em upgrade de modelo. O que rendeu de verdade foi coisa que parece chata: skills bem escritas, hooks que automatizam o tédio, e contexto curado. Uma skill que codifica "como a gente faz X nesse repositório" rende toda vez que alguém - ou algum agente - precisa fazer X. Um hook que roda lint e teste depois de cada edição vale mais do que dez parágrafos de prompt pedindo "por favor não quebre nada". O ganho não veio do modelo ficar mais esperto. Veio da gente ficar mais organizada.
A surpresa ruim foi que adoção é um problema de gente e de processo tanto quanto de tecnologia. Não basta distribuir licença. Tem a questão de confiança - desenvolvedor sênior que não confia no agente acaba refazendo tudo à mão e o ganho vira zero. Tem o onboarding - quem nunca usou agente não sabe escopar tarefa pra ele, e a frustração inicial é alta. E tem a pergunta chata de quem é dono do quê: quem mantém os prompts, quem escreve as skills, quem revisa o contexto quando ele desatualiza. Sem alguém com esse chapéu, o ferramental apodrece rápido.
O tempo que você economiza no boilerplate volta como tempo gasto no review. O saldo só fica positivo se você investir nos guardrails antes, não depois.
O que ainda está aberto
Tem três perguntas que a gente ainda não conseguiu fechar. A primeira é medir produtividade de verdade. "Time-to-PR" caiu, sim, mas PR aberto não é valor entregue. Se o PR fica mais tempo na fila de review, ou volta pra refazer, o ganho de ponta a ponta some. Ainda não temos uma métrica que a gente confie o suficiente pra colocar num slide sem rir.
A segunda é segurança e permissão. Agente que escreve código também é agente que roda comando, lê segredo, abre arquivo. Quanto mais autonomia, mais a gente precisa de limite explícito - o que ele pode tocar, o que precisa de aprovação, o que nunca. E tem o ponto incômodo de que código gerado tende a introduzir mais brecha de segurança do que código escrito à mão, então o review de segurança não pode ser o primeiro a ser cortado em nome da velocidade.
A terceira é propriedade de conhecimento. Quando uma skill codifica como o time resolve um problema, esse conhecimento sai da cabeça das pessoas e vai pro repositório. Isso é ótimo pra onboarding e péssimo se ninguém mantém. Skill desatualizada é pior que skill nenhuma, porque passa confiança falsa. Ainda estamos descobrindo quem deveria ser o dono desse acervo e com que frequência ele precisa ser podado.
Onde isso deixa a gente
O resumo honesto do começo de 2026 é esse: agentes valem a pena, mas não pelo motivo que a gente imaginava. O ganho não está no modelo, está na engenharia em volta dele. E essa engenharia - contexto, harness, skills, hooks, review - é trabalho de gente sênior, não é botão mágico. A gente entrou querendo acelerar e saiu entendendo que o trabalho mudou de lugar, não diminuiu. É menos digitar e mais decidir, especificar e verificar. Pra mim, isso é uma boa notícia.