Este texto é uma releitura de um artigo que publiquei em 2019 (leia o original). Sete anos depois, o que mudou?
Fala galera!
Em 2019 eu escrevi que a gente tinha deixado de ser “atendedor de pedidos” fazia tempo. Que o desenvolvedor participava de todo o ciclo: da reunião de definição técnica até a monitoração em produção, passando por testes automatizados, pipelines e ambientes montados por código. Terminei o texto falando de métricas e de “times com atitude”, em que ninguém é dono exclusivo de uma atividade.
Reli o artigo esses dias e a sensação foi curiosa: tudo aquilo continua valendo. Só que a régua subiu. E subiu por um motivo que em 2019 eu não previa com essa velocidade: a inteligência artificial entrou no dia a dia de quem escreve software.
O que continua igual
A ideia central do texto de 2019 era simples: o desenvolvedor é responsável pela entrega inteira, não só pelo trecho de código que digitou. Isso não mudou. Se algo quebra em produção às três da manhã, continua sendo problema do time, e não de um “pessoal da infra” que ninguém sabe quem é.
Automação de testes, deploy contínuo, infraestrutura como código, observabilidade: em 2019 isso era diferencial. Em 2026 é o mínimo. Quem ainda faz deploy na mão está pagando um preço alto e nem sempre percebe.
E as métricas de uso, que na época eu descrevia como um hobby com dados analíticos, hoje são parte da conversa de produto. Saber qual funcionalidade é usada e qual chamada de API está lenta continua sendo atribuição de quem constrói.
O que mudou: o gargalo agora é a revisão
Aqui está a virada. Com o Copilot e os agentes de código, escrever a linha deixou de ser a parte cara do trabalho. Eu descrevo o que quero, o agente propõe uma implementação, roda os testes, ajusta e me devolve um pull request. Em muitos casos, o que levava uma tarde agora leva o tempo de um café.
Só que revisar código ficou pesado. A gente não consegue revisar na mesma velocidade em que o código é gerado. A revisão virou o gargalo, e por isso ter bons processos de validação desse código deixou de ser detalhe: testes, linters, análise estática, análise de segurança. Tudo isso rodando antes de um humano abrir o diff.
Isso não significa abrir mão de entender o código. Ainda precisamos saber o que foi feito e como foi feito. A diferença é que a revisão humana passa a focar nos pontos específicos e principais — regra de negócio, segurança, decisões de arquitetura — e deixa para as ferramentas o que pode ser verificado automaticamente.
E automação de testes hoje não é opcional. A gente entrega mais de uma vez por dia. Se cada entrega tiver de esperar um time de qualidade rodar um novo ciclo inteiro de testes, o produto não sai do lugar. O teste automatizado valida, no mínimo, o caminho crítico da aplicação: garante que nada impede a conversão de um lead em cliente, de um pedido em faturamento.
Construir o harness virou ofício
Se em 2019 eu dizia que a gente participava de todo o ciclo, em 2026 eu diria que a gente orquestra o ciclo. E orquestrar tem nome: harness. A gente se especializou em montar o conjunto de agentes e subagentes, skills, tools, hooks e demais recursos que os agentes de codificação oferecem, e em otimizar tudo isso para o nosso processo e, sim, para o nosso projeto. Não existe configuração genérica que sirva para todo mundo.
Isso inclui orquestrar as demandas entre os agentes, desenhar os loops de trabalho e, principalmente, medir o consumo de tokens. Cada chamada a um modelo tem preço, e um loop mal feito pode consumir em uma hora o orçamento do mês. Gerir esse custo e demonstrar o retorno sobre o investimento é fundamental. Se você não consegue mostrar quanto a IA custa e quanto ela entrega, alguém vai decidir por você.
Outras atribuições que ganharam peso
- Escrever a especificação antes do código. O tal spec-driven development. Se o agente vai implementar a partir de uma descrição, a qualidade dessa descrição é o que define a qualidade da entrega. Especificar bem virou habilidade técnica, não burocracia de gerente.
- Avaliar a saída dos modelos. Quando a aplicação que você constrói usa um modelo de linguagem, “funciona” deixa de ser binário. Você precisa de conjuntos de avaliação, métricas de qualidade da resposta, testes que detectam quando o modelo começou a alucinar depois de uma atualização. Isso é teste automatizado de 2026.
- Observar a IA em produção. Rastrear prompts, tokens, tempo de resposta, taxa de fallback, o que o agente decidiu fazer e por quê. A observabilidade que eu defendia em 2019 para APIs agora precisa cobrir o raciocínio da aplicação.
Na mesa do produto, não no balcão de pedidos
Em 2019 eu dizia que tínhamos deixado de ser tiradores de pedido. Em 2026 isso ficou ainda mais literal. A gente senta junto com os stakeholders para ajudar a definir o plano de produto. Com base nas métricas de negócio, ajuda a decidir se uma nova funcionalidade é viável e rentável ou não. Quando gerar código fica barato, a pergunta mais cara passa a ser o que vale a pena construir.
Para isso, a gente acompanha as tendências e conhece os jargões do negócio. Afinal, a spec que vai guiar o agente precisa usar a tão famosa linguagem ubíqua que Eric Evans descreve no livro Domain-Driven Design. Se o time técnico e o time de negócio não falam a mesma língua, o agente vai implementar com perfeição a coisa errada.
Acessibilidade é atribuição de todo mundo
Tem um ponto que em 2019 eu deixei de fora e hoje não deixo mais. Eu sou pessoa com deficiência visual e uso leitor de tela o dia inteiro, inclusive para revisar o que os agentes de código me entregam. Sei na prática que acessibilidade tratada como “fase final” vira acessibilidade que não acontece.
E aqui a IA ajuda e atrapalha ao mesmo tempo. Ajuda porque o agente consegue gerar componentes com semântica correta, rótulos e navegação por teclado se você pedir. Atrapalha porque, se você não pedir, ele reproduz o padrão médio da internet, que é ruim. A diferença está na especificação e na validação, que são justamente as atribuições que citei acima. Quem escreve a spec, quem monta os testes automatizados de acessibilidade e quem aprova o pull request decide se a pessoa que usa leitor de tela vai conseguir usar o produto. Não dá mais para terceirizar isso para um especialista no fim do projeto.
Times com atitude, versão 2026
Encerrei o texto de 2019 dizendo que a gente não teria mais “donos” de atividades e precisaria de times com atitude. Sete anos depois, acho que acertei o diagnóstico e errei a escala. Não é só que o dev faz um pouco de infra e um pouco de produto. É que o dev agora coordena ferramentas que fazem parte do trabalho por ele, e a atitude que importa é a de quem assume responsabilidade pelo resultado mesmo quando não digitou cada linha.
Atitude em 2026 é dizer “esse código foi gerado, mas eu entendo o que ele faz e respondo por ele”. É perguntar quanto custa antes de colocar um agente em loop. É recusar um componente bonito que não funciona no teclado. É medir a saída do modelo em vez de confiar no exemplo que funcionou na demo.
O que não mudou nada é a pergunta de fundo: o que é uma atribuição justa? Continuo achando que existem vagas pedindo um profissional impossível pelo salário que querem pagar. Mas também continuo achando que quem se dispõe a enxergar o ciclo inteiro, e agora a orquestrar o ciclo inteiro, é quem torna a operação viável, especialmente em times pequenos.
E você? O que virou sua atribuição nesses últimos anos que em 2019 nem existia?
Até a próxima!
