A BruLethy era gerente sênior de dados numa das maiores empresas de tecnologia do mundo, e pediu demissão depois de oito anos lá dentro. Ela gravou um vídeo contando por quê, e faz questão de dizer, no meio da própria história, que não foi culpa da inteligência artificial.
"Eu não quero ser hipócrita em dizer que a minha vida foi destruída pelas inteligências artificiais. Eu vi como o meu trabalho foi potencializado, mas a forma com que isso foi implementado e a cobrança em cima disso foi o que transbordou o meu copo."
Guarde essa ressalva, porque ela é dela e vai na direção contrária deste texto, que passa daqui em diante falando do que a IA mudou. Eu acho que as duas coisas cabem. A ferramenta é a mesma para todo mundo. O que mudou foi o que ela tornou possível uma gestão fazer.
O que aconteceu com ela foi uma reestruturação. Tiraram os analistas do time e, no lugar de gente, entregaram agentes.
"Ao invés deles me darem pessoas para me ajudar, um time para me ajudar, eles me deram algumas inteligências artificiais que eu podia agora colocar para trabalhar para mim 24 horas por dia, sete dias por semana. Então os limites do que era humanamente possível de ser feito não existiam mais."
E ela era boa nisso. Como sênior, batia o olho na saída do modelo e via o erro rápido. A recompensa por render bem foi mais área, mais projeto e mais agente, até chegar no ponto que ela descreve como cinco projetos planejados sozinha, com cinco modelos diferentes, para entregar tudo no mesmo dia.
Isso tem nome, e eu venho usando ele há três anos. Só que o nome vem depois. Primeiro a frase.
A IA não destruiu a colaboração. Ela removeu a obrigatoriedade dela.
Colaborar era necessidade estrutural de quem não conseguia segurar o problema inteiro sozinho. Hoje uma pessoa com um agente segura, e entrega. E o que vira opcional deixa de acontecer.
O que dava mais medo era depender de uma pessoa só
Em 2023 eu subi no palco do TDC com uma frase que tinha acabado de escrever para um artigo sobre o que faz o deploy dar menos medo, publicado em inglês no Builder Center da AWS. Nada corrompe mais a cultura DevOps do que o heroísmo. Repeti a sessão várias vezes desde então, e a última gravada é do DevOpsDays Campinas de 2025.
A frase nasceu de um exercício simples. Eu queria entender o que exatamente me dava medo na hora de colocar alguma coisa em produção, depois de descontar ferramenta, automação e testes. Sobrava uma coisa só. Me dava medo subir código sabendo que, se desse problema, existia uma única pessoa capaz de resolver.
O ponto que eu defendo nessa sessão é que herói não é falha da pessoa. É falha de liderança. Ninguém acorda querendo ser o único que sabe mexer em uma parte específica do sistema. A pessoa vai acumulando contexto, os outros vão saindo, a organização não cria mecanismo nenhum para espalhar aquilo, e um dia ela olha em volta e está sozinha segurando um pedaço da empresa. Os dois lados dessa moeda são ruins. Eu já estive nos dois.
O que mudou de 2023 para cá é o tempo que leva para produzir um herói.
Antes o herói se formava por acidente
Reparem na ordem dos acontecimentos no relato dela. Uma decisão de reestruturação, tomada de uma vez, removeu o time e colocou capacidade de máquina no lugar. O desgaste de anos que costuma produzir esse tipo de dependência foi pulado inteiro. E foi apresentada como melhoria de cargo. A frase dela é "voltei a ser uma super analista, super super sênior".
É o herói sendo fabricado e comemorado dentro do mesmo processo.
Ela também viveu os dois lados da moeda ao mesmo tempo, o que eu nunca tinha visto acontecer com a mesma pessoa. Era a única capaz de revisar aquele volume, e dependia inteiramente de um sistema que precisava conferir sozinha. Os dois papéis colapsaram em uma cadeira só.
E o exercício que eu proponho na palestra para justificar tudo isso para a gestão, que é perguntar quanto custa se essa pessoa sair do time, acabou de rodar em público. Ela saiu. Passou por burnout, terapia e medicação antes de sair, e conta no vídeo que, ao conversar com os colegas, descobriu que não era só ela.
As cerimônias não eram amadas, eram obrigatórias
Tem um trecho no vídeo dela que é a descrição mais precisa de mob programming que eu já vi, escrita por alguém que não usa esse nome e que está falando no passado.
"Quando a gente tinha um problema que não conseguia resolver sozinho, o que a gente fazia? A gente chamava pessoas que a gente confiava, que a gente admirava intelectualmente. A gente sentava numa sala, mostrava o problema, todo mundo ali interagia colaborativamente para resolver esse problema e a gente chegava numa solução. E aquilo ali não existia mais, porque agora você só precisava escrever um prompt bem bonito e jogar para a inteligência artificial."
O Mano Deyvin assistiu e comentou esse vídeo ao vivo no canal dele, e ataca pelo outro lado, o do processo. Ele desenha a esteira antiga inteira no quadro, discovery, kickoff, priorização, planning, pré-refinamento, refinamento, e diz que com IA isso morreu. E aí o Henrique Breim, no chat, fecha o assunto melhor do que os dois.
"Refinamento hj é plan mode do claude"
@HenriqueBreim, no chat do Mano Deyvin, aos 11:26
Ninguém nunca acordou feliz para o pré-refinamento. Aquilo funcionava porque estava no calendário e não dependia de alguém querer, e o efeito colateral de estar no calendário é que uma vez por semana o time inteiro era empurrado para dentro da mesma sala, olhando para o mesmo problema, com as mesmas dúvidas.
O que removeram do processo foi justamente o que mantinha a colaboração de pé sem depender de vontade. E o que sobra quando a sala para de acontecer é o que ela conta no vídeo, semanas seguidas sem falar com ninguém sobre nada que não fosse uma entrega.
60% preferem trabalhar sozinhos, e não estão errados
O Mano Deyvin rodou uma enquete ao vivo durante a transmissão. 60% do chat dele preferem trabalhar sozinhos com IA. 40% preferem trabalhar com pessoas. O chat responde coisas como "somos antissociais" e "solta o Claude Code na minha mão".
É enquete de chat ao vivo, autosselecionada, e sem número de respondentes divulgado. Serve como sintoma, e é assim que eu vou usar.
O sintoma é a outra metade do mecanismo. A preferência por trabalhar sozinho sempre existiu. O que sustentava a sala de pé, mesmo contra ela, era a obrigatoriedade. Some a obrigatoriedade, some a sala. E isso também significa que qualquer proposta que dependa das pessoas passarem a gostar de sentar juntas já nasce morta.
Ele mesmo, que passou o vídeo inteiro defendendo o lado humano, fecha com uma fronteira que eu acho mais precisa do que qualquer coisa que eu tinha formulado antes.
"Quando você tá numa empresa muito grande, tomar decisão sozinho com uma IA é ruim, é bom ter mais gente. Mas agora como um programador entregando task, solta o Claude Code na minha mão."
Grupo na decisão. Sozinho com o agente na execução.
Isso resolve a tensão inteira, e é exatamente a ordem que a gente acabou seguindo sem ter formulado assim.
A revisão virou o trabalho, e ninguém está formando sênior
A parte mais forte dele é quando desenha o fluxo e mostra onde a IA ajuda e onde não ajuda. Discovery e mão na massa, resolvido. Revisão, não. A frase dele é que você tem muito mais trabalho validando do que criando.
Eu falei uma coisa parecida no DevOpsDays de 2025, e falei de forma absoluta demais. Disse que não faz o menor sentido gerar código com IA e depois botar IA para revisar. A parte que se sustenta é a da responsabilidade, e eu mantenho cada palavra dela. Se eu subo código para produção, eu respondo por aquele código, tendo usado assistente ou não. A parte que envelheceu mal é o absoluto. Revisão assistida como primeira passada, com uma pessoa assinando embaixo do merge, funciona e vai acontecer.
Só que isso parte a revisão em duas, e as duas metades têm destinos diferentes. Ler o diff e apontar o que está estranho é delegável, e cada vez mais. Decidir quando desconfiar do resultado, e em que ponto parar, não é. A máquina assume a primeira. A segunda fica inteira com a pessoa, e é ela que exige repertório.
Só que o Mano Deyvin faz uma observação que fecha a armadilha. Escalar o time não resolve o gargalo de revisão, porque revisão exige alguém sênior. E aí volta o trecho mais grave do vídeo dela.
"Agora era mais fácil pedir para escrever um código SQL do que ensinar o cara que acabou de chegar a escrever e corrigir os erros dele."
Quem toma essa decisão todo dia fica sem sênior em poucos anos. E sem sênior não existe a revisão que acabamos de estabelecer como o gargalo. Sai barato hoje e cobra caro depois, porque formar sênior leva anos e a conta só chega quando já não dá tempo de formar ninguém.
Mob programming é a resposta que eu tenho aqui, e a primeira versão dela está errada. A primeira versão é colocar quem sabe menos vendo quem sabe mais decidir, o que pressupõe alguém na sala com o repertório pronto.
Não tem. Saber quando desconfiar de um agente é conhecimento novo, e os sêniores de hoje não adquiriram isso em lugar nenhum, porque não havia onde. Eu inclusive.
Então não é transmissão, é construção. E a diferença importa mais do que parece. Quando o grupo constrói o julgamento junto, em cima de um problema de verdade, ele nasce distribuído. Quando uma pessoa constrói sozinha, ele nasce concentrado, e a gente já sabe onde isso termina.
E aqui eu preciso separar duas senioridades que eu vinha tratando como uma. A antiga é repertório de domínio e de código, leva anos, e é ela que a decisão de pedir o SQL ao modelo em vez de ensinar quem chegou está destruindo. A nova é saber desconfiar do agente, e essa se constrói em meses, porque nem existia até outro dia.
Só que a nova depende inteiramente da antiga. Ninguém desconfia de um resultado sem ter repertório para achar estranho o que está ali. E é por isso que destruir a formação da primeira inviabiliza a segunda, mesmo a segunda sendo rápida de construir.
Escrever skill é externalização, e a espiral não fecha
Nonaka e Takeuchi já descreveram isso, e melhor do que eu. Eles descrevem quatro movimentos possíveis entre conhecimento tácito e explícito, formando uma espiral que gira porque o explícito volta a virar tácito no fim, e só um dos quatro dispensa documento.
Tem um detalhe nesse quadro que eu só enxerguei há pouco tempo. Quando a gente escreve uma skill para um agente, que é um documento de instruções que ele carrega e executa sozinho, está fazendo externalização, exatamente como quem escreve um playbook. A diferença aparece depois, em quem lê. Playbook uma pessoa lê, aplica, e aquilo vira reflexo, então a espiral gira. Skill o agente executa, e a volta para o tácito simplesmente não acontece.
Dá para entregar cada vez mais assim, indefinidamente, sem que ninguém tenha aprendido no caminho. É a mesma conta do parágrafo anterior, vista pelo outro lado.
O que a gente fez no Dati Labs, e por que o resultado não foi código
O Dati Labs é a área de IA e modernização da Dati, e o que nos ocupa é entender o que muda no jeito de trabalhar quando agentes entram no trabalho para valer.
Em julho o time inteiro passou um dia em cima de um problema de cliente que ninguém tinha resolvido antes, com voz em tempo real e avatar apresentando ao vivo em palco. Nada parecido com o dia a dia de ninguém ali.
Estamos construindo um time, e eu queria fazer isso com problema real em vez de exercício, porque exercício todo mundo sabe que é exercício e ninguém se compromete de verdade com o resultado. E queria que a gente exercitasse programar com IA em grupo, e não cada um na sua máquina descobrindo sozinho o que funciona.
O formato foi uma sessão longa de sabatina com o agente de IA no meio e com a condução mudando de mão o tempo todo ao longo do dia. A pessoa da vez assume o problema e leva as perguntas da sala inteira até a decisão ficar de pé, e então passa adiante. Todo mundo passou pela cadeira.
A troca de mão tinha um artefato. Virava um documento escrito na hora, endereçado a quem assumia a cadeira, com o estado da discussão e a regra de como continuar. E a regra é a parte que interessa aqui. Se algo já decidido parecer errado, desafie uma vez, em voz alta, e deixe o time decidir, que é antiheroísmo escrito dentro do processo.
Em algum ponto do dia o quadro branco entrou. Não estava planejado e não durou muito, uns cinco minutos, o tempo de desenhar o orquestrador no meio, as peças em volta, e colocar o time todo na mesma página.
No fim do dia não havia código de produção. Havia uma especificação escrita e mais de sessenta tarefas especificadas e prontas para desenvolvimento.
Isso me obrigou a atualizar a minha própria palestra. Nas duas gravações eu descrevo mob programming como gente revezando no teclado, quinze ou vinte minutos cada, resolvendo um problema de código de forma colaborativa. Foi assim que eu aprendi programação funcional nos meus primeiros dias no Nubank, todo torto, sem saber as teclas de atalho direito, e foi o período em que eu mais aprendi lá.
Mob programming já estava na lista de antídotos contra o heroísmo que eu publiquei naquele artigo de 2023, junto com pair programming, game days e sessões de whiteboard. E o quadro branco está naquela lista por um motivo específico, que é impedir que a arquitetura desça pronta da cabeça de uma pessoa só.
O teclado hoje é onde o agente trabalha. Então o que o time produz junto deixou de ser apenas o código e passou a ser aquilo que o agente vai consumir depois. O mecanismo continua o mesmo. Mudou o artefato que sai da sala no fim do dia.
Toda sexta o time inteiro junto
Hoje esse projeto está na mão de um desenvolvedor. Uma pessoa sozinha com um agente é, ponto por ponto, a configuração que quebrou a gerente do vídeo, e é o arranjo que produz herói mais rápido que qualquer outro que eu já tenha visto.
Por isso o time inteiro para trinta minutos toda sexta-feira. E o combinado é explícito quanto ao que aquilo não é. Não é reunião de status de tarefa. Quem está no projeto conta o avanço e, principalmente, o método. O combinado até aqui é escolher um projeto por vez e tornar isso um hábito. Estamos só no começo disso.
A palavra que carrega peso ali é método. Status qualquer um extrai do repositório, de uma ferramenta de tarefas, e um agente extrai melhor e mais rápido do que a gente. Por que a pessoa desconfiou do agente naquele ponto específico, o que ela tentou antes, e o que fez ela mudar de ideia, isso não está em commit nenhum.
Nas minhas sessões eu compartilho uma prática parecida chamada rotação do bombeiro. A ideia original é rodar quem fica de plantão, semana a semana, para que o time inteiro aprenda a apagar incêndio e ninguém acabe sendo o único que sabe. Esta sexta-feira que estamos colocando no Dati Labs é a mesma mecânica aplicada a conhecimento em vez de incidente, e ela entrou na agenda antes de existir um herói para dissolver.
Naquele artigo de 2023 eu escrevi que a organização pronta para fazer deploy na sexta é a que entende que cultura de time vale mais que talento individual. Ironicamente, nossa reunião é às sextas-feiras. Só que agora deployment não é o assunto.
O que ainda não sabemos
Isso foi um dia, num projeto. É anedota, não evidência, e eu não vou fingir o contrário.
O que a anedota ilustra, porém, não é anedota. O relatório da DORA de 2025, com quase cinco mil profissionais ouvidos, achou três coisas que conversam direto com este texto. A adoção de IA passou a ter relação positiva com throughput, o que é uma virada em relação a 2024. Ela continua tendo relação negativa com estabilidade de entrega. E 30% relatam pouca ou nenhuma confiança no código que a IA gera, o que o relatório lê como necessidade de capacidade crítica de validação.
Aceleração expondo fraqueza mais adiante no fluxo, e validação virando a habilidade escassa. É o mesmo mecanismo que eu descrevi aqui, medido em escala que eu não tenho.
Falta dizer o que me faria mudar de ideia, porque admitir que é anedota é honestidade sobre a evidência e não sobre a tese. Em seis meses de sexta-feira eu vou olhar duas coisas. Se alguém de fora do projeto conseguir contar o método em voz alta, funcionou. Se a pauta começar a escorregar para status sem ninguém ter decidido isso, virou mais uma reunião no calendário e eu conto aqui.
Também não vou fingir que é uma prática confortável. Na minha sessão eu conto que já trabalhei com gente que simplesmente não entrava no mob, e a parte irônica é que costumavam ser justamente as pessoas com quem eu mais teria aprendido. Expor o que você não sabe na frente do time é desconfortável, e é legítimo que seja. Sem cultura de confiança construída antes, isso não funciona, vira constrangimento e o time abandona na segunda tentativa.
Créditos
A ideia de que heroísmo é anti-padrão não é minha. Ela está em The Phoenix Project, no personagem do Brent, está no Effective DevOps, de Jennifer Davis e Ryn Daniels, que trata heroísmo entre os anti-padrões culturais.
E está na DORA. O State of AI-assisted Software Development de 2025 achou sete perfis de time por análise de cluster, e um deles é o hero team, que entrega com qualidade e impacto sobre uma fundação instável apoiada em heroísmo individual em vez de processo. Eu escrevi uma frase com superlativo em cima de um problema que a comunidade já tinha nomeado, e a frase é o que eu reivindico, não o diagnóstico.
O quadro dos quatro movimentos tem duas datas, e vale separar. Os quatro padrões de conversão entre tácito e explícito já estão no artigo que o Nonaka publicou sozinho na Harvard Business Review em 1991, onde o tácito para explícito se chama articulação. Os nomes que eu uso aqui, externalização inclusive, vêm do livro de 1995, com o Takeuchi. Vale uma correção que eu preciso fazer em mim mesmo. No artigo de 2023 eu escrevi que revisão de código transfere conhecimento tácito por socialização, com essa palavra. No palco, eu apresento três dos quatro movimentos e deixo a socialização de fora. Escrevi certo e falei errado por dois anos.
Mob programming também não é invenção nossa, e eu usei o termo o texto inteiro sem dizer de onde ele vem. A prática foi nomeada pelo Woody Zuill e pelo time dele, e o desenho original é o time inteiro no mesmo problema, ao mesmo tempo, no mesmo espaço e no mesmo computador. O que eu descrevo aqui, com a sessão terminando em especificação em vez de código, é um desvio desse desenho. O desvio é meu, e a crítica sobre ele também deve vir para mim. Vale dizer que parte da comunidade hoje prefere chamar a prática de ensemble programming.
E o vídeo que abre este texto é da BruLethy, com o comentário ao vivo do Mano Deyvin por cima. Os dois merecem ser assistidos inteiros, e a discordância entre eles é mais interessante do que a concordância.
Top comments (0)