No livro Vibe Coding, Gene Kim e Steve Yegge usam a cozinha para explicar isso. Todo mundo foi promovido a chefe de cozinha, e os agentes são os nossos cozinheiros. E, nas palavras deles, não existe opt-out dessa promoção.

Da mesma forma que um chefe de cozinha é responsável por todos os pratos que saem da sua cozinha, nós somos responsáveis por tudo que o nosso agente fizer em nosso nome.

Você delega a execução. A responsabilidade continua sua.

Isso já estava resolvido em 1955

Autoridade se delega. Responsabilidade, não.

Em 1955, Harold Koontz e Cyril O’Donnell chamaram isso de princípio da responsabilidade absoluta, em Principles of Management. A frase deles:

“since responsibility cannot be delegated, no superior can escape, through delegation, responsibility for the activities of subordinates, for it is he who has delegated authority and assigned duties.”

Ou seja: você responde porque foi você quem delegou.

A aviação levou tão a sério que escreveu como regra. O regulamento de voo dos Estados Unidos tem um artigo chamado responsabilidade e autoridade do piloto em comando, e ele diz que o piloto “is directly responsible for, and is the final authority as to, the operation of that aircraft”. O piloto automático voa boa parte do voo.

É exatamente essa a situação em que nós entramos com os agentes. Uma máquina executa, uma pessoa responde, e o arranjo é o mesmo que a aviação enfrentou décadas atrás. Com uma diferença que vale guardar até o fim deste texto: a aviação escreveu a regra dela, e o software ainda está escrevendo a sua.

Se foi o agente que fez, então eu reclamo pra quem?

A pergunta tem nome. Andreas Matthias chamou de responsibility gap em 2004: quando o comportamento do sistema não foi previsto por ninguém, a responsabilidade fica sem dono.

Dan Davies dá um nome melhor em The Unaccountability Machine: accountability sink. A responsabilidade é drenada até não sobrar ninguém a quem reclamar. Você liga, o atendente diz que o sistema não permite, e o sistema não atende telefone.

Um agente é um accountability sink excelente. Ele executa, o resultado sai, e quem foi prejudicado não acha uma pessoa do outro lado.

Já tentaram esse argumento, e perderam na justiça

Em fevereiro de 2024, uma companhia aérea foi ao tribunal sustentar exatamente a tese do Junior ali em cima. Um cliente seguiu uma informação errada do chatbot do site e pediu o dinheiro de volta, e a empresa respondeu que não podia ser responsabilizada pelo que o chatbot disse. O tribunal registrou o argumento e o desmontou em duas frases:

“In effect, [the airline] suggests the chatbot is a separate legal entity that is responsible for its own actions. This is a remarkable submission. [...] It should be obvious to [the airline] that it is responsible for all the information on its website.”

Remarkable até parece elogio, mas nesse caso é eufemismo.

Um ano antes, dois advogados americanos protocolaram uma petição com decisões judiciais que uma IA tinha inventado. O juiz abriu a sentença marcando onde a linha está:

“There is nothing inherently improper about using a reliable artificial intelligence tool for assistance. But existing rules impose a gatekeeping role on attorneys to ensure the accuracy of their filings.”

A multa não foi por usar a ferramenta. Foi por não conferir, e depois insistir. A palavra que o juiz usou para o que eles fizeram foi abandonar as próprias responsabilidades.

E não precisa de tribunal para a conta chegar. O livro do Kim e do Yegge relata um caso de 2024: um agente empurrou para produção uma mudança que acrescentou um evento na montagem de um componente de banner, e aquilo virou 6,6 milhões de chamadas a um serviço externo, com a fatura que se imagina. A conclusão do time foi a mais óbvia e a mais cara de se aprender assim: era para ter revisado.

Se ninguém aceita a desculpa, o que sobra pra fazer?

Você responde pela cozinha, não pela panela

Volte para a cozinha do Kim e do Yegge. O que eles dizem que continua seu, mesmo com os cozinheiros fazendo tudo, é “the menu, the quality control, and the overall vision for what your kitchen produces”.

O chefe não prova cada panela. Ele monta o cardápio, define o padrão e prova o prato.

Na prática, isso é um conjunto de conceitos:

• Guardrail

• Least privilege

• Gate

• Eval

Guardrail

Guardrail é o limite que você desenha em volta do agente, e que não depende de ele concordar.

A OWASP trata como defesa em camadas e nomeia algumas: validação de entrada, least privilege, aprovação humana para ação destrutiva. E carrega um requisito: o controle não pode morar dentro do modelo.

Um levantamento de padrões de projeto para agentes conclui que tornar o modelo robusto por si só é extremamente difícil, e que o caminho está no desenho do sistema em volta dele.

Esse sistema em volta é o harness. O paper publicado na Kaggle sobre o novo SDLC diz que um modelo cru não é um agente: ele vira um quando o harness dá a ele estado, execução de ferramentas, ciclos de retorno e restrições que dá para fazer valer.

Birgitta Böckeler resume numa equação: Agent = Model + Harness. Só que harness é maior que guardrail, e o próprio paper separa os dois quando lista o que cabe ali dentro: arquivos de instrução e regra de um lado, guardrails e hooks do outro.

A regra que você manda no contexto e torce para o agente seguir é harness, e não impede nada: é pedido.

E aqui vão alguns lugares onde construir esse guardrail: o que o agente pode acessar e até onde ele pode agir, o bloqueio quando ele tenta passar do limite e a verificação de que o resultado faz sentido.

Least privilege

Least privilege diz o que o agente pode acessar e até onde ele pode agir. Saltzer e Schroeder escreveram em 1975 que todo programa deve operar com o menor conjunto de privilégios necessário para concluir o trabalho, e a OWASP recolocou a mesma ideia em 2025 como uma das três causas de Excessive Agency. A pergunta prática: quais são as permissões suficientes para executar a tarefa?

Repare no suficientes. Se o agente não consegue rodar o próprio teste, ele não tem autonomia.

O risco não mora em nenhuma permissão sozinha. Simon Willison chama de The lethal trifecta a combinação que faz o estrago: acesso ao seu dado privado, exposição a conteúdo não confiável e possibilidade de se comunicar externamente. Least privilege é como você impede que as três se encontrem.

Gate

Gate é o bloqueio quando o agente tenta passar do limite. CI, CD, linter, validador, teste, type checker. Os modelos de IA são não determinísticos, e essa verificação precisa de determinismo.

Gates determinísticos evitam que um humano precise fazer as verificações que podem ser automatizadas.

Com agentes isso aparece como hook, e vale saber a diferença: o agente não consegue pular um hook, você consegue. O mesmo mecanismo é guardrail de um lado e pedido do outro, e o lado que pode desligar é o seu.

Eval

Eval avalia se o resultado faz sentido de acordo com seus critérios.

Um pull request pode estar com a sintaxe perfeita, com todos os testes passando, e ainda assim implementar a regra de negócio errada. Com o eval dá pra medir isso.

Essa medida pode virar um guardrail se você definir qual é o limiar aceitável.

Nem todo guardrail é determinístico. Linter, type checker, escopo de permissão e teste dão sempre a mesma resposta para a mesma entrada: ou passa, ou não passa. Quando não existe checagem determinística para o que você precisa julgar, o caminho é mandar um prompt para verificar, e tem pesquisa fazendo exatamente isso: um LLM treinado para avaliar a entrada e devolver um veredito, e isso vira um gate e opera como guardrail.

LLM as a judge alcança o que o gate determinístico não alcança, mas traz junto um problema. A OWASP diz o mecanismo em uma frase: “A guardrail LLM is itself an LLM and is itself susceptible to prompt injection.” O Simon Willison reparou que os produtos vendidos como guardrail afirmam capturar “95% dos ataques”, e que em segurança de aplicação 95% é nota de reprovação.

Então a regra é: use o LLM as a judge como mais uma camada, mas saiba que ele não garante o limite. Sempre que possível, prefira as verificações determinísticas.

E repare no que os três têm em comum: o que o agente pode acessar, o que bloqueia quando ele tenta passar e o que verifica o resultado são decisões suas. Nenhuma delas torna o agente responsável. Todas tiram uma decisão de dentro da sua cabeça e criam ferramentas que a cumprem sozinhas, com ou sem agente.

A engenharia já concordou

O paper publicado na Kaggle sobre o novo SDLC descreve o que continua no seu ciclo de desenvolvimento com agentes: especificar, desenhar os guardrails e aprovar.

O eval faz parte do processo de verificação que deve ser feito de acordo com o que foi especificado. O gate está nos testes e verificação: o que falha volta pra fase de planejamento. Mas quem definiu o que deve ser testado e verificado foi você quando estava desenhando os guardrails. E o least privilege é o que decide o que o agente alcança, que é a única coisa que o desenho não mostra: ele já supõe o agente com o acesso de que precisa para trabalhar.

É essa parte que o roadmap do MCP está construindo. A autorização foi desenhada supondo uma pessoa com um navegador na hora do consentimento, e hoje quem chama é um agente.

O que está sendo construído é identidade própria para o agente e delegação de autoridade com escopo. O agente não precisa ter as mesmas permissões e privilégios que quem o criou. É o least privilege subindo de configuração para protocolo.

Isso é justamente pra que a responsabilidade continue endereçável à pessoa e não ao agente.

Quando se aumenta o throughput, a verificação cobra a conta

O preço dessa verificação já foi medido. A FAROS viu o tempo de revisão de pull request subir 91% em 2025 e 441% em 2026, com 31% mais PRs entrando sem revisão nenhuma. O DORA chama de imposto de verificação a parte disso que é conferir o que a IA gerou.

Na analogia da cozinha: cozinha que prova tudo de novo serve o jantar frio.

A saída não é revisar mais. É o gate, que tira da leitura humana tudo que uma máquina reprova sozinha. E gate também é uma parte da cozinha que você desenhou, então um gate frouxo continua sendo responsabilidade sua.

Quatro perguntas antes de deixar um agente agir

1. Quais são os guardrails?

2. Quais são as permissões suficientes para executar a tarefa?

3. O que impede o agente de atravessar o limite, sem alguém lembrar de olhar?

4. Como eu sei que o que saiu faz sentido?

Quem responde por elas é quem cria o agente.

Você já é o chefe

O agente entregou uma funcionalidade quebrada. Verdade. Mas foi você quem mandou ele fazer, com a sua credencial, dentro do escopo que você desenhou, e é em seu nome que ela roda agora.

Você não foi promovido a quem prepara mais rápido. Foi promovido a quem define as regras e os padrões.

Como você delega a implementação sem delegar a responsabilidade? Conta nos comentários o que você já experimentou: o gate que você colocou, o incidente que resultou do excesso de permissão do agente, a coisa que o agente nunca decide sozinho. Salva esse post pra reler quando for desenhar o seu próximo agente.

Se você já ouviu “foi a IA que gerou” numa reunião, manda esse texto pra pessoa que disse.

A correnteza vai lhe empurrando pra fora da rota e você só se dá conta quando volta pra praia e percebe que tá longe da sua sandália.

Nadador experiente levanta a cabeça com frequência. Custa quase nada.

Agora imagine que nadar é produzir código e que o seu agente é muito rápido nisso.

O protocolo que ninguém pediu

O pedido tinha uma linha: “faz a autenticação seguindo o protocolo OAuth”.

O que voltou foi o protocolo inteiro, implementado do zero, com os fluxos que ninguém ia usar e os casos de exceção que ninguém pediu. E não era código ruim. Compilava, rodava e passava nos testes que ele mesmo tinha escrito.

Pra se ter uma ideia, a biblioteca oauthlib tem cerca de 12.520 linhas de código. É código maduro: testado e validado com milhões de downloads por mês. Em alguns minutos, o agente reescreveu o que a comunidade levou anos para amadurecer.

Nada disso foi para produção. Eu olhei, pedi que ele levantasse as bibliotecas que já faziam aquilo, e o trabalho inteiro virou lixo.

E olha a quantidade de token que foi pro lixo entre o meu pedido e a verificação: um protocolo inteiro.

Peça a pesquisa, não a implementação

O erro estava no pedido, não na resposta.

“Faz a autenticação” é claríssimo, e mesmo assim entrega um escopo inteiro. Ele é abrangente: diz o que fazer e não como. A decisão de implementar na mão ou usar uma biblioteca fugiu do controle de quem pediu.

E dava para consertar. Bastava pedir a mesma coisa que eu acabei pedindo, só que antes: “levanta as bibliotecas maduras que fazem isso e o que cada uma custa”. Esse é um pedido inteiro, e a resposta dele é uma decisão sua. Definida a direção, aí você acelera.

A diferença entre pedir isso antes e pedir depois é o tamanho do que se joga fora.

Então é só escrever pedidos melhores?

A conta aparece na areia

Não, e é aqui que o mar volta.

Pedir a pesquisa resolve os problemas que você já conhece. Quem pede assim é porque já cometeu esse erro antes. O problema é que a lista dos erros que você ainda não conhece é a que não acaba, e o agente pode assumir o que você não previu como parte do escopo.

Aí é onde o agente começa a desviar do pedido e você vai precisar identificar o desvio e corrigir o rumo. Se corrigir cedo, o novo rumo é quase igual ao original. Corrigido tarde, ele vira uma travessia inteira só para voltar à linha, e dessa vez nadando contra a correnteza.

E o desvio é traiçoeiro porque não dói enquanto acontece: dentro d’água, nadar torto e nadar reto são a mesma sensação.

Repare no que isso quer dizer. O tamanho do prejuízo não depende de quão errado o agente estava. Depende da quantidade de trabalho que ele fez sem supervisão.

A fórmula, para quem trabalha com agente

É disso que Alisson Vale trata em “A Fórmula da Eficácia”. Eficácia é fazer a coisa certa, e fazer a coisa certa não é saber de antemão qual decisão está correta. É evitar avançar estando errado. Você não controla se vai acertar. Controla quanto tempo leva até descobrir que está errando.

Por trás disso está o ciclo OODA, do estrategista militar John Boyd: observar, orientar, decidir, agir. Quem fecha a volta mais rápido decide melhor, não por acertar mais, mas por errar por menos tempo.

O que muda com agente é o preço da volta. Verificar uma hipótese custava uma reunião e uma semana. Hoje custa alguns minutos. A ferramenta que acelerou o erro acelerou junto a possibilidade de pegá-lo cedo, e quase ninguém está usando a segunda metade.

O relatório de 2026 do DORA resume a régua numa frase que vale colar na parede: “não medimos a IA pelo código que ela escreve, e sim pelos gargalos que ela desobstrui” (no original, “we don’t measure AI by the code it writes but by the bottlenecks it clears”). Um PR de 12.520 linhas é código escrito. E ele não desobstruiu gargalo nenhum: criou um.

Assuma que o agente vai errar

O ditado diz que errar é humano, mas ele também se aplica aos agentes. Da mesma forma que estamos sempre verificando e revisando o nosso trabalho e o dos nossos colegas, devemos usar como premissa que o agente também vai errar. Não por pessimismo, e sim por projeto. Quem acha que vai acertar sempre peca na verificação e descobre o erro da pior forma. Quem assume erro evita que ele persista e aprende mais.

Você provavelmente já acredita nisso. Na pesquisa State of Code da Sonar, com mais de 1.100 desenvolvedores, 96% dizem não confiar plenamente que o código gerado esteja funcionalmente correto, e 61% dizem que a IA costuma produzir código que parece certo e não é confiável.

O que não acompanha é a prática. Na mesma pesquisa, 82% dizem que a IA os faz programar mais rápido, e só 48% sempre conferem o que ela escreveu antes de commitar. A velocidade foi adotada. A verificação, não.

Assumindo que o agente pode errar, aqui vão quatro perguntas para você se fazer antes de mandar o prompt:

1. Cabe numa revisão? Se você não vai ler o diff inteiro, o pedido era grande demais.

2. O critério de pronto foi declarado antes? “Funcionou” não é critério. É condição mínima para aceitar a resposta.

3. Verificar é diferente de rodar? Rodar prova que executa. Verificar é conferir contra o critério que você escreveu antes.

4. É uma decisão por vez? Pedir a escolha da biblioteca e a implementação no mesmo pedido entrega as duas decididas por quem não conhecia o contexto.

Não é teoria contra a corrente. Na pesquisa de 2026 do The Pragmatic Engineer, com 906 pessoas, 56% fazem 70% ou mais do trabalho de engenharia com IA. E continuam com o terminal e a IDE lado a lado, revisando o que o agente muda.

Onde o ciclo curto custa caro

Verificar tem preço, e o preço é atenção.

O DORA report de 2026, The ROI of AI-assisted Software Development deu um nome pra isso: imposto de verificação (verification tax). É o tempo que você gasta revisando código gerado, e aponta esse imposto como uma das causas do vale de produtividade que aparece logo depois de adotar IA. Eles chamam esse vale de mensalidade da transformação, e avisam: quem lê a queda como fracasso corta o investimento bem no fundo dela.

E dá para medir o imposto. Na pesquisa da Sonar, 38% dizem que revisar código gerado dá mais trabalho que revisar o de um colega humano, e quase um quarto da semana de trabalho vai em conferir, consertar e validar o que a IA produziu. O tempo que você economiza escrevendo volta como tempo revisando.

Existe uma segunda fatura, e ela não vence agora. Addy Osmani chama de dívida de compreensão (comprehension debt): você entende cada vez menos da base de código que leva o seu nome. É trivialmente fácil revisar um código que você já não saberia escrever do zero, e quando a sua capacidade de ler para de acompanhar a de gerar, você não está mais fazendo engenharia. Está torcendo.

Então a medida não é “o menor pedaço possível”. Quem nada de cabeça erguida o tempo todo não nada, boia olhando. A medida é o maior pedaço que ainda cabe numa revisão de verdade, e ela é diferente para cada pessoa e para cada base de código.

É por isso que ele erra longe

A velocidade não é o problema. Ela é a melhor coisa que aconteceu com esse trabalho em muito tempo.

O problema é o que a gente escolheu fazer com ela. Dá para gastar velocidade dando mais braçadas antes de olhar, e é isso que produz um PR que ninguém consegue revisar. Ou dá para gastar do outro jeito: pedaço pequeno, critério escrito antes, cabeça erguida no caminho. A mesma velocidade, usada para errar perto.

E você? Qual foi o prompt que você mandou e o agente fez mais do que você conseguia revisar?

Se essa ideia foi útil, passa pra frente.

Isso é o que eu sempre procuro que aconteça depois das minhas palestras. E no RogaDX aconteceu: a palestra logo após a minha parecia uma continuação e depois surgiram muitas conversas com a plateia em torno do assunto.

Eu passei dois dias no evento. Subi no palco da Arena Builder para falar do ciclo de desenvolvimento com IA, e quando não estava lá, percebi que muitas das outras palestras eram baseadas em ideias semelhantes e resolviam problemas parecidos com os meus.

A escolha das palestras foi muito bem feita pela organização e ela faz três coisas difíceis:

1. Escolhe os assuntos que valem a pena;

2. Reúne num mesmo lugar quem se importa com eles;

3. Entrega conteúdo que alguém validou e testou antes de subir no palco.

Por que eu estava lá

O RogaDX é o maior evento de tecnologia de Alagoas e chegou em 2026 à quinta edição, nos dias 14 e 15 de agosto, no Centro de Convenções de Maceió. A organização espalhou a programação por quatro arenas simultâneas: Roga DX, Tech, Builder e a de Negócios, que estreou nesta edição. Os números que o site do evento publica dão a escala: mais de 2 mil participantes, mais de 55 palestrantes, mais de 15 empresas de tecnologia e mais de 20 mentorias.

Eu palestrei na Arena Builder, sobre o ciclo de desenvolvimento com IA e o impacto dela nas carreiras das pessoas.

O argumento que eu levei veio do livro Vibe Coding: Building Production-Grade Software with Genai, Chat, Agents, and Beyond, de Gene Kim e Steve Yegge, e vem do acrônimo FAAFO (Fun, Autonomous, Ambitious, Fast, and Optionality) que eu traduzi para ADORA: Autonomia, Diversão, Opcionalidade, Rapidez e Ambição. São os cinco superpoderes que o desenvolvimento assistido por IA destrava, e a tese que amarra os cinco é que o gargalo do trabalho saiu de lugar. Não está mais em escrever o código. Está em decidir o que construir, revisar o que voltou e responder pelo resultado. Esse é o ciclo.

Tem post aqui no blog sobre isso: ADORA, os 5 superpoderes do Vibe Coding.

Também falei de como podemos instanciar o Paradoxo de Jevons ao impacto que a IA está causando na carreira de desenvolvimento de software. Também tem post sobre isso aqui: O caixa eletrônico não acabou com o caixa. E a IA não vai acabar com o desenvolvedor.

A sala encheu, e esse é um dos melhores dados pra mim. Não pela contagem em si. Sala cheia significa que, quando eu descer do palco, vai existir gente com o mesmo assunto fresco na cabeça, e é isso que faz a conversa depois começar no meio em vez de começar do zero.

E é dessa conversa que sai o que eu mais gosto nos eventos: a experiência de quem já tentou aquilo em outro contexto, a pergunta que eu não tinha previsto, o furo no argumento que só aparece quando alguém que vive o problema discorda na sua frente. Isso refina o que eu entendo, melhora a versão seguinte da palestra e é como eu tenho conhecido mais pessoas e feito amigos em eventos.

Quatro palestras, um assunto só

Quatro palestras me marcaram pela forma como elas se conectaram sem que os palestrantes tivessem planejado isso antes.

A Giovana Armani abriu no primeiro dia separando duas coisas que quase todo mundo trata como sinônimo. Código não é a mesma coisa que software. Código é transformar instruções em implementação. Software é transformar ideias abstratas em um sistema confiável. E ela subiu na tela uma citação do Boris Cherny, criador do Claude Code, que resume o incômodo de 2026 inteiro:

“Podemos dizer que código está, em grande parte, resolvido.”

Se código está resolvido e software continua difícil, a pergunta que sobra é o que exatamente ficou difícil. A resposta dela foi prática: a IA erra por falta de contexto, não por falta de inteligência. Modelos presos no tempo, respostas genéricas, confiança cega. E o fechamento dela foi uma lista de combate a cada um desses problemas, com MCP para dado em tempo real, steering para foco no contexto certo, skills para conhecimento especializado e specs para requisitos e padrões corretos, tudo isso mais revisão humana.

O partiu daí e mostrou como que ele transforma todo o conhecimento de desenvolvimento de produtos em softwares que a IA consegue executar:

“Empresas AI Native não escalam porque possuem melhores modelos. Elas escalam porque transformam conhecimento em sistemas executáveis por IA.”

Ele mostrou os loops de desenvolvimento, a diferença entre um loop aberto e um loop fechado, e onde mora o conhecimento de uma operação quando você resolve versionar esse conhecimento em vez de deixá-lo na cabeça das pessoas. E fechou com três lembretes que valem impressos:

1. Decidir o que não construir é o novo trabalho difícil.

2. Feche o loop: meta, execução, verificação, iteração.

3. Cada erro vira regra escrita, pois o sistema aprende, não só a pessoa.

Repare no terceiro. Ele é a versão operacional do que a Giovana tinha dito de manhã, no mesmo dia: o problema é contexto, e contexto que não vira arquivo não vira contexto de ninguém.

Logo depois, o deu um zoom out e saiu do software.

“A IA deixou de ser produto. Virou poder.”

A palestra dele falava sobre geopolítica, sobre o dia em que o mercado reprecificou software e sobre modelos de fronteira sendo tratados como material estratégico. Mas teve uma frase dele que tocou exatamente no assunto da minha palestra: digitar código deixou de ser o gargalo, e o diferencial de quem desenvolve subiu uma camada de abstração.

Essa é a terceira pessoa dizendo coisas relacionadas por enquadramentos diferentes, e nenhuma das três tinha combinado nada. A Giovana olhou de perto e separou dois conceitos que a gente trata como um. O Marcell enquadrou com o ângulo da empresa, onde o conhecimento precisa virar sistema. O Terron foi para longe, onde o assunto é geopolítica e energia. Cada foto conta uma história diferente da mesma cena: de perto você enxerga o detalhe, de longe você enxerga o todo, e é a soma dos enquadramentos que dá a visão inteira.

Na Arena Builder, no primeiro dia, aconteceu um painel chamado “Design e produto na era da IA: o que o mercado espera de você em 2026”, com , e . Ele é o contraponto interno desta seção: enquanto quatro palestras discutiam o que a IA faz com o código, o painel perguntava o que o mercado vai esperar da pessoa.

Faltava uma perspectiva, e ela veio logo depois da minha palestra.

A grata surpresa que veio depois da minha palestra

O Daniel Fireman palestrou na Arena Builder logo depois de mim, sobre como a Unico adotou desenvolvimento assistido por IA. Eu tinha acabado de descer do palco dizendo que o gargalo saiu de lugar. Ele subiu e mostrou um slide chamado The Bottleneck Moved.

Os números comparam o começo de 2025 com abril de 2026 e são dados internos da Unico:

• Tempo de desenvolvimento ativo caiu 79,4%, de 307,8 horas para 63,3 horas.

• Tempo de revisão caiu 58,7%, de 37,5 horas para 15,5 horas.

No mesmo período: volume mensal de mudanças de código cresceu 144,9%, de 465 para 1.139 mudanças por mês, e a entrega de novas funcionalidades cresceu 129,2%, que foi para onde a capacidade liberada foi parar. E o achado que ele chamou de crítico: a Unico manteve uma release a cada 2,5 dias enquanto o volume mais que dobrava.

A Unico foi na contramão do que a indústria vinha reportando, e é por isso que aquele slide me pegou. Os dados que eu tinha levado ao palco poucas horas antes diziam o contrário. O DORA report 2025 mostra 90% de adoção de IA entre desenvolvedores e 80% relatando ganho de produtividade. E a FAROS mediu para onde a fila andou: o tempo de revisão de PRs subiu 91% em 2025 e 441% em 2026, com 31% dos PRs sendo mesclados sem revisão nenhuma.

É a teoria das restrições cobrando o preço dela, e é o slide mais importante da minha palestra: geramos código mais rápido e empurramos a fila inteira para a revisão. Na Unico o tempo de revisão caiu 58,7%. Ele explicou por quê.

O relatório de ROI que o DORA publicou depois descreve o mecanismo disso. Existe uma queda temporária de produtividade que a maioria dos times paga antes do ganho chegar, e ela vem de três lugares: a curva de aprendizado, o custo de revisar código gerado por IA antes que isso se pague, e os limites de tudo o que vem depois, teste, aprovação e deploy, que não foram construídos para aquele volume.

A Unico não pagou essa conta. As sete capacidades do DORA já estavam no lugar antes da IA chegar. Havia mais de 200 SLIs pegando problema na hora. A revisão de arquitetura somada à IA virava quality gate automático. E o que se media era valor de negócio, não métrica de vaidade. Embaixo dos quatro itens uma lição:

“Nenhum desses quatro itens é sobre inteligência artificial.”

É o mesmo argumento que falo sobre as práticas que tornam a IA mais eficiente e previsível. Essas práticas também se aplicam aos nossos colegas: transparência, direcionamento claro, definição de boas práticas, verificação, observabilidade, etc. O ganho não veio da IA. Veio de padronizar a stack e documentar os padrões e as práticas de engenharia antes de ligar a IA em cima disso.

Com isso, a IA se torna uma aliada e reproduz as boas práticas. Sem isso, ela só aumenta o caos e a desorganização que já existe.

O fechamento dele é uma frase que serve para qualquer empresa que esteja pensando em adotar IA agora: a ordem da maturidade importa mais que a velocidade da adoção.

O preço de quatro palcos

Aqui vem a parte que os posts de evento costumam pular.

Quatro arenas simultâneas são vendidas como abundância, e quem vai sabe que são escolha forçada. Cada bloco de horário que você escolhe custa três blocos que você não vai ver. Ao longo de dois dias, isso significa que você não viu a maior parte do evento e você nunca vai saber o que perdeu.

Eu conheci o lá. Ele foi ótima companhia o evento inteiro, dessas pessoas que você encontra três vezes no mesmo dia e a conversa continua de onde parou. A palestra dele era no mesmo horário da minha.

Eu não vi a dele. Ele não viu a minha. E as duas aconteceram.

Com o foi a mesma conta por outro caminho. A palestra dele não bateu com a minha, bateu com o horário em que eu estava gravando o podcast. Ou seja, nem estar livre resolve: o que eu escolhi fazer com o tempo livre também custou uma palestra.

Não é defeito de organização. É o que acontece quando um evento cresce, e o mesmo crescimento que traz quatro arenas é o que traz gente suficiente para você esbarrar em alguém como o Kácio. As duas coisas vêm no mesmo pacote.

E é justamente por isso que a próxima seção existe. Ninguém consome a grade inteira. A parte do evento que está aberta para todo mundo ao mesmo tempo é a que acontece entre uma palestra e outra.

O que não estava na grade

O exemplo mais limpo foi uma conversa sobre controle de acesso para agentes de IA. Três pessoas em pé, no meio do barulho, discutindo uma coisa bem específica: quando você dá uma credencial para um agente, o que exatamente ele passa a poder fazer, e quem responde quando ele faz.

Não estava na programação, não tinha título, e tocou em um assunto tão relevante que tá no roadmap do MCP e tem uma documentação própria: Enterprise-Managed Authorization. É um assunto crucial para escalar agentes em grandes organizações.

Ela foi com o @armando barbosa Armando Barbosa, que eu já conhecia dos eventos da comunidade Python, e o Guilherme Rocha. Repare no detalhe do Armando: eu não conheci ele no RogaDX. Eu já tinha construído aquela relação em outros eventos, ao longo de anos, e o RogaDX foi só onde ela rendeu a conversa desta vez. Networking de evento não acontece no evento, acontece entre eventos. E esse networking gera mais networking no próximo evento.

Fora da foto, mas dentro da mesma categoria, ficou a conversa com o professor Francisco Vital, da Afya. Alguém que ensina programação hoje está olhando para o mesmo problema que eu, de um ângulo que eu não tenho: o que muda na formação de quem está entrando agora, se código é a parte que a IA faz melhor.

Teve também o podcast, gravado no palco da Maceió Digital com o Daniel Fireman e o Wesley Marinho.

O Wesley fez o que pouca gente faz num podcast de evento: ele preparou. As perguntas deram o trilho da conversa e deu pra compartilhar muito do que eu e o Fireman estamos passando com o uso de IA no desenvolvimento de software. A conversa foi tão boa que rendeu mais conversa longe das câmeras e fora do palco: no Happy Hour.

E teve a organização. O convite para palestrar veio do Gustavo Costa, e a equipe inteira segurou dois dias de evento em quatro arenas sem que nada desandasse.

Isso parece agradecimento protocolar e não é. Um evento que funciona é o que permite que todo o resto aconteça: se a programação atrasa, se o som falha, se ninguém sabe onde é a sala, o tempo que sobraria para conversa vira tempo de logística. A organização não aparece no que ela faz, aparece no que ela deixa você fazer.

Sorvete e café moído na hora

Duas coisas pequenas que eu não consigo tirar do relato.

A primeira foi um sorvete distribuído com a marca do evento carimbada em cima. É um detalhe e é exatamente o tipo de coisa que não acontece por acaso: alguém pensou nisso semanas antes.

A segunda foi o café. A RDV Roasters, torrefação de Maceió, moía e preparava na hora, ali. Eu sou apaixonado por café de qualidade, então declaro o viés: o evento já tinha me ganhado nesse ponto.

Esses são detalhes que marcam o evento e diferenciam da média.

Fora do palco

Se eu tivesse assistido ao RogaDX pelo YouTube, teria pego as quatro palestras e teria perdido tudo o que este post descreve. Teria perdido a conversa em pé sobre agentes. Teria perdido a descoberta, ao vivo, de que o Daniel estava medindo o que eu estava argumentando. Não teria conhecido o Kácio, e não teria nem como saber que perdi a palestra dele.

O conteúdo das palestras é a parte mais confiável de um evento. É argumento que alguém testou antes de subir no palco, com número, com caso, com o custo já pago por quem viveu aquilo. E é também a parte que você acha online: no vídeo, no slide, no relato de quem foi. O que não tem cópia é estar na mesma sala que gente que vive o mesmo problema que você, no dia em que os dois estão pensando nele.

A programação do evento é o que faz essas pessoas aparecerem no mesmo lugar, na mesma data, com o mesmo assunto na cabeça. Sem ela não existe conversa nenhuma, existe um monte de gente num galpão sem motivo comum. A palestra monta o trilho e define o assunto de interesse dos participantes do evento. O que acontece fora do palco é gente compartilhando experiência relacionada ao tema das palestras.

Eu saí do RogaDX 26 com a expectativa superada e já ansioso pelo do ano que vem.

Me conta nos comentários sobre um evento que você participou e que a conversa com as pessoas fora do palco fez a diferença.

A palestra completa, com os slides e o vídeo, está em https://to.vbmendes.dev/palestra-rogadx-26?s=nl. Se quiser conversar sobre o assunto da palestra, eu teria o maior prazer.

Ele não quebrava, não acordava ninguém de madrugada, não gerava incidente. Só respondia devagar de vez em quando e isso prejudicava a experiência de poucos clientes, por isso nunca virava prioridade.

Você conhece esse endpoint. Todo sistema tem o dele.

Até que eu decidi pedir para o agente de IA investigar. Era uma tarefa que demandaria conhecimentos de observabilidade, banco de dados e código. Sem agentes de IA, ia precisar envolver umas três pessoas.

Com o agente, eu resolvi em uma tarde e ainda ensinei a ele como repetir o processo pra depurar as próximas requisições lentas.

O span que segurava o tempo

Abri o agente e dei a ele o MCP da ferramenta de observabilidade. A partir dali ele não estava mais lendo o que eu colava no chat, estava consultando a ferramenta.

Ele puxou os traces daquele endpoint, ordenou pelos mais lentos e a conta apareceu rápido: um span consumia quase todo o tempo da requisição, e dentro dele estava uma query SQL.

Isso é o passo que qualquer um faz. Se a história parasse aqui, o agente teria economizado quinze minutos meus e nada mais.

O que o trace não guardava

A query que aparece no span vem parametrizada. Você vê a forma, não vê os valores. E é com os valores reais que ela ficou lenta, não com valores de exemplo.

Foi aqui que a coisa mudou de patamar. O agente tinha, ao mesmo tempo, três coisas na mão: as properties daquele trace, o MCP do data lake para buscar o que faltava, e o código do repositório.

Com o código ele descobriu qual trecho monta aquela query e quais parâmetros entram nela. Com as properties do trace ele soube quais eram os identificadores daquela requisição específica. Com o data lake ele foi buscar os dados que nem o trace nem o código guardavam.

E reconstruiu a query real. Não uma parecida, a que estava lenta.

Repara que nenhuma dessas três fontes resolve sozinha. O trace sabe quando, o data lake sabe o quê, o código sabe como. A investigação inteira mora na interseção, e é exatamente por isso que ela costumava precisar de três pessoas.

A pergunta que só o banco responde

Com a query real montada, o agente escreveu o EXPLAIN ANALYZE.

O EXPLAIN sozinho mostra o plano que o banco pretende executar: qual índice ele acha que vai usar, em que ordem vai juntar as tabelas, quantas linhas ele estima em cada etapa. O ANALYZE faz o banco rodar de verdade e devolver o plano com os números reais ao lado dos estimados. É a diferença entre a intuição do banco e o que aconteceu, e quase todo gargalo de query mora nessa diferença: onde ele estimou cem linhas e vieram duzentas mil.

E aí o agente parou.

Primeiro gate: quem roda sou eu

Parou de propósito, e é o primeiro dos dois momentos em que essa história depende de mim.

EXPLAIN ANALYZE executa a query. Rodar contra um banco frio devolve um plano que não descreve o problema, então a resposta útil só vem de um banco quente, com os dados e a estatística de produção, ou de uma réplica que valha por um. E decidir se aquela query pode rodar ali, agora, com aquele volume, não é uma pergunta técnica. É uma pergunta de responsabilidade, e a responsabilidade é minha.

Então o desenho é esse, e ele se repete: o agente prepara, você decide. Ele chega até a borda do que é decisão sua e para na borda, com o trabalho pronto.

Rodei. Peguei o plano de execução em JSON e devolvi para ele.

Do plano ao PR

Um plano de execução em JSON é uma árvore com dezenas de nós, cada um com custo estimado, custo real, linhas estimadas, linhas reais e tempo. Ler isso a olho é possível e é chato, e é onde a maioria das investigações morre de tédio.

O agente achou os nós que estouravam. Mas o que ele fez depois é o ponto: ele voltou para o código.

Porque saber onde o banco sofreu não diz o que consertar. O mesmo gargalo aceita correções muito diferentes, e escolher entre elas é uma decisão de projeto. Pode ser um ajuste em como a query é gerada. Pode ser um índice que não existe. Pode ser uma desnormalização, guardar o dado já calculado em vez de recalcular. Pode ser uma mudança de modelo, e aí o problema nunca foi a query. Quem só vê o plano chuta entre essas quatro. Quem vê o plano e o código pode escolher.

Ele escolheu, escreveu a mudança e abriu o PR. E a descrição do PR não era um resumo do diff: era o link para o trace lento que originou tudo, a explicação de por que aquela mudança ataca a causa e não o sintoma, e como testar.

Segundo gate: quando isso vai pro ar

O segundo momento em que a história depende de mim.

Eu reviso, eu decido se aceito aquela proposta de correção, e eu decido quando aquilo vai para produção. Um fix de performance que muda um índice ou um modelo de dados tem hora certa para subir, e essa hora é uma escolha de quem responde pelo sistema.

Repara na conta: numa investigação que cruzou observabilidade, banco de dados e código, o humano apareceu exatamente duas vezes. Nas duas foi para decidir, nunca para operar.

A skill que ficou da tarde

No fim do dia eu pedi mais uma coisa: que ele escrevesse o processo que tinha acabado de executar. Não um relatório do que aconteceu, mas as instruções para fazer de novo. Isso é uma skill: uma pasta com o passo a passo, os scripts e o contexto que o agente carrega quando a tarefa aparece.

O nome disso na documentação da Anthropic é conhecimento procedural capturado, e a orientação deles é literalmente essa: enquanto você trabalha numa tarefa com o agente, peça que ele consolide as abordagens que deram certo em contexto e código reutilizáveis. Uma skill não é documentação sobre o agente. É a experiência daquela sessão, escrita num formato que a próxima sessão consegue ler.

E o que ele escreveu não foi só o caminho rápido. Foram os dois gates junto: montar o EXPLAIN ANALYZE e parar, esperar o plano voltar, abrir o PR e parar de novo. O lugar onde ele tem que me esperar virou parte do procedimento.

No dia seguinte apareceu outra requisição lenta. Rodei a skill. Não expliquei quais MCPs, nem em que ordem, nem que os parâmetros precisavam vir do trace e não de um exemplo. O prompt foi literalmente:

/analyze-slow-trace <link-para-o-trace>

A fila que sumiu

No desenho antigo, aquelas três disciplinas eram três pessoas, e nenhuma delas com o problema inteiro na cabeça ao mesmo tempo.

A fila nunca cobrou só o tempo de execução. Ela cobrava fricção organizacional, porque cada handoff era uma pessoa com a própria agenda.

Cobrava a taxa de “ler a mente”, porque explicar um problema pela metade para quem não estava lá é onde a informação vaza.

Cobrava coordenação, que é o trabalho de fazer as pessoas certas olharem para a mesma coisa no mesmo dia.

E cobrava negociação, porque o meu incidente disputava espaço com o incidente dos outros.

Nada disso aparece no ticket. Tudo isso aparece no calendário.

O que sumiu foi a fila, e as pessoas continuam lá. Os dois gates são a prova: as duas decisões que importavam foram tomadas por uma pessoa.

A conta que chega depois

Só que a fila não evaporou. Ela andou.

Quando uma pessoa faz o trabalho que antes precisava de três, o código passa a sair mais rápido do que o time consegue revisar. Uma sessão do agente de uma tarde vira um PR. Quatro agentes viram quatro PRs, e do outro lado tem um revisor com o mesmo número de horas que tinha antes.

Fazer sozinho não é aprovar sozinho. No caso aqui em cima os dois momentos que continuaram atrás de um humano foram justamente os dois de aprovação, e não por acaso.

Essa conta tem endereço nesta série: ela é o superpoder 4, a Rapidez, e a armadilha que vem junto.

As duas coisas

Rodar contra um banco quente. Publicar em produção.

Foram essas as duas, e as duas são decisão. Tudo o que estava no meio, que é o que sempre consumiu a tarde, o agente fez porque conseguia ver as três fontes ao mesmo tempo.

E você? Qual foi a última vez que passou horas pra depurar uma requisição lenta?Quantas pessoas você envolveu?

Me conta o que você vai ensinar o seu agente a fazer.

A palestra completa, com os cinco superpoderes, está em vbmendes.dev/palestras/rogadx-2026.

Não foi o que aconteceu. E o que aconteceu de verdade é bem mais interessante do que “a previsão errou”.

Algo parecido está acontecendo com muita gente dizendo que a IA vai acabar com quem desenvolve software.

A gente já ouviu essa pelo menos quatro vezes

Antes de falar de banco, vale olhar para a nossa própria profissão, porque essa previsão já foi feita aqui e já errou várias vezes.

Linguagens de alto nível iam matar quem programava em assembly. Visual Basic ia substituir o programador profissional. Plataformas de low code iam tornar programador obsoleto. Ferramentas no code eram o fim da engenharia de software.

Repare que cada uma dessas previsões acertou um pedaço. Escrever código ficou mais abstrato a cada geração de ferramenta, e quem escrevia assembly à mão realmente virou exceção. O que elas erraram foi o principal: confundiram escrever código com desenvolver software. Continuou sendo necessário alguém que entendesse o problema, decidisse o que construir e respondesse pelo resultado.

Quatro vezes seguidas é muita sorte. Tem um mecanismo por trás.

Por que a previsão erra sempre

O mecanismo tem nome e é do século XIX. William Stanley Jevons estudava o consumo de carvão na Inglaterra e observou uma coisa que não fazia sentido nenhum: quando as máquinas a vapor ficaram mais eficientes, o país passou a consumir mais carvão, não menos.

A explicação é simples depois que alguém aponta. Carvão mais eficiente é carvão mais barato por unidade de trabalho. Barateou, então virou viável usar carvão em lugares onde não compensava antes. A demanda total subiu.

Isso ficou conhecido como paradoxo de Jevons, e ele não é sobre carvão. É sobre qualquer recurso: baratear o uso de um recurso pode aumentar a demanda por ele.

Bonito na teoria. Vamos ver com gente de verdade.

O que aconteceu com os caixas

O economista James Bessen foi atrás dos números, e eles contradizem a intuição de todo mundo.

Em 1985, os Estados Unidos tinham cerca de 60 mil caixas eletrônicos e 485 mil caixas humanos. Em 2002, eram cerca de 352 mil caixas eletrônicos. E 527 mil caixas humanos.

Os caixas eletrônicos se multiplicaram por seis, e o emprego de caixa cresceu.

O mecanismo é Jevons inteiro. O caixa eletrônico não substituiu a agência, barateou a agência: uma agência que precisava de vinte caixas passou a funcionar com treze. Agência mais barata significa que vale a pena abrir agência em lugar onde não valia antes. Os bancos abriram mais agências. Mais agências, com menos caixas cada uma, deram mais caixas no total.

Foi exatamente o contrário do que a intuição dizia, e pela razão mais banal do mundo: quando alguma coisa fica barata, você compra mais dela.

O que fica barato é experimentar

Com IA, o que está barateando não é digitar. É experimentar.

Você conhece a lista de coisas que nunca chegam a hora. Aquela documentação que ninguém escreveu. O padrão que todo mundo concorda que seria melhor e que ninguém vai aplicar em duzentos arquivos. O teste da parte chata. A refatoração que economizaria uma semana por trimestre e custa três semanas agora. O bug naquele canto do código que ninguém entende mais.

Nada disso estava parado por falta de vontade. Estava parado porque o retorno não pagava o custo. Quando o custo cai, o retorno não precisa mudar para a conta virar.

E a conta virando muda o que existe. Ideia que não valia um mês de trabalho passa a valer uma tarde. Software que não valia a pena ser escrito passa a valer. O backlog eterno deixa de ser eterno, e aparece demanda por software em lugares que nunca tiveram software.

Alguém precisa fazer esse software.

A história não termina em 2002

Só que ela não termina ali, e essa é a parte que a versão otimista dessa história costuma esconder.

O emprego de caixa de banco parou de crescer e começou a cair. O Bureau of Labor Statistics registra mais de 107 mil vagas de caixa a menos entre 2007 e 2017, e projeta uma queda de mais 13% até 2034. A explicação do próprio BLS é direta: o cliente migrou para o aplicativo, e o banco fechou agências.

Repare no que mudou entre um momento e o outro. O caixa eletrônico automatizava parte do trabalho do caixa: sacar e depositar. Para o resto, você entrava na agência. O celular automatizou o resto.

Enquanto a máquina fazia uma parte, Jevons protegeu o emprego. Quando a máquina passou a fazer quase tudo, parou de proteger.

Jevons protege o trabalho enquanto a máquina faz só uma parte dele.

Essa é a frase para levar embora, e ela vale nos dois sentidos. É por isso que a previsão do fim do caixa errou por trinta anos. E é por isso que ela acabou acertando.

A parte que está em risco

Isso desloca a pergunta. Não é se a sua profissão vai acabar, é qual parte do seu trabalho a máquina alcança primeiro.

E a resposta é a mesma nos dois casos: a parte operacional. No banco, sacar e depositar. Em software, digitar o código.

Andrew Ng tem uma frase sobre isso que ficou conhecida:

A IA não vai substituir as pessoas, mas talvez as pessoas que usam IA vão substituir as que não usam.

A ideia circulava antes dele. Karim Lakhani, de Harvard, tinha publicado uma versão mais categórica um ano antes: inteligência artificial não vai substituir humanos, mas humanos com IA vão substituir humanos sem IA. Acho que o “talvez” faz diferença aqui.

O que eu acrescento é onde mora o talvez:

E isso não se aplica só a programadores, isso se aplica a qualquer área do conhecimento. Se o seu trabalho é muito operacional, a IA muito provavelmente daqui a pouco vai fazer o seu trabalho.

Isso não é sobre programadores

Um caixa de banco não era um profissional de tecnologia, e a régua caiu sobre ele igual.

Se o seu trabalho é executar um processo que alguém já definiu, seguir um roteiro, preencher um formato, produzir a mesma peça com dados diferentes, a régua é a mesma. Não importa se você trabalha com contrato, planilha, laudo, campanha ou código.

E ninguém vai te consultar sobre isso. Você foi promovido de quem executa para quem responde pelo resultado, e essa promoção não tem como recusar.

Para quem está começando agora

Uma palavra para quem está entrando na área, porque esse texto pode ser lido do jeito errado.

Use IA. A indústria inteira usa, e recusar não é estratégia, é cavar a própria cova.

Só que existe diferença entre usar e aprender. Aceitar a resposta é fácil. Entender por que aquela é a resposta é o trabalho, e é o que vira carreira. A parte que a máquina faz por você é justamente a parte operacional, que é a parte exposta. Se você só ficar com ela, ficou com a pior metade.

A boa notícia é que a própria IA resolve isso. Não entender um trecho de código deixou de ser algo pra se envergonhar. Aqui o curioso tem vantagem. Basta perguntar: o que isso faz; por que assim e não de outro jeito; o que acontece se eu fizer diferente? É o professor mais paciente que já existiu.

Esse assunto merece um post inteiro, e vai ter. Se você quiser ler, é só ficar por aqui.

A IA não vai acabar com o desenvolvedor

O caixa eletrônico não acabou com o caixa. O aplicativo no celular acabou, trinta anos depois, quando passou a fazer o trabalho inteiro em vez de um pedaço.

Software está ficando barato, e barateamento aumenta demanda. Vai ter mais software no mundo, em lugares que não tinham, e vai ter mais trabalho para quem faz software. Vai existir mais trabalho, e menos dele vai ser operação.

Então a pergunta não é se a IA vem. Ela já veio.

E você? Qual parte do seu trabalho hoje é operação, e o que aconteceria com ela se ficasse dez vezes mais barata? Responde aqui embaixo, e salva esse post para reler quando essa parte ficar.

A Copa do Mundo acabou e a frase que eu mais escutei durante a disputa foi “Aposte com responsabilidade!”. Antes do jogo, no intervalo e até nas pausas para hidratação, as propagandas de casas de apostas esportivas estavam sempre lá. A popularização dessa prática me fez criar uma certa rejeição ao termo “aposta” pelos inúmeros relatos de pessoas endividadas, famílias desestruturadas e até vidas perdidas.

Essa visão sobre apostas mudou depois que o meu colega Roberto Hayasida me indicou o livro Thinking in Bets (Pensando em Apostas) da Annie Duke. Annie é uma ex-jogadora profissional de poker. Ela propõe que as pessoas precisam tomar decisões o tempo todo e que essas decisões se assemelham às de um jogador de poker e não de xadrez, contradizendo o ditado “a vida é uma espécie de xadrez” popularizado por Benjamin Franklin.

Poker vs Xadrez

No xadrez, todas as peças estão postas na mesa e apesar dos jogadores não saberem qual vai ser a próxima jogada do adversário, é possível calcular as mais prováveis e geralmente existe a jogada certa a fazer para aumentar as chances de vitória em cada situação.

Já no poker, não é possível prever com precisão quais cartas estão na mão do adversário nem quais cartas vão ser viradas no flop, no turn e no river. A decisão precisa ser tomada com base em incertezas e nem todas as informações disponíveis são confiáveis. Mesmo que o adversário faça uma grande aposta, ele pode estar blefando.

Nos negócios e na vida, nem sempre nós temos todas as informações disponíveis no momento de tomar uma decisão. Na verdade, o mais comum é termos pouquíssima informação no início e irmos adquirindo mais conhecimento à medida que o tempo passa. E aí fica muito fácil se tornar um engenheiro de obra pronta e decretar que a decisão foi errada quando na verdade ela geralmente é a melhor possível diante das informações disponíveis.

Decisões como apostas

Como não é possível prever o resultado de uma decisão antes de tomá-la, ela se torna uma aposta. Os resultados percebidos alimentam as próximas decisões e esse é um dos perigos: nem sempre eles são consequências diretas das nossas decisões. Eles podem ser influenciados por fatores externos, pelas nossas próprias ações e a percepção ainda pode ser afetada pelos nossos próprios vieses.

Quando se trata das próprias decisões, as pessoas tendem a associar um resultado ruim à má sorte, enquanto um resultado bom é associado a uma decisão acertada. Nós fazemos exatamente o contrário com as decisões das outras pessoas: sucessos derivam da sorte e fracassos de decisões ruins. Isso tem nome: viés do autosserviço (self-serving bias). E o custo é alto: nos dois casos, a gente aprende a lição errada.

E aqui é onde a gente começa a entender a relação disso tudo com as casas de apostas esportivas. Nesse caso, os resultados das apostas são consequências de fatores externos e da sorte. Perceba que nós não temos influência em nenhum desses fatores e é aí que mora o perigo.

Aposte com responsabilidade

Até agora falamos muito sobre o que é apostar. Agora precisamos entender o que é “responsabilidade”.

res.pon.sa.bi.li.da.de

Dever de responder pelo próprio comportamento, pelas ações de outra pessoas ou instituições. — Dicio

Obrigatoriedade de responder pelos próprios atos ou por aqueles praticados por algum subordinado. — Michaelis

Perceba que a nossa responsabilidade está diretamente relacionada aos nossos atos.

Como podemos ter responsabilidade em uma aposta sobre algo que não temos nenhuma influência?

Como vamos retroalimentar a nossa tomada de decisão com resultados de apostas que são consequências de fatores externos e sorte?

Por isso que tantas apostas dão errado e têm consequências desastrosas.

Para se fazer uma aposta responsável, é necessário apostar com base nas suas crenças e ser capaz de influenciar o resultado das apostas. E eu não estou falando de jogadores sendo induzidos a influenciar o resultado da partida para satisfazer os interesses das casas de apostas.

Eu estou falando de apostarmos em um projeto por acreditarmos no potencial e sermos capazes de atuar para que ele dê certo; em aprender uma habilidade nova porque acreditamos que ela vai nos tornar mais aptos; em aceitar uma proposta de um novo emprego por avaliarmos que vai contribuir para a nossa carreira. Esses são apenas alguns exemplos.

E você? Está apostando seu tempo, energia e dinheiro em coisas que você é capaz de influenciar ou está apenas confiando na sorte ou em fatores que você não controla?

A palestra foi muito inspirada no livro “Vibe Coding: Building Production-Grade Software with GenAI, Chat, Agents, and Beyond” do Gene Kim e do Steve Yegge com prólogo do Dario Amodei, que fala do acrônimo FAAFO (Fast, Autonomous, Ambitious, Fun, and Optionality) que eu traduzi para ADORA (Autonomia, Diversão, Opções, Rapidez e Ambição). Estes são os superpoderes do Vibe Coding que vão mudar a forma como você desenvolve software.

A palestra foi dividida em 5 partes:

1. O que é Vibe Coding?

2. Como a IA impacta carreiras?

3. ADORA - Os Superpoderes do Vibe Coding

4. Loop de Vibe Coding

5. O que pode dar errado?

Neste artigo vou abordar os primeiros 3 e o que você deve aprender com a IA.

O que é Vibe Coding?

Eu começo por definir o que é Vibe Coding porque imagino que cada um tem um conceito diferente na cabeça. E essa confusão se justifica.

Como o próprio livro define:

“Vibe Coding acontece sempre que você está direcionando e não digitando, permitindo que a IA cuide da implementação enquanto você foca em visão e verificação.”

Direcionar é muito diferente da visão que muitos têm de que Vibe Coding é apenas mandar prompts para que a IA eventualmente chegue ao resultado esperado. Essa visão é muito suportada pelo tweet do Andrej Karpathy que introduziu o termo:

“Existe um novo tipo de programação que eu chamo de ‘Vibe Coding’, onde você se entrega completamente à vibe, abraça exponenciais e esquece que o código sequer existe. [...]”

Se o desenvolvedor “esquece que o código sequer existe”, qual a responsabilidade que ele tem sobre esse código?

E o tweet vai além:

“Eu ‘Aceito tudo’ sempre, eu não leio mais diffs […]”

E continua:

“O código cresce além da minha compreensão, […]”

Como alguém pode se responsabilizar por algo que ela sequer compreende?

“[…] eu apenas contorno o bug e peço mudanças aleatórias até que ele suma.”

Essa última frase é exatamente a visão de que basta mandar prompts que a IA vai chegar ao resultado esperado em algum momento.

Mas como podemos esperar que isso aconteça se esse resultado esperado não está claro? Se não definimos os padrões de engenharia que devem ser aplicados? Se não criamos procedimentos confiáveis de verificação do resultado produzido pela IA?

A questão gira em torno exatamente da percepção de responsabilidade em torno do termo que descreve o trabalho profissional de geração de software utilizando a IA como ferramenta. E aí começaram a surgir diversos outros termos para tentar definir melhor:

• Prompt Engineering

• AI-assisted Engineering/Programming/Development

• AI-driven […]

• Agentic […]

• Harness […]

• Spec-driven […]

E quando a gente para pra ver a definição de cada um deles, não é muito diferente do que o livro define como Vibe Coding.

Como a IA impacta carreiras?

Uma pergunta que eu tenho ouvido bastante é se a IA vai tornar o desenvolvedor de software obsoleto. E quanto mais eu estudo sobre o assunto, mais eu acredito que isso não vai acontecer.

Mas tornar obsoleto é diferente de impactar e eu acredito que a evolução da IA está impactando não só trabalho do desenvolvedor como qualquer outro trabalho relacionado a conhecimento. O próprio livro do Steve e do Kim fala que se seu trabalho envolve pensar, analisar, criar ou comunicar, ele já está mudando e não tem como voltar atrás.

“A IA está mudando todo trabalho relacionado a conhecimento.”

Muitas das tarefas podem e devem ser delegadas para agentes de IA, mas delegar implementação ≠ delegar responsabilidade. Por mais que boa parte do trabalho seja feito pela IA, as pessoas ainda são responsáveis por ele.

Tem uma frase que eu gosto muito do Dr. Andrew Ng que diz:

“A IA não vai substituir as pessoas, mas talvez pessoas que usam IA vão substituir pessoas que não usam.”

E esse mesmo padrão aconteceu com outras revoluções que aconteceram na tecnologia da informação e outras indústrias:

• Linguagens de alto nível vão matar programadores assembly

• Visual Basic vai substituir programadores profissionais

• Plataformas de low-code vão tornar programadores obsoletos

• etc.

Assisti à palestra “A reality check on AI’s impact on business transformation” do Dilip Krishna na Lead Dev NYC 2025. Foi quando eu conheci o paradoxo de Jevons:

“Baratear ou tornar mais eficiente o uso de um recurso pode levar a uma maior demanda por esse mesmo recurso.”

O recurso que estamos barateando é o software e o que estamos tornando mais eficiente é o programador. Dado que está mais barato, as pessoas vão experimentar mais formas de resolver problemas com software e isso vai gerar mais demanda. Então eu espero que vão existir mais empregos para desenvolvedores, não menos.

Os 5 superpoderes do Vibe Coding

São eles: Autonomia, Diversão, Opções, Rapidez e Ambição. Ou Fast, Autonomous, Ambitious, Fun, and Optionality em inglês.

Autonomia

Tarefas que antes precisavam de colaboração e coordenação intensas entre várias pessoas passaram a ser desempenhadas por uma única pessoa interagindo com agentes de IA.

Diversão

“Vibe coding transforma o seu teclado em uma slot machine. Você puxa a alavanca e receve uma recompensa” — adaptado do livro Vibe Coding

Cada uma dessas recompensas injeta um pouco de dopamina e nos encoraja a puxar a alavanca novamente. Como o ciclo entre enviar o prompt e receber a “recompensa” é curto, ficamos sempre querendo mandar só mais um prompt.

Opções

O Vibe Coding reduz o custo de explorar múltiplas soluções para um mesmo problema ao mesmo tempo.

A opção é um direito de fazer uma decisão no futuro e quando estamos em um cenário de indecisão, evitamos ao máximo tomar decisões com impacto de longo prazo. Isso é exatamente o problema do big design upfront: muitas decisões são tomadas no início de um projeto e à medida que o projeto evolui, elas se tornam cada vez mais difíceis de reverter.

Dado que o Vibe Coding reduz o custo de explorar múltiplas opções, essas decisões podem ser tomadas com mais embasamento. Além disso, o custo de revertê-las também é reduzido.

A assertividade dos modelos é diretamente impactada pelo tamanho do contexto. Isso significa que quanto menor o contexto associado a uma tarefa, mais assertivo o modelo vai ser. Então quanto mais modulares for a sua solução, menor o custo para reverter as decisões e explorar múltiplas opções.

Rapidez

Esse é provavelmente o aspecto do Vibe Coding mais debatido. A sensação de produtividade é real e à medida que vamos tendo boas experiências com a IA, vamos tendo cada vez mais confiança.

Mas velocidade é diferente de eficiência. Principalmente se for na direção errada. Quanto mais rápido se produz código de baixa qualidade, mais rápido se aumenta o débito técnico. Por isso que é importante que o ciclo de verificação seja curto. Para identificar desvios e corrigir a direção.

De acordo com o AI Engineering Report 2026 - The Acceleration Whiplash da Faros que considerou 22 mil desenvolvedores em 4 mil times, o code churn (quantidade de linhas excluídas em relação às adicionadas) cresceu 861%.

Outro problema de aumentar a velocidade de geração de código é que de acordo com a teoria das restrições, cada sistema tem pelo menos um gargalo. E o mesmo report indica que o gargalo migrou para a revisão de código que está levando em média 199% mais tempo. Isso é potencializado pelo aumento da quantidade de código sendo gerado por IA. O tamanho médio dos PRs cresceu em 51%, demandando cada vez mais engenheiros revisando código.

Ambição

“Vibe coding altera o espectro do que é possível ser construído.” — adaptado do livro Vibe Coding

A definição do que pode ser construído está muito relacionada com o ROI (Retorno sobre o investimento). O ROI é definido por:

Como já vimos, o Vibe Coding reduz o custo de construção. O ROI é inversamente proporcional ao custo, então quanto menor o custo, maior o ROI.

Tarefas que antes se acumulavam no backlog começam a parecer mais viáveis. O que geralmente ficava pro fim da priorização como documentação, testes, pequenas melhorias e refatorações ganha prioridade.

Aprendendo com a IA

Em primeiro lugar, precisamos entender que a área de tecnologia exige aprendizado constante. Ter uma rotina de leitura, pessoas que produzem conteúdo confiável e fontes seguras de informação são extremamente importantes. O importante é estar sempre buscando aprender.

Uma boa forma de aprender também é questionar os motivos da IA ter escolhido as soluções que ela escolheu. Geralmente pedir referências ajuda a IA a lhe dar formas de verificar as respostas. Isso pode levar a dois caminhos:

• A IA pode identificar que se enganou

• ou você vai aprender com ela com base em referências confiáveis

Por falar em verificação, essa é uma parte da interação com a IA que eu acredito que precisamos ter atenção especial. Se conseguirmos ser eficazes na verificação e no controle do que a IA produz, podemos nos beneficiar cada vez mais dela.

A mágica acontece quando a IA consegue observar, executar e validar o seu próprio trabalho.