As habilidades de desenvolvedor de IA do GitHub deixam de escrever código para passar a direcioná-lo

O GitHub mudou seus conselhos de carreira para desenvolvedores em 2 de outubro, apontando três habilidades de desenvolvedor de IA do GitHub que importam à medida que os agentes assumem mais trabalho de implementação. A empresa afirma que os desenvolvedores devem aprender a orientar agentes, questionar suas primeiras respostas e reservar a atenção humana para o julgamento técnico. O conflito é imediato: produzir código está ficando mais fácil, enquanto provar que esse código merece ser lançado continua difícil.

O conselho reflete uma mudança mais profunda na forma como o GitHub descreve uma execução sólida. Antes, um desenvolvedor demonstrava progresso ao escrever, testar e enviar uma implementação. Agora, o GitHub apresenta um fluxo de trabalho no qual vários agentes preparam código, testes e documentação, enquanto o desenvolvedor define o problema e revisa o resultado combinado.

Esse modelo não elimina a responsabilidade de engenharia. Ele concentra a responsabilidade nos pontos em que a IA permanece menos confiável. Os desenvolvedores precisam fornecer contexto, revelar restrições ocultas, comparar alternativas e reconhecer resultados plausíveis, porém incompletos.

O argumento também surge em meio a evidências conflitantes sobre a produtividade com IA. Desenvolvedores frequentemente relatam ganhos pessoais de eficiência, mas pesquisas controladas e dados de entrega mostram que uma geração mais rápida não garante uma entrega de software mais rápida ou mais segura. Portanto, o GitHub está fazendo uma afirmação sobre carreira, não apenas oferecendo um tutorial de ferramenta: a habilidade escassa está passando de produzir código para orientar e validar um sistema de produção maior.

As habilidades de desenvolvedor de IA do GitHub agora começam pela orientação de agentes

A afirmação central do GitHub é que a execução significa cada vez mais definir e coordenar o trabalho, não implementar pessoalmente cada componente.

A orientação de carreira do GitHub descreve uma tarefa convencional de autenticação como uma sequência linear. Um desenvolvedor cria uma branch, escreve o código, executa os testes e abre um pull request. Cada etapa permanece visível e atribuível a uma única pessoa.

Sua alternativa baseada em agentes parece diferente. Um agente prepara a implementação de autenticação, outro redige a documentação e um terceiro constrói a suíte de testes. O desenvolvedor continua responsável pelo resultado, mas se desloca para etapas anteriores, onde requisitos e limites são estabelecidos, e posteriores, onde os resultados são integrados e aprovados.

Isso é mais do que prompting. Um agente de IA é um software que pode perseguir um objetivo por meio de múltiplas ações com supervisão limitada. Orientá-lo exige que um desenvolvedor descreva o resultado desejado, forneça o contexto do repositório, estabeleça restrições e defina evidências de conclusão.

Orientar vários agentes acrescenta outra camada. Suas tarefas precisam ser separáveis, suas premissas devem permanecer compatíveis e seus resultados devem convergir para a mesma arquitetura. A geração paralela economiza pouco tempo se um agente altera uma interface que outro espera que permaneça estável.

Uma especificação sólida, portanto, torna-se coordenação executável. Para um recurso de autenticação, ela pode identificar provedores de identidade compatíveis, comportamento de sessão, requisitos de migração, premissas de ameaça, necessidades de acessibilidade e tratamento de falhas. Também deve definir quais testes precisam passar antes que a revisão comece.

O desenvolvedor deve decidir quanto contexto cada agente recebe. Contexto insuficiente incentiva código genérico que entra em conflito com as convenções do repositório. Contexto demais e sem filtragem pode obscurecer os requisitos relevantes e aumentar a chance de um agente seguir documentação desatualizada.

Isso torna o conhecimento do repositório mais valioso, não menos. Um engenheiro que entende limites de propriedade, práticas de implantação e histórico arquitetural pode dividir o trabalho com segurança. Alguém sem esse entendimento ainda pode gerar código, mas não consegue prever de forma confiável onde a alteração causará falhas.

As novas habilidades de programação com IA do GitHub também incluem gerenciar dependências entre artefatos gerados. Os testes precisam examinar a implementação que realmente será lançada. A documentação deve descrever o comportamento real, e não o projeto pretendido. Alterações de banco de dados precisam estar alinhadas a procedimentos de implantação e reversão.

Por isso, a orientação de agentes deve começar pela decomposição. Os desenvolvedores precisam separar tarefas que podem avançar de forma independente de decisões que exigem julgamento compartilhado. Também precisam de pontos de controle explícitos antes que um agente amplie o escopo de uma alteração.

Um padrão operacional útil é atribuir resultados específicos, em vez de ambições amplas. “Implemente a renovação de token sob estas seis restrições” é revisável. “Melhore a autenticação” convida um agente a tomar decisões de produto, segurança e arquitetura sem autoridade adequada.

A mesma disciplina se aplica aos critérios de conclusão. Uma suíte de testes aprovada é uma evidência, mas não é a definição completa de pronto. O desenvolvedor ainda pode precisar avaliar latência, exposição de dados, compatibilidade retroativa, observabilidade e impacto sobre o usuário.

A primeira recomendação do GitHub, portanto, muda a unidade visível de especialização. Velocidade de digitação e memorização de frameworks ainda ajudam, mas já não diferenciam desenvolvedores quando um agente consegue gerar rapidamente padrões comuns. O diferencial passa a ser a capacidade de transformar uma solicitação ambígua em trabalho delimitado e verificável.

Essa mudança pressiona tanto engenheiros juniores quanto seniores. Desenvolvedores juniores tradicionalmente fortalecem seu julgamento ao implementar muitas pequenas alterações. Desenvolvedores seniores agora precisam preservar essas oportunidades de aprendizado enquanto adotam fluxos de trabalho que delegam a implementação rotineira.

As organizações precisarão decidir se a orientação de agentes se torna uma habilidade individual ou uma prática de engenharia compartilhada. Se cada desenvolvedor inventar prompts, regras de revisão e formatos de repasse separados, as equipes podem ganhar velocidade local enquanto acumulam processos inconsistentes.

Uma base de conhecimento de engenharia pesquisável pode ajudar agentes e desenvolvedores a trabalharem a partir das mesmas decisões. No entanto, a documentação só ajuda quando as equipes a mantêm e distinguem regras atuais das obsoletas.

O conselho do GitHub é mais forte quando lido como uma exigência de melhor definição de problemas. Agentes podem multiplicar a capacidade de implementação. Eles também multiplicam as consequências de requisitos pouco claros, contexto ausente e limites fracos.

A geração mais rápida de código coloca os revisores sob pressão

O gargalo imediato está mudando da produção de código para a verificação de código, enquanto a atenção humana continua limitada.

A segunda recomendação do GitHub é direta: não confie na primeira resposta de um sistema de IA. A empresa ilustra isso com uma consulta SQL que parece correta até que um segundo modelo identifique timestamps duplicados, uma recomendação de índice ausente e baixo desempenho em escala.

Esse exemplo captura o problema central da revisão. O código gerado muitas vezes parece completo porque é sintaticamente refinado e segue padrões familiares. Seus defeitos podem estar em premissas não declaradas, em vez de em erros de sintaxe óbvios.

A pesquisa de desenvolvedores de 2025 do Stack Overflow quantifica essa tensão. Quarenta e seis por cento dos respondentes desconfiavam da precisão dos resultados de IA, enquanto 33% confiavam. Apenas 3% relataram alta confiança.

A mesma pesquisa constatou que 66% dos desenvolvedores encontraram soluções de IA que estavam quase certas, mas não totalmente. Quarenta e cinco por cento disseram que depurar código gerado levou mais tempo. Não se trata de reclamações isoladas sobre interfaces desajeitadas. Elas descrevem uma carga de verificação criada por resultados plausíveis.

Os desenvolvedores precisam revisar o comportamento, não a apresentação. Um diff limpo ainda pode lidar incorretamente com concorrência, limites de autorização, entradas malformadas ou falhas parciais. Testes gerados por IA podem repetir a mesma premissa incorreta incorporada à implementação.

O GitHub propõe a crítica de um segundo modelo como uma defesa. Seu agente Copilot Rubber Duck supostamente usa outro modelo para criticar planos, código e testes. A abordagem pode revelar problemas que o modelo original deixou passar.

Um segundo modelo é útil, mas não constitui prova independente. Modelos podem compartilhar padrões de treinamento, repetir erros convencionais ou aceitar a mesma premissa enganosa. Se a solicitação inicial omitir uma restrição de segurança, ambos os modelos podem produzir respostas confiantes que a ignoram.

Portanto, o revisor humano precisa examinar a premissa antes de comparar respostas. A primeira pergunta não é qual modelo escreveu o código mais limpo. É se a definição da tarefa captura os requisitos reais de clientes, sistemas e operações.

A revisão também precisa de profundidade proporcional. Um erro de digitação na documentação não exige os mesmos controles que uma alteração de autorização. As equipes devem relacionar os requisitos de revisão ao risco, à sensibilidade dos dados, à reversibilidade e ao possível raio de impacto.

Para alterações de baixo risco, testes automatizados e uma revisão humana focada podem ser suficientes. Para código de alto risco, as equipes podem exigir modelagem de ameaças, testes de carga, implantação gradual, registros de auditoria e aprovação de um responsável pelo domínio.

A pressão aumenta quando agentes geram várias alterações simultaneamente. A capacidade de revisão humana não escala automaticamente com o volume de resultados. Um desenvolvedor que recebe três branches concluídas pode enfrentar uma carga cognitiva maior do que aquele que escreveu uma única implementação de forma sequencial.

Grandes lotes pioram isso. Os revisores precisam reconstruir mais contexto, acompanhar mais premissas interdependentes e distinguir alterações intencionais das incidentais. A aparente velocidade de geração pode ocultar uma fila de trabalho de verificação não resolvido.

A pesquisa sobre IA generativa da DORA documentou uma lacuna relacionada. Suas conclusões de 2024 associaram um aumento de 25% na adoção de IA a uma redução de 1,5% no throughput de entrega e uma redução de 7,2% na estabilidade da entrega. A DORA sugeriu que uma geração mais rápida de código pode produzir alterações maiores, que levam mais tempo para revisar e desestabilizam sistemas.

Esses números descrevem associações, não um resultado universal para todas as equipes. Ainda assim, eles desafiam a ideia de que mais código gerado se transforma automaticamente em mais valor entregue. O sistema de entrega precisa absorver, avaliar e lançar esse código com segurança.

As habilidades de desenvolvedor de IA do GitHub precisam, consequentemente, incluir o desenho de evidências. Antes de um agente começar, o desenvolvedor deve determinar o que demonstrará a correção. Essas evidências podem incluir testes baseados em propriedades, limites de desempenho, verificações de segurança ou telemetria esperada após a implantação.

Os desenvolvedores também precisam preservar a rastreabilidade. Os revisores devem saber quais requisitos moldaram uma alteração, o que um agente foi instruído a fazer, quais ferramentas ele usou e onde um humano alterou o resultado. Sem esse histórico, o diff final pode ser difícil de interpretar.

A implicação para a carreira é significativa. A revisão de código já era uma responsabilidade importante de engenharia. Em um fluxo de trabalho intensivo em agentes, a revisão se torna uma atividade primária de produção, e não uma etapa final após o trabalho “real”.

Isso significa que as organizações devem recompensá-la adequadamente. Se os sistemas de desempenho contabilizarem recursos lançados, mas ignorarem defeitos evitados, os desenvolvedores sentirão pressão para aprovar rapidamente o trabalho gerado. A estrutura de incentivos entrará em conflito com o julgamento de que o GitHub diz que as equipes precisam.

A carreira está se deslocando para o julgamento técnico

Quando a implementação se torna mais barata, decidir o que deve ser construído e quais compromissos são aceitáveis se torna mais valioso.

A terceira recomendação do GitHub pede que os desenvolvedores usem IA para problemas maiores. A empresa argumenta que os ganhos na implementação podem criar tempo para compreender clientes, projetar sistemas, avaliar trade-offs e escolher métricas de sucesso.

Seu exemplo de modo escuro divide o trabalho com clareza. A IA constrói o recurso, gera testes e atualiza a documentação. O desenvolvedor valida o problema do cliente, examina os trade-offs arquiteturais, verifica a acessibilidade, define o sucesso e aprova a solução.

Essa divisão destaca o principal antagonismo dessa mudança: produção visível de código versus julgamento de engenharia responsável. Código é fácil de contar. O julgamento aparece em erros evitados, escopo reduzido, projetos mais seguros e decisões de não construir o recurso errado.

O julgamento técnico combina conhecimento do domínio com consciência das consequências. Inclui reconhecer quando um padrão familiar não se aplica, quando um requisito entra em conflito com outro objetivo e quando a incerteza justifica um experimento menor.

A comunicação passa a fazer parte da mesma competência. Desenvolvedores devem explicar por que um design prioriza confiabilidade em vez de velocidade ou por que um atalho cria custos futuros de migração. A IA pode elaborar alternativas, mas o engenheiro responsável deve conectá-las à realidade operacional e do negócio.

Isso muda o que o desenvolvimento no início da carreira deveria enfatizar. Memorizar sintaxe importa menos quando a assistência está sempre disponível. Compreender fluxo de dados, modos de falha, interfaces, limites de segurança e comportamento do sistema importa mais, porque esses conceitos sustentam uma avaliação confiável.

Ainda assim, há um problema de treinamento. Historicamente, desenvolvedores construíram julgamento ao escrever código, depurar falhas e conviver com escolhas de design anteriores. Se os agentes assumirem implementação demais cedo demais, iniciantes poderão perder a repetição que desenvolve a intuição.

As equipes não devem confundir delegação com aprendizado. Um engenheiro júnior pode usar um agente e ainda assim inspecionar cada premissa, prever o comportamento antes de executar testes e explicar o design final. Um fluxo de trabalho que aceita código gerado sem reconstrução oferece menos valor educacional.

Engenheiros seniores enfrentam um desafio diferente. Sua experiência lhes dá instintos de revisão mais fortes, mas a grande familiaridade também pode fazer um agente parecer mais lento. Eles talvez já saibam onde uma mudança deve ser feita e como funcionam as convenções do repositório.

Um estudo randomizado sobre produtividade de desenvolvedores da METR examinou esse cenário em 2025. Dezesseis desenvolvedores experientes de código aberto concluíram 246 tarefas reais em projetos maduros que conheciam bem, com acesso à IA permitido ou proibido de forma aleatória.

Antes do estudo, os desenvolvedores esperavam que a IA reduzisse o tempo de conclusão em 24%. Depois, acreditaram que ela havia reduzido o tempo em 20%. Os resultados medidos mostraram o oposto: o acesso a ferramentas do início de 2025 aumentou o tempo de conclusão em 19%.

O estudo tem limitações importantes. Envolveu um grupo pequeno, ferramentas específicas, repositórios maduros e desenvolvedores com profundo conhecimento dos projetos. Os autores não afirmaram que todo desenvolvedor ou tarefa enfrentaria a mesma desaceleração.

Ainda assim, a diferença de percepção importa. Desenvolvedores podem se sentir mais rápidos porque a geração reduz esforço ou produz progresso visível, mesmo quando solicitar, esperar, corrigir e revisar ampliam o tempo total de conclusão. Impulso subjetivo não é o mesmo que entrega medida.

É por isso que o impacto do GitHub na carreira de desenvolvedores não pode ser reduzido a “aprender prompting”. Um prompt inteligente pode melhorar uma resposta. A vantagem duradoura vem de escolher tarefas adequadas, construir ciclos de feedback confiáveis e detectar quando o uso da ferramenta adiciona sobrecarga.

Os desenvolvedores mais fortes provavelmente alternarão entre modos, em vez de seguir uma única doutrina. Eles delegarão trabalho repetitivo e bem especificado; colaborarão com um agente em implementações incertas; e trabalharão diretamente quando o conhecimento do repositório tornar a assistência ineficiente.

Gestores também precisam de melhores critérios de avaliação. Linhas de código e contagens de pull requests se tornam ainda menos significativas quando agentes podem inflar ambos. Tempo de ciclo, defeitos que escapam, resultados para clientes, manutenibilidade e desempenho de recuperação fornecem sinais mais úteis.

Planos de carreira devem reconhecer qualidade de especificação, eficácia da revisão, prevenção de incidentes e decisões técnicas entre equipes. Caso contrário, desenvolvedores podem otimizar para atividade gerada enquanto a organização depende de julgamento não reconhecido.

A orientação do GitHub aponta para esse futuro sem defini-lo por completo. A empresa identifica as competências que desenvolvedores devem fortalecer, mas os empregadores precisam decidir se sistemas de promoção e alocação de projetos valorizarão essas competências na prática.

As Evidências de Produtividade Ainda Resistem a uma Narrativa Simples

A IA pode melhorar tarefas individuais enquanto torna a entrega da equipe mais lenta, menos estável ou mais difícil de compreender.

O GitHub tem evidências substanciais de entusiasmo entre desenvolvedores. Uma pesquisa com desenvolvedores corporativos de 2024, encomendada pela empresa, abrangeu 2.000 respondentes não gestores nos Estados Unidos, Brasil, Índia e Alemanha.

Mais de 97% disseram ter usado ferramentas de programação com IA no trabalho em algum momento. Dependendo do país, entre 59% e 88% relataram que suas organizações incentivavam ou permitiam essas ferramentas.

Os respondentes também descreveram benefícios significativos. Entre 60% e 71% disseram que ferramentas de IA facilitaram a adoção de uma nova linguagem ou a compreensão de uma base de código existente. Nos Estados Unidos e na Alemanha, 47% afirmaram usar o tempo economizado para colaboração e design de sistemas.

Essas conclusões sustentam o argumento do GitHub de que a IA pode liberar atenção para um trabalho mais amplo. No entanto, elas medem experiência relatada, e não entrega de ponta a ponta sob condições controladas. Também vieram de grandes empresas, onde governança e acesso a ferramentas diferem de organizações menores.

Dados posteriores do Stack Overflow oferecem um quadro misto. Cinquenta e dois por cento dos desenvolvedores concordaram que ferramentas ou agentes de IA afetaram positivamente a produtividade. Entre usuários de agentes, cerca de 70% disseram que os agentes reduziram o tempo gasto em tarefas específicas, enquanto 69% relataram maior produtividade.

Os efeitos nas equipes foram muito mais fracos. Apenas 17% dos usuários de agentes disseram que eles melhoraram a colaboração, o impacto com menor avaliação na pesquisa. Essa diferença sugere que as organizações não podem supor que a aceleração individual melhorará automaticamente a coordenação.

A adoção também continua desigual. O Stack Overflow constatou que 52% dos desenvolvedores não usavam agentes ou dependiam de ferramentas de IA mais simples. Outros 38% não tinham planos de adotar agentes.

O contraste importa porque o fluxo de trabalho proposto pelo GitHub pressupõe que os agentes sejam capazes, disponíveis e integrados aos sistemas de engenharia. Muitos desenvolvedores ainda trabalham em ambientes nos quais políticas, requisitos de privacidade, ferramentas legadas ou a confiabilidade dos modelos limitam essa configuração.

Preocupações com segurança e privacidade continuam proeminentes. O Stack Overflow relatou que 87% dos respondentes estavam preocupados com a precisão dos agentes, enquanto 81% expressaram preocupação com segurança e privacidade de dados.

Essas preocupações afetam mais do que o código gerado. Um agente pode receber arquivos-fonte, documentação interna, logs de produção, dados de clientes ou credenciais ao executar uma tarefa. Direcionar agentes de forma responsável exige controlar quais dados eles podem acessar e quais ações podem realizar.

As ferramentas subjacentes também mudam rapidamente. O resultado da METR em 2025 é um retrato dos sistemas do início de 2025, não um limite permanente. Modelos mais novos, melhor indexação de repositórios, interfaces de agentes aprimoradas e maior experiência dos desenvolvedores podem alterar esse equilíbrio.

Essa incerteza funciona nos dois sentidos. As equipes não devem descartar a IA porque um estudo encontrou uma desaceleração. Também não devem declarar sucesso porque desenvolvedores relatam se sentir mais produtivos.

A pergunta certa é se um fluxo de trabalho específico melhora um resultado específico sob restrições reais. As equipes podem comparar tarefas semelhantes, acompanhar o tempo de revisão, inspecionar taxas de defeitos e medir o intervalo entre trabalho aceito e implantação estável.

Também devem separar o tempo de geração do tempo total da tarefa. Um rascunho de recurso criado em minutos pode exigir horas de esclarecimento, limpeza e revisão. Por outro lado, um agente que não produz código pode ainda economizar tempo ao localizar uma dependência oculta ou resumir módulos desconhecidos.

A medição deve incluir retrabalho. Se a IA aumenta a produção inicial, mas também eleva commits corretivos, rodadas de revisão ou incidentes, o ganho bruto de geração superestima o benefício.

A qualidade do sistema ao redor importa tanto quanto a capacidade do modelo. Documentação clara, mudanças pequenas, testes confiáveis, arquitetura modular e implantações observáveis tornam a produção da IA mais fácil de avaliar. Fundamentos fracos de engenharia dão aos agentes mais espaço para ampliar a confusão.

Esse é o núcleo cético do conselho de carreira do GitHub. As três competências recomendadas são plausíveis porque os agentes continuam imperfeitos, não porque a implementação se tornou totalmente autônoma. Direcionar, revisar e julgar são salvaguardas em torno de uma ferramenta cujo efeito líquido ainda depende fortemente do contexto.

Portanto, desenvolvedores devem resistir a dois extremos. Tratar agentes como autocompletar não confiável ignora ganhos reais. Tratá-los como engenheiros independentes transfere decisões sem transferir responsabilidade.

O Que Comprovará que o Modelo do GitHub para Desenvolvedores Funciona

O próximo teste é verificar se fluxos de trabalho conduzidos por agentes melhoram software concluído, e não se geram mais código.

O primeiro sinal a observar é o desempenho mensurável de entrega. Organizações que adotam agentes devem informar se tempo de ciclo, taxas de falha em mudanças, tempo de recuperação e resultados para clientes melhoram em conjunto. Rascunhos mais rápidos com revisões mais lentas enfraqueceriam o modelo proposto pelo GitHub.

Um resultado mais forte mostraria que as equipes entregam mudanças menores e mais seguras enquanto agentes lidam com tarefas de implementação delimitadas. Isso sugeriria que os desenvolvedores estão direcionando capacidade com sucesso, em vez de apenas aumentar o tamanho dos lotes.

O segundo sinal é como as organizações de engenharia revisam seus planos de carreira. O argumento do GitHub ganha força se empregadores começarem a reconhecer qualidade de especificação, revisão de IA, raciocínio arquitetural e gestão de riscos como critérios explícitos de promoção.

Uma mudança de título, por si só, provaria pouco. A evidência significativa apareceria em exercícios de contratação, avaliações de desempenho, programas de mentoria e responsabilidade por projetos. As empresas precisariam recompensar desenvolvedores por evitar trabalho fraco, e não apenas por produzir artefatos visíveis.

O terceiro sinal é se os sistemas de revisão acompanham o ritmo da geração. Agentes melhores podem criar mais código candidato, mas as equipes precisam de testes mais fortes, procedência mais clara e controles de aprovação baseados em risco. Caso contrário, a fila de verificação se tornará o fator limitante.

Críticas feitas por um segundo modelo são um mecanismo útil. Análise estática, varredura de segurança, testes de propriedades, execução isolada e lançamentos graduais fornecem tipos diferentes de evidência. Nenhum modelo único deve servir simultaneamente como autor e autoridade final.

Desenvolvedores podem agir antes que essas mudanças organizacionais cheguem. Comece selecionando uma tarefa delimitada, com critérios claros de aceitação. Registre todo o tempo gasto especificando, gerando, revisando, corrigindo, testando e implantando-a.

Compare esse resultado com trabalho semelhante concluído sem um agente. Examine qualidade e esforço, não apenas o tempo de geração decorrido. O objetivo é identificar onde a assistência cria alavancagem e onde introduz um custo de revisão.

Em seguida, pratique explicar cada mudança gerada. Se você não consegue descrever suas premissas, modos de falha e trade-offs, não está pronto para aprová-la. Pedir a outro modelo uma crítica pode ampliar a busca, mas seu próprio julgamento técnico deve encerrá-la.

Por fim, proteja o ciclo de aprendizado. Escreva código quando a implementação ensinar algo essencial. Delegue quando a tarefa for compreendida, delimitada e fácil de verificar. Use agentes para ampliar o julgamento de engenharia, não para evitar desenvolvê-lo.

As habilidades de desenvolvedores de IA no GitHub estão se tornando coordenação, revisão crítica e tomada de decisões responsável. Qual parte do seu fluxo de trabalho atual fornece evidências suficientes para confiar em um agente, e qual parte ainda depende de conhecimentos que somente sua equipe possui?