O agente executou um ciclo por 40 horas: como integrar IA ao desenvolvimento sem regressões

Os debates sobre a necessidade de desenvolvedores na era do vibe coding geralmente acabam dominados pela emoção. Em vez disso, o autor de uma análise publicada no Habr mostra o que acontece na prática quando um agente recebe uma tarefa sem receber limites.

Onde o vibe coding falha

No Xenodrift, um projeto pessoal que foi refeito várias vezes, decisões anteriores deixaram de ser respeitadas à medida que novas alterações eram introduzidas. Surgiram regressões, e algumas funcionalidades simplesmente desapareceram. O motivo era trivial: os requisitos não haviam sido documentados em lugar algum, e não existia uma forma de verificar seu cumprimento. A cada vez, o agente trabalhava com o fragmento de contexto disponível naquele momento e não se lembrava do que havia sido acordado antes.

No entanto, a baixa qualidade do código não é inevitável. No DemoBank, a demo de um aplicativo bancário, o autor definiu requisitos de desempenho, reutilização de funcionalidades e sistema de design, mas deliberadamente não prescreveu uma arquitetura. O resultado foi uma estrutura modular feature-first com elementos de Clean Architecture, BLoC/Cubit para gerenciamento de estado e idempotência e retry na camada de rede. A funcionalidade de pagamento de multas funciona tanto dentro do aplicativo quanto de forma independente, sem carregar dependências desnecessárias.

O desempenho foi testado em um realme RMX3760 econômico e real. Durante uma execução de um minuto com 12.000 operações, 0,25% dos frames ultrapassaram o orçamento de 16,7 ms, diante de um critério inferior a 1%. O autor ressalva honestamente que se trata de apenas um dispositivo e um cenário.

Velocidade não é o mesmo que prontidão

O DemoBank exigiu cerca de 27 horas de trabalho total do Codex e aproximadamente 19 horas de tempo real, considerando a execução paralela, além de 2–3 horas do próprio autor. As execuções dos testes de desempenho no telefone foram particularmente caras. A métrica da equipe não deve ser “com que rapidez o código foi gerado”, mas “quanto tempo transcorreu entre a definição da tarefa e a aceitação da mudança”, incluindo revisão e retrabalho.

Harness, quality gates e responsabilidade

Por AI Harness, o autor entende o ambiente de trabalho do agente: o contexto do projeto, as ferramentas, as restrições sobre ações, as verificações automáticas e o processo de entrega do resultado a uma pessoa. Estas são as principais ideias:

• As verificações das quais depende a aceitação devem ser executadas automaticamente e bloquear o merge. Escrever “execute os testes” em um prompt não garante isso.
• O ciclo “continue até as verificações passarem” precisa ser limitado. Um dos projetos do autor ficou rodando por 40 horas, até que ele o interrompeu manualmente. São necessários limites de tempo e dinheiro e, quando um erro se repete sem progresso, o agente deve parar e informar o que tentou fazer.
• Após uma interrupção forçada, é preciso corrigir o processo, não apenas o código. O agente pode ter entendido a tarefa incorretamente, o mapa do projeto pode estar desatualizado ou o modelo pode ser fraco demais.
• Toda decisão deve ter um responsável claramente identificado: produto e analytics aprovam o comportamento, o proprietário do módulo verifica seus contratos e um desenvolvedor analisa a interpretação da tarefa pelo agente antes que o código seja escrito.

Contexto, contratos e domínios

Uma janela de contexto grande não garante o uso correto das informações: o estudo Lost in the Middle mostrou que a qualidade depende da posição dos dados no contexto. Por isso, são necessários um mapa dos módulos, contratos atualizados e ADRs. O autor propõe manter o contrato da API em uma única fonte, como TypeSpec, e gerar OpenAPI, documentação e código do cliente, verificando a consistência no CI. ADRs desatualizados devem ser marcados como superseded.

No entanto, um contrato não substitui testes comportamentais. Uma chave de idempotência pode ser descrita em um schema, mas a ausência de um reembolso duplicado só pode ser verificada por um cenário separado. Um exemplo de e-commerce: com um mapa de projeto ruim, o agente pode chamar a API do provedor de pagamentos diretamente a partir do módulo de pedidos, impedindo que os reembolsos apareçam no registro de pagamentos. DDD e regras arquiteturais verificadas automaticamente podem ajudar nesse caso, junto com uma revisão feita por outro modelo.

O que fazer

As limitações são claras: esta é a experiência de um único autor com projetos pequenos, sem uma auditoria independente do código. Ainda assim, as conclusões são transferíveis. Registre os requisitos em especificações como OpenSpec, Spec Kit, BMAD ou Kiro; torne os quality gates obrigatórios; defina orçamentos para os ciclos dos agentes; e atribua responsáveis pela manutenção do contexto. O papel do desenvolvedor está mudando da escrita de código para a definição de limites e a aceitação do resultado.