Engenheiro de software experiente

O relato de engenharia da própria GitHub sobre a passagem de TypeScript para Rust do ambiente de execução por trás do Copilot CLI e do Copilot SDK: 832 378 linhas de Rust de produção e 468 689 linhas de testes unitários em Rust, feito sobretudo por um único programador em poucos meses. Das 2639 mensagens escritas pelo humano, 31,0% centraram-se em revisão, testes e integração contínua; 17,4% contestaram decisões técnicas ou de desenho; e 15,0% insistiram em que o trabalho ficasse completo. Das 1 130 921 chamadas a ferramentas, 61% vieram de subagentes e não do fio principal da sessão — uma divisão entre agentes, não uma parte do trabalho feito por agentes. O programador guardou para si a arquitetura de destino, que comportamento tinha de ficar idêntico, como se repartia o trabalho, os compromissos ambíguos, a apreciação da prova, a revisão manual das zonas de alto risco e as decisões finais de fusão. Descreve também um agente que aplicou uma etiqueta que deixava passar uma verificação de esquema e que, posta em causa, se revelou esconder uma regressão. Um programador, um projeto, na própria base de código do fornecedor. Registado como capacidade, que neste sítio nunca move uma avaliação.

Uma demonstração, um referencial ou um artigo mostram que a tarefa pode ser feita. Atualiza o que a tecnologia consegue fazer, não o que as empresas vão fazer.

Uma norma de engenharia que vincula as equipas de software do Home Office. Diz que as equipas manterão plena responsabilização por todo o código e todos os resultados assistidos por IA, porque as ferramentas de IA não podem substituir o juízo, a compreensão, o papel de dono ou a responsabilidade humanos pelas decisões, pelo desenho ou pelas alterações feitas aos sistemas; que os resultados assistidos por IA têm de ser revistos e aprovados por um humano antes de chegarem à produção; e que as equipas têm de conseguir atestar a segurança e a facilidade de manutenção do que têm em funcionamento. O «must» firme aplica-se à revisão; a frase sobre o desenho diz onde fica a responsabilização. É a norma publicada de um único departamento, não uma medida da prática noutros lados.

Uma falha, um recuo, uma regulação ou um custo estão a travar a adoção. Pode baixar uma avaliação ou alargar a sua incerteza.

Um grande projeto de compilador de código aberto, vinculativo para os seus contribuidores. A política diz que as ferramentas de inteligência artificial não podem ser usadas para resolver issues do GitHub etiquetadas good first issue, porque essas issues em geral não são urgentes e se destinam a ser oportunidades de aprendizagem para novos contribuidores; diz que passar o feedback dos mantenedores a um LLM não ajuda ninguém a crescer e que rever alterações de novos contribuidores faz parte de formar a próxima geração de contribuidores. A cláusula entrou com a primeira versão da política, submetida a 16 de janeiro de 2026; as edições posteriores não a alteraram. É a regra de um projeto, não de um empregador.

Uma falha, um recuo, uma regulação ou um custo estão a travar a adoção. Pode baixar uma avaliação ou alargar a sua incerteza.

Uma grande distribuição Linux, vinculativa para os seus contribuidores e revisores. A política, cujos MUST e MUST NOT têm o sentido normal de uma especificação, diz que não se pode usar inteligência artificial como árbitro único ou final ao fazer um juízo substantivo ou subjetivo sobre uma contribuição, e que a responsabilidade final por aceitar uma contribuição, mesmo que executada por um sistema automatizado, cabe sempre ao contribuidor humano que autoriza a ação. Permite verificações automatizadas para validação técnica objetiva. Versão 1.0; a linha da própria página indica a última revisão a 24 de outubro de 2025.

Uma falha, um recuo, uma regulação ou um custo estão a travar a adoção. Pode baixar uma avaliação ou alargar a sua incerteza.

Mantenedores experientes em repositórios grandes e maduros que conhecem bem (cerca de 5 anos cada um); as ferramentas eram sobretudo o Cursor Pro com o Claude 3.5/3.7 Sonnet. Os autores não afirmam em momento algum que o resultado se generalize à maioria dos programadores nem ao trabalho em projetos novos ou de nível júnior.

Uma falha, um recuo, uma regulação ou um custo estão a travar a adoção. Pode baixar uma avaliação ou alargar a sua incerteza.

49 009 respostas de 177 países, recolhidas de 29 de maio a 23 de junho de 2025, e autosselecionadas: os inquiridos foram recrutados pelos canais da própria Stack Overflow, pelo que isto mede quem responde à Stack Overflow e não uma amostra aleatória de programadores. Fica registado junto à revisão de código escrito pela máquina e não junto a escrever código, porque o que mede é o motor do volume e a resposta de verificação, não quem escreve o quê. As duas metades pertencem aqui: 84 % usam ou tencionam usar ferramentas de IA (76 % um ano antes) e 51 % dos programadores profissionais usam-nas diariamente, ao passo que o sentimento favorável caiu de mais de 70 % em 2023 e 2024 para 60 %, mais programadores desconfiam ativamente da exatidão das ferramentas de IA (46 %) do que confiam nela (33 %), e os mais experientes apresentam a menor taxa de confiança elevada, 2,6 %, contra a maior taxa de desconfiança elevada, 20 %. O interesse em jogo corta para os dois lados, e isso é invulgar o suficiente para se dizer: o que os assistentes de código deslocam é o próprio tráfego da Stack Overflow, pelo que o dado de adoção vai contra o seu interesse comercial enquanto a queda de confiança vai a seu favor. O inquérito não diz para que foram usadas as ferramentas, se alguma revisão demorou mais, nem o que mudou no código que foi para produção.

Uma ferramenta é usada em grande escala em trabalho real e isso está medido, e quem decidiu usá-la foi a pessoa que trabalha, não quem emprega. É mais do que um registo de capacidade — o trabalho é real, não uma demonstração — e menos do que um de implementação, porque nenhum empregador a pôs em produção, nem a exigiu, nem construiu um processo à sua volta. Ponderada como `cautious`: `automating` significa que a máquina consegue fazer a tarefa E que há sinais de adoção, e isto é um sinal de adoção; mas o uso pode ser experimental, e boa parte da medição vem de uma parte com interesses, por isso um registo nunca chega e dois independentes chegam. Repara também em quem está a contar. A telemetria de um fornecedor vê isto diretamente e ao mesmo tempo vende a ferramenta, por isso um registo deste tipo declara esse interesse no seu âmbito; uma agência estatística que pergunta às empresas se os seus trabalhadores usam IA em tarefas vê o mesmo canal sem interesse nenhum, e onde exista é a melhor fonte.

Um componente de um organismo (ICE) dentro de um governo, e declarado por esse organismo ao abrigo de um dever legal em vez de escolhido para publicação — é precisamente isso que torna as entradas aborrecidas deste inventário dignas de leitura. Entrada DHS-2758 no CSV de declaração individual. O que fica estabelecido é a entrada em produção e as condições que a acompanham, não o quanto as ferramentas são usadas: o inventário não traz nenhum número de utilização, nenhum efetivo e nenhuma afirmação de produtividade para além de o organismo dizer que as ferramentas «aumentam a produtividade dos programadores». As duas cláusulas que sustentam as duas tarefas ligadas são frases separadas, nas palavras do próprio organismo: as saídas «têm de ser revistas e aprovadas antes de serem incorporadas no código através dos processos existentes de controlo de versões e de implementação» (a tarefa de rever), e «as ferramentas não alteram diretamente os sistemas de produção; todas as alterações têm de passar pelos fluxos normais de revisão humana, teste e aprovação» (a tarefa de definir o que um agente pode fazer sem vigilância). A ferramenta nomeada é uma compra a um fornecedor, o que convém saber, embora quem declara aqui seja o organismo e não o fornecedor. O mesmo inventário traz um sinal em sentido contrário do mesmo departamento: a entrada DHS-373, «IA generativa comercial para geração de código», tem como fase de desenvolvimento «Retirada». Essa linha não tem data nem motivo, pelo que apenas estabelece que o DHS chegou a listar esse uso e já não o mantém.

Uma empresa pô-lo em produção. Pode mover a linha de base, ponderado pela escala e por quanto esse contexto se parece com o teu.

Ainda não és esta página, e o caminho até ela é justamente o que está sob pressão — lê primeiro a página de júnior. O que mais conta aqui é que a capacidade que esta profissão vende é critério sobre um sistema concreto, e isso adquire-se estando dentro de um, e não usando ferramentas melhores.

A conclusão medida desta página é que as ferramentas não te aceleraram no teu próprio código, e que podes ter acreditado no contrário. Trata isso como razão para medires o teu próprio trabalho e não como consolo: o ensaio é pequeno e tem um ano, e a parte do lugar que está a crescer não é escrever — é rever o que chega, e responder por aquilo que a um agente foi permitido fazer.

Ficar e reforçar-te

Tornares-te a pessoa em quem se confia para dizer que não

À medida que as alterações geradas se multiplicam, o estrangulamento passa para quem consegue recusar uma com uma razão que se aguenta. Essa autoridade ganha-se estando certo em público, repetidamente, sobre um sistema concreto.

Refazer o posto

Assumir o que os agentes podem fazer

Alguém tem de decidir o que uma alteração automatizada pode tocar e por onde entra. Na maioria das equipas isso não foi dado a ninguém, e é por isso que aparece nos relatórios de incidentes em vez das descrições de funções.

Movimento lateral

Ir para onde estar errado sai caro por lei

Pagamentos, sistemas críticos de segurança, dados regulados — sítios onde uma alteração sem vigilância não é permitida, por isso a revisão e a responsabilidade são financiadas em vez de assumidas.

Mudança de setor

Passar para o lado do problema

Engenharia de soluções, produto técnico, experiência de programador — lugares onde o valor é perceber ao mesmo tempo um sistema e o que alguém precisa dele, e onde escrever nunca foi a parte rara.

O único ensaio aleatorizado que este sítio tem encontrou o contrário, e o detalhe que vale a pena levar é a distância entre medição e perceção: dezasseis mantenedores experientes de código aberto a trabalhar em problemas reais de repositórios que conheciam demoraram 19% mais com ferramentas de 2025, enquanto estimavam ter sido 20% mais rápidos. Os autores não afirmam que isto descreva a maioria dos programadores nem os projetos novos, e tem um ano. O que estabelece é que a aceleração não é automática num código maduro, e que perguntar a ti próprio não resolve a questão.

Ninguém consegue responder a isso com um número, e as respostas confiantes dos dois lados estão a vender alguma coisa. Uma pergunta mais útil é que parte do trabalho, porque as partes movem-se a velocidades diferentes: escrever código de rotina é já em grande medida feito por máquina, rever o que ela produziu tornou-se um trabalho próprio, e decidir o que sai com um risco conhecido não se moveu porque é responsabilidade e não capacidade. Repara antes num sinal que consigas verificar: quanto da tua semana é agora ler código que não escreveste.

Está exposto de outra forma, não mais seguro, e as duas coisas estão ligadas. Uma profissão que deixa de formar seniores tem um problema de abastecimento mais tarde, não uma garantia de segurança agora: se chegarem menos pessoas à base, o ensino que antes se repartia por uma equipa recai sobre menos pessoas. Algumas comunidades de engenharia já protegem esse caminho de propósito — o LLVM proíbe ferramentas de IA nos problemas etiquetados como good first issue, para que os novos contribuidores possam aprender com eles.

Ainda ninguém consegue responder a isso com prova, e dizê-lo é mais útil do que adivinhar. Os três têm exposições genuinamente diferentes, mas os estudos que existem foram desenhados para comparar níveis de experiência e não pilhas tecnológicas, pelo que não há com que os separar. Qualquer ordenação confiante de frontend contra backend deve ser lida como a impressão de alguém. O que a prova sustenta é outro critério: escolher pelo quanto custa errar no teu domínio — e isso atravessa os três por igual.

Rever código que não escreveste, e conseguir dizer porque recusaste alguma coisa. Essa competência esteve sempre neste lugar e nunca foi aquilo por que alguém era contratado ou avaliado; é agora o estrangulamento, porque gerar deslocou o trabalho de produzir para julgar. É também a capacidade que te torna a pessoa em quem se confia para dizer que não, que é a parte deste trabalho sem substituto à vista.