Na era da IA, o dev senior não é medido apenas pela quantidade de código que produz. Seu valor aparece ao escolher o problema certo, testar a resposta da ferramenta e decidir o que pode entrar em produção.

O dev senior decide antes de pedir código

Uma solicitação vaga costuma produzir uma resposta difícil de avaliar. Antes de abrir um assistente, o profissional precisa definir o comportamento esperado, as restrições técnicas e o que não pode mudar.

Considere um checkout que registra o pagamento, mas deixa o pedido em estado indefinido quando a confirmação demora. O pedido correto não é "melhore o checkout". É descrever os estados possíveis, o comportamento de uma nova tentativa e os registros que precisam permanecer consistentes. A IA pode sugerir uma implementação. O dev senior decide se a regra representa o negócio.

IA produz código; o dev senior responde pelo julgamento

O estudo da METR exige cautela com a ideia de aceleração automática. Em um experimento randomizado com 16 desenvolvedores experientes e 246 tarefas reais de código aberto, permitir ferramentas de IA aumentou em 19% o tempo de conclusão, embora os participantes previssem aceleração.

Isso não prova que toda tarefa com IA fica mais lenta. Mostra que a familiaridade com a base, o custo de revisão e o tipo de tarefa mudam o resultado. Em um módulo de autenticação, por exemplo, aceitar uma implementação pronta sem revisar permissões, tratamento de erros e migrações pode economizar digitação e criar trabalho de correção.

A IA amplifica a forma de trabalho

O relatório DORA de 2025 descreve a IA como um amplificador das forças e fraquezas existentes. Seus maiores retornos dependem mais do sistema organizacional ao redor da ferramenta do que da ferramenta isolada.

Se o backlog não tem prioridade, o código não tem testes que expressem o comportamento e ninguém responde pela decisão, gerar mais sugestões aumenta o volume a revisar. Se há objetivo claro, critérios de aceite, revisão e uma forma de observar o comportamento em produção, a equipe consegue julgar cada mudança com menos ambiguidade. Essa é uma aplicação prática do achado do DORA, não uma promessa de ganho automático.

Na LYPES, o uso de IA precisa estar ligado a um problema de produto ou de operação. A pergunta não é quanto código a ferramenta consegue produzir. É qual mudança melhora a eficácia, a eficiência ou a qualidade sem criar um risco que a equipe ainda não consegue avaliar.

Como o dev senior verifica uma sugestão de IA

A pesquisa da Stack Overflow mostra que a confiança tem condição. Quase metade dos desenvolvedores confia na IA apenas quando consegue verificar facilmente o resultado. Somente 6,6% a consideram confiável para decisões importantes, e 78,7% valorizam a atribuição de fontes.

Um fluxo de trabalho mínimo transforma essa condição de confiança em verificação:

  • Defina o problema com o resultado esperado, as restrições e o critério que permite rejeitar a sugestão.
  • Peça uma mudança limitada, com arquivos e comportamento definidos, em vez de uma reescrita ampla.
  • Leia o diff, execute os testes relevantes e confira casos de erro, segurança, performance e manutenção.
  • Registre a decisão, as hipóteses e as fontes consultadas para que outra pessoa consiga revisar o raciocínio.

Para uma alteração que muda o cálculo de frete, por exemplo, a validação deve cobrir entradas conhecidas, limites, arredondamentos, falhas do serviço externo e o efeito sobre um pedido já criado. O código parece correto quando passa pelo caminho feliz. O julgamento aparece nas condições que podem quebrá-lo.

Se a equipe convive com backlog, retrabalho ou decisões técnicas difíceis de priorizar, converse com a LYPES para discutir as melhorias prioritárias e avaliar se o próximo passo pede correção, evolução ou modernização.