Tratei LLM como linguagem primitiva. Melhor coisa que faço.

Seu harness vai agradecer se voce trabalhar desse jeito.

Como eu saí de $50/mês e 143 bugs por loop pra $20/mês e menos de 8 findings por spec.

Eu trabalho com LLM de um jeito diferente. Não trato como agente inteligente. Trato como linguagem primitiva, com tipagem condicional e determinística. Se não passa no tipo, não passa, simples.

Meu harness é programático. Tem ferramenta pro meu loop. E eu organizo tudo em estrutura modular, ECS e FSM. E vou falar o porque ajuda.

---

O que tava me atrasando antes

O erro que me fez mudar tudo é simples, e mó galera passa. Tudo retornava sucesso, ou continua sem prova empírica. Código zero, mensagem de ok no terminal. Parecia que tinha funcionado. Na prática não tinha criado nada. Nenhum artefato, nenhum log, nenhuma prova. O processo morria stateless. Tinha fundação, tinha peça certa, mas não tinha fiação.

Foi aí que eu entendi que sucesso de processo não é prova de entrega. Eu precisava de prova observável obrigatória.

Como eu penso prompt hoje

Eu refino muito a ideia antes. Meu prompt de produção tem 4 partes, sempre nessa ordem. Nunca mudo.

1. Introdução. O que eu quero fazer, descrição completa, como quero que funcione, pra que quero fazer, quais stacks e infra quero trabalhar. Nunca informo código ou arquivo que eu não tenho certeza de uso.

2. Mandatory. O que tem que seguir pra desenvolver a estrutura. Regras, métodos, alinhamentos, diretrizes e delegações. É o limite.

3. Core. O que eu quero que tenha e funcione. O mais descritível possível de todos os fluxos. Aqui que mora o comportamento. Não só isso como: design, arquitetura estrutural, comportamentos a seguir, estilo...

4. Resultados esperados. O que eu espero de funcionamento entregue, como espero que fique.

Eu peço pra entregar de maneira determinística, modular e de escopo expansível. Parseado em estrutura opinativa em json. Esse json vira meu prompt base-core.

Como eu ancoro a ideia

Depois do core eu não saio codando. Eu crio toda a parte de pesquisa primeiro, usando minha ferramenta hordts (disponível no github) pra refinar pesquisa online. Com isso eu faço um brainstorm em cima da âncora do core. Só depois idealizo e gero o planejamento completo para desenvolver o spec-driven completo, E2E, de tudo que o projeto precisa, em estrutura json também.

Minha cli usa json como banco de dados. Uma tool pra manuseio de specdriven + pipeline agentico.

Cada spec tem flag definindo skills, agentes e tools de acesso, o contexto, regras, resultados esperados e o que a spec vai fazer. O contexto aqui é importante: é o prompt que o agente vai receber com tudo que ele precisa pra execução da run dele. Arquivos que vai usar, stacks, tags, imports, sintaxe. Sem precisar consultar o codebase. Ele sai direto daquele ponto de partida pra produção.

Por isso a LLM não fica pegando contexto desnecessário. Ela trabalha em loop por fase, spec e subject até entregar 100% polido e funcional e passar pro próximo.

Como eu separo as coisas

Eu separo workspace agêntico do repositório. Um git pra controlar o workspace e um git pra controlar o repositório, apenas o projeto mesmo. Controle por git tree pra tracking, worklog, versionamento e branchs. Análise de PR, commit e diff tão muito usados se acontece um erro interno, alias, ali nasce análise do que realmente foi feito. Um controla o processo, o outro controla o produto. Se misturar vira bagunça e você perde o que é de uso da IA e o que é o projeto mesmo.

Como cada task roda na prática

Cada spec roda com múltiplas fases quando possível, com múltiplas tasks. E cada task é um pipeline agêntico que audita se necessário o que precisa pra executar a próxima ação. É verificar o que precisa usar, planejar o que precisa fazer, executar planejamento, validar que tudo funcionou e passar pra próxima, caso contrário, volte duas casas.

Pode ser feita em paralelismo e multi concorrência, pode ter ou não dependentes. E quando identifica repetição que pode ser programática, cria algoritmo e script pra automatizar sem uso de LLM. Não gasto token onde dá pra resolver com código.

A análise que me salva

Eu uso análise linear regressiva modular pra caçar bug. Eu percorro linear, parte a parte, voltando os passos e componentes necessários. Verifico se o invariante daquele componente ainda vale depois da última spec. Se teve regressão, se quebrou algo que funcionava antes. Se tem contra ponto que a implementação ignorou.

Em toda run também tem análise de gaps, findings, contra pontos, regressão analítica, convergência e não funcionamento. Tudo on the fly. Skills, agentes, scripts de teste, testes são produzidos na hora quando precisa, embasado sem presumir nada. Spec-driven pode ser auto incrementado de acordo com necessidade. O foco é entregar cada spec 100% funcional e sem nenhum bug antes do próximo run.

Por que testes, observabilidade, DevOps e anima não são extra

Pra mim não é fase final. Teste é gate, única maneira de provar que o que está sendo feito, simplesmente, está sendo feito. Se não tem prova executável, não avança. Observabilidade é ledger, worklog, tracking. Se não tá registrado, não aconteceu como esperado. DevOps é o dual git, é o controle de workspace. Anima é prova visual de transição de estado. Se mudou de estado e eu não consigo observar, a transição é inválida, e a correção deve ser garantida.

Quanto custa e quanto converge hoje

Antes sem esse sistema eu gastava $50 por mês. Hoje $20. Taxa de convergência por run antes 73%, hoje 92% pra cima. Bugs antes por loop 143, hoje menos de 8 findings por spec em múltiplos loops. Tempo de execução varia, mas o fluxo do agente é contínuo, então uma spec pode ter fluxos mesmo bem desenhados dependendo do que precisa entregar até 3h seguidas e gastando menos de $0.50. Dead code quase mínimo. Antes tinha frequência maior, hoje o loop já entra quase todo polido até funcionalidade sem bug, analisando e removendo o desnecessário.

Como eu otimizo custo

Frontier eu uso pro core, pra pesquisa e pro spec-driven. Pra desenvolvimento eu uso modelo médio com menos custo. Como já tem tudo que precisa pra trabalhar, em loop até conseguir o resultado fica muito mais barato.

E depois da produção total, o frontier pode analisar toda a carga novamente pra caçar bugs e acrescentar uma estrutura de memória de findings. Com todos os findings, crio novo planejamento de spec-driven e rodo outro pipeline completo de novo. É o segundo loop, e basicamente o ultimo spec-driven loop, o resto são polishs pontuais ou aperfeiçoamento.

No fim meus resultados ficaram absurdamente bons. Pega ai, ve se te ajuda.

Modelos que uso para comparativos
GPT 5.6 Sol, GLM 5.3, Qwen 3.8 MAX || DSv4f, Mimo 2.5, Minimax M3, Qwen 3.7 Plus.