Programar com IA: delegar sem perder o controlo

Os agentes de programação aceleram algumas tarefas, mas a sua supervisão depende de competências que é preciso continuar a exercitar. O que os estudos e os engenheiros permitem realmente afirmar.

Um agente de programação pode escrever código, executar comandos e encadear várias etapas sem esperar por uma instrução a cada passo. O trabalho do programador muda, então: menos escrita, mais definição de objetivos e verificação. Mas há uma questão menos visível do que o ganho de tempo: se praticarmos menos determinadas tarefas, como manter as competências necessárias para detetar um erro ou voltar a assumir o controlo?

Este risco é debatido por engenheiros que usam estas ferramentas no dia a dia, mas não deve ser confundido com uma perda duradoura de competências comprovada em todos os programadores. Os elementos disponíveis descrevem sobretudo utilizações, perceções e experiências limitadas a tarefas específicas. Ainda assim, permitem compreender em que situações a delegação pode tornar-se frágil e como tornar o controlo mais concreto.

Delegar código não significa delegar a responsabilidade

Num texto dedicado à utilização de agentes de programação, Addy Osmani, engenheiro na Anthropic e membro da equipa do Claude Code, distingue três níveis de delegação. No primeiro, o agente apresenta uma proposta que a pessoa analisa. No segundo, essa proposta torna-se o ponto de partida do trabalho. No terceiro, é aceite sem um verdadeiro controlo. Os investigadores da Wharton designam esta atitude pela expressão «capitulação cognitiva».

A diferença reside menos na ferramenta do que no papel que o utilizador mantém. Um programador pode deixar um agente escrever uma função e continuar a ser responsável por compreender o que ela faz, verificar se corresponde à necessidade e decidir se pode ser integrada. Em contrapartida, uma resposta tecnicamente plausível pode ser aceite por estar bem apresentada ou porque o primeiro teste passa.

No entanto, um teste que passa só demonstra aquilo que verifica. Se o teste reproduzir uma hipótese errada da função que deveria controlar, ambos podem não detetar o problema. Por isso, uma verificação útil consiste também em analisar o alcance do teste: que casos abrange, quais deixa de fora e que pressupostos é preciso aceitar para que o resultado seja fiável?

Os ganhos na utilização não medem a aprendizagem

Um estudo publicado pela Anthropic em 2025 dá uma perspetiva sobre as mudanças observadas na empresa. Baseia-se num inquérito a 132 engenheiros e investigadores, 53 entrevistas e na análise de 200 000 transcrições internas do Claude Code, recolhidas em fevereiro e agosto de 2025. No inquérito, os trabalhadores estimavam utilizar o Claude em 59 % do seu trabalho e atribuíam-lhe um aumento médio de produtividade de 50 %. Estes números são declarativos: descrevem a sua perceção, não uma medição independente do tempo efetivamente poupado.

A análise das transcrições mostra, por sua vez, uma evolução na distribuição das utilizações. Entre fevereiro e agosto, a proporção de transcrições classificadas como relativas à implementação de novas funcionalidades passou de 14,3 % para 36,9 %, e a proporção classificada como relativa à conceção ou ao planeamento de código passou de 1 % para 9,9 %. A ferramenta também encadeava mais ações antes de uma nova intervenção humana. Estes resultados indicam que as equipas confiavam ao Claude Code tarefas mais complexas ou mais autónomas. Por si só, não medem um aumento do volume total de trabalho nem o nível de competência de cada pessoa.

As entrevistas revelam o possível reverso desta evolução. Alguns participantes afirmam ganhar à-vontade em áreas que dominavam pouco, porque a IA facilita a criação de uma primeira versão ou a exploração de código novo. Outros receiam aprender menos ao resolverem os problemas por si próprios: ler a documentação, analisar o funcionamento de uma ferramenta ou acompanhar um erro pode transmitir conhecimentos que não são indispensáveis para a correção imediata, mas que depois ajudam a compreender o sistema no seu conjunto.

A Anthropic especifica que os participantes são funcionários de uma empresa que desenvolve estas ferramentas e que lhes acedem num contexto particular. As respostas também podem ser influenciadas pela seleção das pessoas entrevistadas e pelo caráter declarativo de algumas medições. Este trabalho esclarece opções observadas nessa organização; não permite concluir que os programadores, em geral, perdem duradouramente as suas competências quando utilizam IA.

Supervisionar pressupõe saber o que se está a controlar

Este é o paradoxo prático da supervisão: para avaliar o código de um agente, é preciso ter conhecimentos suficientes para detetar o que é perigoso, incompleto ou inadequado. Ora, os participantes entrevistados pela Anthropic exprimem precisamente preocupações quanto à manutenção de competências que servem tanto para escrever código como para o avaliar. Por isso, alguns dizem reservar momentos para programar sem IA, de modo a continuarem a exercitar esse saber-fazer.

Esta opção não responde a todas as questões. Continua, nomeadamente, por determinar que competências são indispensáveis num trabalho em que as ferramentas alteram as tarefas confiadas aos engenheiros. Alguns trabalhadores entrevistados perspetivam uma mudança para a conceção, a revisão ou a coordenação de agentes. Outros lamentam a prática direta de programação ou questionam-se sobre a formação dos principiantes. O estudo relata estes pontos de vista; não determina o futuro da profissão.

Os resultados de outro estudo, discutido pelos seus autores na Wharton Magazine, chamam a atenção para a aceitação de uma resposta gerada. Os participantes podiam consultar o ChatGPT para resolver questões de lógica e raciocínio. Steven Shaw explica que, nas experiências, as pessoas que consultaram a ferramenta adotavam frequentemente a sua resposta, incluindo quando esta estava incorreta. Estes exercícios esclarecem um comportamento numa situação experimental; não medem nem a qualidade do trabalho de um programador numa empresa nem uma erosão duradoura das suas capacidades.

Um controlo ajustado ao risco

Addy Osmani não recomenda verificar todas as tarefas com a mesma intensidade. Uma delegação de baixo risco e fácil de corrigir não exige necessariamente o mesmo escrutínio que uma alteração suscetível de afetar a segurança, os dados ou a entrada em produção. Antes de uma tarefa importante, propõe formular uma hipótese própria e, depois, procurar o que poderia tornar falsa a resposta do agente. Aconselha também a pedir-lhe que explicite as suas escolhas e os valores predefinidos que utilizou.

No caso de uma alteração de software, estas etapas podem traduzir-se em perguntas concretas: que comportamento deve mudar? Que partes do sistema serão afetadas? Que casos abrange realmente o teste? O agente introduziu uma dependência ou um pressuposto que a equipa não analisou? Uma revisão útil não consiste apenas em reler o resultado; confronta-o com critérios definidos antes de o aceitar.

A questão não é, portanto, escolher entre escrever cada linha pessoalmente e deixar que um agente faça tudo. Trata-se de decidir que operações podem ser delegadas, manter compreensão suficiente para supervisionar as decisões importantes e verificar se os hábitos de trabalho continuam a gerar as competências necessárias. A rapidez de execução é visível assim que o código é gerado. A capacidade de voltar a assumir o controlo, essa, mede-se quando é preciso explicá-lo, corrigi-lo ou fazê-lo evoluir.