Como capacitar desenvolvedores para usar IA

Depois de um curso de IA, a pergunta mais importante para a liderança técnica é simples: essa pessoa consegue usar a ferramenta em uma tarefa real sem abandonar julgamento, validação e comunicação? Uma pessoa capacitada para trabalhar com inteligência artificial precisa explicar a tarefa, formular uma hipótese de uso da IA, produzir uma saída verificável, revisar riscos e registrar aprendizado reutilizável. Para declarar autonomia, comece por uma avaliação curta, com trabalho real de baixa criticidade.

Por que curso concluído não prova capacidade de trabalho com IA

Um desenvolvedor pode concluir um curso, instalar uma ferramenta no editor, gerar código em segundos e ainda assim não estar pronto para usar IA com autonomia no fluxo de engenharia.

Isso não é contradição. É a diferença entre conhecer uma ferramenta e demonstrar capacidade de trabalho.

A presença da IA muda partes do processo, mas não remove as perguntas que sempre sustentaram boa engenharia: qual problema está sendo resolvido, quais restrições importam, que comportamento precisa permanecer, que risco foi introduzido e como a equipe vai verificar a mudança.

Quando a liderança mede capacitação apenas por horas de treinamento, ela corre o risco de aprovar uma habilidade performática: a pessoa sabe pedir algo à IA, mas não sabe avaliar se a resposta serve. O resultado pode parecer fluido em uma demonstração e frágil em uma base de código real.

A apresentação do relatório DORA 2025 descreve a IA como amplificadora de forças e fraquezas existentes na organização. Essa leitura é útil para a liderança porque desloca a pergunta. O ponto não é se a ferramenta impressiona. É se o sistema de trabalho permite usar a ferramenta com critério.

Esse cuidado também evita outro erro: tratar capacitação como evento isolado. O DORA relaciona cultura de aprendizagem ao desempenho de entrega de software e propõe tratar aprendizagem como investimento da organização. Isso não significa que todo uso de IA gere aprendizagem automaticamente. Significa que a equipe precisa desenhar mecanismos para transformar prática em repertório.

Se a empresa ainda está organizando sua direção mais ampla para IA, vale conectar este artigo ao guia sobre como criar uma estratégia de inteligência artificial conectada ao negócio. Mas aqui a decisão é menor e mais operacional: como saber se um desenvolvedor consegue trabalhar melhor com IA em uma tarefa concreta.

Quais tarefas reais servem para avaliar desenvolvedores usando IA

Uma boa avaliação prática de IA não precisa ser grande. Na verdade, quanto maior e mais ambígua a tarefa, mais difícil fica distinguir competência, sorte, familiaridade com o domínio e ajuda externa.

O melhor ponto de partida é escolher tarefas pequenas, frequentes e relevantes para a equipe. Elas devem representar trabalho que a pessoa realmente encontrará depois da capacitação.

Exemplos adequados:

refatorar um trecho de código com comportamento conhecido;
escrever ou ajustar testes para uma regra existente;
investigar um bug simples com escopo delimitado;
melhorar uma documentação técnica usada pela equipe;
comparar duas alternativas de implementação para uma mudança de baixa criticidade;
revisar uma alteração sugerida por IA antes de abrir uma solicitação de mudança.

O critério não é escolher uma tarefa fácil demais. É escolher uma tarefa em que seja possível observar julgamento técnico.

Tarefas artificiais demais premiam performance de demonstração. Um desafio criado apenas para gerar uma resposta bonita no prompt pode dizer pouco sobre o trabalho cotidiano da equipe. Por outro lado, tarefas críticas, com dados sensíveis ou impacto arquitetural alto, não são bons ambientes para avaliar autonomia inicial.

Uma regra prática: a tarefa deve ter contexto suficiente para exigir decisão, mas risco baixo o bastante para permitir observação e correção sem pressão indevida.

Se a organização já tem um roadmap de IA, a avaliação de desenvolvedores não deve virar uma versão pequena do roadmap. Ela deve selecionar uma fatia concreta de trabalho e verificar se a pessoa consegue usar IA sem terceirizar o próprio raciocínio.

Como observar a prática antes de medir produtividade

Antes de falar em produtividade, observe como a pessoa trabalha.

A pergunta mais útil não é “quanto tempo levou?”. É “o que ela fez para chegar a uma decisão confiável?”. Em tarefas com IA, velocidade pode esconder retrabalho, aceitação acrítica ou mudanças que parecem corretas fora do contexto do sistema.

A liderança técnica ou um par experiente deve observar evidências como:

clareza do objetivo antes de acionar a IA;
qualidade do contexto fornecido à ferramenta;
decomposição da tarefa em partes verificáveis;
capacidade de questionar a resposta recebida;
identificação de riscos, efeitos colaterais e dependências;
decisão explícita sobre o que aceitar, ajustar ou descartar;
explicação do resultado para outra pessoa da equipe.

Esse tipo de observação protege a equipe de uma confusão comum: achar que uma resposta coerente é uma resposta correta. Em software, a coerência textual não basta. A mudança precisa respeitar regra de negócio, arquitetura, testes, segurança, manutenção e acordos de equipe.

A Microsoft descreve sua plataforma ExP como uma forma de incorporar experimentação ao ciclo de desenvolvimento, validar hipóteses, medir impacto e iterar produtos. O paralelo aqui é limitado, mas útil: trabalhar com IA também exige hipótese e verificação. A hipótese pode ser simples, como “a IA pode ajudar a identificar duplicação nesta função sem alterar o comportamento esperado”. Depois disso, a pessoa precisa testar se a hipótese se sustenta.

Não chame qualquer tentativa de experimento. Um experimento precisa de uma hipótese testável, uma forma de checagem e uma decisão depois da evidência.

Evidências mínimas de capacitação em IA em uma tarefa real

O checklist abaixo serve para uma sessão prática de capacitação em IA de curta duração, usando uma tarefa real de baixa criticidade. A observação pode ser feita por uma liderança técnica ou por um par experiente. Cada item pede evidência concreta, não impressão geral.

Entendimento da tarefa

A pessoa explica o objetivo, o comportamento esperado e as restrições antes de acionar a IA.

O critério de passagem é simples: ela consegue diferenciar o que precisa ser resolvido do que seria apenas uma melhoria opcional. Se a pessoa começa pedindo uma solução sem entender o problema, a IA vira atalho para uma decisão que ainda não foi tomada.

Formulação do contexto

A pessoa fornece à IA informações suficientes sobre código, regra, teste, dependências e limite da mudança.

O bom pedido reduz ambiguidade sem expor informação desnecessária. Isso inclui saber recortar contexto. Jogar um volume grande de informação na ferramenta não é necessariamente melhor do que selecionar o trecho certo, explicar a intenção e delimitar o que não deve mudar.

Uso da IA como apoio, não substituto de julgamento

A pessoa compara a resposta com o contexto do sistema e questiona suposições da ferramenta.

O critério de passagem é conseguir apontar pelo menos uma sugestão aceita, uma ajustada e uma rejeitada. Essa distinção mostra que a pessoa não tratou a resposta como autoridade automática.

Validação técnica

A pessoa executa ou propõe testes, revisão estática, leitura de diferenças no código ou outra forma verificável de checagem.

A decisão de seguir não pode depender apenas da aparência da resposta. Se a pessoa não consegue dizer como verificaria a mudança, ainda não demonstrou autonomia suficiente.

Comunicação da decisão

A pessoa registra o que mudou, por quê, quais riscos permanecem e o que precisa de revisão humana.

Outra pessoa da equipe deve conseguir entender a mudança sem refazer toda a investigação. Esse registro não precisa ser longo. Precisa ser claro o bastante para sustentar revisão.

Aprendizagem reutilizável

A pessoa identifica um padrão, prompt, cuidado ou exemplo que pode ajudar a equipe em tarefas semelhantes.

O aprendizado precisa ser específico. “Usar IA para refatorar” é genérico demais. “Ao refatorar regra duplicada, pedir primeiro uma lista de comportamentos preservados e só depois sugestões de extração” já é mais útil.

Um critério prático é considerar alguém pronto para usar IA com mais autonomia quando demonstra evidência suficiente nesses seis pontos em pelo menos duas tarefas reais diferentes. Isso não transforma a pessoa em especialista, nem autoriza decisões críticas sem revisão. Apenas reduz a distância entre treinamento formal e capacidade observável.

Avaliação prática de uma refatoração assistida por IA

Imagine uma equipe de produto interno com uma função que calcula permissões de acesso em duas telas diferentes. O código tem duplicação, mas o comportamento esperado já é conhecido pela equipe. O exemplo é fictício e serve apenas para ilustrar a avaliação.

A pessoa desenvolvedora recebe a tarefa de propor uma refatoração assistida por IA. Antes de pedir qualquer coisa à ferramenta, ela descreve o objetivo: reduzir duplicação sem alterar as permissões existentes. Também lista restrições: manter a assinatura pública usada por outros módulos, preservar testes atuais e não mexer na regra de auditoria.

Em seguida, ela formula um pedido com o trecho relevante do código, os testes existentes e a instrução de não propor mudanças de comportamento. A IA sugere extrair uma função comum e também sugere simplificar uma condição.

A avaliação não aprova a pessoa porque o código ficou menor. Aprova, se for o caso, porque ela percebe que a simplificação proposta mudaria um caso de acesso excepcional. Ela aceita a extração da função comum, ajusta o nome para refletir a linguagem do produto e rejeita a simplificação da condição.

Depois, ela executa ou descreve os testes necessários, lê as diferenças no código e registra a decisão: o que foi extraído, que comportamento foi preservado, qual sugestão da IA foi recusada e por quê. Por fim, ela anota um aprendizado reutilizável para a equipe: em refatorações de regra de permissão, pedir à IA que enumere comportamentos preservados antes de sugerir redução de código.

Nada nesse exemplo prova ganho de produtividade. Esse efeito seria uma hipótese a medir em outro desenho de avaliação. O que a sessão demonstra é mais específico: a pessoa usou IA sem abandonar entendimento, validação e comunicação técnica.

Como registrar evidências para próximas avaliações

A avaliação individual perde força quando fica apenas na memória de quem observou. Para virar capacidade da equipe, ela precisa alimentar exemplos internos, acordos de revisão e documentação fácil de encontrar.

O DORA avalia qualidade da documentação por atributos como clareza, facilidade de localização e confiabilidade, além de recomendar criação e manutenção ativa. Para uma equipe que usa IA, isso sugere uma disciplina simples: registrar bons exemplos de uso, erros recorrentes e cuidados que realmente apareceram no trabalho.

Essa documentação não precisa virar um manual pesado. Pode começar como uma biblioteca pequena de exemplos:

prompts que ajudaram a delimitar comportamento esperado;
situações em que a IA sugeriu mudança perigosa;
critérios usados para aceitar ou rejeitar uma resposta;
exemplos de registros de decisão bem escritos;
tipos de tarefa em que a equipe ainda exige acompanhamento próximo.

O registro deve guardar prompts úteis, recusas justificadas e critérios de revisão que apareceram nas tarefas observadas. Quando a prática é documentada com clareza, a equipe ganha repertório compartilhado. Isso conversa com discussões mais amplas sobre maturidade em IA, mas aqui o recorte continua sendo operacional: transformar avaliação prática em material de aprendizagem.

Também vale separar descoberta de hipótese e execução de experimento. Uma pessoa pode descobrir que a IA ajuda a explicar um trecho legado. Depois, a equipe pode formular a hipótese de que esse uso melhora a revisão de refatorações. Só então faria sentido medir impacto de forma mais estruturada.

Quando não declarar alguém capacitado ainda

Não declarar alguém capacitado ainda é uma decisão de qualidade, não uma punição.

A liderança deve segurar a autonomia quando a pessoa aceita respostas sem verificação, não consegue explicar escolhas técnicas, usa IA para contornar revisão, expõe contexto sensível sem critério, não registra aprendizado ou depende da ferramenta para tarefas que deveria compreender.

Também é prudente limitar autonomia quando a pessoa só demonstra competência em tarefas muito artificiais. Se a avaliação não se parece com o trabalho real, ela mede outra coisa: familiaridade com a ferramenta, improviso ou habilidade de apresentação.

Há ainda um limite de escopo. Uma boa execução em tarefa pequena não autoriza uso autônomo em mudanças críticas de arquitetura, decisões com dados sensíveis ou alterações de alto impacto no produto. Capacitação em IA deve aumentar responsabilidade, não suspender revisão.

Para lideranças que estão conectando IA a decisões estratégicas, a reflexão sobre liderança e humano ampliado ajuda a manter o julgamento humano no desenho do trabalho, não como correção tardia.

O próximo passo é criar uma avaliação prática curta, com tarefa real de baixa criticidade, evidências mínimas e revisão posterior com pares. Se a pessoa demonstra entendimento, contexto, julgamento, validação, comunicação e aprendizagem reutilizável em mais de uma situação, a liderança tem uma base melhor para ampliar autonomia. Se não demonstra, o próximo passo não é mais palestra. É prática acompanhada em uma tarefa melhor escolhida.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.