Henrique Mauri

Posted on Oct 24 Originally published at henriquemauri.net

O papel do desenvolvedor .NET na era da IA

#dotnet #ai #career #programming

Recentemente fiz uma palestra para o time da Dotcode com o mesmo título deste artigo. Foram duas horas de conversa, dados, uma demonstração prática com IA em um projeto .NET real e muitas perguntas no final. A pergunta que mais apareceu, de formas diferentes, foi sempre a mesma: qual é o nosso papel agora?

Resolvi transformar essa conversa em texto, porque acredito que ela vale para qualquer desenvolvedor .NET, não só para o meu time. E vou começar pela frase que abriu a palestra:

Escrever código ficou barato. Decidir qual código escrever ficou caro.

O que os dados dizem (e o que o hype não conta)

Antes de opinar, gosto de olhar números. E os números sobre IA no desenvolvimento de software contam uma história bem mais interessante do que os vídeos de “criei um SaaS em 10 minutos” que circulam por aí.

A adoção já é praticamente universal. O relatório DORA 2025, do Google, ouviu quase 5 mil profissionais de tecnologia: 90% já usam IA no trabalho.
Mas a confiança é baixa. Na pesquisa da Stack Overflow de 2025, apenas 3% dos desenvolvedores disseram confiar muito no que a IA gera.
Sentir-se mais rápido não é o mesmo que ser mais rápido. Em um estudo controlado do METR, desenvolvedores experientes esperavam ganhar 24% de velocidade com IA. Na prática, levaram 19% mais tempo. E mesmo depois do experimento, continuavam achando que tinham sido mais rápidos. O estudo tem limitações (16 desenvolvedores, projetos que eles já conheciam muito bem, ferramentas de 2025), mas o recado é claro: percepção não é métrica.
Segurança não acompanhou a velocidade. O relatório da Veracode de 2025 mostrou que o código gerado por IA introduziu vulnerabilidades em 45% das tarefas testadas. A edição de 2026 indicou que o cenário praticamente não melhorou.

Nada disso significa que a IA não funciona. Eu uso IA todos os dias e o ganho é real. Significa que o ganho não vem da ferramenta sozinha. Vem de quem a conduz.

A IA é um amplificador

A conclusão central do DORA 2025 resume bem o que vejo nos projetos: a IA amplifica. Times com bons processos, boa arquitetura e boas práticas ficam ainda melhores. Times desorganizados produzem mais desorganização, só que mais rápido.

Gosto de uma analogia histórica para explicar isso. Quando a eletricidade chegou às fábricas, no fim do século XIX, muitas delas simplesmente trocaram o grande motor a vapor por um grande motor elétrico e mantiveram todo o resto igual: o mesmo layout, os mesmos eixos e correias, o mesmo fluxo de trabalho. O ganho de produtividade foi pequeno. Ele só apareceu décadas depois, quando as fábricas foram redesenhadas em torno da nova tecnologia.

Com a IA está acontecendo a mesma coisa. Colocar um assistente de código em cima de um processo ruim é trocar o motor e manter as correias. A IA não conserta processo quebrado. Ela acelera o que já existe.

De quem escreve código para quem responde pelo resultado

Se a IA escreve boa parte do código, o que sobra para o desenvolvedor? Na minha visão, sobra a parte mais valiosa. O papel muda de foco:

Antes: o valor estava em saber escrever código. Agora: o valor está em saber o que deve ser escrito e por quê.
Antes: a sintaxe e a API decoradas eram diferenciais. Agora: contexto, critério e capacidade de revisão são os diferenciais.
Antes: o desenvolvedor executava tarefas. Agora: o desenvolvedor orienta agentes, valida entregas e responde pelo resultado.

Pense em um piloto de avião. O piloto automático faz a maior parte do voo, mas ninguém embarcaria em um avião sem piloto. Ele é quem define a rota, monitora, decide e assume o controle quando algo sai do esperado. É exatamente esse o papel que o desenvolvedor passa a ter.

Entender o negócio vem antes do prompt

Aqui está o ponto que mais insisti com o time: o desenvolvedor que vai se destacar é o que entende mais de negócio, não o que conhece mais frameworks. Tecnologia continua sendo obrigatória, mas deixou de ser suficiente.

A IA é excelente em responder perguntas bem formuladas. O problema é que ela não sabe quais perguntas importam para o seu cliente. Antes do primeiro prompt, eu recomendo responder cinco perguntas:

Qual problema de negócio estamos resolvendo?
Quem vai usar e em qual situação?
Como vamos medir se deu certo?
Quais regras, restrições e integrações existem?
O que acontece se isso der errado?

Quem responde bem a essas perguntas escreve prompts melhores, revisa com mais critério e entrega soluções que o cliente realmente usa. Quem pula essa etapa entrega código bonito resolvendo o problema errado.

O que continua sendo responsabilidade sua

A IA gera código. Mas algumas coisas não podem ser delegadas:

Arquitetura: decidir camadas, contratos, dependências e como o sistema vai evoluir.
Segurança: tratar todo código gerado como código de terceiros, que precisa ser revisado e testado.
Performance: a IA costuma gerar código que funciona, mas nem sempre código que escala. Um N+1 no Entity Framework passa facilmente em um teste local e derruba a aplicação em produção.
Testes e validação: se você não consegue provar que funciona, não está pronto.
Decisão: escolher entre duas soluções válidas considerando prazo, custo e risco do negócio.

Por que o .NET é um ótimo lugar para estar

Tenho uma opinião clara aqui: o desenvolvedor .NET está em uma posição privilegiada nessa transição.

Primeiro, porque tipagem forte e compilador são o primeiro revisor do código gerado pela IA. Boa parte dos erros que passariam despercebidos em linguagens dinâmicas é barrada antes mesmo de rodar. Some a isso os analisadores do Roslyn, o nullable reference types e uma boa suíte de testes, e você tem guard-rails automáticos para trabalhar com IA.

Segundo, porque o ecossistema evoluiu muito rápido. Hoje temos o Microsoft.Extensions.AI como abstração comum para modelos, o Microsoft Agent Framework para construir agentes (escrevi sobre ele no artigo anterior) e o SDK oficial de MCP em C# para expor nossas APIs para agentes de IA.

Terceiro, porque o .NET é forte justamente onde a IA corporativa vai rodar: sistemas de negócio, integrações com ERP, APIs críticas e ambientes Azure. Quem domina esses sistemas e aprende a conectar IA a eles tem um diferencial enorme.

Como eu uso a IA no dia a dia com .NET

Na demonstração da palestra, usei o Claude Code em um projeto .NET. O que faz diferença não é o prompt perfeito, é o contexto. Por isso, todo projeto deveria ter um arquivo de instruções para a IA com as regras do time. Um exemplo simplificado de CLAUDE.md:

# Projeto Pedidos.Api

## Arquitetura
- Clean Architecture: Domain, Application, Infrastructure e Api
- Regras de negócio ficam no Domain, nunca nos controllers

## Convenções
- .NET 10, C# com nullable habilitado
- Entity Framework Core: sempre usar AsNoTracking em consultas de leitura
- Nunca concatenar strings em consultas SQL

## Antes de concluir qualquer tarefa
- Rodar dotnet build sem warnings
- Rodar dotnet test e garantir que todos os testes passam

Com esse contexto, a IA para de “chutar” o padrão do projeto e passa a seguir as decisões que o time já tomou. E repare: escrever esse arquivo exige justamente conhecimento de arquitetura e de negócio. A IA executa, mas quem define as regras é você.

Como se destacar: um plano prático

Terminei a palestra com um plano simples, que deixo aqui para quem quiser começar:

30 dias: use IA em todas as tarefas do dia a dia e meça. Anote quanto tempo levou, quantas vezes precisou corrigir e onde ela errou. Pare de confiar na sensação de produtividade.
60 dias: crie o arquivo de contexto do seu projeto, automatize build e testes como validação obrigatória e aprofunde-se no negócio do cliente que você atende.
90 dias: construa algo com IA dentro do produto, não só com IA no editor. Um agente, uma integração via MCP, uma automação que gere valor real para o usuário.

Conclusão

A IA não vai substituir o desenvolvedor .NET. Mas o desenvolvedor que entende de negócio, domina arquitetura e sabe conduzir a IA vai substituir o que apenas escreve código.

Se eu tivesse que resumir tudo em uma frase, seria a que usei para encerrar a palestra:

A IA escreve o código. Você responde pelo resultado.

Entenda o negócio, decida a arquitetura, oriente os agentes e valide tudo. IA do jeito certo, sem hype, só resultado.

E você, como está usando a IA no seu dia a dia com .NET? Deixe nos comentários, quero muito saber.

Referências

Publicado originalmente em henriquemauri.net.

DEV Community