Existe uma narrativa comum dentro das empresas de tecnologia: a de que desenvolvedores estão sobrecarregados porque o volume de trabalho aumentou, mas, olhando com mais atenção, o problema não é exatamente esse.
Os dados mais recentes mostram um cenário mais complexo e desconfortável.
Segundo a Atlassian, embora 99% dos desenvolvedores já utilizem IA e 68% relatem economizar mais de 10 horas por semana com essas ferramentas, metade ainda perde 10 horas ou mais em atividades que não envolvem codificação. E 90% perdem pelo menos 6 horas semanais em tarefas como buscar informação, alternar entre ferramentas e lidar com ineficiências operacionais.
Ou seja: o tempo está sendo ganho de um lado e perdido do outro.
A produtividade não está sendo limitada apenas pelo volume de trabalho. Está sendo drenada por fricção.
O problema invisível: trabalho quebrado
Dentro desse cenário, AppSec ocupa um papel central, e muitas vezes mal compreendido.
A forma como a segurança é implementada em grande parte das organizações ainda segue um modelo fragmentado com múltiplos scanners, múltiplos dashboards e múltiplos fluxos de análise, cada um gerando sinais isolados, sem uma visão consolidada de risco.
Na prática, isso transforma o desenvolvedor em um “correlacionador manual” de informação.
Ele precisa entender qual finding importa, descobrir se aquilo é realmente crítico, identificar a origem do problema e só então decidir como corrigir.
Esse processo não é só ineficiente. Ele é cognitivamente caro.
Cognitive load: o verdadeiro gargalo
Hoje, um dos conceitos mais importantes para entender esse cenário é o de carga cognitiva (cognitive load).
Não se trata de quantas tarefas um desenvolvedor tem, mas de quanta energia mental ele precisa gastar para executá-las.
Alternar entre ferramentas, interpretar dados desconectados, lidar com tickets pouco claros e navegar entre múltiplos contextos quebra o fluxo de trabalho, o chamado flow state, onde o desenvolvimento de alta qualidade realmente acontece.
Pesquisas da Microsoft mostram que quanto maior a distância entre a “semana ideal” de um desenvolvedor (focada em codificação, arquitetura e resolução de problemas) e a “semana real” (marcada por interrupções, comunicação fragmentada e tarefas operacionais), menor a produtividade e a satisfação.
Nesse contexto, segurança mal integrada é um problema de desempenho humano.
Quando segurança vira backlog permanente
Esse modelo fragmentado tem um efeito direto sobre a postura de segurança.
Segundo dados recentes da Veracode, 82% das organizações carregam dívida crítica de segurança, com um crescimento de 36% nas vulnerabilidades de alto risco.
Isso não acontece porque as empresas não sabem o que corrigir. Acontece porque o processo de correção não escala.
Quando os desenvolvedores passam mais tempo entendendo o problema do que resolvendo, o backlog cresce. Quando as correções são feitas de forma pontual, sem atacar a causa raiz, os problemas se repetem.
O resultado é um ciclo contínuo:
mais código → mais findings → mais esforço manual → mais atraso → mais dívida
E, inevitavelmente, mais desgaste.
IA: solução parcial, problema ampliado
A introdução de IA no desenvolvimento trouxe ganhos reais, mas também revelou um desequilíbrio importante.
Enquanto ferramentas de IA aceleram a criação de código e reduzem tarefas mecânicas, os processos ao redor, especialmente os ligados à segurança, continuam operando com o mesmo nível de fricção.
Isso cria um cenário paradoxal:
Mais código sendo produzido mais rápido;
Mais vulnerabilidades sendo geradas;
Mas o mesmo modelo de triagem e remediação.
A consequência é clara: a velocidade de geração de risco passa a superar a capacidade de resolução.
A IA resolve parte do problema, mas, sem mudança de modelo, também amplifica o restante.
O erro mais comum: adicionar ferramenta em vez de remover fricção
Diante desse cenário, muitas organizações seguem um caminho previsível: adicionam mais ferramentas.
Mais scanners.
Mais dashboards.
Mais camadas de controle.
Mas isso raramente resolve o problema.
Porque o gargalo não está na falta de visibilidade. Está na falta de correlação, contexto e ação integrada.
Sem isso, cada nova ferramenta adiciona mais ruído, mais contexto a ser interpretado e mais carga cognitiva para o desenvolvedor.
O que muda o jogo: sair de “finding” para “resolução”
O que a pesquisa aponta com bastante clareza é que a evolução necessária em AppSec não é incremental.
É estrutural.
O foco precisa sair de encontrar mais vulnerabilidades e ir para resolver melhor, e com menos esforço, as vulnerabilidades que realmente importam.
Isso implica algumas mudanças importantes:
Consolidação de contexto
Não basta listar findings. É preciso conectar vulnerabilidade, código, dependência e impacto em um mesmo fluxo.
Remediação orientada à causa raiz
Corrigir um problema na origem, evitando sua repetição, em vez de tratar sintomas isolados.
Automação do trabalho repetitivo
Triagem, priorização, deduplicação e roteamento não devem depender de esforço manual.
Integração ao fluxo de desenvolvimento
Segurança precisa acontecer dentro do workflow, não como uma camada externa que interrompe o trabalho.
AppSec como problema de arquitetura operacional
O ponto mais importante dessa discussão é que AppSec deixou de ser apenas um problema de segurança.
Ela passou a ser um problema de arquitetura de trabalho.
Organizações que continuam tratando segurança como atividade separada tendem a aumentar custo operacional, reduzir velocidade de entrega e sobrecarregar seus times.
Por outro lado, empresas que tratam segurança como parte do fluxo, com padronização, automação e contexto, conseguem reduzir esforço, melhorar qualidade e manter o ritmo de desenvolvimento.
O burnout em desenvolvimento não é um acidente.
Ele é o resultado previsível de sistemas de trabalho mal desenhados.
E, dentro desses sistemas, AppSec tem um papel central.
Não porque exista segurança demais, mas porque ela ainda é, em muitos casos, operacionalizada da forma errada.
O desafio, portanto, não é fazer o desenvolvedor lidar melhor com a segurança.
É fazer a segurança exigir menos esforço desnecessário.
Porque, no fim, a pergunta não é quantas vulnerabilidades você consegue encontrar.
É quanto da sua capacidade de engenharia está sendo consumida no processo de lidar com elas.
Fontes
Atlassian — State of Developer Experience 2025
Microsoft Research — The Gap Between Ideal and Real Developer Workweeks
GitLab — Global DevSecOps Report 2024
Veracode — State of Software Security 2026
Google Cloud — Internal Developer Platforms & Cognitive Load
DORA — AI and Software Delivery Performance Insights
Posts recentes
