Índice do artigofaltam 3 min de leitura
Num estudo da Upwork e de uma universidade australiana, publicado em 5 de novembro, seis IAs que programam assumiram projetos em andamento e só cerca de 1 pedido em 20 saiu certo. Com os requisitos escritos, a maioria deixou o sistema rodando sem fazer o pedido. Se o fornecedor novo promete tocar seu sistema com IA, o risco é aprovar uma entrega que parece pronta e falha no uso.
Na reunião de contratação, faça três perguntas. De qual página com o que o sistema deve fazer hoje ele vai partir? Como o aceite confere a alteração pedida, e não só se o sistema continua rodando? As conversas do projeto, com dados de clientes, vão para a IA de qual empresa e sob qual contrato? Se não houver essa página, peça a alguém da sua equipe que a escreva antes da troca.
O que o estudo testou
Os agentes receberam o histórico inteiro das conversas entre quem pediu o trabalho e quem o executava, em projetos reais de uma plataforma de trabalho freelance, e o pedido seguinte. Os autores chamam a situação de "project takeover": assumir no meio, sem especificação limpa na mesa. Ao todo foram 37 pedidos de 7 projetos.
Uma entrega só contava como completa se passasse em três checagens: o sistema continua rodando, o pedido foi feito e nada do que já funcionava quebrou. Entraram duas ferramentas para pôr esses agentes para trabalhar, o Codex CLI e o Claude Code (programas que executam o modelo de IA no projeto). Um único agente entregou mais de dois pedidos (4 de 37). Com uma execução por pedido, as diferenças menores equivalem a um pedido a mais ou a menos, e o estudo não as trata como ranking.
Entregar ao agente só as mensagens ligadas ao pedido, para encurtar o histórico, não ajudou: a média de entregas completas caiu de 4,95% para 2,70%.
Com os requisitos escritos, o sistema para de quebrar, mas o pedido segue errado
Os autores repetiram o teste trocando o histórico pelo estado correto dos requisitos, escrito por eles e já com o pedido incorporado. A entrega completa subiu de 4,95% para 8,11%.
O que mudou por dentro diz mais. Com o alvo escrito, o sistema passou a rodar em 96,40% das entregas e o que já funcionava foi preservado em 90,99%. O pedido em si, porém, foi atendido em só 9,01%.
Na prática, das entregas feitas nessa condição, 84,02% deixaram tudo funcionando e não fizeram o que foi pedido. É a entrega que parece pronta na revisão rápida e falha no uso. Os autores levantam uma hipótese, que o estudo não testa: mesmo com o alvo explícito, o agente pode manter premissas antigas ou fazer só ajustes locais.
Onde o agente se perde no histórico
Antes de escrever código, o agente precisa descobrir o que vale. O agente com melhor resultado de entrega encontrou quase todas as mensagens importantes para o pedido, mas trouxe junto cerca de três mensagens erradas para cada certa.
Em nenhum dos 312 casos com informação suficiente para agir algum agente reconstruiu a lista de requisitos sem erro. No exemplo escolhido pelos autores, de uma placa de circuito, o cliente pede para mover o conector da bateria para o verso da placa. O agente anota os furos de montagem e, ao atualizar a lista, apaga o requisito inteiro de layout mecânico, que o cliente não tinha retirado.
Histórico no WhatsApp e dado pessoal na conversa
Nos projetos herdados que chegam à X-Apps, como regra, o histórico não está num sistema de chamados: está em grupos de WhatsApp, e-mails e atas de reunião. O primeiro trabalho é escrever o estado atual dos requisitos numa página.
Esse histórico também traz nome, telefone, e-mail e, às vezes, documento de cliente e de usuário final, tudo dado pessoal pela LGPD. Entregá-lo inteiro a um agente é enviar esse conteúdo para o serviço do fornecedor do modelo (a API), o que pede base legal e contrato de tratamento definidos antes do primeiro pedido à IA.
Limites do estudo
É um estudo publicado antes da revisão de outros pesquisadores, com 37 pedidos, uma execução por agente em cada um e sem custo por execução. O material são conversas de plataforma freelance, diferente de chamado e especificação de empresa. Para projeto novo, que começa de uma especificação limpa, o estudo não diz nada.
Como a X-Apps assume um sistema existente
A X-Apps começa pelo diagnóstico do que existe e escreve o estado dos requisitos antes de pedir a próxima entrega, a uma pessoa ou a um agente. Foi assim no projeto da Housi, de moradia por assinatura: o app anterior tinha sido montado numa ferramenta sem código e, segundo o case, "antes de desenhar qualquer coisa, o trabalho começou olhando para o que já existia".
Dos projetos em andamento na sua empresa, quantos têm os requisitos atuais escritos em algum lugar fora do chat?
Fontes e método. Preprint "Take It From Here: Evaluating Coding Agents on Project Takeover", arXiv:2611.07307v1, de pesquisadores da Upwork e da University of Technology Sydney, submetido em 05/11/2026 e lido na íntegra em 06/11/2026, ainda sem revisão de outros pesquisadores. Case: texto publicado da Housi em x-apps.com.br.
