Durante décadas, a senioridade de um profissional de tecnologia foi associada à sua capacidade de executar tarefas mais difíceis.
O desenvolvedor mais experiente escrevia o código mais complexo. O arquiteto desenhava as integrações críticas. O especialista em dados construía os modelos mais sofisticados. A qualidade individual era demonstrada principalmente pela capacidade de produzir soluções que poucas pessoas conseguiriam produzir.
A inteligência artificial está alterando essa lógica.
Código, documentação, análises, testes, consultas, protótipos e alternativas de solução podem ser gerados em uma velocidade antes impraticável. O custo de produzir uma primeira versão está diminuindo, enquanto o volume de artefatos disponíveis cresce.
Isso não torna o especialista menos importante.
Torna insuficiente um tipo específico de especialista: aquele cujo valor depende exclusivamente de executar pessoalmente cada parte do trabalho.
Em ambientes apoiados por inteligência artificial e agentes, a contribuição mais relevante começa a se deslocar da produção direta para outro conjunto de responsabilidades: definir a intenção, decompor o problema, organizar o contexto, coordenar a execução, validar resultados e responder pelas consequências.
O especialista deixa de ser apenas o principal executor.
Ele passa a ser o orquestrador de um sistema de trabalho composto por pessoas, ferramentas e agentes de IA.
Quando produzir deixa de ser o principal gargalo
A maior parte das organizações ainda está utilizando a IA para acelerar atividades existentes.
Um profissional pede que a ferramenta escreva uma função, resuma um documento, gere um teste ou proponha uma consulta. O processo continua essencialmente o mesmo. A diferença é que uma etapa antes manual recebe algum grau de automação.
Esse uso pode gerar ganhos reais, principalmente em tarefas delimitadas.
Em um experimento controlado publicado pela Microsoft Research, desenvolvedores com acesso ao GitHub Copilot concluíram uma tarefa específica de programação 55,8% mais rapidamente do que o grupo sem a ferramenta. O experimento, porém, avaliou uma atividade bem definida: a implementação de um servidor HTTP em JavaScript.
O cenário muda quando o profissional precisa atuar sobre sistemas reais, com histórico, dependências, regras implícitas e consequências operacionais.
Em 2025, a METR conduziu um experimento randomizado com 16 desenvolvedores experientes, trabalhando em 246 tarefas reais dentro de grandes repositórios de código aberto que conheciam profundamente. Naquele contexto específico, os participantes levaram, em média, 19% mais tempo quando puderam utilizar ferramentas de IA. Os próprios desenvolvedores acreditavam que a IA os havia tornado mais rápidos, mostrando uma diferença relevante entre percepção e desempenho observado. A METR ressalta que o resultado representa aquele contexto e não deve ser generalizado para todo o desenvolvimento de software.
Os dois resultados não são contraditórios.
Eles indicam que o impacto da IA não depende apenas da capacidade do modelo. Depende da natureza da tarefa, da qualidade do contexto, da familiaridade do profissional com o sistema, do custo de revisão e da forma como o trabalho é organizado.
Produzir código para um problema delimitado é diferente de modificar um sistema que possui anos de decisões acumuladas, múltiplas integrações, regras de segurança e comportamentos que nunca foram completamente documentados.
Quanto mais complexo o contexto, menor é o valor de simplesmente gerar mais artefatos.
O gargalo passa a ser decidir o que deve ser gerado, sob quais restrições e como demonstrar que o resultado está correto.
Código abundante não significa software confiável
Uma pesquisa apresentada em 2026 no ICSE Future of Software Engineering argumenta que, quando máquinas conseguem produzir código mais rapidamente do que seres humanos conseguem analisá-lo, a engenharia de software não pode continuar organizada principalmente em torno da construção manual.
Segundo os autores, o núcleo da disciplina se desloca para três atividades: articulação de intenção, controle arquitetural e verificação contínua. A automação não elimina o trabalho de engenharia; ela transfere o principal gargalo da produção para o discernimento humano.
Essa distinção é fundamental.
Um agente pode produzir uma implementação funcional e ainda assim:
- Interpretar incorretamente uma regra de negócio;
- Ignorar uma restrição de segurança;
- Duplicar uma capacidade já existente;
- Introduzir dependências desnecessárias;
- Resolver o caso principal e falhar nos casos de exceção;
- Alterar comportamentos que outros sistemas utilizam;
- Produzir uma solução difícil de operar ou manter;
- Atender ao pedido literal sem alcançar o objetivo real.
O problema não está necessariamente na qualidade sintática do código.
Está na distância entre a solução gerada e a intenção que deveria orientar o sistema.
Esse risco cresce porque a geração é rápida e convincente. Uma resposta bem estruturada, um teste aprovado ou uma interface visualmente correta podem criar a impressão de que o problema foi resolvido.
A velocidade da produção pode esconder a ausência de compreensão.
Por isso, o valor do especialista passa a estar menos relacionado à quantidade de código que consegue escrever e mais à sua capacidade de estabelecer limites dentro dos quais a geração pode acontecer com segurança.
Orquestrar não é apenas escrever bons prompts
A ideia de orquestração pode ser confundida com a capacidade de elaborar comandos detalhados para uma ferramenta de IA.
Isso é apenas uma pequena parte do trabalho.
Um prompt orienta uma interação. A orquestração organiza um sistema de execução.
Ela começa antes que qualquer agente seja acionado.
O especialista precisa compreender qual resultado deve ser alcançado, quais informações são confiáveis, quais decisões podem ser delegadas e quais precisam permanecer sob controle humano.
Também deve identificar se o problema realmente exige um agente.
A Anthropic diferencia workflows de agentes. Nos workflows, modelos e ferramentas seguem caminhos previamente definidos. Nos agentes, o próprio modelo decide dinamicamente como utilizar ferramentas e conduzir o processo. A recomendação da empresa é começar pela solução mais simples e aumentar a autonomia apenas quando a complexidade do problema justificar os custos adicionais de latência, operação e previsibilidade.
Essa decisão é parte da especialidade.
Um profissional imaturo pode tentar transformar qualquer processo em um conjunto de agentes autônomos porque a tecnologia está disponível.
Um especialista compreende que algumas tarefas precisam apenas de uma chamada bem contextualizada. Outras funcionam melhor como workflows determinísticos. Apenas uma parte dos problemas exige autonomia, planejamento dinâmico e uso flexível de ferramentas.
Orquestrar significa escolher o nível correto de automação.
Também significa definir:
- Quais dados cada agente pode acessar;
- Quais ferramentas pode utilizar;
- Quais ações pode executar sem aprovação;
- Como seu resultado será verificado;
- O que acontece quando há incerteza;
- Quando a execução deve ser interrompida;
- Como decisões e alterações serão registradas;
- Quem permanece responsável pelo resultado final.
A responsabilidade não desaparece quando uma tarefa é delegada a uma IA.
Ela apenas se torna mais difícil de localizar.
O especialista passa a definir intenção
Sistemas tradicionais também precisam de requisitos, mas o trabalho com agentes torna a qualidade da intenção ainda mais importante.
Quando uma equipe humana recebe uma especificação incompleta, seus membros frequentemente percebem ambiguidades, fazem perguntas e utilizam o conhecimento organizacional para preencher lacunas.
Um agente tende a transformar a solicitação recebida em uma trajetória de execução.
Caso a intenção esteja incompleta, ele poderá completar as lacunas com inferências plausíveis, porém incorretas.
Por isso, definir intenção não significa apenas descrever uma funcionalidade.
Significa explicitar:
- Qual problema precisa ser resolvido;
- Qual resultado representa sucesso;
- Quais comportamentos são obrigatórios;
- Quais comportamentos são proibidos;
- Quais restrições técnicas e regulatórias existem;
- Quais concessões podem ser feitas;
- Quais evidências serão utilizadas para aceitar o resultado.
Um trabalho recente sobre a transformação da engenharia de software argumenta que, à medida que o código se torna abundante, o valor durável do engenheiro migra para a especificação da intenção, o julgamento crítico e a supervisão responsável, em vez de permanecer concentrado no volume de código produzido.
Essa mudança aproxima o especialista da arquitetura, do produto e da operação.
Para formular uma intenção suficientemente precisa, ele precisa compreender não apenas a tecnologia, mas o ambiente no qual a solução funcionará.
Uma solicitação como “crie uma integração com o ERP” é insuficiente para uma execução autônoma.
É necessário determinar qual sistema possui autoridade sobre cada dado, como conflitos serão resolvidos, qual comportamento é esperado em caso de indisponibilidade, quais eventos precisam ser auditados e como a operação será reconciliada.
Sem essas definições, o agente pode produzir uma integração.
Mas não necessariamente a integração que o negócio consegue operar.
Executar passa a significar decompor e coordenar
Em um modelo tradicional, o especialista costuma assumir pessoalmente as partes mais difíceis do trabalho.
Com agentes, ele pode distribuir a execução, mas precisa fazer isso sem perder coerência.
Uma demanda de desenvolvimento pode ser dividida entre agentes responsáveis por explorar o repositório, propor uma arquitetura, implementar componentes, gerar testes, revisar segurança e documentar decisões.
Essa distribuição não elimina a necessidade de conhecimento técnico.
Ela exige conhecimento suficiente para decompor corretamente o problema e reconhecer quando diferentes resultados não se encaixam.
O especialista precisa entender dependências, precedências e superfícies de risco.
Duas implementações podem funcionar isoladamente e ser incompatíveis quando combinadas. Um teste pode validar o comportamento esperado e ignorar uma exigência não funcional. Uma revisão de segurança pode se concentrar no código gerado e não observar a forma como o agente acessou informações sensíveis durante a execução.
Coordenar agentes é diferente de distribuir tarefas para pessoas.
Agentes não possuem compreensão organizacional compartilhada, responsabilidade própria ou experiência acumulada do contexto da empresa. Eles operam sobre o contexto disponibilizado e sobre os sinais recebidos durante a execução.
O orquestrador precisa construir essa coerência externamente.
A validação se torna parte central da produção
Quando o custo de gerar diminui, o custo relativo de verificar aumenta.
Esse fenômeno já aparece em pesquisas sobre uso real de agentes de programação.
O estudo SWE-chat analisou 6.000 sessões públicas de agentes de desenvolvimento, envolvendo mais de 63 mil prompts e 355 mil chamadas de ferramentas. Segundo os autores, apenas 44% do código produzido pelos agentes permaneceu nos commits finais. Usuários corrigiram, interromperam ou reportaram problemas nas respostas dos agentes em 44% dos turnos, e o código gerado apresentou mais vulnerabilidades de segurança do que o código escrito por humanos no conjunto analisado.
Outro estudo de 2026 analisou 278.790 conversas de revisão de código em 300 projetos de código aberto. As sugestões de agentes foram adotadas em proporção significativamente menor do que as sugestões humanas. Mais da metade das recomendações de IA que não foram aceitas estava incorreta ou precisou ser resolvida de outra maneira pelos desenvolvedores. O estudo também observou que sugestões de agentes, quando adotadas, produziram aumentos maiores de tamanho e complexidade do código, reforçando a necessidade de supervisão humana contextual.
Esses resultados não significam que agentes sejam incapazes de produzir software útil.
Mostram que geração e aceitação são problemas diferentes.
O especialista precisa criar mecanismos que transformem a validação em algo mais consistente do que uma leitura manual feita ao final.
Testes automatizados, contratos de API, regras arquiteturais, análise estática, ambientes isolados, observabilidade e critérios de aceite executáveis passam a funcionar como instrumentos de controle.
O teste deixa de ser apenas uma etapa posterior à implementação.
Ele passa a ser uma forma de expressar intenção antes e durante a geração.
Quando um agente recebe critérios verificáveis, sua autonomia pode aumentar sem que a organização perca completamente a capacidade de controle.
Governança deixa de ser uma camada administrativa
Em muitas empresas, governança é tratada como algo externo à execução técnica.
O time produz. Outra área verifica segurança, privacidade, conformidade ou documentação.
Esse modelo se torna frágil quando agentes conseguem tomar decisões e executar ações em alta velocidade.
A governança precisa estar incorporada ao próprio desenho do trabalho.
Um agente que consulta dados de clientes, modifica um sistema produtivo ou cria uma integração não deve receber acesso irrestrito simplesmente porque sua tarefa exige autonomia.
O especialista precisa projetar limites de atuação.
Isso inclui permissões mínimas, separação de ambientes, aprovação para ações críticas, registro de ferramentas utilizadas e capacidade de reconstruir como uma alteração foi produzida.
A arquitetura deixa de ser apenas uma representação dos componentes do sistema.
Ela se torna uma superfície de controle.
Uma boa arquitetura delimita o que pode ser alterado, como partes do sistema se relacionam, quais contratos precisam ser preservados e onde verificações devem ser aplicadas.
Sem esses limites, a capacidade de geração pode aumentar mais rapidamente do que a capacidade de compreender o sistema resultante.
A consequência é uma organização que produz mais software, mas confia menos nele.
O especialista não deixa de executar
A mudança para a orquestração não significa que profissionais experientes deixarão de programar, analisar ou construir soluções.
A execução direta continua necessária.
Um especialista precisa intervir nos pontos em que a abstração não é suficiente, explorar problemas ainda pouco compreendidos e validar se as ferramentas estão operando de maneira adequada.
Também precisa manter proximidade com o trabalho concreto para não se transformar em um coordenador incapaz de avaliar a qualidade do que está sendo produzido.
A diferença está na distribuição de seu tempo.
Em vez de assumir automaticamente toda tarefa crítica, o especialista avalia onde sua atuação direta gera maior retorno.
Ele pode implementar a primeira versão de um componente para estabelecer um padrão, enquanto agentes produzem variações posteriores. Pode investigar pessoalmente um incidente complexo, mas automatizar a coleta de evidências. Pode definir a arquitetura e utilizar agentes para testar alternativas antes de consolidar a decisão.
A execução deixa de ser o único produto de seu trabalho.
Ela passa a ser um instrumento de direção, aprendizado e controle.
O novo especialista precisa dominar mais do que ferramentas de IA
Saber utilizar copilotos, modelos de linguagem e agentes será uma competência comum.
Isso não será suficiente para caracterizar um profissional de alto impacto.
O especialista necessário para esse novo contexto precisa combinar profundidade técnica com capacidade de modelar problemas.
Ele deve conseguir transformar uma necessidade vaga em uma intenção verificável, estabelecer critérios de qualidade e reconhecer quando o resultado produzido apenas parece correto.
Também precisa compreender arquitetura, segurança, custos e consequências operacionais.
A coordenação de agentes cria novas decisões: qual modelo utilizar, quanto contexto fornecer, quando permitir autonomia, como avaliar a resposta, como limitar o consumo de recursos e como preservar rastreabilidade.
Essas decisões exigem repertório.
Um profissional sem experiência pode utilizar agentes para gerar rapidamente uma solução que não saberia construir sozinho. O ganho imediato pode ser significativo, mas sua capacidade de identificar falhas também será limitada.
A IA amplia tanto a capacidade de produção quanto o alcance dos erros.
A especialidade continua sendo o mecanismo que diferencia velocidade útil de velocidade descontrolada.
As empresas precisarão rever o que consideram produtividade
Métricas tradicionais de produção tendem a se tornar menos representativas.
Linhas de código, quantidade de commits, tickets concluídos ou documentos produzidos podem aumentar simplesmente porque a geração se tornou mais barata.
Esse crescimento não demonstra, por si só, que a organização está entregando mais valor.
Em um ambiente com agentes, uma avaliação mais adequada deve considerar a relação entre velocidade e confiabilidade.
A empresa precisa observar quanto do trabalho gerado foi efetivamente aceito, quanto precisou ser refeito, quais defeitos chegaram à produção, qual foi o custo da execução e quanto tempo humano foi consumido na supervisão.
Também deve avaliar se a automação criou capacidade reutilizável.
Um workflow bem estruturado, com contexto, ferramentas, testes e limites claros, pode continuar produzindo valor. Uma sequência de interações improvisadas pode gerar resultados pontuais sem deixar qualquer ativo organizacional.
A produtividade deixa de ser apenas a quantidade produzida por uma pessoa.
Passa a incluir a capacidade que essa pessoa construiu para que o sistema continue produzindo com qualidade.
A contratação também precisa mudar
Essa transformação altera a forma como empresas devem selecionar profissionais de tecnologia.
Listar ferramentas de IA em um currículo diz pouco sobre a capacidade real de trabalhar em um modelo orientado por agentes.
Durante a avaliação, é necessário investigar como o profissional estrutura problemas, valida resultados e toma decisões sob incerteza.
Um bom candidato não deveria apenas demonstrar que consegue gerar uma solução rapidamente.
Ele deveria conseguir explicar:
- Qual intenção orientou a execução;
- Que informações foram fornecidas ao agente;
- O que permaneceu sob controle humano;
- Como o resultado foi validado;
- Quais riscos foram identificados;
- Que evidências sustentaram a aprovação;
- Como a solução poderia ser reproduzida e auditada.
A senioridade passará a ser percebida menos pela velocidade com que o profissional aceita uma resposta e mais pela qualidade das perguntas que faz antes de aceitá-la.
Alocar especialistas passa a significar alocar capacidade de orquestração
Nem toda empresa terá internamente todos os perfis necessários para essa transição.
Projetos de agentes, automação ou desenvolvimento apoiado por IA frequentemente começam pela escolha de ferramentas. Em pouco tempo, surgem questões mais profundas sobre arquitetura, dados, segurança, processos e responsabilidade.
Nesse momento, o problema deixa de ser apenas implementar a tecnologia.
A empresa precisa de profissionais capazes de integrá-la à realidade operacional.
É nesse contexto que a alocação especializada ganha uma função diferente.
Não se trata apenas de adicionar uma pessoa para aumentar o volume de execução. Trata-se de incorporar alguém capaz de organizar a relação entre pessoas, sistemas e agentes, definir critérios de controle e ajudar o time a construir uma forma de trabalho sustentável.
Na REVIIV, a alocação de profissionais parte do problema e da maturidade do projeto, não apenas de uma lista de tecnologias.
Em iniciativas apoiadas por IA, isso significa identificar perfis que combinem conhecimento técnico, visão de negócio, capacidade de validação e responsabilidade sobre resultados.
A ferramenta utilizada pode mudar rapidamente.
A capacidade de organizar intenção, execução e controle continuará relevante.
O futuro não é composto apenas por agentes autônomos
Existe uma tendência de representar o futuro do trabalho como um ambiente no qual agentes executam integralmente projetos e profissionais humanos apenas aprovam resultados.
Essa visão simplifica excessivamente o problema.
Sistemas reais possuem objetivos conflitantes, requisitos incompletos e consequências que não podem ser reduzidas a uma função de sucesso.
Uma implementação pode ser tecnicamente correta e comercialmente inadequada. Uma automação pode reduzir custos e aumentar o risco regulatório. Um agente pode cumprir sua tarefa e prejudicar o funcionamento do conjunto.
Por isso, o futuro mais provável não é a retirada completa do especialista.
É a ampliação de seu campo de responsabilidade.
Ele produzirá menos partes manualmente, mas precisará compreender um sistema de execução mais amplo. Tomará menos decisões locais e mais decisões sobre objetivos, limites, interfaces e evidências.
A inteligência artificial desloca trabalho, mas não desloca responsabilidade.
Quando a produção se torna abundante, o julgamento se torna mais valioso.
O especialista do futuro não será aquele que insiste em executar tudo sozinho.
Também não será aquele que delega tudo à IA.
Será aquele capaz de determinar o que pode ser delegado, construir os mecanismos de controle e permanecer responsável pelo resultado.
Esse profissional não será apenas usuário de agentes.
Será o arquiteto do trabalho realizado por eles.
Fontes e referências
Kohl, Karina; Carro, Luigi. When Code Becomes Abundant: Redefining Software Engineering Around Orchestration and Verification. ICSE Future of Software Engineering, 2026.
Alenezi, Mamdouh. Human-AI Collaboration and the Transformation of Software Engineering Work. 2026.
Baumann, Joachim et al. SWE-chat: Coding Agent Interactions From Real Users in the Wild. 2026.
Zhong, Suzhen et al. Human-AI Synergy in Agentic Code Review. 2026.
Becker, Joel et al. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR, 2025.
Peng, Sida et al. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. Microsoft Research, 2023.
Anthropic. Building Effective Agents. 2024.
