A IA não está mais só completando código. Ela já está recebendo tarefas inteiras

Há poucos anos, ver o GitHub Copilot completar uma função enquanto você ainda estava digitando parecia algo impressionante.

Você começava a escrever e a IA tentava descobrir o que viria depois. Às vezes acertava em cheio, outras vezes inventava alguma coisa completamente errada, mas já economizava tempo suficiente para mudar a rotina de muita gente.

Depois vieram os chats dentro das IDEs.

Começamos a selecionar um trecho do código e perguntar por que aquilo não funcionava. Pedíamos uma refatoração, um teste unitário, documentação ou ajuda para entender aquele erro que já tinha consumido algumas horas.

Só que estamos entrando em outra fase.

A mudança mais importante não é que os modelos ficaram melhores em escrever código. É que começamos a entregar tarefas inteiras para eles.

É aí que entram os Coding Agents.

E isso muda bastante a relação entre desenvolvedor e inteligência artificial.

A diferença aparece quando paramos de pedir ajuda e começamos a delegar

Vamos pegar uma tarefa comum: adicionar autenticação JWT em uma API existente.

Com um assistente tradicional, eu poderia perguntar como implementar JWT, pegar o código sugerido, adaptar para a estrutura do projeto, criar o middleware, adicionar os testes e voltar para a IA sempre que alguma coisa desse errado.

A IA ajuda, mas sou eu que continuo coordenando cada etapa.

Com um Coding Agent, a instrução pode ser outra:

Implemente autenticação JWT nesta API respeitando a arquitetura atual. Adicione os testes necessários e valide que a aplicação continua funcionando.

A diferença está no que acontece depois.

O agente pode analisar o repositório antes de escrever qualquer coisa, descobrir como o projeto foi organizado, localizar os arquivos envolvidos, modificar mais de um componente, executar comandos e rodar os testes.

Se alguma coisa quebrar, ele analisa o erro e tenta corrigir.

No final, eu não recebo apenas uma resposta para copiar.

Recebo uma alteração no projeto para revisar.

É uma diferença enorme.

Perguntar “como faço isso?” é pedir conhecimento.

Dizer “faça isso” é delegar trabalho.

E essa segunda situação já deixou de ser apenas demonstração bonita em evento de tecnologia.

Na Rakuten, um agente trabalhou sete horas praticamente sozinho

Um dos casos que mais me chamou atenção aconteceu na Rakuten.

A empresa colocou o Claude Code para implementar um método específico de extração de vetores de ativação dentro do vLLM, um projeto open source com cerca de 12,5 milhões de linhas de código e múltiplas linguagens.

Não era gerar uma função isolada.

O agente precisava navegar em uma base de código enorme, entender onde aquela implementação deveria entrar e produzir um resultado compatível com um método de referência.

O Claude Code trabalhou durante sete horas em uma única execução. Segundo o engenheiro responsável pelo teste, ele não escreveu código durante esse período e deu apenas orientações pontuais.

O resultado atingiu 99,9% de precisão numérica em comparação com o método de referência. A Rakuten também relata uma redução de 79% no tempo médio para colocar novas funcionalidades no mercado, de 24 para 5 dias, em equipes que adotaram a ferramenta.

Esse caso é interessante não porque “uma IA programou durante sete horas”.

O mais importante é que havia uma forma objetiva de verificar se o trabalho estava correto.

99,9% contra um resultado de referência.

Isso muda bastante a conversa.

Autonomia sem uma forma de validar o resultado pode simplesmente produzir problema mais rápido. Autonomia acompanhada de testes, métricas e critérios claros de aceitação começa a virar uma ferramenta de engenharia.

O lançamento do DeepSeek Harness entra exatamente nessa discussão

O lançamento do DeepSeek Harness mostra como o mercado começou a olhar além do modelo.

O produto está em Developer Preview, é open source sob licença MIT e foi disponibilizado pela DeepSeek para desenvolvedores no mundo todo. Ele pode ser executado diretamente com npx, além de ter o código-fonte disponível.

Mas a parte mais interessante está na maneira como a própria DeepSeek apresenta o produto:

Agent = Model + Harness

Essa frase resume bem uma coisa que muitas vezes desaparece no meio da discussão sobre GPT, Claude, Gemini ou DeepSeek.

Um bom modelo não vira automaticamente um bom agente.

O modelo consegue raciocinar sobre o problema e decidir o que deveria fazer. Mas alguém precisa permitir que ele trabalhe dentro de um ambiente real.

É aí que entra o harness.

No DeepSeek Harness, capacidades como modelos, ferramentas, skills, sessões, sandboxes, armazenamento, loops, agendamento e até a interface são tratadas como plugins que podem ser combinados ou substituídos.

O modo Standard já oferece recursos de um Coding Agent completo: edição de arquivos, shell, pesquisa em arquivos e web, planejamento, objetivos, subagentes e workflows.

Também existe um detalhe que considero particularmente importante: cada execução pode ser rastreada.

O Harness mantém registros das informações recebidas pelo modelo, chamadas de ferramentas, resultados, execução de subagentes e injeções de contexto. Depois é possível voltar naquela trajetória e entender o que aconteceu.

Se vamos permitir que uma IA altere dezenas de arquivos e execute comandos dentro de um projeto, saber o que ela fez deixa de ser um detalhe.

Vira requisito.

O modelo é só uma parte do problema]

Durante bastante tempo acompanhamos os lançamentos de IA olhando quase exclusivamente para benchmarks.

Qual modelo programa melhor?

Qual raciocina melhor?

Qual tem mais contexto?

Qual ficou mais barato?

Essas comparações continuam importantes. Mas para Coding Agents existe outra camada.

Imagine dois modelos com desempenho parecido em programação.

Um deles está dentro de um ambiente onde consegue entender a estrutura do projeto, executar testes confiáveis, consultar logs, trabalhar isoladamente e receber feedback quando alguma coisa dá errado.

O outro simplesmente gera código.

Na prática, podemos ter experiências completamente diferentes mesmo com modelos tecnicamente próximos.

A OpenAI publicou um experimento interno que mostra bem isso.

Durante cinco meses, uma pequena equipe construiu uma versão beta interna de um produto usando Codex com uma regra bastante radical: nenhuma linha de código seria escrita manualmente por humanos.

O resultado chegou a aproximadamente 1 milhão de linhas de código e 1.500 pull requests, inicialmente com apenas três engenheiros conduzindo os agentes. A OpenAI estima que o produto foi construído em aproximadamente um décimo do tempo que levaria com desenvolvimento manual. O sistema chegou a ter centenas de usuários internos.

Só que a parte mais útil desse relato não são os números.

São os problemas.

Quando o código começou a sair rápido demais, o gargalo virou humano

No experimento da OpenAI, o aumento da produção de código criou um problema inesperado: a capacidade humana de revisar tudo começou a virar o gargalo.

Os agentes já conseguiam trabalhar durante horas em uma mesma tarefa. A equipe relata execuções individuais do Codex passando de seis horas, inclusive enquanto os engenheiros estavam dormindo.

Mais código começou a ser produzido do que as pessoas conseguiam acompanhar da maneira tradicional.

E apareceu outro problema ainda mais interessante.

Os agentes aprendiam com os padrões já existentes no repositório. Quando um padrão ruim entrava, ele podia começar a ser reproduzido.

A equipe chegou a gastar as sextas-feiras, cerca de 20% da semana, fazendo limpeza do que eles próprios chamaram de “AI slop”. Depois perceberam que isso simplesmente não escalava e começaram a transformar os padrões desejados em regras verificáveis pelo próprio ambiente.

Para mim, essa é uma das partes mais importantes dessa história.

O problema deixa de ser:

“Será que a IA consegue escrever essa classe?”

Ela consegue.

A pergunta começa a ser:

“Como evitamos que uma máquina capaz de produzir código muito mais rápido do que nós espalhe uma decisão ruim pelo projeto inteiro?”

Isso é um problema de engenharia bem mais interessante.

Código funcionando nunca foi sinônimo de código bom

Vamos voltar ao exemplo do JWT.

O agente implementa a autenticação.

A aplicação inicia.

Os testes passam.

A tarefa está concluída?

Talvez.

O segredo pode ter sido armazenado de forma inadequada.

O agente pode ter introduzido uma biblioteca enorme para resolver um problema pequeno.

Pode ter criado uma política de expiração ruim.

Pode ter duplicado uma implementação que já existia em outro módulo.

Ou pode ter aumentado o acoplamento de uma parte do sistema sem quebrar absolutamente nenhum teste.

Esse tipo de problema nunca aparece necessariamente como uma tela vermelha dizendo “erro”.

É por isso que acho perigosa a ideia de que Coding Agents tornam conhecimento de programação menos importante.

Na prática, pode acontecer justamente o contrário.

Quanto maior a velocidade de geração de código, maior a necessidade de alguém capaz de avaliar as decisões feitas durante essa geração.

E existem dados interessantes sobre isso

A Anthropic analisou cerca de 400 mil sessões do Claude Code, envolvendo aproximadamente 235 mil usuários entre outubro de 2025 e abril de 2026.

Um dos resultados é especialmente interessante.

Nas sessões típicas, as pessoas continuam tomando a maior parte das decisões relacionadas a o que precisa ser feito, enquanto o Claude toma uma parcela maior das decisões relacionadas a como executar aquilo.

A pesquisa também encontrou uma relação entre conhecimento do domínio e sucesso: usuários com mais experiência tendem a obter resultados melhores e conseguem fazer o agente realizar mais trabalho a partir de cada instrução.

Isso desmonta um pouco aquela ideia de que saber menos será uma vantagem porque “a IA faz tudo”.

Quem entende melhor o problema consegue delegar melhor.

E, principalmente, consegue perceber quando aquilo que recebeu não deveria ser aceito.

O trabalho do desenvolvedor pode estar mudando de lugar

A própria Anthropic fornece outro dado interessante, embora aqui seja importante lembrar que estamos falando de números internos da empresa que desenvolve o Claude.

Em maio de 2026, mais de 80% do código integrado à própria base da Anthropic era atribuído ao Claude. A empresa também relata que, no segundo trimestre de 2026, o engenheiro típico estava integrando cerca de oito vezes mais código por dia do que em 2024.

Isso não significa que os engenheiros passaram a trabalhar oito vezes mais.

Significa que eles deixaram de produzir cada linha diretamente.

A quantidade de software que uma pessoa consegue coordenar aumentou.

Essa diferença importa.

Um desenvolvedor pode estar analisando um problema enquanto um agente implementa uma alteração. Outro agente pode estar investigando um bug. Um terceiro pode estar preparando testes.

Na Rakuten, Yusuke Kaji descreveu exatamente esse tipo de situação: manter uma tarefa com o desenvolvedor e delegar outras quatro em paralelo para o Claude Code.

Isso já é bem diferente de ter um autocomplete aberto no editor.

Só que existe um preço para essa produtividade

Quanto mais trabalho conseguimos executar em paralelo, mais disciplina precisamos colocar no sistema.

Não adianta ter cinco agentes produzindo alterações simultaneamente se ninguém consegue dizer o que pode ou não entrar em produção.

Por isso, testes automatizados, CI/CD, análise estática, segurança, observabilidade e documentação não perdem importância com Coding Agents.

Eles viram parte do mecanismo que permite dar autonomia para os agentes sem simplesmente confiar neles.

A experiência publicada pela OpenAI chega justamente a essa conclusão: quando o agente falhava, a equipe começou a tratar o problema menos como “o modelo precisa tentar de novo” e mais como “qual informação, ferramenta ou limite está faltando no ambiente para que ele consiga fazer isso corretamente?”.

Isso muda até a forma como podemos pensar um bom repositório.

Documentação não serve apenas para a próxima pessoa que entrar na equipe.

Testes não servem apenas para impedir regressões.

Logs não servem apenas para investigar produção.

Tudo isso também passa a ser uma forma de tornar o software compreensível para agentes.

É por isso que o DeepSeek Harness é um lançamento importante

O DeepSeek Harness chega em um momento no qual essa discussão está amadurecendo.

A competição já não está limitada ao modelo que consegue gerar o melhor trecho de código.

DeepSeek Harness, Codex, Claude Code e GitHub Copilot estão atacando, de formas diferentes, o problema de transformar modelos em trabalhadores dentro de um ambiente de desenvolvimento.

E existe uma distância enorme entre essas duas coisas.

Gerar código é relativamente fácil de demonstrar.

Trabalhar durante horas em um repositório real, utilizar ferramentas, perceber erros, corrigir decisões, respeitar limites e entregar alguma coisa que outra pessoa tenha coragem de colocar em produção é um problema muito maior.

É justamente aí que acredito que veremos boa parte da competição daqui para frente.

Não apenas em modelos melhores.

Mas em ambientes melhores para que esses modelos trabalhem.

E isso também muda a discussão sobre o futuro do desenvolvedor.

A pergunta que mais ouvimos ainda é se a IA vai substituir quem programa.

Talvez estejamos olhando para a parte errada do problema.

Se um agente consegue trabalhar sete horas sozinho dentro de uma base com milhões de linhas, se três engenheiros conseguem coordenar aproximadamente 1.500 pull requests em poucos meses e se cada vez mais código é produzido sem alguém digitando cada linha, a capacidade de produzir software claramente está mudando.

O que ainda não podemos delegar com a mesma facilidade é o julgamento.

Alguém precisa decidir se a arquitetura faz sentido, se o risco é aceitável, se o requisito está correto e se aquela implementação deveria realmente chegar à produção.

Por isso, a pergunta que mais me interessa hoje não é se a IA vai aprender a programar melhor que nós.

É outra: Se cada vez mais código for escrito por agentes, nós continuaremos sabendo dizer quando ele está errado?