~US$ 15 por mês em modelos, uma VPS e um iPad. Como estruturei meus projetos para agentic coding, por que modelos menores resolvem a execução e o que aprendi sobre o custo oculto de revisar código de agentes
Da arquitetura de contexto para o projeto funcional
No final de 2025, um levantamento com 700 engenheiros mostrou que a maioria esmagadora dos líderes relatou aumento no tempo de revisão de código após adoção de IA. Cerca de um terço do dia do desenvolvedor passou a ser consumido revisando código de agente, corrigindo bugs sutis e trocando contexto entre tarefas. Foi esse número que me fez parar e repensar como estava estruturando meus projetos com agentes.
Na Parte 1, mostrei a estrutura de harness engineering que montei: agentes, skills e rules organizados para transbordar meu contexto para qualquer LLM. A pergunta seguinte era inevitável: como transformar essa base em um projeto real, sem que o custo cognitivo de revisar código de agente anulasse a produtividade que ele prometia? A resposta veio com uma estrutura fixa de documentação e um fluxo de desenvolvimento que venho aplicando na prática.
A estrutura fixa de projetos
Para todos os meus projetos, uso a mesma estrutura de arquivos. O motivo é simples: ficar criando prompts brilhantes do zero custa tempo. Tempo que não tenho. Estudos recentes mostram que prompts excessivamente complexos ou com instruções genéricas demais podem, inclusive, piorar o resultado do modelo em tarefas de raciocínio e extração de dados.1 Nada melhor do que uma estrutura fixa que me permite reaproveitar o que já funcionou.
A estrutura:
-
description.md: guia qualquer consulta de contexto que agentes ou skills possam precisar conforme o projeto avança. É o ponto de entrada. -
ui-ux.md: quando o projeto tem frontend, descrevo páginas, fluxos de navegação, interações do usuário, alertas de erro. Sem isso, agentes de frontend entregam qualquer coisa. -
architecture.md: complemento técnico dodescription.md. Contém peças de infraestrutura, tecnologias, linguagens, frameworks e como funcionam as integrações entre componentes. Com esse arquivo, posso ter agentes e skills mais genéricos, porque as especificações suprem o contexto que faltaria. - Diagrama de alto nível da arquitetura: tem coisas que só se representam bem visualmente. Desenho uma arquitetura simples e mantenho a imagem no repositório.
Alguém pode argumentar que isso trava o projeto, porque cada escopo pede uma estrutura diferente. Mas pense pelo outro lado: ter sempre a mesma estrutura acelera a organização das ideias, porque você tem referências passadas. É otimização de tempo. Sem isso, não chego ao final de nenhum projeto.
Do Spec ao código: planejar com modelo grande, executar com modelo barato
Com a documentação inicial pronta, aplico um fluxo baseado em Spec-Driven Development, uma abordagem que trata a especificação como artefato principal e o código como derivado dela. O termo não tem uma definição única na indústria, e a implementação varia conforme o contexto do time e do projeto.2 No meu caso, derivo três arquivos:
-
spec.md: condensa e adiciona informações técnicas. É o documento-base para tudo que vem depois. -
plan.md: estrutura como vou executar e quebrar as atividades. É a ponte entre a especificação e a execução. -
task.md: todas as atividades necessárias, quebradas em epics e tasks.
O projeto do Hub de Conteúdo gerou aproximadamente 20 epics e pouco mais de 100 tasks. Cada epic agrupa um conjunto de tasks relacionadas. As atividades são cadastradas no GitHub como issues e sub-issues, organizadas em um project no estilo kanban. Consigo acompanhar o andamento visualmente, mesmo acessando do iPad.
Aqui está o pulo do gato: agrupando tasks dentro de um epic, posso usar o modo de planejamento que a maioria dos agentes e modelos oferece hoje. Na fase de planejamento, uso modelos maiores e melhores, com alto nível de effort. O resultado é um plano de execução bem estruturado. Na fase de execução, mudo para modelos menores e mais baratos.
Isso só funciona porque, em 2026, a diferença entre modelos frontier para programação está na casa dos pontos percentuais, enquanto a diferença de preço está na casa das vezes. Modelos abertos como DeepSeek V4 entregam performance comparável aos modelos fechados mais caros por uma fração do custo.3 Já que o planejamento foi feito com o modelo mais capaz, não há motivo para continuar usando o mais caro para gerar código. Existem inúmeras maneiras de implementar a mesma coisa, mas com fluxos extras de qualidade e segurança rodando depois, a variação na implementação se torna irrelevante.
Modelos chineses, VPS e um iPad
A maior parte do meu uso de LLM é com modelos chineses. Desde a chegada do DeepSeek, fiquei interessado nesses modelos porque eles liberaram informações que as Big Techs ocidentais tratam como caixa preta. Boa parte é open source, permitindo reuso, destilação e fine tuning. É um nível de transparência que não vejo sendo praticado por quem vende soluções fechadas.
Também uso bastante um modelo brasileiro, da Maritaca AI, principalmente quando trabalho com conteúdo 100% nacional. Um modelo treinado nas nuances brasileiras faz diferença, e a empresa mantém contato próximo com a comunidade.
Na prática, meu ambiente de desenvolvimento é uma VPS com vscode-server, opencode, Claude Code e Pi Agent. Isso me permite programar do iPad em horários alternativos. À noite, depois do trabalho, nem sempre tenho cabeça para mais horas na frente do computador. Também quero estar com minha família. A VPS virou a ponte entre o tempo que tenho e os projetos que quero tirar do papel.
O que o código dos agentes cobra de você
Esse não é o único projeto que estou construindo, mas foi o que mais me trouxe maturidade no uso de agentes para programação. Minha função atual é mais estratégica, e a programação deixou de ser minha entrega principal. Uso GenAI para programar, mas também para documentação, análise de dados e validação de hipóteses com deep research.4
A maior lição veio de um desconforto específico: em determinados pontos de implementação ou refatoração, dependendo do tamanho do epic, é muito complicado revisar tudo com 100% de segurança. Senti que não tinha certeza absoluta do que havia sido desenvolvido e gastei boas horas revisando.
Estudos recentes confirmam que essa não é uma experiência isolada. Um levantamento com 700 profissionais publicado em 2026 mostrou que 81% dos líderes de engenharia relataram aumento no tempo de revisão de código após adoção de IA. Cerca de 31% do dia do desenvolvedor é consumido revisando código de IA, corrigindo bugs sutis e trocando contexto entre tarefas.5 Outro estudo, com rastreamento ocular, revelou que cada sugestão de código de IA introduz uma microinterrupção no fluxo do desenvolvedor. Cerca de 50% das sugestões nem são olhadas, e das que são, mais de 75% são descartadas. O custo cognitivo está na interrupção, não no resultado.6
É um projeto pessoal. Por isso trabalho com nível de confiança de 70% a 80%. Em ambiente corporativo, não faria dessa maneira. Precisamos equilibrar o uso da tecnologia. Estamos vendo brechas abertas por uma promessa de produtividade que, olhando os números, não se sustenta.
O saldo até agora
Tem sido enriquecedor construir um projeto do zero com aplicação real para uma dor que eu tenho. O fluxo que encontrei está fazendo sentido, não porque seja perfeito, mas porque aceita o custo cognitivo da revisão como parte do processo, e não como falha.
Consumo entre 10 e 15 dólares por mês com modelos chineses para programação, e cerca de 30 reais com modelos da Maritaca AI para revisões de conteúdo. O custo em dinheiro é baixo. O custo em atenção é real, mas administrável, desde que você saiba que ele existe. Esse é o ponto que a maioria dos posts sobre agentic coding omite.
Na Parte 3, vou detalhar os fluxos de qualidade e segurança que rodam depois da implementação, e como estou fechando o ciclo de publicação automatizada.
Referências
1. Commey, D. When "Better" Prompts Hurt: Evaluation-Driven Iteration for LLM Applications. arXiv, jan. 2026. Mostra que prompts genéricos com regras explícitas reduziram a acurácia de extração de 100% para 90% e a conformidade RAG de 93% para 80% em testes com Llama 3. https://arxiv.org/abs/2601.22025
2. Piskala, V. Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants. arXiv, jan. 2026. Define níveis de maturidade de SDD e demonstra que a implementação varia conforme o contexto do time, não havendo estratégia fixa. https://arxiv.org/abs/2602.00180
3. Hexaware Technologies. The Closing Window: Open vs Closed AI Models. abr. 2026. Análise comparativa mostra quatro modelos frontier com diferença de até 0.6 pontos percentuais no SWE-Bench Verified, mas com custo de 5 a 18 vezes maior nos modelos fechados. https://hexaware.com/blogs/the-closing-window/
4. Google Research. Accelerating Scientific Discovery with AI-Powered Empirical Research Assistance. set. 2025. Sistema baseado em Gemini que testa milhares de variantes de código para validação de hipóteses científicas, reduzindo exploração de meses para horas. https://research.google/blog/accelerating-scientific-discovery-with-ai-powered-empirical-software/
5. Harness. 2026 State of Engineering Excellence Report. 2026. Apud SD Times: "The Invisible Burden: How AI is Redefining Developer Productivity in 2026." https://sdtimes.com/softwaredev/the-invisible-burden-how-ai-is-redefining-developer-productivity-in-2026/
6. ICSE 2026. An Eye for AI: Eye-Tracking the Micro-Interruptions of GenAI Code Suggestions. Artifact Award Winner. Estudo com 35 profissionais usando rastreamento ocular para medir interrupções cognitivas causadas por sugestões de código de IA. https://conf.researchr.org/details/icse-2026/icse-2026-research-track/90/An-Eye-for-AI-Eye-Tracking-the-Micro-Interruptions-of-GenAI-Code-Suggestions
Top comments (0)