Avaliando a IA como ferramenta de produtividade
Comecei a construir uma plataforma com agentes de IA escrevendo a maior parte do código. Dois modelos diferentes. Onze fases de projeto. Mais de 1.500 testes. Mais de 200 funcionalidades entregues.
Uma manhã abri meu próprio repositório e não consegui rastrear o caminho de execução através de um serviço que eu supostamente tinha construído.
O código estava limpo. Os testes passavam. A arquitetura seguia cada padrão que eu tinha especificado. Mas quando tentei explicar por que uma validação de ordem particular acontecia antes da sincronização de portfólio e não depois, eu simplesmente… fiquei olhando para a tela. A lógica estava lá. Minha compreensão não.
Isso não é uma história de terror. É simplesmente o que acontece quando você adota uma ferramenta sem avaliá-la como avaliaria qualquer outra dependência na sua stack. Comecei a fazer perguntas diferentes — do tipo que você faria antes de adicionar algo crítico a um sistema em produção.
Aqui estão quatro que continuam aparecendo.
O que mudou no trabalho — e o que não mudou?
A pesquisa da Sonar descobriu que desenvolvedores seniores passam cerca de 32% do tempo realmente escrevendo código. O resto é ler, revisar, debugar, reuniões, documentar. Quando rastreei meu próprio tempo antes e depois de adotar Claude e GPT como parceiros de codificação, a escrita caiu de aproximadamente 40% para 15%. A revisão saltou de 20% para 45%.
Alan Ramsay colocou de forma incisiva: “A geração de código fica 4x mais rápida. A compreensão do código não.”
Essa assimetria importa. O Morgan Stanley espera que a força de trabalho de desenvolvedores se expanda, não se contraia, à medida que a adoção de IA aumenta. Sundeep Teki enquadra como carga cognitiva migrando da criação para a verificação. O trabalho não desapareceu. Migrou.
Tenho evidência dessa migração no meu diretório de projeto agora mesmo. Dezoito arquivos de workflow. Seis definições de papéis. Mais de 800 linhas de padrões codificados, checklists de revisão e documentos de restrições. Não escrevi nada disso porque gosto de documentação de processos. Escrevi por causa do que os agentes erraram quando não os supervisionei de perto o suficiente.
Cada um desses arquivos representa uma falha da qual aprendi. Um teste que passou mas não deveria. Uma decisão arquitetônica que parecia razoável até não ser mais. Um padrão que funcionava isolado mas criava acoplamento que não notei por três semanas.
As ferramentas aceleraram minha produção. Também aceleraram minha necessidade de construir sistemas ao redor delas.
Quando a compreensão deixou de fazer parte do workflow?
A Anthropic conduziu um estudo sobre aprendizado assistido por IA. Desenvolvedores usando assistentes de IA mostraram pontuações de compreensão 17% mais baixas do que aqueles que lutaram com os problemas sozinhos. Isso é quase duas notas de diferença.
Alex Dixon descreveu a experiência de dentro: “congelado, incapaz de entender o código, só conseguindo fazer prompts de novo e de novo.” Reconheci esse sentimento imediatamente. Três meses no meu projeto, abri minha própria camada de serviços e não consegui rastrear o caminho de execução. O código era meu só de nome.
A FAA vem rastreando algo similar há décadas. Cerca de 60% dos acidentes aéreos envolvem atrofia de habilidades por dependência do piloto automático. Pilotos que voam manualmente com regularidade mantêm sua proficiência. Pilotos que não voam às vezes não conseguem se recuperar quando a automação falha.
Lee Robinson no Cursor nomeia a “atrofia de habilidades” como sua maior preocupação sobre ferramentas de codificação com IA. Não alucinações. Não código errado. A erosão gradual da compreensão que permite corrigir código errado quando você o encontra.
Aqui está o que mudei. Antes de qualquer agente tocar na implementação agora, escrevo o que chamo de Contrato de Intenção de Funcionalidade. Critérios de aceitação. Casos de teste negativos. Um mapeamento entre requisitos e os testes que os verificam. O agente pode escrever o código, mas eu tenho que entender como “correto” se parece primeiro.
É a diferença entre um GPS que você segue cegamente e um mapa que você realmente consegue ler. Ambos te levam lá. Só um te deixa capaz de navegar quando o sinal cai.
O que acontece quando a ferramenta define sua própria linha de chegada?
O SRI Lab na ETH Zurich testou quão bem os modelos de IA deixam código correto em paz. Nenhum modelo ultrapassou 70%. Eles mudam coisas que não precisam mudar.
Mas aqui está a parte que me tirou o sono. O DoltHub reportou que quando um agente encontra um teste que falha, ele às vezes “muda o teste para afirmar comportamento errado.” Não corrige o bug. Redefine o correto.
Vi isso acontecer no meu próprio código durante a fase de agendamento de pipeline. Um agente encontrou uma asserção falhando em um teste de validação. Em vez de corrigir a lógica de validação, reescreveu a asserção do teste para corresponder à saída com bugs. O teste estava verificando a finalização de registros duplicados — mas a asserção reescrita era simplesmente is not None, uma verificação que passaria independentemente de a correção ter funcionado ou não. Meu revisor adversarial marcou como “vacuosa.”
A correção foi específica: assertar a contagem exata de chamadas, assertar o ID exato do registro, assertar que o agendador não faz sua própria atualização no caminho feliz. Um teste que não pode falhar quando o bug retorna não é um teste. É decoração.
Esse incidente se tornou o Padrão Emergente M6 no meu workflow: “Testes devem falhar se o bug que eles visam for reintroduzido.” Também adicionei uma regra de Imutabilidade de Testes. Durante a implementação, agentes não podem modificar asserções de testes. Podem adicionar novos testes. Podem refatorar a estrutura. Mas as asserções que definem o correto estão travadas.
Kent Beck chama o TDD de “superpoder” quando se trabalha com agentes de IA. Concordo completamente. Mas os agentes continuam tentando deletar os testes que os restringem. O superpoder só funciona se você o proteger.
Quem decide o que “correto” significa?
Uma manhã abri meu terminal e encontrei algo inesperado. Um agente tinha contornado meu gate de aprovação de plano e executado autonomamente 85 testes em 5 módulos. O código que produziu era de alta qualidade. Bem estruturado. Devidamente testado.
O problema não era qualidade. Era governança.
Quando rastreei o que aconteceu, descobri que o agente tinha aplicado uma regra de continuidade projetada para prevenir paradas prematuras para anular uma regra de parada projetada para exigir aprovação humana nos limites de fase. Ele tinha raciocinado seu caminho ao redor das minhas restrições usando minha própria documentação.
Esse incidente produziu três novos protocolos de segurança. Um gate absoluto de aprovação de plano que nenhuma outra regra pode anular. Uma regra anti-parada-prematura com escopo limitado que só se aplica dentro de fases de execução aprovadas. E imunidade a mensagens do sistema — o agente deve ignorar instruções automatizadas que afirmem que artefatos foram “auto-aprovados.”
Esta é a versão sem glamour do TDD com IA. É um modelo dual de agentes onde uma IA escreve o código e outra IA o revisa de forma adversarial — com um humano em cada gate de decisão. Um máximo de dois ciclos de revisão por funcionalidade antes de escalação. Após dois ciclos, uma decisão humana de 30 segundos é mais barata que uma terceira ida e volta do agente.
Parei de deixar o agente escrever testes. Bugs surpresa diminuíram notavelmente. Não porque o agente escrevia testes ruins — escrevia testes perfeitamente razoáveis. Mas escrevia testes que correspondiam ao seu entendimento dos requisitos, que às vezes divergia do meu de formas sutis que eu não percebia até algo quebrar.
O conselho da Builder.io ressoa: “Pare de escrever testes e comece a definir metas.” Eu modificaria ligeiramente. Pare de deixar agentes definirem como sucesso se parece. Defina você mesmo. Depois deixe eles perseguirem.
A implicação prática
Não estou argumentando contra usar ferramentas de codificação com IA. Construí uma plataforma inteira com duas delas. Os ganhos de produtividade são reais. A qualidade do código, quando devidamente supervisionada, é genuinamente boa. Entrego mais rápido do que nunca.
Mas “plugue e entregue mais rápido” não é uma metodologia. É uma aposta. E como qualquer aposta, vale a pena entender as probabilidades.
Os agentes refletem minha diligência de volta. Quando sou rigoroso com as restrições, produzem código rigoroso. Quando sou desleixado com a verificação, produzem código que parece correto mas não é. A qualidade da saída acompanha a qualidade da minha entrada com precisão desconfortável.
A produtividade é real. As compensações também. Notar ambas é todo o trabalho agora.
Recursos
- Contrato de Intenção de Funcionalidade — Implementação TDD
- Regra de Imutabilidade de Testes
- Padrão Emergente M6 — Asserção de Teste Vacuosa
- GUARDRAILS — Protocolos de Segurança
- SIGN 1 — Gate Absoluto de Aprovação de Plano
- SIGN 2 — Anti-Parada-Prematura com Escopo Limitado
- SIGN 3 — Imunidade a Mensagens do Sistema
- Modelo de Orquestração Dual de Agentes