Um Engineering Manager abre três painéis para responder a uma pergunta que o board fez de manhã: o quanto a IA está ajudando o time. O primeiro dá um número. O segundo dá outro. O terceiro não bate com nenhum dos dois. Os três dizem medir “uso de IA”, e cada um definiu isso à sua maneira. No fim do dia, a resposta que sobe é honesta no tom e frágil no dado: a gente sente que está ajudando.

Fomos atrás dessa cena conversando com líderes de engenharia, para ouvir onde a medição dói de verdade. Um padrão se repetiu, mesmo entre empresas de contextos bem diferentes: quando os números de ferramentas diferentes não batem, a primeira coisa que se perde é a confiança em qualquer um deles.

Por que essa conta ficou urgente agora

Usar IA para escrever código deixou de ser novidade. Um levantamento da Pragmatic Engineer de 2025 aponta que 85% dos desenvolvedores já usam essas ferramentas no trabalho. A adoção já é grande. O que mudou foi o preço da pergunta seguinte. Token custa, licença custa, e o orçamento de IA virou linha que alguém acima do EM quer ver justificada. Quando o custo aparece, “a gente acha que ajuda” para de ser resposta suficiente.

E essa dificuldade não é de um time só. Num levantamento da LeadDev feito com a DX, ouvindo mais de 880 líderes de engenharia, a falta de métricas claras aparece entre os maiores desafios de quem adota IA. O EM que trava na hora de justificar está diante de um problema estrutural, não de um lapso pessoal.

Medir IA é novo para o setor inteiro, inclusive para as ferramentas

Duas camadas costumam cair no mesmo balde. Vale separá-las.

Nas métricas clássicas de engenharia (fluxo de entrega, tempo de ciclo, cobertura de teste, change failure rate), o mercado ao menos concorda sobre o que medir. Existe uma linhagem de mais de uma década, de DORA a SPACE, e ferramentas construídas em cima disso. Dá para discutir o número, mas a definição é compartilhada, e é ela que deixa o número comparável de um mês para o outro.

Na camada de IA, não existe nem esse consenso. Falta acordo sobre o que conta como “uso de IA”, “produtividade com IA” ou “qualidade do que a IA escreveu”. E isso não é só percepção de campo. Ao mapear como 18 grandes empresas de tecnologia medem o impacto da IA, a DX encontrou empresas parecidas, do porte de Microsoft e Google, medindo coisas diferentes, sem uma prática única que sirva de referência. Se quem tem times enormes e orçamento de sobra ainda está experimentando, o EM de um time menor não está atrasado. O terreno é novo para o setor inteiro ao mesmo tempo.

Some a isso um agravante herdado: medir produtividade de engenharia já era um problema não resolvido antes da IA. O setor discute isso há mais de uma década sem chegar a uma métrica única e confiável, e a IA chegou sobre um terreno que já estava instável.

O que essas métricas estão contando

Se a definição não é compartilhada, cada ferramenta preenche a lacuna do seu jeito. E aqui aparece a parte que os líderes menos gostam de admitir: o número que você recebe é o número que o fornecedor consegue medir. Um líder do Monzo colocou isso de forma direta ao Pragmatic Engineer, dizendo que o fornecedor mede o que dá, e é esse o número que chega até você.

O que quase todas essas ferramentas conseguem medir é a mesma coisa: o anel em volta do código. Uso da ferramenta, sugestões aceitas, sessões, tokens, teclada. Sinais de atividade, capturados da telemetria do editor ou do plugin. São baratos de instrumentar e, por isso mesmo, cada um recorta do seu jeito, o que explica por que a mesma métrica sai com valores distintos conforme a origem. Enquanto a conta olhar a atividade, ela vai continuar sem convergir, porque atividade é justamente a parte que cada fornecedor define como quiser.

E atividade responde à pergunta errada. O board não pergunta o quanto a IA foi usada. Pergunta o que ela deixou no produto. Esse sinal está num lugar diferente do anel de telemetria: está no que o time de fato entregou e com que qualidade, no código que foi mergeado e ficou de pé. Um artefato é mais difícil de recortar do que uma métrica de uso: ele é aquilo que ficou pronto.

Há ainda o reflexo mais antigo do mercado: na falta de uma definição boa, corre-se para a métrica fácil. Foi assim que a indústria voltou a se fixar em linhas de código e em “percentual de código escrito por IA”, números que rendem boa manchete e quase nada de leitura sobre qualidade ou resultado. “Percentual de código escrito por IA” é o retrato acabado disso: conta o volume que a IA gerou, sem uma palavra sobre se aquilo prestava.

A armadilha da taxa de aceitação

A taxa de aceitação de sugestões é o exemplo mais puro de contar o anel, e por isso vem perdendo espaço. Laura Tacho, CTO da DX, resume a armadilha numa pergunta: estamos confundindo atividade de IA com impacto de IA? A aceitação olha o instante em que a sugestão aparece e ignora o que vem depois: se o código se manteve, se foi revertido, se introduziu um bug. Ela registra que a IA foi usada. O que a IA deixou no fim fica de fora. Um número que sobe sem dizer se as coisas melhoraram não sustenta decisão, por mais preciso que pareça na tela.

O feeling não fecha a conta

Se o dado das ferramentas é frágil, a saída natural do EM é confiar na percepção do time. Aqui mora a última armadilha. Num experimento controlado do METR, no começo de 2025, desenvolvedores experientes trabalharam em repositórios que conheciam bem, metade das tarefas com IA liberada, metade sem. Eles se sentiram cerca de 20% mais rápidos usando IA. Na medição, levaram cerca de 19% mais tempo. O próprio METR trata o resultado como o retrato de um momento específico e já publicou números mais novos depois. O que interessa aqui é o descompasso, não a direção do efeito: a percepção, mesmo de quem está com a mão no código, é um instrumento pouco confiável para dizer se a IA está ajudando.

Painel e feeling falham pela mesma razão. Os dois olham a atividade: o painel pela telemetria, o feeling pela impressão de quem trabalhou. Nenhum dos dois olha o resultado que ficou. Medir mal não empurra para largar a medição. Empurra para mover a régua da atividade para o resultado.

Medir o quê, já que medir bem é difícil

A medição de IA vai continuar imperfeita por um bom tempo. O consenso não chega amanhã, e cada ferramenta vai seguir com o seu recorte. Quem lidera engenharia não vai escolher a medição perfeita. Vai escolher que pergunta vale a pena perseguir enquanto o consenso não vem.

Perseguir o uso é perseguir um número que sobe sozinho e não diz nada sobre o produto. Perseguir o resultado, o que o time entregou e com que qualidade depois que a IA entrou, é uma pergunta mais difícil de responder e a que o board de fato faz. A diferença entre um time que sabe conversar sobre IA com a liderança e um que responde no feeling costuma estar aí, em qual das duas perguntas ele decidiu levar a sério.

É esse o problema que a gente investiga no WeLuvCode: enxergar, direto do código, o que o time entrega e com que qualidade, a partir de uma definição estável de onde os números vêm, para que a evidência sirva a quem decide sem virar mais um painel para comparar. Ler o impacto da IA nesse mesmo eixo é uma frente que estamos construindo. Seria bom ouvir como outros times de engenharia estão lidando com isso à medida que a adoção amadurece.

Conheça o WeLuvCode

Todo desenvolvedor que adotou IA vai dizer, com razão, que ele ficou mais rápido. E o painel vai concordar: mais atividade, mais entregas, mais velocidade. Ainda assim, quando a liderança medir o que de fato chegou à produção, do commit ao deploy, a entrega do time anda quase no mesmo ritmo de um ano atrás.

Essa distância entre a aceleração que se sente e a entrega que não se move é um dos assuntos mais mal compreendidos da engenharia neste momento: velocidade local, o ganho do desenvolvedor sozinho, não é a mesma coisa que velocidade sistêmica, o ganho no fluxo de entrega do time inteiro. A primeira subiu, e muito. A segunda, quase nada. Entender esse fenômeno é determinante para transformar a adoção de IA em resultado.

O ganho é real, e mais estreito do que parece

Vale começar reconhecendo: o ganho existe, e é grande onde as condições ajudam. Analisando dezenas de milhares de engenheiros, a pesquisa citada pelo DORA de 2026 encontrou de 35 a 40% de ganho de produtividade em tarefas greenfield, código novo e simples. O problema é o outro lado do mesmo dado: em base legada e complexa, o ganho desaba para 10% ou menos. E é na base legada que mora a maior parte do trabalho real de praticamente todo time maduro.

Há aí um detalhe contra-intuitivo que diz muito sobre a natureza do ganho. Os desenvolvedores mais experientes tendem a extrair mais da IA que os juniores, não menos. Isso diz muito sobre capacidade de julgamento: saber o que pedir, reconhecer quando a resposta está errada, onde encaixar o trecho gerado num sistema que já existe. Ou seja, a parte que a IA acelera de verdade nunca foi escrever código, foi o entorno. E é exatamente no entorno que o ganho individual começa a se perder antes de chegar ao time.

No caminho até a entrega, o ganho evapora

O DORA descreve bem o primeiro motivo de perda: a fricção não desaparece, ela muda de lugar. O esforço que você economiza deixando a IA escrever o boilerplate reaparece como esforço de auditar um código que se parece muito com um código correto sem necessariamente ser. É o que o relatório chama de verification tax. Ler e validar com rigor algo plausível cansa mais que escrever do zero, porque o erro não salta aos olhos, ele se esconde.

A expectativa natural é que esse custo diminua à medida que o time ganha experiência com a ferramenta. Os dados mostram o contrário. Quando a Anthropic mediu como as pessoas de fato supervisionam agentes de IA no dia a dia, encontrou um padrão que, à primeira vista, parece paradoxal: quanto mais experiente o usuário, mais ele passa a aprovar automaticamente as ações e, ao mesmo tempo, com mais frequência ele interrompe o agente. A supervisão não some com a maturidade. Ela muda de forma: de aprovar cada passo para monitorar e intervir no ponto correto. A Anthropic lê isso como supervisão saudável. Mas é a mesma moeda pela outra face: supervisão eficaz tem preço, e é esse preço que o verification tax nomeia. O custo de verificar não desaparece porque o time amadureceu. Ele deixa de aparecer como aprovação manual e passa a se manifestar como atenção contínua.

O segundo motivo de perda que o DORA apresenta está associado ao throughput: o time passa a gerar código mais depressa do que as etapas seguintes conseguem absorver: revisão, teste, aprovação de mudança, deploy. O ganho individual chega à esteira, forma fila e quem paga essa conta é o fluxo inteiro. Cada desenvolvedor acelerou a vazão individual, mas o gargalo virou o pipeline. Velocidade local vira estoque parado, não entrega mais rápida.

Por trás desses dois motivos que levam à perda dos ganhos da adoção de IA, há uma crença de fundo que alimenta os dois: a de que engenharia de software seria o terreno seguro para delegar à IA, porque o resultado é verificável, bastando rodar o código e ver se funciona. É algo que a própria pesquisa da Anthropic reflete, ao tratar a testabilidade do software como aquilo que torna mais fácil a confiança no agente nessa área do que em outras, como direito, medicina ou finanças.

O DORA complica esse raciocínio, e é uma complicação que reconhecemos na prática. “Passar no teste” não é “estar estruturalmente correto”. Um código gerado por IA pode compilar, passar no CI e ainda assim falhar em arquitetura, manutenção ou integração com o resto da base. O teste verde é o disfarce perfeito: dá a sensação de que a tarefa está concluída, e o verification tax passa sem ser notado. Ou seja, a verificabilidade que supostamente torna o software seguro para delegar é precisamente onde o custo se esconde.

O custo que ninguém orçou

Perder o ganho no caminho já seria problema suficiente. Mas há um efeito pior: parte do que foi produzido volta como custo. Quando o DORA mediu o efeito da IA sobre dez dimensões de engenharia, o maior avanço veio, como se esperava, na efetividade individual. Mas o efeito sobre o throughput do time, a vazão real de entrega, foi quase nulo. E o segundo maior efeito de todos foi negativo: aumento de instabilidade. Mais falha em produção, mais tempo consertando.

É o que se pode chamar de instability tax. O sistema ficou mais rápido para produzir e, na mesma medida, mais rápido para quebrar. Com isso, o tempo gasto estabilizando toma de volta parte do ganho que cada desenvolvedor jurava ter entregue. Some verification tax, fila no pipeline e instabilidade, e você tem a anatomia completa de como um ganho individual de 35% chega perto de zero na conta do time.

O que muda para quem lidera

A primeira consequência prática dessa leitura é parar de tratar velocidade local como se fosse velocidade sistêmica. Tempo economizado por desenvolvedor, sugestões aceitas, PRs por semana, tudo isso é sinal local, e sobe mesmo quando a entrega do time não anda. A pergunta que interessa é outra: o fluxo inteiro, do commit à produção, ficou mais rápido sem ficar mais instável?

A segunda é contar com a queda antes da subida. A adoção de IA costuma desenhar uma curva J: uma perda temporária de produtividade enquanto o time aprende a ferramenta, ajusta o pipeline e paga o verification tax, seguida de recuperação. No modelo do DORA, o vale dura algo como três meses. Esse vale é o custo de matrícula da transformação, não o veredito dela. Quem lê o vale como fracasso corta o investimento pouco antes da virada e, aí sim, garante o fracasso.

Mas há uma armadilha: a subida da curva J não é automática. Costuma-se vender como promessa: desce e sobe. Não é. A recuperação depende inteiramente do sistema em que o vale acontece.

Num sistema maduro, o vale vira recuperação e o ganho individual finalmente se converte em velocidade de time. Num sistema caótico, o mesmo vale pode nunca virar subida. A linha pode seguir descendo, com a IA apenas acelerando a deterioração. A curva J não é um direito adquirido de quem adota IA. É o resultado que só um sistema saudável entrega.

O que nos leva ao achado mais honesto do DORA: a IA não gera valor, ela amplifica o sistema em que cai. Um sistema maduro transforma o ganho individual em velocidade de time. Um sistema caótico transforma o mesmo ganho em caos mais rápido.

E não é só o DORA que aponta para lá. A Anthropic chegou a uma conclusão parecida por outro caminho: ao medir como a autonomia dos agentes cresce na prática, encontrou que ela sobe de forma gradual e não acompanha os saltos de capacidade dos modelos. Quem determina a autonomia não é o modelo, é o sistema em que ele opera.

Duas pesquisas, por caminhos opostos, uma medindo entrega e outra medindo autonomia, chegam ao mesmo destino: o que decide o resultado não é a ferramenta, é o sistema que a cerca.

Descobrir em qual dos dois sistemas você está não se faz olhando o desenvolvedor. Se faz medindo o sistema. É esse o trabalho ao qual nos dedicamos no WeLuvCode.

Conheça o WLC

Toda operação que aceita transações tem um porteiro. Obviamente, o banco tem, mas o e-commerce também tem, e a seguradora, o marketplace, a plataforma de mobilidade, a operadora de telecom. Em todos eles existe um ponto onde alguém — ou alguma coisa — decide se aquela transação passa ou não. O que mudou, ao longo do tempo, foi a forma como esse porteiro aprendeu a decidir.

No começo ele era um segurança com uma prancheta de rostos procurados: conferia cada pessoa contra uma lista fixa e barrava quem aparecia nela. Depois, já um segurança mais experiente, que já viu milhares de pessoas passarem, ele aprendeu a reconhecer, pelo jeito de cada um, quem parece suspeito — mas ainda com base no que já viu antes. Em seguida, ele deixou de ser um porteiro e virou uma equipe: investiga, cruza informações, faz perguntas e toma decisões por conta própria.

A pergunta que este texto quer provocar é simples: em qual dessas gerações a sua operação realmente está? A resposta quase nunca é a que o time de tecnologia gostaria de dar.

As duas primeiras gerações, em rápida retomada

Se você leu a primeira parte desta série, já conhece o essencial dos dois primeiros degraus — sinta-se à vontade para pular direto para a próxima seção.

A primeira geração é a das regras. O marco é o FICO Falcon, de 1992: uma rede neural detectando fraude de cartão em tempo real, mas ancorada, como a própria FICO descreve, em padrões de fraude conhecidos. Regra é barata, é determinística e é explicável — e continua insubstituível para o que é conhecido e estável. Seu teto é igualmente claro: ela não enxerga o que ainda não tem nome.

A segunda geração é a do machine learning supervisionado, que a partir dos anos 2010 troca a codificação manual de regras pelo aprendizado de padrões a partir de dados rotulados. É um salto real, mas ele carrega um limite herdado: um modelo supervisionado aprende com fraude confirmada e, por construção, está sempre uma geração atrás do fraudador. A análise comportamental — detecção de anomalia não-supervisionada, com métodos como o Isolation Forest — é o auge dessa segunda geração e a antessala da terceira, porque começa a mudar a pergunta de: “esse padrão é fraude conhecida?”, para: “esse comportamento foge do normal desta conta?”.

O ponto que interessa aqui não é reviver esse histórico, e sim notar uma coisa sobre a forma dele: cada geração não apagou a anterior, ela foi um incremento.

O movimento maior que chegou ao antifraude

Antes de seguir, é preciso destacar que a lógica de “especificar regras, aprender com dados e delegar julgamento a um sistema autônomo” não é uma peculiaridade do antifraude. É a forma como praticamente toda disciplina de automação amadurece. Antes de ser uma história sobre fraude, essa é uma história sobre automação.

O desenvolvimento de software vive isso agora, ao migrar de escrever instruções explícitas para descrever a intenção e deixar que a máquina preencha o “como”.

Em todas essas disciplinas, o movimento é o mesmo: sobe-se um degrau de abstração, transferindo para o sistema uma parcela maior de decisão. Antifraude está subindo exatamente esse degrau, e é isso que a terceira geração representa.

E é olhando desse degrau que a terceira geração do antifraude precisa ser entendida. É também onde o discurso de mercado costuma ficar mais barulhento e menos preciso, então convém definir com cuidado o que de fato muda da segunda para a terceira geração que é, fundamentalmente, o que acontece depois que o sistema chega a uma conclusão.

Terceira geração: de sinalizar para agir

As gerações anteriores focaram em pontuar e sinalizar: calcular um score, produzir uma recomendação, disparar um alerta, deixando a decisão para um humano. Um sistema agêntico não para nesse ponto: ele percebe, raciocina, decide e age por conta própria, sem esperar aprovação a cada passo. É essa passagem, do sinalizar para o agir, que redefine o problema.

A própria FICO define IA agêntica de forma sóbria: sistemas que percebem dados, raciocinam sobre eles, decidem e agem sem intervenção humana em cada etapa; e faz questão de posicionar a IA generativa como copiloto do analista, que reduz carga cognitiva e acelera investigação sem substituir o julgamento de um profissional experiente.

Ou seja, a FICO não faz um discurso de substituição, mas de alavancagem. E já existe implementação concreta: a Nasdaq Verafin descreve seu analista agêntico como uma mudança de “IA como ferramenta” para “IA como trabalhador”, capaz de percorrer sozinho o fluxo investigativo de um alerta.

Na mesma linha, a Enrst & Young, aponta que “IA agêntica permite monitoramento em tempo real e aprendizado adaptativo, analisando transações de forma autônoma e refinando a detecção, com redução significativa de falsos positivos”.

Até aqui, parece só progresso. O contrapeso honesto vem agora. Em nossa experiência implantando soluções de antifraude nos clientes da Duranium, aprendemos que autonomia sem três condições não é ativo, é passivo.

A primeira é o dado. Um agente que decide sozinho amplifica a qualidade — ou a pobreza — dos dados que o sustentam. Autonomia sobre dado ruim apenas erra mais rápido e em maior escala.

A segunda é explicabilidade. No momento em que o sistema age em vez de sugerir, alguém vai perguntar por quê. Um agente que não sabe explicar por que agiu é um risco jurídico esperando para acontecer. Setores regulados sentem isso primeiro e com força — no mercado financeiro brasileiro, por exemplo, o arcabouço em torno da Resolução BCB nº 538 deixa explícita a exigência de gestão e prestação de contas sobre decisões de risco. Mas isso não é um problema só de banco: qualquer operação cujo sistema bloqueie um cliente, negue uma apólice ou cancele uma conta vai precisar justificar a decisão, seja para o cliente, para o jurídico, para o mercado.

A terceira é governança. Quando o porteiro-equipe age sozinho e erra, quem responde? A pergunta não é retórica. Delegar decisão a um sistema autônomo é também delegar responsabilidade, e essa parte não pode ser terceirizada para o algoritmo.

Instalar um agente não é chegar à terceira geração

Daí decorre o erro mais comum de quem quer pular etapas. Instalar um componente agêntico não coloca ninguém na terceira geração se as camadas de baixo não estiverem maduras.

A evolução é cumulativa: o agente que raciocina depende do modelo que aprende, que depende do dado bem rotulado, que depende da regra bem desenhada. Pular a base não acelera a chegada à fronteira — só produz uma automação confiante e cega.

É por isso que vale enunciar o princípio que atravessa toda a série: uma geração mais avançada alimentada por dado ruim é pior do que uma geração anterior alimentada por dado bom. A conversa sobre “qual geração de IA você usa” quase sempre deveria ser, antes, uma conversa sobre a qualidade e a origem do dado que sustenta qualquer uma delas — um tema que merece um capítulo próprio.

O que já é produto e o que ainda é fronteira

Se uma geração avançada depende da qualidade das camadas anteriores, o primeiro passo é reconhecer onde a operação está de fato. Essa distinção é importante para separar maturidade real de promessa de mercado.

Na Duranium, a leitura é que a terceira geração só faz sentido quando as camadas anteriores estão bem resolvidas. Por isso, o FraudGate opera solidamente na segunda geração, e de forma madura: combina uma camada determinística — regras duras, listas e limites que o cliente ajusta em tempo real — com uma camada comportamental probabilística, calibrada com rigor sobre o eixo de falsos positivos e falsos negativos (FAR/FRR) e desenhada para a realidade transacional brasileira.

A camada agêntica é, para a Duranium, direção de pesquisa e visão de mercado — investigada internamente sob o nome Autopilot —, não um recurso pronto de prateleira. Dizer o contrário seria vender a fronteira sem ter atravessado a ponte que leva até ela.

É essa a pergunta que vale levar para dentro de qualquer operação, dentro ou fora do setor financeiro: o debate útil não é “você já tem IA agêntica?”. É “as suas camadas de baixo — regra, modelo, dado — estão maduras o suficiente para sustentar a próxima geração?”. Quem responde a essa pergunta com sinceridade descobre em que degrau realmente está.

Quer mapear em qual geração sua operação está de fato? O time de antifraude da Duranium conduz assessments de maturidade que traduzem exatamente isso: onde estão suas regras, seus modelos, seus dados — e o que falta para sustentar o próximo degrau. Fale com a gente.

Fontes

• FICO — Falcon Fraud Manager e The Future of Fraud Protection: From Platforms to Agentic AI (fico.com): marco histórico do Falcon (1992) e definição sóbria de IA agêntica e generativa em antifraude.

• Liu, F. T.; Ting, K. M.; Zhou, Z. H. (2008). Isolation Forest. IEEE ICDM — detecção não-supervisionada de anomalias.

• Nasdaq Verafin — materiais sobre Agentic AI Workforce (verafin.com): IA agêntica em produção e o conceito de “IA como trabalhador”.

• EY — The rise of agentic AI: transforming fraud risk management (ey.com): monitoramento autônomo e redução de falsos positivos por aprendizado contínuo.

• Banco Central do Brasil — Resolução BCB nº 538 (referência ilustrativa ao peso regulatório sobre gestão e prestação de contas de decisões de risco).

Compartilhar

Existe uma pergunta que toda liderança de engenharia de software precisa se fazer com frequência: o que estamos entregando é realmente bom?

Quando volume ainda significava maturidade

Por anos, essa pergunta foi respondida de forma indireta, olhando para a velocidade: deploys frequentes, ciclos curtos, alto volume de pull requests e aumento de throughput costumavam ser sinais de um time saudável.

Essas métricas nunca foram uma medida perfeita de qualidade, mas funcionavam como indicadores razoáveis em um contexto no qual esforço humano e volume de entrega ainda caminhavam relativamente próximos.

Até pouco tempo atrás, quando a escrita do código dependia quase inteiramente do trabalho humano, havia uma relação mais estável entre o trabalho produzido e o cuidado necessário para produzi-lo. Um time que entregava mais, com ciclos menores e frequência constante, provavelmente tinha processos mais maduros, menor fricção e boa capacidade de execução. O volume não dizia tudo, mas ajudava a interpretar a saúde da engenharia.

O que a IA generativa mudou

A adoção de IA generativa mudou essa relação.

Hoje, um desenvolvedor apoiado por um agente consegue abrir múltiplos PRs em poucos minutos. O painel pode registrar mais atividade, mais entregas e mais velocidade, sem que isso represente, necessariamente, uma base de código mais saudável. O que antes era uma pista razoável de maturidade agora passou a capturar também a intensidade de uso da ferramenta.

Essa mudança cria um problema importante para quem lidera engenharia: as métricas tradicionais continuam subindo, mas parte delas deixa de responder à pergunta central sobre qualidade. Elas mostram que mais coisas estão sendo produzidas. Não mostram, sozinhas, se essas coisas melhoram ou deterioram o sistema.

O que o relatório DORA de 2026 revela

O relatório DORA de 2026 ajuda a enxergar a amplitude desse descompasso. Ao medir os efeitos da adoção de IA sobre diferentes dimensões de engenharia, o estudo identificou um ganho relevante na efetividade individual do desenvolvedor. Esse resultado é esperado: a IA ajuda a escrever, completar, revisar e acelerar partes do trabalho.

O ponto crítico está em outro efeito detectado pelo relatório: um aumento expressivo na instabilidade da entrega.

Ao mesmo tempo em que a IA torna cada pessoa mais rápida, a qualidade do código e o throughput do time apresentam ganhos limitados, aumentando o risco de instabilidade no sistema. O resultado é um descompasso: o processo acelera sem que aquilo que realmente importa melhore na mesma proporção.

Onde a fricção foi parar

Isso não significa que a IA seja ruim para engenharia. Significa que ela muda o lugar onde a fricção aparece. Parte do esforço economizado na escrita do código passa a ser gasto na validação de um código que parece correto, compila, passa em testes automatizados, mas ainda pode falhar em aspectos importantes de arquitetura, negócio, manutenção ou integração com o restante da base.

Esse efeito também não se distribui de maneira uniforme. Em códigos novos e simples, os ganhos de produtividade podem chegar a 35% ou 40%. Em bases legadas, com dependências acumuladas, decisões antigas e maior complexidade estrutural, esse ganho pode cair para 10% ou menos.

A leitura superficial dos indicadores tende a mostrar uma melhora geral. Os indicadores do painel ficam todos verdes, mas a realidade por baixo desses números é mais fragmentada. Em alguns contextos há ganho real. Em outros, há apenas mais produção sobre uma estrutura igualmente frágil.

A decepção por trás dos números verdes

Esse descompasso já aparece na percepção executiva. Em uma pesquisa recente conduzida pela Writer em parceria com a Workplace Intelligence, quase metade dos executivos relatou decepção relevante com o retorno do investimento em IA, em um movimento que cresceu de forma consistente de um ano para o outro.

O padrão é compreensível. Os indicadores tradicionais mostram aumento de atividade, mas quem opera os sistemas percebe mais retrabalho, mais revisão, mais dúvidas sobre o que foi realmente resolvido e mais dificuldade para separar velocidade real de produção inflada. Quando isso acontece, a liderança perde clareza sobre a pergunta mais importante: a engenharia está entregando melhor ou apenas entregando mais?

Métricas que medem consequência, não atividade

A resposta não está em abandonar métricas. Métricas continuam sendo fundamentais para entender fluxo, gargalos, previsibilidade e capacidade de entrega. O problema está em tratar métricas de volume como se fossem evidência direta de qualidade.

Alguns indicadores continuam úteis justamente porque medem consequências, não atividade. Falhas em produção, tempo de recuperação, volume de retrabalho e recorrência de incidentes dizem mais sobre o efeito real das entregas do que a simples contagem de PRs, deploys ou linhas de código.

Um defeito que chega ao ambiente de produção é um fato concreto, independentemente de ter sido escrito por uma pessoa ou gerado com apoio de IA.

O tempo necessário para recuperar um sistema depois de um incidente também revela algo importante sobre a compreensão da base, a robustez da arquitetura e a capacidade do time de operar aquilo que constrói.

O retrabalho segue a mesma lógica. Quando um código precisa ser refeito logo depois de ser considerado pronto, existe uma diferença entre produção aparente e entrega real. Esse cenário tende a se tornar mais frequente quando o código gerado com IA resolve o sintoma imediato, mas não considera adequadamente o contexto do sistema ou o objetivo de negócio. Por isso, a pergunta sobre qualidade precisa ir além da contagem.

O teste que separa atividade de qualidade real

Uma forma simples de testar uma métrica é perguntar se um agente de IA conseguiria inflar aquele número sem de fato gerar melhorias. Se a resposta for sim, a métrica ainda pode ter valor operacional, mas não deve ser lida como prova de qualidade.

Isso vale para número de PRs, linhas de código, volume de commits e até frequência de deploys. Esses indicadores ajudam a entender movimento. Não bastam para entender saúde. Para avaliar qualidade, é preciso observar o conteúdo do que foi entregue.

Imagine dois PRs com o mesmo cycle time, ambos aprovados no CI e registrados da mesma forma no painel. No primeiro, o desenvolvedor entendeu a causa raiz de um bug e corrigiu o problema na origem. No segundo, um agente de IA tratou apenas o sintoma, adicionou mais linhas de código, acoplou uma nova dependência e não criou testes capazes de validar o cenário de risco.

Pelas métricas de fluxo, os dois PRs podem parecer equivalentes. Em alguns casos, o segundo pode até parecer mais produtivo, simplesmente por gerar mais código. A diferença real aparece quando alguém analisa o conteúdo da entrega: um PR reduziu risco e melhorou a base; o outro apenas deslocou o problema para o futuro.

Esse é o tipo de distinção que a contagem não consegue fazer sozinha. Ela exige leitura do código, da arquitetura, dos testes, das dependências e dos efeitos acumulados sobre a base.

Ler o conteúdo significa observar sinais que nem sempre viram número de forma automática: aumento de acoplamento, duplicação de lógica, crescimento de complexidade, ausência de testes em áreas críticas, dependências mal introduzidas e soluções que resolvem o caso imediato sem preservar a qualidade estrutural do sistema.

Esses sinais ajudam a responder uma pergunta diferente daquela respondida pelas métricas de fluxo. O fluxo mostra como o time entrega, onde trava e com que velocidade avança. A leitura do conteúdo mostra o que está sendo acumulado na base a cada entrega, independentemente da velocidade.

As duas dimensões são necessárias. Sem métricas de fluxo, a liderança perde visibilidade sobre ritmo, previsibilidade e gargalos. Sem leitura do conteúdo, ela pode confundir atividade com evolução. O risco, na era da IA, é deixar que um dashboard cheio de sinais positivos esconda uma base de código que está ficando mais frágil.

Por que criamos o WeLuvCode

Foi a partir dessa leitura que criamos o WeLuvCode.

O WeLuvCode integra métricas de fluxo, extraídas do histórico do Git, com análise semântica do conteúdo do código. A proposta é oferecer à liderança uma visão que conecte velocidade de entrega com impacto estrutural sobre a base.

Na prática, isso permite identificar situações em que o cycle time caiu, mas o acoplamento nos módulos alterados aumentou na mesma proporção. Também permite observar quando uma sequência de PRs acelerou o fluxo, mas elevou complexidade, duplicação ou risco de manutenção em partes importantes do sistema.

Em outras palavras, o WeLuvCode mostra se a velocidade veio com um custo estrutural. Algo que nenhum dos dois indicadores mostraria sozinho.

Esses sinais, vistos isoladamente, podem passar despercebidos. A queda no cycle time sugere ganho de eficiência. O aumento de acoplamento sugere perda estrutural. Quando os dois aparecem juntos, a liderança consegue enxergar o custo real da velocidade.

E não se trata de uma foto pontual, mas de uma leitura contínua e automatizada. O WeLuvCode realiza uma leitura contínua e acompanha a evolução da base a cada nova entrega. Isso permite observar tendências, identificar deterioração progressiva e entender como decisões de curto prazo afetam a saúde do código ao longo do tempo.

Conheça o WeLuvCode

Nossa própria experiência com IA em escala

Sobre essa fundação, estamos construindo uma camada adicional voltada especificamente para o uso de IA na engenharia. O objetivo é entender quanto do código já é assistido por ferramentas de IA generativa, qual é o custo desse uso e que nível de qualidade ele produz.

Essa convicção vem da nossa própria experiência. A Duranium é parceira oficial da Anthropic e implementa IA aplicada à engenharia no dia a dia.

Convivendo de perto com código gerado em larga escala, ficou claro que medir apenas adoção, volume ou velocidade seria insuficiente. A pergunta relevante não é apenas quanto a IA está sendo usada, mas o que ela está produzindo para a saúde da base.

O WeLuvCode nasce desse aprendizado: medir fluxo continua importante, mas a liderança também precisa ler o conteúdo do que está sendo entregue.

Da contagem ao entendimento

Para quem lidera engenharia, a recomendação não é descartar frameworks como DORA ou SPACE. Eles continuam úteis para entender desempenho, fluxo e operação. O ponto é complementar essas métricas com uma camada capaz de avaliar qualidade estrutural.

A relação histórica entre volume e valor ficou menos confiável. Com IA, um time pode produzir mais sem necessariamente melhorar o sistema. Pode reduzir cycle time e, ao mesmo tempo, aumentar retrabalho. Pode elevar o número de entregas e acumular dívida técnica silenciosa.

A liderança que quiser avaliar o impacto real da IA na engenharia precisará olhar para além da atividade gerada. Será necessário conectar fluxo, consequência e conteúdo: o que foi entregue, como isso afetou a base e quais sinais indicam melhora ou deterioração ao longo do tempo.

No fim das contas, quem vai saber se a IA está ajudando o time ou deteriorando a base de código em silêncio é quem parou de contar o que a engenharia produz e começou a entender o que cada entrega muda no sistema.

Imagine um segurança parado na porta de um prédio, com uma prancheta de rostos de pessoas procuradas na mão. A cada pessoa que chega, ele compara o rosto com a lista. Se bate, barra. Se não bate, deixa passar. É um sistema que funciona muito bem contra reincidentes — quem já foi fichado não entra de novo. Mas ele tem um ponto cego estrutural, e o ponto cego não é uma falha de execução: é a própria definição do método. O segurança não consegue identificar um novo golpista. Quem nunca apareceu na lista atravessa a porta sorrindo.

Por mais de trinta anos, foi assim que a detecção de fraude funcionou: comparando cada transação com um catálogo do que já se sabia ser golpe. Agora imagine esse mesmo segurança diante não de uma fila organizada, mas de uma multidão atravessando a porta ao mesmo tempo, em segundos, sem catraca e sem volta.

Foi exatamente isso que o Pix fez com o mercado brasileiro. Em 2025, o sistema processou 79,8 bilhões de transações — uma média acima de 200 milhões por dia, com pico de mais de 313 milhões em um único dia de dezembro. Cada uma delas é processada em segundos. É nessa multidão, nessa velocidade, que o ponto cego daquele segurança hipotético deixou de ser um detalhe e virou o problema central do antifraude no país.

O limite estrutural: você só detecta o que já tem nome

A disciplina de antifraude nasceu olhando para trás. O marco fundador é de 1992, quando a FICO lançou o Falcon, um sistema de detecção de fraude em cartões baseado em rede neural operando em tempo real. Foi um avanço enorme para a época, e a arquitetura que ele inaugurou ainda domina o mercado: um modelo aprende, a partir de transações historicamente rotuladas como fraude, a reconhecer os padrões que se repetem. Quanto melhor o histórico, melhor a detecção. A própria FICO descreve o Falcon como uma tecnologia que “alavanca padrões de fraude conhecidos” para atingir seus níveis de precisão.

A palavra que importa nessa frase é essa: conhecidos.

Diante disso, a leitura fácil é dizer que o problema é a regra velha e que a solução é simplesmente colocar mais inteligência artificial no lugar. Mas essa é uma falsa oposição.

Vale ser justo com o estado da arte: os grandes fornecedores globais já foram muito além de regras estáticas há tempos — operam camadas robustas de machine learning, biometria comportamental e inteligência de rede. A Feedzai, por exemplo, se posiciona justamente pela capacidade de identificar fraudes novas a partir de desvios de comportamento. O antagonista desta história, portanto, não é “regra contra IA”. Essa é uma simplificação que qualquer pessoa de risco desmonta em trinta segundos.

O limite real é mais sutil e mais profundo, e tem duas camadas.

A primeira é temporal: um modelo supervisionado — por mais sofisticado que seja — aprende com fraude confirmada. Por construção, ele está sempre uma geração atrás do fraudador, porque precisa que um golpe aconteça, seja rotulado e entre no conjunto de treino antes de saber reconhecê-lo.

A segunda é geográfica, e é aqui que a coisa ganha um verniz à brasileira. A inteligência desses fornecedores é calibrada, na maior parte, sobre a realidade transacional de outros mercados — e o catálogo de fraudes do mundo deles não é o nosso.

O golpe que define o Brasil não é o vazamento de cartão à americana. É o falso funcionário do banco que liga pedindo um Pix “de segurança”; é o falso parente no WhatsApp; é o falso boleto e a falsa central de atendimento; é o investimento fraudulento que circula em grupo de mensagens; é a conta-laranja que recebe e repassa o dinheiro em cadeia, em minutos; é a cultura de um pagamento que não tem estorno automático.

Nada disso aparece com a mesma cara — nem com a mesma frequência — em modelos treinados sobre fraude de cartão europeia ou norte-americana.

São esses dois limites somados — o que chega tarde e o que olha para o lugar errado — que abrem a porta para novas modalidades de golpes.

O comportamental detecta o desvio, não o rótulo

Se o nosso segurança segurando a prancheta pergunta: “esse rosto está na lista de procurados?”, o sistema comportamental pergunta outra coisa: “essa pessoa está agindo como o dono desta conta costuma agir?”.

A diferença não é cosmética. É a diferença entre detecção supervisionada — que aprende com exemplos rotulados — e detecção não-supervisionada de anomalias, que não precisa de rótulo nenhum para funcionar.

Ela modela o comportamento normal de cada conta e dispara quando há um desvio relevante daquele perfil, independentemente de aquele tipo específico de fraude já ter um nome.

A literatura técnica sustenta isso de forma sólida. Algoritmos como o Isolation Forest, proposto por Liu, Ting e Zhou em 2008, isolam anomalias explicitamente em vez de modelar laboriosamente o que é “normal”.

Autoencoders fazem algo parecido por outro caminho: aprendem a reconstruir o comportamento típico e tratam o erro de reconstrução como sinal de anomalia.

O ponto que importa para quem decide é este: métodos não-supervisionados têm capacidade comprovadamente superior de detectar ataques desconhecidos, justamente porque não dependem de assinaturas prévias.

Traduzindo para a operação: a camada determinística — regras duras, listas, limites — continua essencial e barata para o que é conhecido e estável. Mas é a camada comportamental, probabilística, que cobre o território onde a fraude ainda não tem nome.

O trabalho fino não está em escolher uma ou outra, e sim em calibrar a fronteira entre as duas — o equilíbrio entre falsos positivos (FAR) e falsos negativos (FRR) que decide se o sistema protege o cliente ou o pune. É nesse ajuste que mora a engenharia de verdade.

O Pix mudou a geometria do problema

Nada disso seria tão urgente se a janela de reação ainda existisse. No mundo do cartão, do boleto, da transferência que levava horas para compensar, havia tempo: dava para detectar depois, estornar, bloquear o saque. A fraude tinha um intervalo onde podia ser interrompida.

O Pix fechou esse intervalo. A liquidação é final e acontece em segundos — não existe, no Pix, o estorno automático que o cartão oferece via chargeback. E a escala torna tudo mais sério: segundo o Banco Central, o sistema movimentou R$ 35,36 trilhões em 2025, cerca de três vezes o PIB do país, com quase 80 bilhões de transações e alcance de praticamente toda a população adulta.

Isso não significa que não exista caminho de volta. O Banco Central criou o MED — Mecanismo Especial de Devolução —, que dá à vítima até 80 dias para contestar uma transação de golpe ou fraude e permite o bloqueio cautelar dos valores na conta de destino.

Mas o MED não é um botão de desfazer: a devolução só acontece se o dinheiro ainda estiver lá.

E os fraudadores sabem disso — esvaziam a conta de destino em minutos, pulverizando o valor por uma cadeia de contas-laranja.

O problema é tão estrutural que o próprio regulador precisou evoluir o mecanismo: o MED 2.0 (Resolução BCB nº 493/2025), obrigatório desde fevereiro de 2026, passou a rastrear o caminho do dinheiro por várias contas justamente porque a recuperação na conta original quase sempre falhava.

A leitura correta, portanto, não é “a transação é irreversível”. É algo incômodo: a recuperação depois do fato é uma corrida contra o relógio na qual, na maioria das vezes, a vítima perde.

A ACI Worldwide diz o mesmo em linguagem técnica — em transações instantâneas não há janela de recuperação confiável, o que torna o monitoramento pós-transação insuficiente por si só. Tudo isso empurra a decisão para o único lugar onde ela ainda faz diferença: os milissegundos antes da liquidação.

E há um tipo de golpe que ataca a velha prancheta no seu ponto mais sensível.

A modalidade que mais cresce nos pagamentos instantâneos é o golpe de pagamento autorizado — o que a ACI chama de “fraude Pix” no Brasil.

Nele não há invasão de conta nem transação tecnicamente anômala: é o próprio cliente legítimo, manipulado por engenharia social, quem autoriza a transferência. Do ponto de vista da credencial, está tudo correto (e por isso o golpe contorna os controles tradicionais). O rosto que chega na porta é o do próprio morador, agindo sob um engano que o sistema não enxerga.

Os números dão a dimensão do estrago: só em 2024, o Banco Central contabilizou R$ 6,5 bilhões em perdas com fraudes envolvendo o Pix, alta de 80% em um único ano.

Há aqui um detalhe que o mercado ainda está digerindo: o próprio MED, criado para proteger a vítima, pode, potencialmente, se tornar uma superfície de ataque. Fraudadores aprenderam a explorar o mecanismo de contestação - como nos golpes que vêm atingindo lojistas que recebem por Pix e, em seguida, têm o pagamento contestado. A Duranium dedicou um whitepaper inteiro a mapear esses vetores de ameaça ao MED 2.0. Mas isso é assunto para outra conversa.

Por que o Brasil virou laboratório de detecção comportamental

Junte os três fatos: volume gigantesco, liquidação final em segundos e um fraudador local criativo, que opera por WhatsApp e engenharia social em vez de invasão técnica. O resultado é um ambiente onde a detecção baseada em fraude conhecida não tem para onde correr — o intervalo de reação que ela pressupõe simplesmente não existe.

Isso coloca o Brasil numa posição incomum. Em vez de importar o problema dos mercados desenvolvidos com cinco anos de atraso, como costumava acontecer, o país chegou primeiro à fronteira. A combinação de pagamento instantâneo de massa com fraude em tempo real é um cenário que Europa e Estados Unidos só começam a viver agora, à medida que seus próprios trilhos instantâneos amadurecem. Quem aprende a detectar comportamento fraudulento no ambiente brasileiro está, na prática, resolvendo um problema antes do resto do mundo.

A fronteira não é reconhecer a fraude. É reconhecer o desvio.

A lição que atravessa tudo isso é simples de enunciar e difícil de implementar: vencer a fraude deixou de ser uma questão de ter o melhor catálogo de fraudes conhecidas. Passou a ser uma questão de reconhecer o desvio de comportamento antes que ele tenha um nome — e de fazer isso na janela de milissegundos antes de uma transação que não volta atrás.

É essa a tese que orienta o FraudGate, a plataforma de antifraude da Duranium. Em vez de tratar regra e comportamento como rivais, ela combina uma camada determinística — regras duras, listas e limites que o cliente ajusta em tempo real — com uma camada comportamental probabilística, calibrada com rigor sobre o eixo FAR/FRR e desenhada para a realidade transacional brasileira, não adaptada a ela depois. A diferença entre os dois projetos é a diferença entre o segurança que confere a prancheta e o que conhece, de fato, quem mora no prédio.

A pergunta que vale fazer dentro da sua operação não é “qual é o nosso melhor modelo”. É outra: quanto da nossa detecção ainda depende de a fraude já ter acontecido antes para que a gente saiba reconhecê-la? A resposta diz onde sua instituição está na fronteira — e quanto da sua exposição mora no ponto cego.

Quer mapear onde sua operação está nessa curva? O time de antifraude da Duranium conduz assessments de maturidade que medem exatamente isso: quanto da sua detecção é reativa ao conhecido e quanto já cobre o comportamental. Fale com a gente.

E aquela outra conversa — sobre o MED virar alvo? Ela já existe. No whitepaper Modelagem de Ameaças ao MED 2.0, a Duranium mapeia, via STRIDE, os vetores que transformam o mecanismo de devolução em superfície de ataque — e o que isso exige das instituições financeiras. Baixe o material.

Fontes

• FICO — Falcon Fraud Manager e Fraud Detection with Machine Learning (fico.com): histórico do Falcon (1992, rede neural, tempo real) e limites da detecção por padrões conhecidos.

• Liu, F. T.; Ting, K. M.; Zhou, Z. H. (2008). Isolation Forest. IEEE ICDM — método fundacional de detecção não-supervisionada de anomalias.

• Feedzai — materiais de produto (feedzai.com): posicionamento de detecção comportamental de fraudes desconhecidas.

• ACI Worldwide / GlobalData — Scamscope Report e materiais sobre pagamentos em tempo real: irreversibilidade dos trilhos instantâneos e golpes de pagamento autorizado (”fraude Pix”).

• Banco Central do Brasil — Estatísticas de Pagamentos e balanço do Pix 2025 (R$ 35,36 tri; 79,8 bi de transações); perdas com fraude no Pix em 2024 (R$ 6,5 bi, +80%).

• Banco Central do Brasil — Mecanismo Especial de Devolução (MED) e MED 2.0 (Resolução BCB nº 493/2025): janela de contestação de 80 dias, bloqueio cautelar e rastreamento do caminho do dinheiro.

• Duranium — Whitepaper: Modelagem de Ameaças ao MED 2.0 (análise STRIDE de vetores de ataque ao mecanismo).

Algo que a indústria vinha evitando dizer em voz alta ficou explícito em dois sinais que aconteceram quase ao mesmo tempo em maio de 2026.

A Microsoft, que investiu cerca de US$ 13 bilhões na OpenAI e escreve perto de 30% do próprio código com IA generativa, pediu, discretamente, que engenheiros de uma divisão importante parassem de usar o Claude Code. Não porque a ferramenta não funcionava. Porque a conta ficou grande demais.

O segundo sinal veio da da Uber alguns dias depois: a empresa havia colocado um agente de codificação nas mãos de cerca de 5.000 engenheiros em dezembro de 2025. Em abril de 2026, o CTO revelou a repórteres que o orçamento anual de IA tinha sido consumido em quatro meses. Engenheiros gastavam entre US$ 500 e US$ 2.000 por mês só em chamadas de API. Adoção em 95%. Setenta por cento dos commits dirigidos por IA. E, ainda assim, o COO da empresa, Andrew Macdonald, admitiu não conseguir traçar uma linha entre esses números impressionantes e valor real para o usuário.

Quem trabalha há tempos com engenharia reconheceu o problema na hora: o número de linhas de código nunca foi um bom indicador do valor do trabalho de engenharia. Gerar mais linhas, mais rápido, não torna o indicador mais confiável; só torna o desperdício mais veloz.

A pergunta que importa, então, deixa de ser “quanto código a IA produz?” e passa a ser “como você governa, mede e prova o retorno desse código?”. E é exatamente aí que entra o framework que o Google publicou recentemente.

Do vibe coding à engenharia agêntica

O paper do Google (”The New SDLC With Vibe Coding“) trata vibe coding e engenharia agêntica não como um sim/não, mas como extremos de um espectro. No “vibe coding”, você descreve o que quer em linguagem natural, aceita o que a IA devolve e, quando algo quebra, cola a mensagem de erro de volta e pede para consertar. Verificação é opcional: roda, parece certo, segue.

Na outra ponta, a engenharia agêntica trata a IA como um motor de implementação dentro de um sistema cuidadosamente desenhado de restrições, testes e feedback loops, com humanos mantendo a decisão sobre arquitetura, correção e qualidade.

O diferenciador entre os dois não é usar IA. É quanta estrutura, verificação e julgamento cercam o output.

Isso parece abstrato até você trocar o exemplo. Um protótipo de fim de semana pode ser puro vibe coding, com risco aceitável e código descartável. Um sistema que sustenta um produto em produção exige engenharia agêntica. No meio, fica quase todo o trabalho real, e a habilidade está em saber onde traçar a linha para cada tarefa. Essa decisão vale para qualquer empresa que já gera código com IA (e, segundo a Stack Overflow, isso já são 84% dos desenvolvedores).

O harness é governança de IA

Há uma tentação, quando se começa a trabalhar com agentes, de tratar o modelo como o sistema inteiro. Modelo novo, agente fica melhor; modelo velho, agente piora. O modelo vira a explicação para tudo.

O Google argumenta que essa intuição é errada e cara. O modelo é só um insumo. Tudo o mais (os prompts, as ferramentas, as políticas de contexto, os hooks, os sandboxes, a observabilidade) é o que eles chamam de harness: o arcabouço em volta do modelo que faz ele realmente terminar alguma coisa.

A equação é simples:

Agente = Modelo + Harness

Se o modelo é o motor, o harness é o carro, a estrada e as leis de trânsito. Um motor sozinho não fabrica um carro. E os números são contundentes: num benchmark público (Terminal Bench 2.0), um time tirou um agente de fora do Top 30 e o colocou no Top 5 sem trocar o modelo, mexendo só no harness. A conclusão do paper é direta: a maioria das falhas de agente, examinadas com honestidade, são falhas de configuração, não do modelo.

Aqui vale traduzir “harness” para a linguagem de quem precisa responder por essa adoção: harness é governança de IA, na prática. Ele inclui as regras e instruções que o agente carrega (arquivos como AGENTS.md, CLAUDE.md), as ferramentas que ele pode chamar, os ambientes isolados onde o código roda, a lógica de orquestração e os guardrails, hooks e observabilidade: código determinístico que dispara em momentos do ciclo (por exemplo, bloquear um commit que tente subir uma senha), o rastreamento de qual código foi gerado por IA, e a capacidade de auditar por que um agente tomou determinada decisão.

Governar significa exatamente isso: saber o que o agente pode fazer, o que ele fez e por que. Segurança é uma das dimensões dessa governança — importante, mas não a única. Sem o harness, você não tem um problema de modelo; tem um problema de controle.

O novo SDLC: você não escreve código, você projeta a fábrica

A consequência disso para o ciclo de desenvolvimento (SDLC) é estrutural. Quando a implementação que levava semanas passa a levar horas, o gargalo migra. Requisitos, arquitetura e verificação seguem teimosamente humanos; a escrita de código, não.

O Google resume isso no que chama de modelo de fábrica: o entregável principal do desenvolvedor deixa de ser o código e passa a ser o sistema que produz código. Esse sistema reúne especificações e contexto, agentes que traduzem specs em implementação, testes e quality gates que verificam correção, feedback loops que devolvem as falhas para o agente corrigir e guardrails que mantêm o agente dentro de um comportamento seguro.

Um gerente de fábrica não monta cada peça à mão. Ele projeta a linha de montagem e garante o controle de qualidade.

Aqui mora o risco que o discurso de produtividade costuma pular. Uma fábrica sem controle de qualidade não produz menos defeito — produz defeito em escala. E os dados não são gentis: 45% do código gerado por IA contém vulnerabilidades (Veracode, 2025), e 20% dos pacotes que a IA sugere simplesmente não existem — o fenômeno do slopsquatting. Sem governança embutida na linha, a fábrica industrializa o defeito na mesma velocidade com que industrializa a entrega.

Assine agora

A economia: o problema é provar o ROI

Para um líder de engenharia, a métrica que importa não é velocidade — é retorno. E é aí que os fatos convergem.

O vibe coding parece imbatível em custo: uma assinatura mensal e alguns prompts. O CapEx (investimento inicial) é quase zero, porque você se apoia inteiramente na capacidade bruta do modelo. Mas o paper do Google mostra o que isso esconde: um OpEx (despesas operacionais) alto e crescente, em três parcelas.

A primeira é o token burn — o loop caro de despejar arquivos enormes no contexto e pedir, repetidamente, que o modelo conserte os próprios erros.

A segunda é o imposto de manutenção: código gerado por prompt ad-hoc costuma não ter consistência estrutural, e meses depois alguém gasta dias fazendo engenharia reversa de um “espaguete”.

A terceira é a remediação: corrigir uma falha em produção custa exponencialmente mais do que pegá-la no design.

O caso Microsoft/Uber é precisamente esse OpEx se materializando. E o ponto mais incômodo não foi a conta — foi o COO da Uber não conseguir provar o que aquele gasto comprou. Esse é o coração do problema de ROI da IA: commits são contáveis; valor, não. A menos que você instrumentalize a medição.

A engenharia agêntica inverte a equação: CapEx alto, OpEx baixo. Investe-se tempo, antes da primeira linha de produção, em desenhar schemas, construir suítes de teste e, sobretudo, estruturar o contexto do agente. O custo marginal de cada feature despenca, porque a IA opera dentro de uma fábrica governada. Context engineering, nesse mundo, deixa de ser um truque técnico e vira uma alavanca financeira. Provar o ROI deixa de ser narrativa e passa a ser leitura de métrica DORA, qualidade, custo por feature entregue e verificada.

O elo que ninguém terceiriza: o time que sabe dirigir agentes

Há uma última peça nessa história, uma que a fintech sueca Klarna aprendeu do jeito caro.

Em 2024, a empresa cortou cerca de 700 posições para substituir gente por IA. A satisfação despencou justamente nos casos complexos; os que exigiam julgamento e não estavam nos padrões aprendidos pela IA se acumularam sem ninguém preparado para resolver, enquanto a média geral mascarava a piora. Em meados de 2025, a empresa recontratava humanos.

A versão de manchete diz “a IA falhou”. A versão precisa é outra: a IA resolveu o trabalho que foi feita para resolver, e aí se descobriu que esse trabalho não era a maior parte do trabalho. Sistemas reais acumulam história. Uma IA lê o código, mas não leu a reunião em que se decidiu não usar uma abordagem por causa de uma falha de três anos atrás que nunca foi documentada.

Por isso o Google é categórico ao falar de pessoas: o gargalo migra da escrita para a especificação, a avaliação e o julgamento, e os engenheiros mais valiosos dos próximos anos serão os que dirigem agentes bem, não os que escrevem mais código. Isso não acontece por osmose. Acontece quando a empresa decide educar o time deliberadamente para especificar com precisão, decompor tarefas, avaliar output com ceticismo e desenhar os guardrails e feedback loops que mantêm o agente produtivo.

Geração resolvida. O novo ofício é outro.

A transição de sintaxe para intenção não é previsão de futuro, é presente. A transformação já está acontecendo e agora é questão com quanta disciplina cada time vai navegá-la. Três princípios resistem: estrutura escala, “vibe” não; a IA amplifica a cultura de engenharia que encontra — multiplica forças e fraquezas; e o papel humano evolui, não diminui.

É essa a leitura que orienta o trabalho da Duranium, IA-first dos dois lados — protegendo o código e a transação.

Como Parceiro Anthropic, ajudamos a estruturar esse harness de ponta a ponta; em setores regulados, como o financeiro, onde acumulamos cases, ele ainda vira evidência de conformidade; mas o problema é horizontal: vale para qualquer empresa que já gera código com IA.

A geração de código está resolvida. Governança, prova de ROI, julgamento e educação são o novo ofício.

Sua empresa já gera código com IA. A pergunta é se isso está governado, medido e nas mãos de um time preparado.

Fale com a Duranium sobre WeLuvCode, Consultoria Anthropic e a Duranium Academy.

#IAnaEngenharia #EngenhariaAgentica #GovernancaDeIA #ROIdeIA #ClaudeCode

O Cenário em Números: Uma Mudança de Ordem de Grandeza

Em 2024, o MITRE CVE (Common Vulnerabilities and Exposures) chegou a registrar picos de vulnerabilidades nunca antes vistos. Para colocar em perspectiva: há dez anos, falávamos em centenas de CVEs por mês. Hoje, esse número é uma rotina para muitos segmentos e, em picos específicos, entra na casa dos milhares.

Em 2025, Daniel Stenberg, mantenedor histórico do cURL (uma das bibliotecas mais usadas na internet), comentou que a velocidade de descoberta e publicação de vulnerabilidades tornou-se incompatível com o ritmo de correção tradicional. Antes, uma vulnerabilidade podia ficar “quieta” no radar por meses. Hoje, é medida em horas.

Estamos em um cenário de transformação estrutural.

Por Que Isso Está Acontecendo: A Democratização da Descoberta

A resposta está em uma palavra: automação.

Ferramentas de análise estática (SAST), análise dinâmica (DAST), scanning de dependências (SCA) e, crucialmente, modelos de IA aplicados à detecção de vulnerabilidades tornaram a busca por falhas uma atividade escalável, barata e contínua.

Antes, encontrar uma vulnerabilidade requeria expertise humana. Hoje, um pipeline de CI/CD com as ferramentas certas consegue varrer código, identificar padrões suspeitos, e reportar potenciais CVEs em minutos.

A consequência: o custo de descoberta caiu dramaticamente. Onde havia gargalos humanos, agora há paralelização.

Empresas que conseguem equipar seus time com ferramentas modernas,como orquestração AppSec com integração de SAST, SCA, análise comportamental, começam a descobrir vulnerabilidades que, há cinco anos, teriam passado desapercebidas por meses.

O Caso Mythos: De Meses para Horas

Em 2026, a Anthropic divulgou publicamente um cenário emblemático: uma vulnerabilidade complexa em uma biblioteca de processamento de linguagem natural foi descoberta, validada, corrigida e patcheada em poucas horas — não dias, não semanas. O ciclo completo.

Isso não seria notável se não fosse impossível há pouco tempo. Antes, esse tipo de descoberta levaria semanas de análise, mais semanas de comunicação com mantenedores, e meses até a propagação do patch.

O que mudou? Análise contínua automática sobre uma codebase viva. A IA não só identificou a falha, mas sugeriu a correção contextualizada, e engenheiros humanos validaram em tempo real.

O significado é profundo: não estamos apenas descobrindo mais vulnerabilidades, estamos reduzindo o tempo de exposição. A velocidade de correção começou a acompanhar a velocidade de descoberta, pelo menos nos casos em que há automação envolvida.

ASSISTA AO WEBINAR

O Efeito Colateral: O Dilema de Priorização Explodiu

Aqui está o dilema que mantém os security leads acordados à noite: se há 2.000 CVEs potenciais na sua stack, qual você corrige primeiro?

Há dez anos, a resposta era simples: todos, pois a quantidade era administrável, já hoje, isso seria impossível.

O que antes era uma lista de prioridades virou um problema combinatório. Uma organização típica pode estar exposta a 500+ vulnerabilidades conhecidas simultânea e legitimamente, considerando dependências indiretas, versões não-auditadas de bibliotecas, código legado nunca revisado.

Um banco, uma fintech, uma empresa de seguros. Todas enfrentam a mesma realidade: priorizar não é mais uma questão operacional, é uma questão de risco.

E aqui é onde a IA realmente entra: modelos treinados para entender o “risco contextual” de uma vulnerabilidade — isso é, qual CVE é mais provável de ser explorado dado o seu ambiente específico, suas dependências, sua exposição de rede, seu padrão de tráfego — começam a tornar a priorização viável novamente.

Mas exige equipamento. Exige estrutura.

O Que Não Funciona: Os Processos de Antes Não Escalam

Muitas empresas ainda operam com processos desenhados para o mundo anterior: planilhas de priorização manual, reuniões semanais de triagem, análise humana pura de cada CVE. Esses processos quebram sob volume. Colocar mais gente no problema não resolve. Uma equipe de segurança de 50 pessoas não consegue revisar 2.000 vulnerabilidades de forma contínua. O problema não é linear, é exponencial.

Alguns cenários que não funcionam mais:

• “Vamos revisar todos os CVEs em comitê” → Impossível. O tempo de decisão vai além do tempo de exploração.

• “Vamos fazer um plano de remedição de 12 meses” → A vulnerabilidade explorada no mês 3 não espera o plano.

• “Vamos cuidar só das críticas” → “Crítico” é subjetivo. Um CVE classificado como “média” pode ser crítico no seu contexto específico.

• “Vamos ignorar as que têm CVSS < 7.0” → Você vai descobrir que metade das suas breaches vieram de CVEs abaixo dessa linha.

O que começa a funcionar é:

• Automação de scanning contínuo — não mensal, não trimestral. Contínuo.

• Priorização contextual baseada em dados — seu risco real, não o CVSS genérico.

• Correlação automática — “esse CVE está em código que toca dados de clientes? Eleva de media para critical.”

• Human in the loop — mas estratégico. Humanos revisam exceções, validam recomendações, tomam decisões de negócio. Não fazem scanning manual.

O Que a Indústria Está Começando a Fazer

As organizações mais maduras em AppSec já começaram a responder:

1. Orquestração de ferramentas Não é SAST ou SCA. É SAST + SCA + DAST + análise comportamental + inteligência de ameaças. Tudo alimentando um dashboard unificado que faz correlação automática.

2. Modelos de risco dinâmicos Em vez de um CVSS fixo, o risco muda com o contexto: a biblioteca vulnerável está em produção? Quem tem acesso a ela? Há detectores de anomalia observando aquele componente?

3. Correção automática quando possível Não é só identificar. É corrigir: patches automáticos, bumps de versão sugeridos, reescritas de código oferecidas (com revisão humana).

4. Compliance como subproduto Se você tem visibilidade contínua e priorização inteligente, compliance (BACEN, PCI-DSS, SOX) é automaticamente mais fácil, você tem o histórico de o quê, quando, por quê.

O Que Uma Empresa Deve Fazer Agora

Se você está enfrentando esse cenário, a recomendação não é heroica, é pragmática:

1. Mapeie sua baseline hoje

Antes de fazer qualquer coisa, saiba: quantas dependências você tem? Quantas delas têm vulnerabilidades conhecidas? Qual é a distribuição de severidade? Sem baseline, não há priorização, só caos.

2. Automatize o scanning

Não negocie isso. Se seu pipeline de CI/CD não está rodando análise de segurança em todo commit, você está acumulando débito.

3. Escolha ferramental com inteligência sobre contexto

Não basta “encontrar vulnerabilidades”. Ferramentas que conseguem correlacionar risco com sua exposição real (código que roda em produção, que toca dados sensíveis, que é acessado externamente) reduzem o ruído exponencialmente.

4. Estruture priorização inteligente

Trabalhe com a área de segurança para definir: qual é o seu real apetite de risco? Em quais ativos não é aceitável desvio? Onde há folga? Com essas respostas, modelos de priorização tornam-se possíveis.

5. Invista em treinamento, não em heroísmo

Equipes que entendem por que uma vulnerabilidade importa no contexto específico delas conseguem tomar decisões melhores (incluindo “vamos aceitar esse risco”) do que equipes que recebem listas genéricas.

6. Integre humanos em pontos de decisão, não em pontos de entrada

Deixe máquinas fazerem triagem, correlação e sugestão. Coloque humanos para validar exceções, explicar tradeoffs, assinar decisões de risco.

A Realidade que Está Aqui

O vulpocalipse não é um cenário futuro. É hoje.

Empresas que enxergam volume crescente de vulnerabilidades como um sinal de que seus processos viraram obsoletos, saem na frente. Empresas que tentam escalar processos manuais vão se afogar.

A boa notícia? A tecnologia para navegar isso existe. A orquestração AppSec com inteligência contextual, automação e priorização inteligente não é ficção científica. Está aqui, operacional, reduzindo risco em tempo real.

A pergunta agora é: “como eu navego o volume, priorizo efetivamente, e reduzo meu tempo de exposição?”

Responder essa pergunta exige equipamento moderno, estrutura de dados clara, e humanos focados em decisão, não em entrada de dados.

Está na hora de equipar seu time.

Assista nosso Webinar com a Conviso, onde abordamos esse tema e muitos outros

Fontes e Referências

• MITRE CVE Report 2024–2026: dados de volume de CVEs

• Daniel Stenberg (cURL maintainer): discussão pública sobre velocidade de descoberta vs. correção, 2025

• Anthropic disclosure (2026): caso de estudo de ciclo de descoberta e correção acelerado via análise contínua

• Convenção: discussão sobre orquestração AppSec e correlação de risco contextual na prática

O que a maioria dos times de engenharia não consegue responder

Existe uma pergunta simples que a maioria dos líderes de engenharia não consegue responder com dados: o que meu time está entregando, com qual qualidade, e onde estão os riscos?

Não por falta de esforço. Por falta de fonte.

O que existe hoje, na maior parte das organizações, são dashboards montados manualmente, velocity como proxy de saúde, e reuniões onde os dados apresentados são os que o time conseguiu levantar na semana anterior. Segundo o relatório Port 2025, cerca de 50% dos engenheiros não confiam nos dados que a própria empresa usa para medir a engenharia — e 53% das organizações que rastreiam métricas ainda fazem isso de forma manual.

O resultado tem um nome: teatro de métricas. Os números existem para reportar, não para decidir.

Mas esse é só o primeiro problema. Embaixo dele, existem outros dois que crescem em silêncio.

O conhecimento que ninguém documenta — e o risco que isso representa

Pesquisas mostram que 58% do tempo dos desenvolvedores é gasto lendo e entendendo código existente — não escrevendo código novo. Isso não é ineficiência individual. É o custo estrutural de sistemas que cresceram sem documentação acompanhando.

Todo mundo sabe que documentação é necessária. E quase ninguém tem tempo de fazer. Dados de mercado mostram que menos de 3% do dia de um desenvolvedor é dedicado a documentação, e apenas 1% das atividades de PR incluem atualização de docs. Não porque o time é negligente — porque documentar manualmente compete com entregar, e entregar sempre ganha.

O efeito acumulado é a dívida técnica consumindo, em média, 42% da capacidade produtiva dos times de engenharia — horas por semana gastas em manutenção de código que ninguém tem contexto suficiente para tocar com confiança.

E quando esse contexto está concentrado em poucas pessoas, o risco fica ainda mais concreto. 65% dos repositórios dependem de no máximo duas pessoas para manter o conhecimento ativo sobre aquele código. Quando uma delas sai, o time leva meses para recuperar o que foi embora com ela — porque o conhecimento nunca foi do repositório, foi da pessoa.

70% das organizações levam mais de um mês para colocar um desenvolvedor novo em produção. Parte desse tempo é onboarding inevitável. Mas boa parte é tempo gasto tentando entender um sistema que não se explica sozinho.

Três problemas. Uma mesma raiz.

Teatro de métricas, documentação inexistente e conhecimento concentrado parecem problemas separados. Mas têm a mesma causa: a engenharia não tem uma fonte de verdade contínua sobre si mesma.

O repositório contém tudo — cada decisão de arquitetura, cada padrão adotado, cada hotspot de risco, cada sinal de qualidade. O que falta é uma forma de lê-lo de maneira estruturada, contínua e sem exigir disciplina extra do time.

Quer entender o que o WeLuvCode encontra na sua engenharia? Conheça a plataforma

O que muda quando o repositório vira fonte de verdade

O WeLuvCode conecta ao repositório e, a cada novo merge, mantém três frentes atualizadas automaticamente — sem instrumentação no time, sem mudança de processo.

Na frente de saúde da engenharia, indicadores de fluxo, qualidade, eficiência e riscos são calculados do código real e atualizados a cada entrega. Frameworks DORA e SPACE calibrados para o contexto brasileiro. O Engineering Manager para de montar planilha. O CTO para de apresentar velocity como proxy de saúde. A liderança passa a apresentar dados que a própria engenharia reconhece como verdadeiros.

Na frente de conhecimento, o WeLuvCode faz engenharia reversa a cada merge: sete frentes de documentação — arquitetura, regras de negócio, dependências, segurança e mais — são regeneradas automaticamente. O contexto técnico do sistema vira ativo da empresa, não informação na cabeça de quem escreveu. Uma busca semântica cross-repo responde em segundos perguntas que hoje custam horas: “onde tem código que valida CNPJ?”, “quais são os pontos de atenção desse repositório?”, “como está a engenharia este mês?”.

Na frente de ação, o conhecimento extraído vira produto: planos de onboarding de 90 dias construídos a partir do código real, por contexto e squad, e descrições de vagas com a stack real do time. Novos desenvolvedores chegam com um caminho

estruturado — não com uma pilha de documentação desatualizada para decifrar sozinhos. Os seniores param de ser a única fonte de verdade sobre o sistema.

O repositório continua sendo o mesmo. O que muda é o que a organização consegue ver nele.

Veja como o WeLuvCode funciona na prática.

CONHEÇA A SOLUÇÃO

Fontes: Port 2025 Engineering Benchmark · Xia et al., IEEE Transactions on Software Engineering (2017) · GitLab Global DevSecOps Report (2024) · Jellyfish State of Engineering (2021) · Stripe Engineering Productivity Research · CISQ Cost of Poor Software Quality · Avelino et al., ICPC 2016 · SmartBear/Cisco Code Review Study · Frameworks DORA e SPACE

A Duranium publicou o onepager do WeLuvCode, sua plataforma de inteligência de engenharia. O material apresenta o produto em três blocos: o problema (custo da engenharia invisível, embasado em seis estudos públicos), o que a plataforma entrega (três frentes integradas: saúde da engenharia, conhecimento que não se perde e ações que liberam seniores) e como funciona na operação (contínuo, cross-repo, seguro por contexto e com zero fricção pro time).

Este post resume o conteúdo do onepager e contextualiza por que o problema que o WeLuvCode endereça importa agora — especialmente em times que estão adotando IA na engenharia em ritmo superior à sua capacidade de absorver contexto.

→ Acessar o onepager

O custo da engenharia invisível

Times de engenharia produzem contexto crítico todos os dias — e raramente conseguem capturá-lo de forma estruturada. O conhecimento fica na cabeça de quem escreveu o código. A liderança decide com base em estimativa. Quem chega ao time gasta semanas em arqueologia antes de contribuir de forma efetiva.

Seis estudos públicos documentam a dimensão desse problema.

Desenvolvedores profissionais gastam 58% do tempo lendo e compreendendo código existente — não escrevendo código novo (Xia et al., IEEE Transactions on Software Engineering, 2017).

Em 70% das organizações, colocar um dev novo em produção leva mais de um mês (GitLab Global DevSecOps Report, 2024).

Em 65% dos repositórios analisados no GitHub, o conhecimento técnico está concentrado em no máximo duas pessoas — uma demissão ou licença basta para que ele saia pela porta (Avelino et al., ICPC 2016). E código com ownership fraco apresenta seis vezes mais bugs do que código com ownership forte (Microsoft Research, MSR 2011–2015).

A leitura combinada desses dados aponta para o mesmo lugar: o conhecimento crítico está concentrado, o contexto técnico não é capturado de forma estruturada e a liderança toma decisões sem visibilidade real do que está acontecendo na engenharia.

Por que esse problema ficou mais urgente agora

A adoção acelerada de IA na engenharia aprofundou o desafio. O Google Cloud/DORA Accelerate State of DevOps Report 2024, com respostas de mais de 39 mil profissionais, identificou que 76% já usam IA para escrever, explicar ou documentar código. A produção de código acelerou. Mas o mesmo relatório registrou que 39% dos profissionais desconfiam do código gerado por IA — e que adoção de IA correlacionou com piora em métricas de entrega de software, não melhora.

O padrão é direto: enquanto a IA amplia a velocidade de produção, a capacidade dos times de absorver, revisar e manter esse código não cresce na mesma proporção. Em times onde o contexto técnico já estava mal documentado, essa pressão chega num sistema que não estava preparado para absorvê-la.

O que está no Onepager

O material detalha as três frentes que o WeLuvCode cobre, como cada uma opera na prática e o que muda para liderança e times de engenharia. Inclui os seis dados públicos com fontes, exemplos de tela e os princípios operacionais que diferenciam a plataforma de ferramentas tradicionais de métricas ou documentação.

Para times que quiserem ir além do material, a Duranium está abrindo pilotos de 15 dias com repositórios reais, sem custo. Ao final, o time vê o que o WeLuvCode encontrou sobre sua própria engenharia. A decisão de seguir é do cliente.

→ Baixar o onepager

→ Iniciar um piloto: contato@duranium.io

Fontes: Xia et al., IEEE TSE, 2017 · GitLab Global DevSecOps Report, 2024 · Avelino et al., ICPC 2016 · Microsoft Research, MSR 2011–2015 · Google Cloud/DORA Accelerate State of DevOps Report, 2024

Compartilhar

A aceleração que criou um novo gargalo

Nos últimos dois anos, a adoção de ferramentas de IA para codificação passou de experimento a padrão. Mais de 75% dos times de engenharia já trabalham com algum nível de assistência de IA no dia a dia — e o efeito mais imediato aparece no volume: mais código escrito, mais pull requests abertos, ciclos de entrega mais curtos.

O problema é que code review não acompanhou esse ritmo. Revisar código continuou sendo um trabalho humano, sequencial, que depende de quem entende o contexto da codebase. E o volume de PRs que chegou para revisão praticamente dobrou em muitas equipes.

O resultado prático: os mesmos engenheiros seniores que antes já tinham pouco tempo disponível passaram a ser o principal ponto de contenção do processo. A IA acelerou a geração de código. O gargalo só mudou de lugar.

O que os dados de qualidade estão registrando

Mais código entrando não significa necessariamente melhor código entrando. Ferramentas de IA são boas em produzir código que funciona na superfície — que compila, passa em testes básicos, parece correto numa leitura rápida. O que elas costumam ignorar são os padrões internos da codebase, as decisões de arquitetura que não estão documentadas, as dependências que só quem trabalha no repositório há meses conhece.

O efeito acumulado aparece em métricas de qualidade pós-merge: a taxa de code churn — código reescrito ou descartado pouco depois de entrar — praticamente dobrou entre 2020 e 2024, segundo análise do GitClear após análise de 211 milhões de linhas de código. O Cortex Engineering Benchmarks 2026 registrou crescimento de 23,5% em incidentes por PR e 30% na taxa de falha de mudanças em equipes com alta adoção de IA sem controles de qualidade correspondentes.

Temos mais output individual mas, ao mesmo tempo, uma entrega organizacional que não melhora na mesma proporção.

O que o board está cobrando — e por que a resposta não vem

Enquanto o time lida com volume e qualidade, a liderança enfrenta uma pressão diferente: demonstrar retorno sobre o investimento em IA.

O problema é que as métricas disponíveis não respondem essa pergunta com precisão. Taxa de aceitação de sugestões, linhas de código geradas — medem atividade, não impacto. Não dizem se a base de código está mais saudável, se os incidentes diminuíram, se o time está de fato entregando com mais qualidade.

Resultado: 71% dos CIOs e CTOs dizem que as expectativas do board sobre ROI de IA são irreais — porque não conseguem demonstrá-lo com dados concretos, segundo pesquisa da Solvd com a Wakefield (2025). Decisões sobre investimento em ferramentas continuam sendo tomadas com base em percepção.

O paradoxo em números

O paradoxo é mensurável: devs acham que são 24% mais rápidos com IA, mas uma pesquisa da METR mostrou que, em tarefas reais de repositório, a velocidade caiu 19%. Mais output individual, entrega organizacional estagnada.

Nesse caso, a percepção e a realidade foram em direções opostas — e ninguém que participou do estudo percebeu enquanto acontecia.

Isso não significa que IA não funciona. Significa que o impacto é mais complexo do que parece e que medi-lo com as ferramentas erradas leva a conclusões erradas.

O que falta não é dado — é leitura

O repositório registra tudo. Cada merge, cada reversão, cada trecho de código que entrou e saiu em duas semanas, cada PR aprovado sem revisão real. Os sinais estão lá — o que falta é uma forma de lê-los de maneira contínua, sem exigir que alguém monte um dashboard manualmente toda semana.

É exatamente o que o WeLuvCode faz. A plataforma conecta ao repositório e, a cada novo merge, agentes especializados analisam o que mudou: as métricas se atualizam, os hotspots ficam visíveis, e a documentação se regenera automaticamente — sem instrumentação no time, sem mudança de processo.

Na frente de saúde da engenharia, indicadores de fluxo, qualidade, eficiência e riscos são calculados do código real e atualizados a cada entrega. Se o throughput sobe sem que a qualidade acompanhe, aparece nos dados. Se a revisão está concentrada em duas pessoas, aparece nos dados. Se o código gerado por IA está sendo validado de verdade ou apenas aprovado, aparece nos dados.

Na frente de conhecimento, o contexto técnico do sistema — arquitetura, regras de negócio, dependências — vira ativo da empresa, não informação na cabeça de quem escreveu. Uma busca semântica cross-repo responde em segundos perguntas que hoje custam horas de investigação manual.

E na frente de ação, o conhecimento extraído dos repositórios vira plano de onboarding por contexto e descrição de vagas com a stack real do time — liberando os seniores do papel de única fonte de verdade sobre o sistema.

A liderança passa a ter o que estava faltando: não mais volume como proxy de saúde, mas evidência real sobre o que está sendo entregue — e com qual qualidade.

Compartilhar

Fontes: Faros AI — AI Productivity Paradox Report (2025) · GitClear — AI Copilot Code Quality Report (2025) · Cortex — Engineering in the Age of AI: 2026 Benchmark Report · METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (2025) · Solvd/Wakefield Research — CIO & CTO Insights: AI Research (2025) · DX Report: How Top Companies Measure AI (2025)

A AWS quase protagonizou um grande incidente de supply chain. Um atacante chegou ao repositório oficial do Amazon Q Developer, embutiu um payload destrutivo em um release legítimo, e o código foi distribuído para quase 1 milhão de instalações.

O que impediu o estrago não foi detecção. Não foi controle de integridade. Não foi resposta a incidente.

Foi um erro de sintaxe no código malicioso.

Essa é a parte que não deveria passar despercebida.

Assine agora

Três vetores. Nenhum sendo observado.

O ataque combinou uma credencial com escopo excessivo no pipeline de CI/CD, ausência de controles efetivos de integridade no fluxo de release, e um terceiro vetor que praticamente nenhuma empresa está preparada para tratar: prompt injection indireta em um agente com acesso amplo ao ambiente de desenvolvimento.

Cada um desses vetores tem fornecedor, tem ferramenta, tem framework há anos. Tê-los instalados e tê-los efetivamente operando, no entanto, são coisas diferentes — e o denominador comum dos três foi a ausência de alguém olhando.

Por que AI coding assistants mudam o jogo

Uma extensão tradicional de IDE tem escopo previsível, ações específicas e raio de dano local. Um agente de AI coding interpreta linguagem natural, decide o que fazer e age sobre o ambiente: cria arquivos, executa comandos, conversa com a cloud. O escopo é dinâmico. O raio de dano deixa de ser local — passa a alcançar o pipeline e a conta cloud inteira.

Isso transforma cada AI coding assistant em software privilegiado. E exige uma camada de visibilidade que poucas empresas construíram.

O ponto cego: o painel da operação de engenharia

Ferramentas pontuais resolvem suas camadas bem. Nenhuma delas responde à pergunta que o CTO precisa responder na segunda de manhã: o que está acontecendo no meu código? Não no nível do alerta — no nível do padrão.

Quantas mudanças entraram nos repositórios críticos esta semana? Onde a profundidade de revisão caiu? O que o agente de IA está modificando com mais frequência? Onde o conhecimento dos módulos críticos está concentrado em uma única pessoa?

Essa é a camada que o incidente da AWS expôs como ausente — e onde Engineering Intelligence opera.

Sorte não escala

Mesmo a AWS só não sofreu dano maior porque o atacante errou a sintaxe. Operar engenharia hoje sem visibilidade contínua é construir sobre sorte.

→ Baixe o whitepaper completo: a análise técnica dos três vetores, o framework de visibilidade da camada de Engineering Intelligence e como o WeLuvCode operacionaliza isso na prática antes que sua empresa precise da mesma sorte.

Baixar o whitepaper completo

A conferência Black Hat Asia deste ano em Singapura trouxe uma das palestras mais equilibradas e provocativas da temporada de eventos de segurança. Ari Herbert-Voss, CEO da RunSybil e ex-primeira contratação de segurança da OpenAI — onde liderou os red teams dos modelos GPT-3 e Codex —, apresentou um panorama técnico sobre o que modelos de linguagem de grande escala (LLMs) realmente mudam no cenário ofensivo. E, mais importante: o que ainda não mudaram.

O resumo direto: a IA está acelerando a descoberta de vulnerabilidades de forma significativa. Isso tem implicações concretas para qualquer time de engenharia que ainda trata segurança como uma etapa pós-desenvolvimento.

O paralelo com o fuzzing — e por que ele importa

Herbert-Voss abre sua análise com um paralelo histórico útil. Nos anos 2000, o fuzzing foi recebido como uma tecnologia que tornaria pesquisadores de vulnerabilidades obsoletos — uma ferramenta que encontraria falhas em escala, automaticamente, sem esforço humano. O que aconteceu de fato foi diferente: o fuzzing criou um volume enorme de possíveis bugs, mas alguém ainda precisava triá-los, identificar os exploráveis e entender a causa raiz.

“De certa forma, o fuzzing tornou os pesquisadores de vulnerabilidades mais valiosos”, disse Herbert-Voss.

O mesmo padrão está se repetindo com LLMs. Modelos como o Mythos (Anthropic) conseguem gerar datasets massivos, confirmar anomalias e sugerir formas de exploração — mas a validação de quais achados têm impacto real de segurança ainda exige julgamento humano. “Equipes podem gerar mais bugs possíveis do que nunca. Validar quais têm impacto real de segurança ainda requer um humano. Esse gap é o problema”, afirma o especialista.

Os números que mudam a conversa

Há um dado no artigo que merece atenção particular de qualquer engineering manager ou responsável por produto:

Entre 2023 e 2026, o tempo médio entre a descoberta de uma vulnerabilidade e sua exploração caiu de cinco meses para dez horas.

Isso não é uma projeção especulativa — é uma mudança observável no comportamento de ameaças reais. Em competições profissionais de capture-the-flag (CTF), desafios que antes levavam horas para times especializados estão sendo resolvidos em minutos por jogadores usando ferramentas agênticas.

A aceleração não é uniforme entre todos os tipos de vulnerabilidade: modelos como o Mythos apresentam ganhos expressivos na descoberta de bugs “rasas” de baixa severidade, ganhos moderados para falhas de nível intermediário, e ganhos limitados para as mais complexas. Mesmo assim, o volume aumentado de detecções automatizadas coloca pressão constante sobre as equipes de defesa.

O que isso significa na prática para times de desenvolvimento

Herbert-Voss é direto: “Em breve será o caso de que organizações simplesmente não conseguirão entregar código com bugs sem que esses bugs sejam encontrados e explorados rapidamente.”

É aqui que entra o conceito de shift left — e vale explicar o que isso significa na prática.

Shift left é a ideia de mover as verificações de segurança e qualidade para mais cedo no ciclo de desenvolvimento — ou seja, para a “esquerda” do pipeline, mais próximas do momento em que o código é escrito. Em vez de testar e auditar no final, antes do deploy, a lógica é: detectar problemas enquanto o desenvolvedor ainda está com o contexto fresco, o custo de correção é baixo e a janela de exposição ainda não se abriu.

Com a aceleração que Herbert-Voss descreve, essa prática deixa de ser uma recomendação de boas práticas e passa a ser uma resposta estrutural a um cenário concreto: bugs que chegam à produção têm cada vez menos tempo de vida antes de serem explorados.

Quatro capacidades técnicas foram destacadas como prioritárias para times que querem se posicionar bem nesse novo ritmo:

1. Raciocínio aprofundado — Grande parte da segurança envolve lógica causal: como isso funciona? Como pode quebrar? Se X acontece, o que isso implica?

2. Uso eficaz de ferramentas — Agentes precisam conseguir interagir com sistemas reais para provar que uma vulnerabilidade existe. Agentes modernos já são consideravelmente melhores nisso.

3. Engenharia de “harness” de qualidade — Agentes têm janelas de contexto limitadas. Para trabalhar bem, precisam receber acesso ao contexto certo, com o escopo certo e as ferramentas certas. Isso é uma disciplina de engenharia, não só uma configuração.

4. Sistemas ao redor do harness — Um único agente com bom contexto tem limite. A efetividade real vem de múltiplos agentes trabalhando em conjunto, com comunicação bem estruturada entre eles.

O que o WeLuvCode tem a ver com isso

Existe uma conexão direta entre o que Herbert-Voss descreve e o problema que o WeLuvCode foi construído para resolver.

Quando ele fala que “organizações simplesmente não conseguirão entregar código com bugs sem que esses bugs sejam encontrados e explorados”, está descrevendo um novo patamar de exigência sobre a qualidade do que sai dos repositórios dos times de engenharia. A janela de tolerância está encolhendo.

O WeLuvCode atua precisamente nesse ponto crítico: integrado diretamente ao fluxo de trabalho do time de produto e desenvolvimento, ele aciona agentes a cada novo Pull Request submetido — validando segurança, padrões de codificação, boas práticas e regras específicas do repositório antes que qualquer mudança avance no pipeline. A cada push, os agentes validam funcionalmente a mudança. Issues recebem melhoria automática de especificação.

Esse modelo de revisão contínua e integrada ao ciclo de desenvolvimento não é apenas uma conveniência — é uma resposta estrutural ao tipo de pressão que Herbert-Voss descreve. Quanto mais cedo uma vulnerabilidade é identificada no ciclo de desenvolvimento, menor o custo de correção e menor a janela de exposição.

Dados internos do WeLuvCode apontam que 40% do código gerado com auxílio de IA contém mais vulnerabilidades do que código escrito manualmente — dado que reforça a necessidade de validação sistemática, especialmente em ambientes onde o uso de copilotos de código está se tornando padrão.

Uma oportunidade, não só uma ameaça

Herbert-Voss conclui sua palestra com uma perspectiva que vale ser registrada. Apesar de toda a aceleração ofensiva, ele enxerga na democratização dos modelos de fronteira também uma oportunidade para defensores: construir defesas em múltiplas camadas, priorizar patches, e finalmente executar as práticas de segurança que já deveriam ter sido implementadas.

“Há muito mais oportunidade de focar na construção de defesas em múltiplas camadas e na aplicação de patches — e usar essa energia e esse momentum para fazer muitas das coisas que provavelmente já deveríamos ter feito antes.”

O momento atual pede menos especulação sobre cenários apocalípticos e mais ação nos fundamentos: código mais seguro, revisão mais próxima do ponto de escrita, e times de engenharia com contexto técnico para tomar decisões melhores.

É nesse espaço que ferramentas como o WeLuvCode fazem sentido — não como uma solução definitiva, mas como uma camada de inteligência que desloca a detecção para onde ela é mais barata e mais eficaz: antes do merge.

Quer saber como o WeLuvCode se integra ao fluxo do seu time de desenvolvimento?

[Fale com a Duranium.]

Em janeiro de 2026, a Anthropic publicou uma pesquisa controlada randomizada com desenvolvedores de software investigando uma pergunta que muita gente já se fazia em voz baixa: usar IA durante o aprendizado ajuda ou atrapalha?

A resposta curta: depende completamente de como você usa.

O estudo identificou seis padrões distintos de uso da IA. Três deles levaram a notas até 86% mais altas nos testes de compreensão. Os outros três resultaram em aprendizado medíocre — e um deles, o pior de todos, deixou o dev mais lento e com menos conhecimento ao mesmo tempo.

O dado que mais chama atenção: participantes que usaram IA durante o aprendizado tiraram, em média, nota 17% menor do que os que codificaram manualmente. Mas isso só vale para quem usou IA sem critério. Os que souberam usar a ferramenta com intenção chegaram exatamente ao resultado oposto.

Esse é o ponto central: não é se você usa IA. É como você usa.

A partir dessa pesquisa, a Duranium organizou um guia com 10 dicas práticas para devs que estão começando a carreira agora, mas também para quem já está na carreira. O material cobre desde padrões de uso da IA que preservam o aprendizado até mentalidade de segurança — uma lacuna que o próprio estudo aponta como crítica, já que cerca de 45% do código gerado por IA contém vulnerabilidades identificáveis.

Você pode ler e baixar o guia completo aqui: https://content.duranium.io/10-dicas_carreira_engenharia_software_ia

Abaixo, um resumo dos principais aprendizados.

Os padrões que funcionam (e os que não funcionam)

O que prejudica o aprendizado:

• Delegar tudo para a IA sem tentar entender o código gerado (AI Delegation — 39% no quiz)

• Começar fazendo perguntas, mas na segunda tarefa já entregar tudo para a IA (Progressive AI Reliance — 35%)

• Ficar num loop de “IA, debugga isso” sem entender o erro (Iterative AI Debugging — 24% e o mais lento de todos)

O que preserva o aprendizado:

• Gerar o código com IA e depois perguntar “me explica o que esse código faz” (Generation-then-Comprehension — 86%)

• Pedir código e explicação na mesma query (Hybrid Code-Explanation — 68%)

• Fazer apenas perguntas conceituais e implementar por conta própria (Conceptual Inquiry — 65%, e o segundo mais rápido)

A diferença não está no acesso à ferramenta. Está na postura de quem usa.

Por que segurança entra nessa conversa

Uma das dicas do guia que mais gera reação é a dica 9: cultive mentalidade de segurança desde o início.

Não por alarmismo. Mas porque o código gerado por IA chega com vulnerabilidades reais que um dev sem base em AppSec não vai identificar. OWASP Top 10, validação de inputs, gerenciamento de secrets — esses fundamentos precisam andar em paralelo com o aprendizado de IA, não depois.

O guia completo explora isso (e as outras 9 dicas) com contexto, exemplos e referências úteis.

📥 Leia e baixe gratuitamente: https://content.duranium.io/10-dicas_carreira_engenharia_software_ia

Compartilhar

Nos últimos 18 meses, uma pergunta se tornou recorrente em conversas de RH, em reuniões de liderança e nos corredores de empresas de tecnologia: ainda precisamos contratar desenvolvedores juniores?

A pergunta parece apenas provocativa. Mas os dados que a sustentam são bem reais.

Um estudo da Universidade de Stanford identificou queda de quase 20% no emprego de desenvolvedores entre 22 e 25 anos desde o pico de 2022. No Reino Unido, vagas de nível de entrada em TI recuaram 46% em 2024. Nos EUA, alguns recortes apontam retração de até 60–70% nas posições iniciais do setor. Um estudo da Harvard Business School, que analisou 285.000 empresas ao longo de uma década, detectou que a adoção de IA generativa reduz o emprego júnior entre 9% e 10% em seis trimestres — enquanto as contratações seniores sobem 5%.

Isso é motivo para alarme? Não. É o mercado processando uma mudança estrutural que já estava acontecendo.

Vamos falar um pouco sobre essa mudança, antes de responder a pergunta do primeiro parágrafo.

O paralelo que ajuda a entender

A eletrificação do início do século XX não eliminou trabalhadores. Ela tornou obsoletos alguns ofícios e criou outros inteiramente novos. O tecelão artesanal não desapareceu — ele se transformou em operador de máquina, em técnico de manutenção, em engenheiro de processos.

A IA está fazendo o mesmo com as carreiras de tecnologia. Não se trata do fim das profissões. Trata-se de uma redefinição radical do que cada nível profissional precisa saber — e, principalmente, do que precisa entregar.

Ferramentas como Claude Code, GitHub Copilot e Cursor já são capazes de gerar código boilerplate, scaffolding, testes unitários e documentação em minutos. O que antes ocupava uma semana de um desenvolvedor júnior hoje é uma tarefa de prompt.

A pergunta, portanto, deixa de ser “quem escreve o código?” e passa a ser “quem é responsável pelo que o código faz?”

O paradoxo que ninguém está discutindo o suficiente

Aqui está o ponto que merece mais atenção do mercado: velocidade não é sinônimo de qualidade.

Assistentes de codificação com IA podem tornar o desenvolvimento até 4x mais rápido — mas também podem torná-lo significativamente mais arriscado. Estudos indicam que uma parcela relevante do código gerado automaticamente apresenta vulnerabilidades sérias de segurança que passam despercebidas em testes convencionais. Projeções do setor apontam que 1 em cada 5 brechas de segurança poderá ser atribuída a código gerado por IA até 2027.

No Spotify, 90% dos desenvolvedores já usam IA diariamente. O resultado: 30% mais code changes por pessoa. E também: preocupações crescentes sobre qualidade e revisão.

Mais volume, mais velocidade, mais risco. Para empresas que atuam em cibersegurança — onde uma vulnerabilidade sutil em produção pode comprometer dados de clientes ou expor tenants cruzados —, esse paradoxo não é teórico. É operacional.

O que a IA não consegue fazer (e provavelmente nunca vai)

Há um conjunto de competências que a pesquisa e a prática convergem em apontar como cada vez mais valiosas — justamente porque são as que a IA executa mal ou simplesmente não executa:

Enquadrar problemas antes de construir soluções. A maioria das demandas chega formulada como solução (”adicionar filtros ao dashboard”), não como problema real. Um profissional que sabe fazer as perguntas certas antes de escrever uma linha de código entrega mais valor do que um que executa rapidamente a tarefa errada.

Pensar em métricas, não em funcionalidades. Ferramentas de IA constroem qualquer coisa que se peça. O diferencial está em saber o que vale a pena construir — e medir se aquilo realmente moveu algum indicador.

Projetar sistemas sob restrições reais. Uma LLM gera código correto para um endpoint. Ela não decide se esse endpoint deve ser síncrono ou assíncrono, qual a latência aceitável, o que acontece quando o serviço dependente fica indisponível por 30 minutos. Essas decisões dependem de contexto organizacional que nenhum modelo carrega.

Comunicar e influenciar. Traduzir uma descoberta técnica em linguagem de risco de negócio — e convencer o CISO do cliente a priorizar uma vulnerabilidade classificada como “média” pela ferramenta mas crítica no contexto específico daquela empresa — é uma habilidade que a IA não replica.

Revisar criticamente o que a IA entrega. O profissional que valida, corrige e melhora o resultado gerado é um ativo. O que confia cegamente é um passivo. A diferença entre os dois é exatamente o que separa o risco da alavancagem.

Então, o que muda na gestão de talentos?

Diante desse cenário, gestores podem se sentir tentados a perguntar: se a IA faz o trabalho de juniores, por que contratar juniores?

A resposta que parece mais óbvia - investir na contratação de profissionais mais experientes que possam atuar onde a IA não consegue - cria um problema de médio prazo que é muito mais caro.

Empresas que eliminarem posições de entrada em 2026 podem enfrentar escassez severa de profissionais plenos e seniores em três a cinco anos. O pipeline de talentos não é um custo — é um investimento com prazo de retorno.

Há também um segundo efeito menos óbvio: sem juniores para quem delegar tarefas de menor risco, seniores ficam presos em ciclos exaustivos de revisão de código gerado por IA, sem a válvula de pressão que a delegação proporciona. O custo cognitivo sobe. A capacidade de entrega cai.

O que muda na prática?

Muito. E é exatamente na dimensão mais prática — como redesenhar planos de carreira, quais critérios incluir em promoções, como estruturar mentoria e medir o desenvolvimento de equipes nesse novo contexto.

Tudo isso está documentado em detalhes no material que a Duranium acaba de publicar.

O e-book “Carreiras de Tecnologia em Tempos de IA” apresenta uma taxonomia completa para o desenvolvimento profissional em tecnologia, com recomendações estratégicas baseadas em dados, referências acadêmicas rastreáveis e exemplos práticos aplicados ao contexto de cibersegurança.

Não é um manual de autoajuda para profissionais ansiosos com o futuro. É um documento de trabalho — para líderes de tecnologia, gestores de RH e profissionais que querem entender onde estão e para onde precisam se mover.

[Acesse, leia e baixe o e-book gratuitamente]

Duranium · Segurança da Informação, Antifraude e IA ·duranium.io

Compartilhar

Um novo levantamento acendeu o sinal de alerta para CISOs, gestores de TI e líderes de negócio: boa parte das organizações ainda não testa de forma consistente sua capacidade de recuperação após incidentes. E o dado mais preocupante? 24% das empresas afirmam nunca testar seus planos de Disaster Recovery.

O estudo, conduzido pela Quest Software e publicado pelo SegInfo em março de 2026, ouviu 650 profissionais de TI e Segurança da Informação ao redor do mundo. Os resultados revelam um desequilíbrio claro: enquanto as organizações investem cada vez mais em controles preventivos, a fase de recuperação — tão crítica quanto a prevenção — continua negligenciada.

Este artigo explora o que esses dados significam na prática e como as soluções BeyondTrust e Teramind, disponíveis no portfólio da Duranium, ajudam sua organização a fechar essas lacunas antes que um incidente real exponha suas vulnerabilidades.

O problema: prevenir sem preparar para recuperar é metade da proteção

Muito se fala sobre firewalls, MFA, antivírus e políticas de acesso. E com razão — a prevenção é o primeiro pilar de qualquer estratégia sólida de segurança. Mas o estudo reforça algo que especialistas discutem há anos: proteção sem resiliência é insuficiente.

Quando um ataque acontece — e a questão hoje é quando, não se — a capacidade de resposta e recuperação determina o tamanho do impacto. Organizações que nunca simularam um cenário de crise real tendem a descobrir as falhas do seu plano de continuidade no pior momento possível: no meio do incidente.

O relatório também aponta que essa fragilidade é ainda mais acentuada em ambientes de Tecnologia Operacional (OT), onde os testes de Disaster Recovery frequentemente se limitam a simulações básicas voltadas apenas ao cumprimento formal de requisitos, sem validar a resposta real a uma crise.

Do ponto de vista de governança, fica clara a desconexão entre gestão de riscos, continuidade de negócios e Segurança da Informação — três pilares que precisam operar de forma coordenada para que uma organização seja verdadeiramente resiliente.

O segundo alarme: identidade é o novo perímetro — e está exposta

Se o gap em Disaster Recovery já é preocupante, o levantamento reforça outro desafio igualmente urgente: a segurança de identidade.

A multiplicidade de identidades distribuídas entre ambientes on-premises, cloud e híbridos aumenta exponencialmente a complexidade da gestão de acessos. Mas o ponto mais crítico trazido pelo estudo é o crescimento acelerado das identidades não humanas: contas de serviço, aplicações, bots e automações que, em muitos ambientes, já superam em volume os usuários humanos.

O resultado? Visibilidade reduzida, controle fragmentado e uma superfície de ataque que cresce mais rápido do que a capacidade das equipes de monitorar.

Dados do relatório mostram que mais da metade dos profissionais entrevistados aponta identidades não humanas como uma das áreas mais difíceis de proteger, seguidas por contas de terceiros e sistemas legados.

E com a inteligência artificial potencializando ataques automatizados e novos vetores de comprometimento de credenciais, o cenário exige respostas mais inteligentes e proativas. Não à toa, 79% dos entrevistados acreditam que soluções baseadas em IA aumentam a eficácia das estratégias de ITDR (Identity Threat Detection and Response).

Como fechar essas lacunas: BeyondTrust e Teramind em ação

A Duranium trabalha com um portfólio selecionado de soluções que endereçam diretamente os desafios apontados pelo levantamento. Dois produtos se destacam nesse contexto:

BeyondTrust — Controle total sobre acessos privilegiados

O BeyondTrust é uma plataforma de PAM (Privileged Access Management) que resolve na raiz um dos principais vetores de comprometimento de identidade: o acesso privilegiado sem controle, rastreabilidade e governança adequados.

Na prática, o BeyondTrust oferece:

• Eliminação de senhas compartilhadas e planilhas de credenciais, um dos maiores riscos em ambientes corporativos

• Revogação automática de acessos após o uso, reduzindo a janela de exposição

• Monitoramento completo de sessões privilegiadas, com trilha de auditoria para investigações e conformidade regulatória

• Redução de até 95% no risco de vendor risk, com controle granular sobre acessos de terceiros e fornecedores

• Suporte a Zero Trust e controles de acesso rigorosos, alinhados às exigências regulatórias como a Resolução BCB 538/2025

Para um Disaster Recovery eficaz, saber quem acessou o quê durante um incidente é tão importante quanto a recuperação em si. O BeyondTrust permite que essa rastreabilidade exista — e que contas comprometidas possam ser isoladas rapidamente, limitando o raio de impacto.

Teramind — Visibilidade comportamental antes, durante e depois do incidente

Se o BeyondTrust protege o acesso privilegiado, o Teramind atua em uma camada complementar e igualmente estratégica: o monitoramento comportamental de usuários (UAM) e a prevenção de vazamento de dados (DLP).

O Teramind entrega:

• Detecção em tempo real de comportamentos suspeitos — uploads indevidos, acessos fora de padrão, exfiltração de dados

• Logs detalhados para investigação forense, essenciais tanto para resposta a incidentes quanto para a fase de recuperação

• Identificação de padrões anômalos antes que se tornem um incidente confirmado

• Redução de 90% em vazamento de dados e 70% no tempo de investigação pós-incidente

• Trilha completa para auditorias, alinhada a frameworks como NIST e às exigências da LGPD e do BACEN

A relação entre Teramind e Disaster Recovery é direta: você não pode recuperar o que não sabe que perdeu. A plataforma permite visibilidade sobre o que aconteceu durante um ataque — informação fundamental para acionar o plano de recuperação com precisão e evidências sólidas.

Além disso, enquanto o mercado sofre em média US$ 4,44 milhões por vazamento de dados, com 241 dias para detectar o incidente, organizações que operam com o Teramind reduzem esse impacto para menos da metade, com detecção e bloqueio em tempo real.

Dê o próximo passo

Na Duranium, combinamos consultoria especializada com tecnologia de ponta para ajudar organizações a elevar sua maturidade em segurança de forma estruturada.

Quer entender como o BeyondTrust e o Teramind se encaixam na realidade da sua empresa? Fale com um dos nossos especialistas e agende uma avaliação sem compromisso.

👉 Entre em contato com a Duranium

Fonte de referência: Levantamento aponta baixa maturidade em testes de disaster recovery e reforça desafios em segurança de identidade – SegInfo, março de 2026

Compartilhar

O Pix cresceu. As fraudes também.

Desde o seu lançamento, o Pix transformou a forma como o Brasil movimenta dinheiro. Com mais de 60 bilhões de transações realizadas em 2024, o sistema tornou-se a espinha dorsal dos pagamentos instantâneos no país. Mas esse crescimento trouxe consigo um efeito colateral inevitável: ele também se tornou um dos principais alvos de organizações criminosas.

Em resposta, o Banco Central do Brasil evoluiu o Mecanismo Especial de Devolução (MED) — a ferramenta regulatória criada para proteger vítimas de fraude no ecossistema Pix. A versão atual, normatizada pela Resolução BCB 318/2023, é conhecida como MED 2.0, e representa uma ampliação significativa de escopo, automação e responsabilidades para as instituições financeiras.

O problema? Criminosos já aprenderam a explorar o próprio mecanismo de defesa.

O que é o MED 2.0 — e o que mudou?

O MED foi criado para permitir que vítimas de fraude no Pix pudessem recuperar valores transferidos indevidamente. Na prática, funciona como um mecanismo de contenção dentro do arranjo: a vítima aciona sua instituição financeira, que notifica a instituição receptora via Infraction Report, e o saldo suspeito é bloqueado de forma cautelar enquanto a análise ocorre.

Com o MED 2.0, três mudanças centrais ampliaram o alcance do mecanismo:

Prazo de contestação estendido para até 80 dias. Uma transação realizada hoje pode ser contestada até quase três meses depois — o que aumenta consideravelmente o período de exposição para comerciantes e recebedores legítimos.

Bloqueio cautelar automático e imediato. Ao abrir um MED, o sistema bloqueia automaticamente o saldo na conta suspeita, sem validação prévia. Isso é ao mesmo tempo uma proteção para vítimas reais e uma arma nas mãos de fraudadores.

Integração com o DICT e os Infraction Reports. A marcação de chaves Pix suspeitas e a comunicação entre instituições foram formalizadas, criando um protocolo de inteligência compartilhada — mas ainda com lacunas de validação que organizações criminosas já começaram a explorar sistematicamente.

Por que isso importa para a sua instituição?

Os números são reveladores. Em 2024, o Brasil registrou 12,1 milhões de solicitações MED — um crescimento de 145% em relação a 2023. No primeiro semestre de 2025, foram 7,75 milhões de novas solicitações, ritmo 60% superior ao mesmo período do ano anterior. E, apesar de todo esse volume, a taxa de recuperação efetiva ficou em apenas 9,3% dos valores contestados.

Esse abismo entre volume e recuperação não é acidente: é a medida exata da maturidade das organizações criminosas que operam nesse ecossistema.

Ameaças ao ecossistema MED2.0

A Duranium mapeou dez vetores de ameaça estruturados no ecossistema MED 2.0, distribuídos entre ataques ao usuário e ao comerciante e ameaças interbancárias de infraestrutura. Seis deles foram classificados como CRÍTICO.

Para dar a dimensão do problema, um exemplo de cada domínio:

No lado do cliente: o vetor mais frequente inverte a lógica do MED contra a própria vítima. O fraudador envia um Pix real, alega “engano”, orienta a devolução para uma conta diferente da origem — e abre um MED alegando não ter recebido o valor. Resultado: a vítima perde o dinheiro devolvido e tem o saldo restante bloqueado pelo sistema regulatório. O mecanismo de defesa do Banco Central se torna a arma do ataque.

No lado interbancário: contas mula são esvaziadas em menos de 15 minutos após receber um crédito Pix fraudulento. Quando o bloqueio cautelar chega, não há mais saldo a recuperar. A velocidade é a defesa do criminoso.

Esses dois exemplos ilustram apenas uma parte do mapa completo. Os demais vetores — incluindo manipulação de Infraction Reports, conluio entre instituições e ataques de replay nas APIs SPI — estão documentados em detalhe no material que preparamos.

📥 Baixe o Threat Model completo MED 2.0 →

Como identificar um ataque antes que ele se complete

Cada vetor de ameaça deixa rastros. Alguns são comportamentais, outros transacionais, outros se manifestam nos próprios fluxos interbancários. A boa notícia: esses padrões são detectáveis — desde que sua instituição esteja monitorando os sinais certos.

No material completo, documentamos os Indicadores de Comprometimento (IoCs) associados a cada vetor, organizados por tipo de sinal e por janela temporal de detecção. São os mesmos indicadores que alimentam os modelos de ML do FraudGate, nossa plataforma antifraude desenvolvida especificamente para o ecossistema Pix.

Por que regras fixas já não são suficientes (e por que é hora de adotar arquiteturas de Machine Learning)

Pense assim: um sistema baseado em regras é como um guarda de segurança que só age quando vê o sinal que está no manual. Fraudadores aprenderam a não dar esse sinal.

Machine learning, por outro lado, aprende o que é comportamento normal para cada conta e sinaliza qualquer desvio relevante — mesmo que nunca tenha visto aquele padrão específico antes. Para o MED 2.0, isso não é diferencial: é requisito.

No material completo, detalhamos as arquiteturas de ML recomendadas para cada categoria de ameaça — desde modelos de sequência temporal para detectar o padrão fraude reversa até Graph Neural Networks para identificar conluio interbancário — com orientações de implementação para diferentes portes de instituição.

Próximos Passos: Sua Instituição está preparada?

O MED 2.0 não é apenas uma exigência regulatória — é um sinal de que o ecossistema de pagamentos instantâneos entrou em uma nova fase de maturidade. As organizações criminosas já se adaptaram.

A Duranium recomenda três ações prioritárias para os próximos 30 dias. A primeira — e mais urgente — é auditar a integração entre os fluxos MED e o motor PLD/FT da sua instituição. A falta dessa conexão é a principal porta de entrada para lavagem via MED. As outras duas ações, com o detalhamento técnico para implementação, estão no material abaixo.

📥 Baixe agora o Estudo Completo de Modelagem de Ameaças MED 2.0 — com os 10 vetores detalhados, IoCs completos, arquiteturas de ML recomendadas e o plano de ação de 90 dias.

Baixar o Threat Model MED 2.0 — Duranium →

Compartilhar

A segurança da supply chain de software raramente aparece nas primeiras páginas do orçamento — e é exatamente por isso que merece atenção estratégica. À medida que aplicações modernas se tornam composições cada vez mais complexas de bibliotecas open source, integrações de terceiros e pipelines automatizados — e que ferramentas de IA generativa aceleram a produção de código sem necessariamente ampliar a revisão de segurança —, a superfície de risco cresce em proporção direta à velocidade de desenvolvimento. O que muitas organizações ainda não mapearam, porém, é o impacto financeiro concreto de deixar essa superfície desprotegida.

Neste artigo, traduzimos o risco da supply chain insegura em números — de violações, de multas regulatórias e de custos operacionais — para ajudar líderes de tecnologia e segurança a tomar decisões de investimento com clareza e embasamento.

O Número que o Board Precisa Ver

Em 2024 e 2025, os ataques à supply chain deixaram de ser episódios isolados de espionagem sofisticada para se tornarem o vetor preferido de grupos de ransomware comercial. Os números são brutais: os ataques mensais à supply chain mais que dobraram entre o início de 2024 e o segundo semestre de 2025, chegando a uma média de 28 incidentes por mês — com outubro de 2025 registrando 41 ataques, o maior pico da história.

Mais revelador ainda: cerca de 23% das violações em 2025 envolveram terceiros”, segundo o Verizon DBIR — o dobro da taxa registrada no período anterior. E uma pesquisa da BlackBerry revelou que mais de 75% das organizações sofreram um ataque à supply chain de software no último ano.

A pergunta não é mais “isso pode acontecer conosco?”. É: “quando acontecer, quanto vai custar?”

O Custo Específico Para o Setor Financeiro Brasileiro

Para instituições financeiras no Brasil, há uma camada adicional que transforma risco técnico em risco de negócio imediato: conformidade regulatória.

Em dezembro de 2025, o Banco Central do Brasil e o Conselho Monetário Nacional publicaram as Resoluções BCB nº 538 e CMN nº 5.274 — os normativos de cibersegurança mais prescritivos já emitidos pelo regulador brasileiro. Com prazo de conformidade em março de 2026, eles exigem explicitamente:

• Controles de segurança estendidos a sistemas de terceiros e fornecedores, não apenas aos sistemas próprios da instituição

• Rastreabilidade completa do ciclo de vida dos ativos tecnológicos — o que, na prática, significa saber a procedência de cada biblioteca e componente em produção

• Gestão de vulnerabilidades abrangendo todo o ecossistema computacional, incluindo dependências externas

• Requisitos de segurança explícitos para integração via APIs — o canal central da supply chain moderna

O descumprimento dessas normas não gera apenas risco operacional. Gera exposição a sanções administrativas do BCB, que podem incluir multas, restrições operacionais e responsabilização pessoal de dirigentes. Para um CISO ou CTO de uma instituição regulada, ignorar a supply chain em 2026 é assinar embaixo de um passivo que pode ser cobrado pelo regulador antes que um ataque sequer ocorra.

O Caso Que Mudou o Debate: Três Anos de Infiltração, Zero Alarmes

Em março de 2024, um desenvolvedor da Microsoft chamado Andres Freund investigava uma lentidão inexplicável no SSH de um sistema Debian. O que ele encontrou reconfigurou a percepção de risco de toda a indústria.

Uma biblioteca de compressão chamada XZ Utils — presente em praticamente todas as distribuições Linux do planeta — havia sido comprometida. Não por uma invasão técnica. Por uma operação de engenharia social de três anos de duração, em que um agente desconhecido construiu reputação, confiança e autoridade dentro do projeto open source antes de inserir um backdoor cirúrgico no código.

A vulnerabilidade, classificada com CVE-2024-3094 e CVSS 10.0 — pontuação máxima —, teria dado acesso remoto irrestrito a centenas de milhões de servidores ao redor do mundo. O pesquisador de segurança Alex Stamos afirmou que poderia ter se tornado a backdoor mais abrangente já plantada em qualquer produto de software da história.

Foi descoberta por acaso. Por um engenheiro que não era pesquisador de segurança, investigando um problema de performance num domingo.

Qual é o custo de um incidente desse escopo? A título de referência: o ataque SolarWinds de 2020 — que usou o mesmo vetor de comprometimento de pipeline de build — resultou em investigações federais nos EUA, processos regulatórios contra a empresa, e bilhões de dólares em impacto combinado para as organizações afetadas.

O Panorama Global Confirma: 2025 Foi o Ano da Supply Chain como Vetor Dominante

Os dados que apresentamos até aqui ganham ainda mais peso quando colocados em perspectiva global. O High-Tech Crime Trends Report 2026 da Group-IB dedicou seu relatório anual inteiramente ao tema, batizando 2025 como “A Era dos Ataques à Supply Chain”.

Entre os achados mais relevantes do relatório: ataques via supply chain deixaram de ser operações isoladas para se tornarem o mecanismo central que conecta phishing, ransomware, vazamentos de dados e comprometimento de identidade em um único ecossistema. Um único fornecedor comprometido foi suficiente para expor centenas de organizações downstream — como demonstrado pelo caso Salesloft/Drift/Salesforce, em que tokens OAuth roubados impactaram mais de 700 empresas globalmente, incluindo nomes como Palo Alto Networks, Cloudflare e Workday.

O relatório também documenta a ascensão dos worms de supply chain no ecossistema npm: o malware Shai-Hulud comprometeu mais de 800 pacotes e atingiu 100 milhões de downloads, propagando-se de forma autônoma a partir de tokens de mantenedores roubados — exatamente o tipo de risco invisível que um SBOM e controles de integridade de artefatos existem para mitigar.

A conclusão da Group-IB alinha-se diretamente ao que discutimos aqui: “A confiança não pode mais ser assumida — ela precisa ser verificada, monitorada e protegida continuamente.”

(Fonte: Group-IB High-Tech Crime Trends Report 2026 — The Age of Supply Chain Attacks)

O Que Você Está Pagando Hoje Sem Saber

Há um custo da supply chain insegura que não aparece em nenhum relatório de incidente: o custo operacional do caos invisível.

Segundo o relatório Future of Application Security 2024 da Checkmarx, 91% das organizações admitiram ter implantado código vulnerável conscientemente — alegando pressão de prazos. E 92% sofreram uma violação relacionada a vulnerabilidades em aplicações que elas próprias desenvolveram.

Isso significa que a maioria das organizações não está escolhendo entre “seguro” e “inseguro”. Está escolhendo entre “inseguro agora” e “inseguro e comprometido depois” — e pagando o custo da segunda opção sem nunca ter calculado o da primeira.

A lógica financeira é direta: corrigir uma vulnerabilidade no pipeline de desenvolvimento custa uma fração do custo de responder a um incidente em produção. A diferença entre os dois cenários é onde no ciclo de vida do software você decide agir.

O Que Organizações Que Já Calcularam Esse Custo Estão Fazendo

Líderes que entendem o risco financeiro da supply chain insegura estão priorizando três movimentos:

Inventário antes de qualquer outra coisa. Você não pode precificar um risco que não enxerga. Um SBOM (Software Bill of Materials) é o ponto de partida — um inventário completo de cada componente, biblioteca e dependência em produção, com rastreabilidade de origem. Sem ele, qualquer exercício de gestão de risco é estimativa no escuro.

Integridade de ponta a ponta. O caso XZ Utils provou que código-fonte limpo não garante binário seguro. A assinatura digital de artefatos fecha a cadeia de custódia entre o commit e o deploy — garantindo que o que chegou em produção é exatamente o que saiu do repositório, sem adulterações intermediárias.

Detecção antes do deploy, não depois. Cada vulnerabilidade detectada em pipeline custa uma fração do que custaria detectada em produção — em tempo de engenharia, em exposição regulatória, e em risco de incidente. Ferramentas integradas nativamente ao CI/CD transformam segurança de auditoria reativa em controle preventivo contínuo.

A Decisão Que Está na Mesa

Se você é CISO, CTO ou lidera engenharia em uma instituição financeira brasileira, há uma decisão concreta na sua mesa agora: chegar à conformidade com as Resoluções BCB 538 e CMN 5.274 de forma proativa, com visibilidade e controle — ou aguardar que o regulador ou um incidente faça essa conta por você.

A diferença entre as duas opções não é filosófica. É financeira.

Na Duranium, ajudamos organizações a transformar essa decisão em um plano de ação concreto — com assessment do estado atual, identificação de gaps críticos, e implementação de controles alinhados às novas exigências regulatórias.

Quanto custa não fazer nada? Agende um Assessment e descubra antes que o mercado responda por você.

FALE COM A DURANIUM →

Referências

• IBM: Cost of a Data Breach Report 2025

• Cybersecurity Ventures: Software Supply Chain Cost Projections 2025–2031

• Verizon: Data Breach Investigations Report 2025

• BlackBerry: Software Supply Chain Survey 2024

• Checkmarx: Future of Application Security Report 2024

• Wikipedia / CISA / Red Hat: XZ Utils Backdoor — CVE-2024-3094

• Cyble: Supply Chain Attacks — Monthly Tracking, 2024–2025

• Banco Central do Brasil: Resolução BCB nº 538 e CMN nº 5.274, dezembro de 2025

Compartilhar

🤖 A IA está escrevendo seu código — mas quem está auditando?
Ferramentas como GitHub Copilot e ChatGPT aceleraram o desenvolvimento, mas também aumentaram o volume de código não revisado que entra em produção todos os dias.

🦠 O VS Code virou alvo: extensões maliciosas roubando credenciais em 2026
Em janeiro de 2026, 19 extensões maliciosas foram descobertas no marketplace oficial do VS Code — incluindo uma que instalava um trojan capaz de exfiltrar senhas, tokens e chaves de API diretamente da máquina do desenvolvedor.

🔓 Seu código gerado com IA pode estar criando brechas que você não consegue ver
SQL injection, autenticação incorreta e dados sensíveis expostos em logs são vulnerabilidades que LLMs podem introduzir em códigos — e que ferramentas de segurança tradicionais não foram desenhadas para capturar.

🇧🇷 Para líderes brasileiros de AppSec a maturidade não acompanha os riscos
Uma reportagem do TI Inside de dezembro de 2025 revelou que a maioria das organizações no Brasil adota IA para produtividade sem implementar os controles de segurança correspondentes.

✅ O que organizações maduras estão fazendo diferente — e como você pode replicar
Análise automática de todo código independente da origem, security gates específicos para padrões de IA, e rastreabilidade para auditoria são as práticas que separam quem previne de quem responde a incidentes.

O copiloto que ninguém auditou

Existe uma transformação silenciosa acontecendo em todo time de desenvolvimento do Brasil agora mesmo. Desenvolvedores que antes escreviam cada linha de código estão cada vez mais aceitando sugestões, completando prompts, e gerando funções inteiras com ferramentas como GitHub Copilot, ChatGPT, Gemini, Amazon CodeWhisperer, e dezenas de outras.

A produtividade aumentou. Os prazos ficaram mais fáceis de cumprir. O onboarding de novos desenvolvedores foi acelerado.

Nesse cenário, o volume de código não auditado que entra em produção todos os dias também aumentou — exponencialmente.

O blog oficial da Snyk publicou em 2025 uma análise abrangente sobre ferramentas, bem como os benefícios e riscos na geração de código por IA, que é leitura obrigatória para qualquer gestor de desenvolvimento ou segurança. O diagnóstico central é preciso: as ferramentas de IA de geração de código introduzem uma categoria nova de risco de segurança que as abordagens tradicionais de AppSec não foram desenhadas para capturar. (Fonte: Snyk Blog, “AI Code Generation: Code Security, Quality, Benefits, Risks, and Top Tools”, 2025)

O que a pesquisa mais recente revela sobre código gerado por IA

O Snyk AI Code Security Report — atualizado com dados de 2025 — analisou centenas de milhares de projetos que utilizam assistência de IA no desenvolvimento e chegou a conclusões que devem figurar em toda apresentação de riscos para o board:

Os três riscos principais do código gerado por IA, segundo a Snyk:

1. Alucinações de segurança Modelos de linguagem grandes (LLMs) são treinados para gerar código que parece correto e seguro. Mas “parecer” não é necessariamente “ser”. LLMs com frequência podem gerar código que usa funções depreciadas, implementar criptografia de forma incorreta, ou criar padrões de tratamento de erros que expõem informações sensíveis.

2. Confiança excessiva dos desenvolvedores Pesquisas consistentes mostram que desenvolvedores que usam ferramentas de IA tendem a revisar menos criticamente o código sugerido do que o código que escrevem eles mesmos. A IA cria uma heurística de “já foi validado” que não existe de fato.

3. Velocidade que supera a revisão A aceleração de produtividade proporcionada por IA significa que mais código entra no pipeline mais rápido. Se os processos de revisão de segurança não acompanham essa velocidade, a lacuna entre “código escrito” e “código auditado” cresce continuamente.

(Fonte: Snyk, “Secure AI-Generated Code”, 2025; Snyk Blog sobre geração de código por IA, 2025)

Os vetores de ataque que ninguém estava esperando: extensões do IDE

Em janeiro de 2026, a comunidade de segurança foi sacudida por uma descoberta que combina de forma perturbadora com o tema de código gerado por IA: extensões maliciosas do editor de código baseado em IA, VS Code, distribuindo malware.

A Hunt.io documentou em detalhes a cadeia de ataque de uma extensão chamada Anivia, que carregava o OctoRAT — um trojan de acesso remoto sofisticado. A extensão estava disponível no marketplace oficial do VS Code e tinha aparência completamente legítima. Uma vez instalada, ela:

• Exfiltrava variáveis de ambiente (onde ficam tokens de API, chaves AWS, strings de conexão com banco de dados)

• Capturava credenciais de repositórios git

• Executava comandos remotos no sistema do desenvolvedor

• Se movia lateralmente na rede corporativa

(Fonte: Hunt.io, “Malicious VSCode Extension Anivia OctoRAT Attack Chain”, janeiro de 2026)

Simultaneamente, a Infosecurity Magazine reportou que 19 extensões maliciosas do VS Code foram identificadas em uma única investigação em janeiro de 2026, representando um padrão coordenado de ataques ao ecossistema de desenvolvimento. (Fonte: Infosecurity Magazine, janeiro de 2026)

A conexão com IA é direta: à medida que desenvolvedores dependem mais de ferramentas de IA integradas ao ambiente de desenvolvimento, o VS Code se torna ainda mais central no fluxo de trabalho — e portanto ainda mais valioso como alvo. Extensões que prometem integrar LLMs locais, otimizar prompts para Copilot, ou melhorar a geração de código são exatamente o tipo de isca que um atacante usaria para distribuir malware nesse contexto.

A superfície de ataque que o código de IA cria nos seus pipelines

Vamos ser específicos sobre onde o código gerado por IA cria vulnerabilidades que chegam à produção sem detecção:

Injeção de SQL gerada por IA LLMs frequentemente geram código de acesso a banco de dados que concatena strings diretamente em queries, especialmente quando o contexto do prompt não especifica claramente o uso de queries parametrizadas. O resultado é: código que funciona perfeitamente — e que está vulnerável a SQL injection.

Tratamento incorreto de autenticação e autorização: Código de autenticação gerado por IA frequentemente apresenta falhas sutis: verificações de permissão implementadas no lugar errado no fluxo de execução, tokens validados de forma incompleta, entre outras.

Exposição de dados sensíveis em logs: LLMs tendem a gerar código de logging abrangente para facilitar o debugging — o que frequentemente resulta em dados pessoais, tokens de autenticação, ou informações de pagamento sendo escritos em logs. Para uma empresa sujeita à LGPD e às resoluções do BACEN, isso é uma violação em potencial com cada linha de log.

Dependências inseguras sugeridas por IA: Quando você pede a uma LLM que gere código para uma função específica, ela frequentemente sugere importar bibliotecas. Essas bibliotecas podem ter versões mais recentes com correções de segurança — mas a IA não tem como saber qual versão está atualizada no momento em que você está codificando.

O que os líderes de AppSec brasileiros dizem sobre isso

Em dezembro de 2025, o TI Inside publicou um levantamento com líderes de AppSec de empresas brasileiras que revelou um quadro preocupante: a maturidade de segurança de aplicações no Brasil não está acompanhando a velocidade com que as ameaças evoluem.

Os entrevistados apontaram especificamente a adoção acelerada de ferramentas de IA no desenvolvimento como um dos principais fatores que ampliaram a superfície de risco sem a correspondente evolução dos controles de segurança. A maioria das organizações avança na adoção de IA para produtividade — mas pouquíssimas têm políticas formais de governança de segurança para o código que essas ferramentas produzem. (Fonte: TI Inside, dezembro de 2025)

Isso cria um gap que é, ao mesmo tempo, técnico e regulatório. A Resolução BCB nº 538/2025,publicada em dezembro de 2025, é o normativo de cibersegurança mais prescritivo já emitido pelo Banco Central. Em seu Art. 3º, §3º, ela estende explicitamente os controles de segurança ao desenvolvimento de sistemas e à adoção de novas tecnologias, inclusive IA — o que significa que usar Copilot ou ChatGPT para gerar código sem governança de segurança correspondente não é apenas um risco técnico: é não conformidade regulatória documentada. A CMN nº 5.274 complementa esse cenário reforçando os requisitos de gestão de vulnerabilidades e rastreabilidade em toda a cadeia de fornecimento de software.

[A Duranium desenvolveu uma calculadora de assessment gratuita que aponta em minutos os principais gaps da sua organização em relação às novas exigências — antes que o regulador os encontre por você.

👉 assessment.duranium.io ]

O que organizações maduras estão fazendo diferente

A Snyk, em sua documentação de boas práticas para segurança de código gerado por IA publicada em 2025, descreve o modelo que organizações de segurança madura adotam:

Análise automática de todo código — independente da origem A regra é simples: se o código vai para o repositório, ele passa pela análise de segurança. Não importa se foi escrito por um desenvolvedor sênior, um estagiário, ou o GitHub Copilot. A política é uniforme.

Contexto de segurança em prompts de IA Times maduros desenvolvem bibliotecas de prompts padronizados que incluem contexto de segurança — especificando explicitamente o uso de queries parametrizadas, autenticação adequada, e tratamento seguro de dados. Isso não elimina o risco, mas reduz significativamente a taxa de código inseguro gerado.

Security gates específicos para padrões de IA O Snyk DeepCode AI foi treinado especificamente para identificar padrões de vulnerabilidade que emergem com frequência em código gerado por LLMs — padrões que ferramentas de SAST tradicionais, treinadas em código humano, frequentemente deixam passar.

Rastreabilidade de código gerado por IA Para fins de auditoria e conformidade, organizações maduras mantêm metadados sobre qual código foi gerado por IA versus escrito por humanos — permitindo revisões direcionadas e demonstração de controles para reguladores.

(Fonte: Snyk, “Secure AI-Generated Code”, 2025)

Como a Snyk endereça especificamente os riscos de 2026

A Snyk não é uma ferramenta de segurança que existia antes da IA e simplesmente “adicionou suporte” para código de IA como feature de roadmap. Ele foi ativamente desenvolvido para o mundo onde IA e desenvolvimento de software são inseparáveis:

Snyk Code (SAST) Análise estática que usa IA para identificar vulnerabilidades semânticas — não apenas padrões sintáticos. Integrado ao VS Code, JetBrains, e outros IDEs, funciona como um revisor de segurança em tempo real enquanto o desenvolvedor (ou a IA) escreve.

Snyk Open Source (SCA) Análise de composição de software que mapeia todo o grafo de dependências, incluindo transitivas, com atualização contínua do banco de dados de CVEs. Quando o CVE-2026-21858 é publicado, a detecção é automática e imediata.

Snyk DeepCode AI Motor de análise específico para padrões de código gerado por IA, treinado em centenas de milhões de exemplos para identificar as categorias de vulnerabilidade mais comuns introduzidas por LLMs.

Snyk Container Análise de imagens de contêiner para garantir que vulnerabilidades não se propagam para os artefatos de deploy.

Integração com GitHub Copilot e outros assistentes A Snyk se integra diretamente com ferramentas de IA no IDE para fornecer feedback de segurança antes que o código gerado seja aceito — não depois que já foi commitado.

A implementação Duranium: feita para o contexto brasileiro

A Duranium não é apenas um revendedor da Snyk. Somos especialistas em fazer com que a segurança de código funcione no contexto específico das organizações brasileiras — com suas particularidades regulatórias, suas stacks tecnológicas, e suas equipes de desenvolvimento que têm muito trabalho e pouco tempo para lidar com falsos positivos e ferramentas que atrapalham mais do que ajudam.

Nossa metodologia em quatro fases foi desenhada para entregar valor rápido e conformidade sustentável:

Fase 1 — Assessment (1 semana): Análise do estado atual do código e pipeline, com identificação das 10 vulnerabilidades mais críticas presentes hoje.

Fase 2 — Quick Win (2 semanas): Correção das vulnerabilidades mais críticas com suporte hands-on. Resultado mensurável e apresentável para a diretoria em menos de 30 dias.

Fase 3 — Implementação (4–6 semanas): Integração completa com CI/CD, configuração de security gates, políticas de governança para código de IA.

Fase 4 — Governança contínua: Relatórios de conformidade BACEN, treinamento do time em DevSecOps, expansão das políticas conforme a organização evolui.

A pergunta que não pode ficar sem resposta

Com extensões maliciosas no VS Code exfiltrando credenciais, CVEs críticos surgindo toda semana em janeiro de 2026, e o código gerado por IA entrando nos seus repositórios em escala crescente — você sabe o que está vulnerável no seu ambiente agora mesmo?

Se a resposta não for um “sim” fundamentado em dados e ferramentas, é hora de mudar isso.

Agende um Assessment com a Duranium e você terá a resposta.

FALE COM A DURANIUM

Assine agora

No cenário frenético do final de 2025, um projeto de código aberto chamado “Clawdbot” alcançou o tipo de saturação meteórica e repentina que geralmente precede uma aquisição multimilionária.

Com mais de 80.000 estrelas no GitHub, a ferramenta foi aclamada como o agente de IA local definitivo — um assistente privado e autônomo capaz de administrar a vida digital de um usuário, desde o gerenciamento de conversas no WhatsApp até a execução de comandos no terminal.

O hype era tão grande que até as vendas de hardware dispararam; usuários estavam comprando Mac minis apenas para servirem como servidores locais dedicados para o bot.

Mas por trás do crescimento viral estava o “paradoxo da IA ​​local”. A própria arquitetura construída para garantir a privacidade — executando localmente com acesso total ao sistema — tornou-se o vetor exato para algo catastrófico.

Nessa história, uma advertência legal de um gigante corporativo desencadeou um efeito dominó de erros induzidos pelo pânico, roubo de identidade e um prejuízo financeiro de US$ 16 milhões.

É um lembrete sombrio de que, na era dos agentes autônomos, a distância entre a “vanguarda” e o “comprometimento total” é medida em segundos.

Lição 1: A Armadilha da Marca Registrada e a “Muda”

A trama não começou com uma exploração sofisticada, mas com um e-mail “educado” da Anthropic. A gigante da IA ​​por trás dos modelos Claude alegou que o “Clawdbot” — apesar de sua marca ser um trocadilho literal com lagostas — infringiu sua marca registrada.

Essa pressão legal colocou o projeto em uma posição precária, demonstrando como até mesmo as comunidades de código aberto mais robustas permanecem vulneráveis ​​à enorme influência das corporações dominantes na IA.

Após uma votação frenética da comunidade às 5 da manhã no Discord, Peter Steinberger, o fundador do projeto, iniciou uma reformulação forçada da marca. O tema da lagosta foi mantido, mas o projeto foi rebatizado de “Moltbot”, uma referência ao processo de troca de carapaça dos crustáceos.

“A mesma alma de lagosta, com uma carapaça nova.”

Essa “muda” - como se chama o processo de troca de carapaça em crustáceos -, no entanto, provaria ser muito mais perigosa do que a ameaça legal da qual foi projetada para escapar.

Lição 2: O Sequestro de 10 Segundos

A falha mais devastadora ocorreu durante a execução da reformulação da marca. Em uma transição que só pode ser descrita como induzida pelo pânico, Steinberger tentou trocar simultaneamente a organização do projeto no GitHub e os nomes de usuário do X (antigo Twitter) para manter a consistência da marca. O que se revelou um erro.

Nos segundos entre Steinberger liberar os nomes de usuário “@clawdbot” e tentar registrar os novos equivalentes “@moltbot”, agentes maliciosos — que vinham monitorando o projeto — atacaram. Esses invasores sequestraram com sucesso os nomes de usuário originais, roubando efetivamente a prova social de um projeto com 80.000 estrelas em uma janela de segundos.

“Tem alguém do GitHub na minha timeline que possa me ajudar a recuperar minha conta? Ela foi roubada por golpistas de criptomoedas.” — Peter Steinberger

Isso foi um sequestro de prova social em grande escala. Ao se apropriarem da identidade original, os golpistas tiveram acesso imediato e confiável a um público enorme e desavisado.

Lição 3: O Token Fantasma de US$ 16 Milhões

Com o nome de usuário @clawdbot em segurança, os atacantes partiram para um golpe clássico. Eles lançaram um token falso chamado “CLAWD” na blockchain Solana, usando a visibilidade roubada do projeto para atrair especuladores.

As consequências financeiras foram rápidas. Impulsionada pela reputação viral do projeto, a capitalização de mercado do token CLAWD explodiu para US$ 16 milhões em poucas horas. Quando a bolha inevitavelmente estourou, os investidores da fase final perderam tudo.

Apesar das negações públicas imediatas e repetidas de Steinberger sobre qualquer envolvimento com criptomoedas, o estrago já estava feito. Investidores “arruinados” lançaram uma campanha coordenada de assédio contra ele, exigindo que ele “assumisse a responsabilidade” por suas perdas.

Lição 4: O Banquete de Segurança da “Autenticação Zero”

Enquanto o roubo de identidade se desenrolava nas redes sociais, pesquisadores de segurança descobriram que o próprio software era um “banquete” de vulnerabilidades. Os pesquisadores Luis Catacora e Jamieson O’Reilly usaram varreduras do Shodan para encontrar centenas de instâncias do Moltbot expostas à internet pública na porta 18789.

O cerne do problema era uma falha de autenticação em “localhost”. O sistema foi projetado para autorizar automaticamente qualquer conexão originada da máquina do próprio usuário (127.0.0.1).

No entanto, quando usuários inexperientes implantaram o bot por trás de um proxy reverso — uma prática padrão para habilitar acesso remoto — o software tornou-se um pesadelo de segurança. Como o proxy reside na mesma máquina ou rede, ele encaminha o tráfego externo para o bot, fazendo com que o software veja o IP interno do proxy (127.0.0.1) em vez do IP externo do atacante. Isso concedia acesso irrestrito a qualquer servidor remoto.

Além da falha de proxy, o projeto enfrentou uma enorme superfície de ataque por meio de injeção de prompt. Os pesquisadores demonstraram que um PDF ou e-mail malicioso poderia enganar a IA para executar comandos ocultos, como encaminhar silenciosamente as mensagens privadas de um usuário para o servidor de um invasor externo.

“Exposição do gateway do Clawdbot identificada: centenas de chaves de API e registros de bate-papo privados estão em risco. Várias instâncias não autenticadas são acessíveis publicamente e diversas falhas de código podem levar ao roubo de credenciais e até mesmo à execução remota de código (RCE).” — Alerta da Equipe X da SlowMist.

Lição 5: Roubo de Contexto Cognitivo

A descoberta mais assustadora feita por pesquisadores da InfoStealers foi o surgimento do “Roubo de Contexto Cognitivo”. Como o Moltbot foi projetado para “lembrar” a vida digital de um usuário — fluxos de trabalho, rotinas e contatos — ele armazena perfis confidenciais e tokens de autenticação em arquivos de texto simples na máquina host.

Essa arquitetura transformou a IA em uma mina de ouro centralizada para operadores de Malware como Serviço (MaaS).

Famílias de malware estabelecidas, como Vidar, RedLine e Lumma, já começaram a adaptar seus códigos para atacar esses bancos de dados de IA locais não criptografados.

A ironia é total: um projeto comercializado com base na premissa de privacidade local criou um mapa abrangente e em texto simples de toda a existência digital de um usuário, pronto para ser exfiltrado em uma única varredura.

Conclusão: A Lacuna na Postura de Segurança do Setor

A saga do Moltbot prova que a economia da adoção de IA está se movendo em uma velocidade que as auditorias de segurança não conseguem acompanhar. Embora o software continue sendo uma ferramenta poderosa para tarefas autônomas, sua implantação para usuários “novatos” sem configurações de segurança padrão reforçadas criou a tempestade perfeita para exploração.

À medida que avançamos para um futuro definido por agentes autônomos com acesso total ao sistema, devemos preencher a lacuna entre utilidade viral e rigor técnico. A “janela do caos” para qualquer projeto de tecnologia moderno não é mais medida em dias, mas nos segundos que leva para clicar em “renomear”.

A questão fundamental da era digital permanece: os usuários estão realmente preparados para deter as chaves de toda a sua existência digital quando as fechaduras são tão fáceis de arrombar?

Na Duranium construímos jornadas completas para que empresas implementem IA sem transformar inovação em vulnerabilidade. Se você está nessa jornada e quer conversar sobre como fazer isso do jeito certo, fale com a gente: contato@duranium.com

A explosão da inteligência artificial generativa está criando uma urgência sem precedentes na segurança de dados corporativos. Segundo análise recente do Gartner, até 2026, três em cada quatro organizações que adotam GenAI precisarão redirecionar seus investimentos em segurança, saindo de dados estruturados para focar em dados não estruturados.

O Novo Cenário de Riscos

A adoção massiva de ferramentas como ChatGPT, Gemini e outras aplicações de IA trouxe riscos que muitas empresas ainda não compreenderam totalmente:

Proliferação descontrolada de dados através de migrações cloud e ambientes multicloud, dificultando rastreamento e controle.

Exposição acidental de informações sensíveis quando colaboradores usam chatbots de IA sem políticas claras de proteção.

Multas regulatórias crescentes com a multiplicação de leis de privacidade globais (GDPR, LGPD, CCPA, PIPL).

O alerta mais grave do Gartner: até 2027, pelo menos uma grande empresa global terá sua implementação de IA banida por reguladores devido a falhas em conformidade com proteção de dados.

O Que Muda na Prática

Detecção de intenção em tempo real
Organizações que incorporarem capacidades de detecção de intenção e remediação em tempo real em seus programas de prevenção de perda de dados devem reduzir riscos internos em 33% até 2027.

Foco em dados não estruturados
A mudança de investimentos reflete uma realidade: a maioria dos dados críticos hoje não está em bancos de dados tradicionais, mas em documentos, e-mails, chats e interações com IA.

Consolidação de ferramentas
Empresas estão migrando de múltiplas soluções isoladas para plataformas integradas de segurança de dados, reduzindo complexidade e custos operacionais.

Recomendações Práticas do Gartner

Para implementação imediata:

• Estabeleça políticas claras e restritivas para uso de ferramentas de IA generativa até que controles adequados estejam implementados

• Traduza riscos técnicos de dados em impactos de negócio compreensíveis para stakeholders

• Invista em descoberta e classificação automatizada de dados, especialmente os não estruturados

• Implemente criptografia e gerenciamento de chaves como proteção proativa, não apenas controles reativos

Para planejamento estratégico:

• Desenvolva um programa multidisciplinar de segurança de dados que integre processos, políticas e tecnologias

• Priorize visibilidade sobre uso criptográfico e prepare-se para a transição pós-quântica

• Avalie plataformas DSPM (Data Security Posture Management) para identificar repositórios desconhecidos em ambientes cloud

• Considere técnicas de mascaramento de dados e dados sintéticos para uso seguro em projetos de IA

O Fator Humano

Um dos maiores desafios identificados: muitos usuários não compreendem como suas interações com ferramentas de IA podem comprometer dados corporativos sensíveis. Programas de alfabetização em dados tornaram-se críticos, não apenas para conformidade, mas para criar uma cultura de decisões orientadas por dados de forma segura.

Próximos Passos

A mensagem do Gartner é clara: segurança de dados deixou de ser apenas proteção contra ameaças externas. É agora um diferencial competitivo que determina quem pode inovar com IA de forma segura e quem ficará para trás — ou pior, enfrentará banimentos regulatórios.

O momento de agir é agora. Organizações que esperarem por uma solução perfeita ou um incidente grave para reagir já estarão em desvantagem significativa.

FALE COM A DURANIUM

Na Duranium, ajudamos empresas a avaliarem sua maturidade em segurança de dados e implementarem programas efetivos para a era da IA. Entre em contato para uma avaliação inicial.

Baseado em pesquisa estratégica do Gartner para líderes de segurança e gestão de riscos.

Compartilhar