Matriz de competências em IA para desenvolvimento

Uma matriz de competências de desenvolvimento com inteligência artificial deve mostrar o que cada pessoa consegue decidir, revisar, documentar e sustentar quando a IA participa do trabalho. A pergunta útil não é “quem sabe usar IA?”, mas “em qual responsabilidade essa pessoa demonstra autonomia, critério e limite?”. Para isso, a matriz precisa partir do ciclo real de desenvolvimento e transformar competências abstratas em comportamentos observáveis.

Por que a matriz deve começar pelas responsabilidades, não pelas ferramentas

Ferramentas mudam rápido. Responsabilidades de engenharia mudam mais devagar.

Quando uma liderança monta uma matriz de competências em IA a partir de nomes de ferramentas, comandos ou tipos de prompt, cria um retrato que envelhece antes de orientar decisões. A pessoa pode ser fluente em uma interface e ainda assim não saber quando rejeitar uma sugestão, pedir revisão, documentar uma escolha ou interromper um caminho arriscado.

Uma matriz mais útil começa pelas responsabilidades do desenvolvimento de software: entender requisito, analisar legado, propor solução, implementar, testar, revisar código, documentar decisão, monitorar efeito em produto e orientar outras pessoas. A partir daí, a IA entra como parte do trabalho, não como uma categoria separada de habilidade.

Isso evita um erro comum: tratar “usa IA” como competência única. Usar IA para explicar um trecho de código legado não exige o mesmo nível de julgamento que usar IA para alterar uma regra crítica, sugerir uma migração de arquitetura ou gerar uma bateria de testes para uma funcionalidade sensível.

A apresentação do relatório DORA 2025 descreve a IA como amplificadora das forças e fraquezas existentes na organização e destaca a importância do sistema organizacional para o retorno do investimento. Essa é uma boa razão para olhar menos para o brilho da ferramenta e mais para o sistema de responsabilidades onde ela será usada.

Se a empresa já vem discutindo maturidade, estratégia ou governança de inteligência artificial, a matriz de competências deve se conectar a esse diagnóstico. O ponto de partida pode estar em uma leitura mais ampla sobre maturidade em IA, mas a matriz precisa descer para evidências do trabalho diário.

Uma boa competência não diz apenas “usa assistente de código”. Ela diz algo como: “usa IA para levantar alternativas de implementação, compara as opções com as restrições do serviço e registra por que aceitou, adaptou ou rejeitou a sugestão”.

Essa frase permite observar trabalho. A anterior apenas declara familiaridade.

Como separar competência técnica, julgamento e responsabilidade

Três coisas costumam ser misturadas quando se fala em competências de desenvolvimento com IA.

A primeira é a competência técnica de operar a ferramenta. A pessoa sabe formular uma pergunta, oferecer contexto, pedir variações, solicitar explicações e explorar alternativas.

A segunda é o julgamento técnico. A pessoa consegue avaliar se a resposta faz sentido diante da arquitetura, dos padrões do projeto, das restrições de segurança, dos testes existentes, do comportamento esperado do produto e da capacidade da equipe de manter aquela decisão depois.

A terceira é a responsabilidade. A pessoa tem autorização e maturidade para aceitar ou rejeitar a sugestão da IA em determinado contexto. Em algumas situações, ela pode decidir sozinha. Em outras, precisa chamar revisão técnica, envolver produto, consultar operação ou registrar uma decisão mais formal.

A matriz precisa deixar essas três dimensões visíveis. Fluência em prompt não é o mesmo que autonomia técnica. Velocidade para gerar código não é o mesmo que capacidade de sustentar uma mudança.

Um comportamento observável combina as três dimensões. Por exemplo: “usa IA para propor testes de regressão, confere se os testes cobrem os fluxos alterados, remove casos irrelevantes e solicita revisão quando a mudança afeta comportamento compartilhado por outros módulos”.

Essa formulação mostra operação, validação e limite de autonomia.

Também ajuda a liderança a evitar uma injustiça frequente. Uma pessoa que usa IA pouco, mas valida bem, pode estar mais madura do que alguém que usa IA o tempo todo sem deixar rastro de decisão. A matriz não deve medir quantidade de uso. Usar mais não significa decidir melhor.

Essa separação conversa com uma decisão maior de liderança: criar uma estratégia de inteligência artificial conectada ao negócio sem transformar adoção em teatro de ferramenta. Em desenvolvimento de software, capacidade aparece quando a equipe melhora a qualidade das decisões, não quando todos passam a usar o mesmo atalho.

Quais comportamentos observar em cada responsabilidade de desenvolvimento

A forma mais simples de construir a matriz é escolher responsabilidades recorrentes e escrever comportamentos verificáveis para cada uma. O objetivo não é cobrir tudo. É começar pelos pontos em que a IA já aparece no trabalho ou tende a alterar riscos e decisões.

Em análise de requisito, comportamentos observáveis podem incluir:

• usa IA para identificar ambiguidades em uma história ou especificação;
• compara as perguntas geradas com o contexto do produto antes de levá-las ao time;
• registra dúvidas relevantes para discussão com produto ou negócio;
• distingue sugestão plausível de requisito validado.

Em implementação, a matriz pode observar se a pessoa:

• fornece contexto suficiente sobre padrões do projeto antes de pedir uma solução;
• adapta o código sugerido em vez de copiar sem leitura;
• verifica compatibilidade com convenções, dependências e restrições existentes;
• sabe quando uma mudança local exige revisão mais ampla.

Em revisão de código, a competência muda de natureza. A IA pode ajudar a explicar trechos, apontar riscos ou sugerir testes, mas a responsabilidade continua sendo humana e técnica. Comportamentos observáveis incluem:

• compara a explicação da IA com o diff e com o comportamento esperado;
• identifica riscos que a IA não mencionou;
• registra decisões relevantes quando aceita uma abordagem não óbvia;
• orienta o time sobre padrões de revisão assistida por IA.

Exemplo fictício: em um time de produto digital, uma desenvolvedora usa IA para revisar uma alteração em um módulo de assinatura. Em nível inicial, ela pede uma explicação do diff e confere se a resposta parece compatível com o código alterado. Em nível mais maduro, percebe que a IA não comentou um risco de duplicidade em um fluxo assíncrono, cria testes para explorar a hipótese, registra a decisão no pull request e compartilha com o time um exemplo de revisão para mudanças parecidas. O efeito esperado, que precisaria ser medido no contexto real, seria reduzir decisões implícitas e melhorar a qualidade das revisões futuras.

Em documentação técnica com IA, a matriz deve avaliar clareza, localização e confiabilidade. O DORA sobre qualidade da documentação avalia documentação por atributos como clareza, facilidade de localização e confiabilidade, além de recomendar criação e manutenção ativa. Isso sustenta uma regra prática: a IA pode ajudar a redigir, mas a competência está em manter a documentação útil para quem decide e opera.

Comportamentos observáveis nessa responsabilidade podem ser:

• usa IA para transformar uma decisão técnica em rascunho claro;
• verifica se o texto descreve o estado real do sistema;
• remove generalizações que não ajudam manutenção;
• atualiza documentação quando a decisão muda.

Como definir níveis de maturidade sem criar cargos artificiais

A matriz não precisa inventar cargos paralelos, como “desenvolvedor IA júnior” ou “especialista de prompt sênior”. Isso tende a confundir mais do que ajuda.

Uma alternativa melhor é descrever níveis de autonomia e impacto por responsabilidade. Os nomes podem variar, mas quatro níveis costumam funcionar bem como linguagem de gestão: assistido, operacional, criterioso e referência.

No nível assistido, a pessoa usa IA com supervisão. Ela consegue pedir explicações, gerar alternativas simples e comparar respostas com instruções recebidas, mas ainda precisa de apoio para validar impacto, escopo e risco.

No nível operacional, a pessoa aplica IA em tarefas conhecidas. Ela oferece contexto, revisa a saída, executa validações básicas e sabe quando a sugestão não se encaixa nos padrões do projeto.

No nível criterioso, a pessoa decide com autonomia em parte relevante da responsabilidade. Ela identifica riscos não óbvios, documenta escolhas, rejeita respostas sedutoras quando não sustentam o problema e pede revisão quando a mudança ultrapassa seu limite de decisão.

No nível referência, a pessoa orienta outras. Ela transforma bons usos e erros relevantes em exemplos internos, melhora padrões de revisão, ajuda a equipe a calibrar riscos e participa da evolução das práticas.

A diferença entre esses níveis não é quantidade de ferramenta usada. É a qualidade da pergunta, da validação, da decisão e do aprendizado compartilhável.

Por isso, cada competência deve ter evidências. Uma evidência pode estar em um pull request, em um documento de decisão, em um teste criado, em uma revisão comentada, em um exemplo interno ou em uma conversa de pareamento registrada de forma apropriada para o time.

Se a empresa estiver desenhando um roadmap de IA, esses níveis ajudam a separar ambição de capacidade. Não basta decidir que uma área vai usar IA. É preciso saber quem consegue revisar, quem pode orientar e onde ainda há dependência de supervisão.

Checklist para escrever uma competência observável de desenvolvimento com IA

Antes de incluir uma frase na matriz, vale submetê-la a um teste simples. Se a competência não passa por esses critérios, provavelmente está genérica demais.

Responsabilidade explícita

A competência está ligada a uma responsabilidade real, como analisar requisito, escrever código, revisar, testar, documentar ou decidir arquitetura?

Fraca: “sabe usar IA para programar”.

Forte: “usa IA para levantar alternativas de implementação e compara as opções com as restrições técnicas do serviço”.

Comportamento observável

Uma liderança conseguiria observar ou revisar a evidência desse comportamento em um artefato de trabalho?

Fraca: “tem bom senso ao usar IA”.

Forte: “registra quais sugestões da IA foram aceitas, rejeitadas ou adaptadas em uma decisão técnica relevante”.

Critério de validação

A competência deixa claro como a pessoa confere se a saída da IA é adequada?

Fraca: “confia na IA quando a resposta parece boa”.

Forte: “valida a saída da IA com testes, leitura do contexto e comparação com padrões do projeto antes de incorporar a mudança”.

Limite de autonomia

A matriz indica quando a pessoa pode decidir sozinha e quando deve pedir revisão?

Fraca: “usa IA com autonomia”.

Forte: “pode usar IA para refatorações locais, mas solicita revisão técnica antes de alterar contratos de integração ou regras críticas”.

Aprendizagem compartilhável

O comportamento gera aprendizado para a equipe ou fica restrito ao indivíduo?

Fraca: “aprende novas formas de usar IA”.

Forte: “transforma um uso bem sucedido ou um erro relevante em exemplo interno reutilizável pela equipe”.

Esse checklist não substitui julgamento de liderança. Ele reduz ambiguidade. A matriz fica melhor quando uma competência pode ser observada, discutida e revisada sem depender da impressão vaga de que alguém “manda bem com IA”.

Como usar a matriz em conversas de desenvolvimento da equipe

A matriz de competências não deve virar instrumento punitivo. Se ela nasce como ranking, a equipe aprende a performar maturidade. Se nasce como ferramenta de desenvolvimento, ajuda a distribuir responsabilidade com mais clareza.

Em conversas individuais, a matriz pode orientar feedback concreto. Em vez de dizer “você precisa usar melhor IA”, a liderança pode dizer: “nas revisões, você já pede boas explicações à IA, mas ainda não registra por que aceitou ou rejeitou sugestões em mudanças relevantes”.

Em pareamento, a matriz ajuda a combinar pessoas com níveis diferentes de autonomia. Alguém criterioso em testes pode parear com alguém operacional em implementação. Alguém referência em documentação pode transformar decisões recorrentes em exemplos internos.

Em planejamento, a matriz ajuda a decidir quem deve revisar uma mudança, quem pode assumir uma investigação e onde a equipe precisa de apoio antes de ampliar o uso de IA. Isso é particularmente útil quando a organização está tentando equilibrar produtividade, qualidade e aprendizagem, sem tratar automação como atalho universal.

O DORA sobre cultura de aprendizagem relaciona cultura de aprendizagem ao desempenho de entrega de software e propõe tratar aprendizagem como investimento da organização. A matriz pode apoiar esse investimento quando transforma uso individual em aprendizagem compartilhada. Ela não prova, por si só, que a equipe terá melhor desempenho.

Há também uma conexão com liderança. Trabalhar com IA exige confiança como infraestrutura, não como discurso. Se a pessoa não sabe quando pode decidir, quando precisa pedir revisão e como documentar uma escolha, a confiança vira ansiedade ou permissividade. Nenhuma das duas sustenta engenharia madura.

Como manter a matriz atualizada conforme o uso de IA amadurece

Uma matriz útil não é escrita uma vez e guardada. Ela deve ser revisada conforme a equipe encontra novos padrões de uso, riscos, dúvidas e responsabilidades.

A revisão não precisa ser pesada. Pode partir de evidências do trabalho:

• decisões técnicas que exigiram muita discussão;
• erros ou quase erros em sugestões aceitas sem validação suficiente;
• incidentes evitados por uma revisão cuidadosa;
• dúvidas recorrentes sobre quando usar IA;
• lacunas de documentação;
• mudanças nas práticas de produto, dados ou operação;
• exemplos internos que passaram a orientar o time.

Quando a equipe experimenta novas formas de trabalhar, convém separar descoberta, hipótese e experimento. Descoberta é entender onde há oportunidade ou problema. Hipótese é formular uma suposição testável. Experimento é alterar uma prática, medir impacto e decidir se ela continua, muda ou para.

A Microsoft descreve a ExP como uma plataforma para incorporar experimentação ao ciclo de desenvolvimento, validar hipóteses, medir impacto e iterar produtos. A lição aplicável aqui é de disciplina: práticas com IA também precisam de hipótese, observação e iteração. Isso não significa que qualquer feedback retreina automaticamente um modelo, nem que toda equipe precise de uma plataforma própria para aprender.

Também vale explicitar limites na própria matriz. Nem toda atividade deve ser assistida por IA. Em decisões críticas, a matriz deve indicar quando a automação é inadequada ou quando a revisão humana é obrigatória. Modelos de terceiros podem fazer parte de produtos e fluxos maduros, desde que a responsabilidade por validação, documentação e decisão esteja clara.

Uma boa matriz de competências de desenvolvimento com IA não tenta prever todas as ferramentas que virão. Ela cria linguagem para observar trabalho, distribuir autonomia e aprender com evidências. A próxima decisão é escolher três ou quatro responsabilidades reais do ciclo de desenvolvimento, escrever comportamentos verificáveis para cada uma e revisar a matriz quando o trabalho mostrar novos riscos ou novas capacidades.

Se essa conversa precisa sair do abstrato na sua equipe, converse com a dooop.

Leituras para continuar

• Como preparar uma empresa de software para trabalhar com IA
• Como organizar a adoção de IA sem paralisar as entregas
• Como compartilhar práticas de IA entre equipes de engenharia

Fontes

• DORA 2025
• DORA: cultura de aprendizagem
• DORA: qualidade da documentação
• Microsoft: plataforma de experimentação