O Dev que irá sobreviver
1. O profissional diferenciado é o que conhece o negócio
O que diferencia um profissional hoje é o seu conhecimento do negócio e a visão voltada para o produto. O domínio técnico continua sendo a base, mas deixou de ser o ponto principal que separava um profissional de outro. O que separa é conhecer o negócio: entender de que a empresa precisa, onde dói, o que custa, e medir o próprio trabalho pelo efeito que ele produz ali, não pelo conhecimento acumulado nem pela tarefa concluída.
Uma decisão técnica boa depende do que não está no código — a meta do negócio, o que a infraestrutura aguenta, como o time trabalha. Por isso o arquiteto precisa conversar com as áreas de negócio, de infraestrutura e de processos: quem só olha código decide no escuro. A mesma ideia, aplicada ao desenvolvedor, quem só reage a cards entrega o que foi pedido, e quem olha antes do card influencia o que vai ser pedido. É isso que se chama engenharia de software com mentalidade de produto.
Mas olhar para o negócio sem critério vira frustração ou desperdício. O freio vem de duas ideias que anotei no evento. A primeira: observar os problemas importantes que estão ao seu alcance, ou seja, aqueles que você pode resolver. A segunda: software sempre tem custo. A refatoração que não se faz custa zero; a que se faz custa tempo, risco de regressão e a revisão de alguém. Um problema pode ser real tecnicamente e não afetar o negócio — uma API que poderia ser mais rápida, mas é tão pouco usada que otimizá-la não muda nada. Trabalhar nela é esforço genuíno gasto onde não importa.
É aí que entra o "nenhum heroísmo sem métrica". Heroísmo não é trabalhar demais; é trabalhar no problema errado com dedicação. A métrica é o instrumento que impede isso, e ela faz dois trabalhos: escolhe a briga, mostrando qual problema vale atacar e defende a escolha. Um argumento técnico só admite concordar ou discordar, enquanto o número transforma opinião em decisão. Daí as anotações de que decisões precisam passar por métricas.
Entregar o que o negócio precisa também pede uma competência técnica específica: modelar bem a solução e decidir bem a estrutura. Ela é extremamente necessária e precisa ser aprendida — mas é o meio pelo qual o conhecimento do negócio vira sistema, não o diferencial em si.
2. A IA escreve o código
Escrever código, que era o ofício, passou a ser feito pela máquina. Se a máquina escreve, o que sobra de valioso no humano é decidir o que construir e julgar se o que foi produzido resolve o problema. Pensar arquitetura e negócio virou questão de sobrevivência, e a leitura crítica de código deixou de ser opcional.
Segundo o 2025 GenAI Code Security Report, da Veracode, 45% do código gerado por IA falhou em testes de segurança; As falhas mais frequentes foram log injection e XSS, e outra análise aponta que código de IA tem quase o dobro de chance de criar acesso indevido a dados de outro usuário (IDOR). Não é um defeito isolado do modelo: é reflexo do código público em que ele foi treinado. E, como a IA potencializa tanto o processo bom quanto o ruim, o processo precisa ser bem definido.
A parte que virou commodity é escrever; a parte que ficou mais valiosa é julgar com conhecimento do contexto.
3. O arcabouço em volta da IA
Se a máquina produz e o humano responde pela qualidade e pelo rumo, é preciso um arcabouço em volta da IA que faça com que ela entregue com mais precisão e confiabilidade. Ele tem duas frentes: modelar bem o que se constrói e cercar a produção da IA.
A primeira frente é a do harness que é tudo o que “envelopa” o modelo. O modelo é o motor; o harness é o carro (instruções, regras do projeto, testes, lint, conexões externas etc). Um bom harness tem contexto certo, regras explícitas e verificação. Existem várias estratégias que ajudam e melhoram a entrega da IA(harness), como: Multiagente, RAG, SDD etc.
A segunda frente é a da arquitetura — e estudá-la hoje é adquirir conhecimento voltado para o negócio. O DDD trata do que se modela: olhar o negócio, separar domínios, definir o onde e o como. A IA aumentou o custo de não ter fronteira clara: antes, código bagunçado custava o tempo do dev; agora custa também tokens, alucinações e sessões longas do agente, toda vez, para todo o time. A arquitetura virou documentação para a IA.
4. Como me torno esse profissional
Primeiro me tornar um profissional dedicado a entender o negócio da empresa, o contexto dos problemas. Um dev que se preocupe menos com “qual linguagem é melhor” e mais com “qual é a melhor forma de resolver esse problema no contexto da empresa”.
Trazendo uma visão mais técnica o estudo de maior alavanca no contexto atual é o que fica perto do problema diário: Arquitetura de software, DDD, segurança da informação, Design Patterns, TDD, concorrência e outros.
Esteja inserido na comunidade, mostre o seu trabalho, pergunte, tire dúvidas de outras pessoas, contribua, adquira e gere conhecimento. Isso faz uma grande diferença na sua vida profissional.
O profissional diferenciado é o que conhece o negócio e mede o próprio trabalho pelo efeito que causa na empresa. A IA tornou isso mais urgente, porque assumiu justamente a parte que deixou de ser diferencial.