Image generated by Google Gemini
Se um agente de IA quebrou seu app durante um refactoring, se você quer transformar sistemas legados em um ambiente onde a IA possa trabalhar, se quer redirecionar orçamentos de manutenção de legacy das Fortune 500 para orçamentos de transformação — este artigo é o roteiro.
Memória trancada
Durante a bolha da internet, empresas começaram a acumular ativos digitais. Código, bancos de dados, especificações, documentos, APIs — décadas de memória corporativa.
Essa memória estava trancada. Impossível de pesquisar, impossível de verificar, inalcançável (unreachable). A única forma era uma pessoa ler, entender e modificar manualmente. Por isso 60-80% do orçamento de TI das Fortune 500 é gasto mantendo essa memória trancada. Não conseguem abri-la, então apenas guardam.
Estamos no meio do que chamam de bolha de IA. O verdadeiro significado desta era não é que os modelos estão ficando mais inteligentes. É que a memória legacy trancada por anos está se tornando alcançável (reachable).
Mas ainda não. Em 2026, agentes de IA escrevem código. Um queima milhões de tokens em 68 minutos, termina um refactoring. O aplicativo quebra completamente. Histórias assim aparecem no X todo dia.
Por que isso se repete?
Não porque o agente é burro. Porque o ambiente não foi construído para agentes trabalharem. Você não coloca um robô num escritório humano. Você constrói uma fábrica onde robôs possam trabalhar.
Para destrancar a memória trancada, ela precisa primeiro ser transformada numa forma que possa ser aberta. Não é só um problema de código. Bancos de dados, especificações, documentos, APIs — todo o patrimônio digital da empresa é opaco para agentes.
O que significa Agent-Operable
Para um agente trabalhar autonomamente, três condições são necessárias:
1. Deve ser legível — sem ruído
Para encontrar uma função num arquivo de 2.000 linhas, 1.950 linhas são ruído. Para encontrar dados de um cliente num banco de dados não normalizado, é preciso fazer join de três tabelas. Regras de negócio escondidas em planilhas Excel são invisíveis para agentes.
Legível não significa que uma pessoa consegue ler. Significa que uma máquina consegue fazer parsing estrutural.
2. Deve ser verificável — deterministicamente
Se um agente não consegue saber o que quebrou após uma mudança, cai num doom loop. Código precisa de testes. Bancos de dados precisam de constraints. APIs precisam de validação de schema. Especificações precisam de verificação cruzada.
Um LLM verificar outro LLM é como perguntar ao seu amigo bêbado “Estou bêbado?”. go test não alucina. Um CHECK constraint não mente. JSON Schema não deriva.
3. O estado deve persistir — mesmo quando o agente morre
Agentes vão falhar. Limites de tokens, erros de rede, sessões cortadas. Se o progresso não for salvo, cada execução começa do zero.
Quando o Agente A processa até a função #200 e morre, o Agente B deve continuar da #201. Agentes são descartáveis. O progresso deve acumular.
Passo zero: congele os bugs
As três condições são o destino. O ponto de partida é outro. Sem documentação, sem testes, 300 arquivos de 2.000 linhas cada. Esse é o ponto de partida.
Diga a um agente para “refatorar” nesse estado. O que acontece? Ele “corrige” um bug de dez anos. O problema é que esse bug não é um bug.
Lei de Hyrum: todo comportamento observável de uma API suficientemente antiga tem alguém dependendo dele. Um erro de arredondamento decimal abandonado por uma década tem a lógica de pagamento de um cliente VIP amarrada a ele. Um bug de parsing de datas gerou uma macro de Excel que sustenta todo o departamento de contabilidade. Bugs antigos são especificações de negócio implícitas.
A primeira tarefa do agente não é corrigir código. É congelar o comportamento atual.
Cutuque a API. Registre a resposta. Fixe essa resposta como um teste Hurl. Bug bizarro ou comportamento intencional — sem distinção. Congele como está. Este é o primeiro dente do ratchet — trava o agente para que não “melhore” as coisas por conta própria.
Mudanças são decididas apenas por quem detém a especificação. O agente é um executor. Não um juiz.
Concluído o congelamento, começa a transição rumo às três condições: legibilidade, verificabilidade, persistência.
Não é só código
“Agent-operable codebase” é o ponto de partida. Os ativos digitais de uma empresa não são só código.
| Ativo | Estado atual | Estado Agent-Operable |
|---|---|---|
| Código | Arquivos de 2.000 linhas, sem testes | Um conceito por arquivo, testes para cada função |
| Banco de dados | Não normalizado, sem documentação | Gestão declarativa de DDL, migrations auto-geradas |
| Especificações | Wiki, repasse verbal, drift | 9 SSOTs com verificação cruzada, encadeados por um identificador único |
| Documentos | Regras escondidas em PDFs e Excel | Extração de schema, legível por máquinas |
| API | Sem documentação, contratos implícitos | Captura OpenAPI, validação de schema |
Visto individualmente, cada linha parece “deveríamos organizar isso”. Visto em conjunto, formam um sistema.
Symbolic Feedback Loop
Uma estrutura comum torna essa transição possível.
LLM gera → ferramenta determinística julga → resultado devolvido ao LLM → repetir
No código, nos testes, nas especificações, nos dados — o mesmo loop opera:
Estrutura de código: filefunc validate → feedback de violação → LLM corrige → repetir
Testes: go test + coverage → feedback de linhas não cobertas → LLM reforça → repetir
Consistência de specs: yongol check → feedback de drift → LLM corrige → repetir
Regras de usuário: rulecat evaluate → feedback de violação → LLM corrige → repetir
A única coisa que o LLM faz é gerar. O que corrigir, se passou, o que vem depois, se terminou — tudo decidido por máquinas. O LLM não recebe autoridade de decisão.
Isso não é uma invenção. C. elegans dedica 60 de seus 302 neurônios (20%) à entrada sensorial. À verificação, não à geração. Quinhentos milhões de anos de evolução chegaram a esta conclusão: melhorar a qualidade do feedback supera adicionar mais neurônios para a sobrevivência.
A indústria está fazendo o trem (o modelo) mais rápido. Modelos maiores, agentes mais inteligentes, prompts melhores. Mas quanto mais rápido o trem, mais os trilhos importam.
80/20
No estado final, o sistema se divide em duas camadas.
SSOT (80-90%)
├── OpenAPI, DDL, SSaC, FuncSpec, Rego, Hurl, React TSX, Mermaid, manifest
└── Gerado a partir de specs. Drift eliminado na origem. Agentes modificam livremente.
Custom (10-20%)
├── Regras de negócio, lógica de domínio, cálculos legais/de políticas
└── Estruturado com filefunc, testado com tsma. Humanos revisam.
O código que humanos realmente precisam cuidar se comprime a 10-20%. O resto é gerado por agentes lendo specs, verificado por máquinas.
Os 60% das Fortune 500
60-80% do orçamento de TI das Fortune 500 é consumido em manutenção de legacy. 42% do tempo dos desenvolvedores vai para dívida técnica. 70% das migrações manuais de legacy falham.
Esse orçamento já está sendo gasto. Não é preciso orçamento novo. Apenas redirecionar. Transformar orçamentos de manutenção em orçamentos de transformação.
Insira o legacy inteiro e sai um sistema agent-operable. Essa é a promessa de Building Agent-Operable Systems.
Por que as Big Tech não fazem isso
Anthropic e OpenAI constroem modelos de propósito geral. Melhore um modelo em 10% e se aplica a todos os clientes. Mas construa um feedback loop de Go test e se aplica apenas a desenvolvedores Go. Construa uma ferramenta de coverage de Python e se aplica apenas a projetos Python.
Verificação simbólica é inerentemente específica de domínio. Cada linguagem, cada framework, cada especificação requer um verificador diferente. Sem generalidade, não se encaixa no ROI das Big Tech.
Por isso esse espaço está vazio. Quem constrói o trem e quem estende os trilhos não são concorrentes. São complementares.
Perguntas
Seu agente escreve código. Mas quem verifica se esse código está correto?
Outro agente? Ou go test?
Seu LLM realmente lê todas as 100.000 linhas?
Ou finge que lê?
O que a era dos agentes precisa não são agentes mais inteligentes. São sistemas onde agentes possam trabalhar.
Sources
- Gartner, “IT Budget and Cost Optimization” — 60–80% of enterprise IT budgets consumed by legacy maintenance
- Stripe & Harris Poll, The Developer Coefficient (2018) — 42% of developer time spent on technical debt
- McKinsey & Company, Why do most transformations fail? (2019) — ~70% of digital transformation projects fall short of goals
- Hyrum Wright, Hyrum’s Law — “With a sufficient number of users of an API, all observable behaviors of your system will be depended on by somebody”
- Winters, Manshreck, Wright, Software Engineering at Google (O’Reilly, 2020) — Formal book source for Hyrum’s Law
- White et al., “The structure of the nervous system of C. elegans”, Phil. Trans. R. Soc. Lond. B 314 (1986) — 302-neuron connectome
- Inglis et al., The sensory cilia of C. elegans, WormBook (2007) — 60 sensory neurons (~20% of total)
- METR, Early-2025 AI Developer Productivity Study (2025) — AI tools made experienced developers 19% slower, yet developers perceived 24% speedup
- GitClear, AI Copilot Code Quality 2025 (2025) — 211M lines analyzed, refactoring down 60%, copy-paste code up 48%
- Mehtiyev & Assuncao, Beyond Resolution Rates (2026) — 19 agents, 9,374 trajectories; 12.4% of total compute spent on zero-yield tasks