{"slug": "hot-take-harness-loop-engineering-graph-engineering-sao-bullshit", "title": "Hot take: Harness, Loop Engineering, Graph Engineering são Bullshit", "summary": "In a blog post, developer Fabio Akita argues that 'Harness, Loop Engineering, Graph Engineering' are overhyped, claiming that as AI technology becomes commoditized, money shifts to taxonomy, creating new names for API calls and certifications that expire in six months. Akita cites his own LLM Coding Benchmark showing that for frontier models, harness choice makes negligible difference (e.g., Grok 4.6 scored 92 on OpenCode and 93 on grok CLI), while for weaker models it can help (Grok 4.3 scored 18 on OpenCode vs 55 on grok CLI). He also notes significant cost differences, with Grok 4.6 costing $1.19 on grok CLI versus $6.33 on OpenCode via OpenRouter, over 5x cheaper due to native caching.", "body_md": "# Hot take: Harness, Loop Engineering, Graph Engineering são Bullshit\n\n*Se tem preguiça de ler, clique*\n\n[aqui](https://claude.ai/new?q=Por+favor%2C+abra+esta+URL+com+busca+na+web+e+leia+o+artigo+completo%3A+https%3A%2F%2Fwww.akitaonrails.com%2F2026%2F08%2F18%2Fhot-take-harness-loop-engineering-graph-engineering-sao-bullshit%2F%0A%0ADepois+de+ler+o+conte%C3%BAdo+real+do+artigo%2C+fa%C3%A7a+o+seguinte%3A%0A1%29+Resuma+os+5+pontos+mais+importantes+e+a+conclus%C3%A3o.%0A2%29+Depois+do+resumo%2C+diga+ao+leitor+quais+detalhes%2C+dados+e+insights+ele+est%C3%A1+perdendo+por+n%C3%A3o+ler+o+artigo+completo.+Seja+espec%C3%ADfico+o+suficiente+pra+deixar+ele+curioso.%0A3%29+Lembre+que+ele+pode+continuar+fazendo+perguntas+sobre+o+artigo+aqui+neste+chat.%0A4%29+Sugira+uma+boa+pergunta+de+follow-up+que+ele+poderia+fazer+pra+come%C3%A7ar.)pro TL;DRSoltei [este tweet](https://x.com/AkitaOnRails/status/2089734682325794897) hoje de manhã e ele rendeu. O ponto completo: quando a tecnologia em si vira commodity, o dinheiro migra pra taxonomia. Criam cinco nomes novos pra encadear chamada de API e de repente surge uma certificação que expira em seis meses.\n\nDeixa eu sustentar a provocação com calma, porque ela não é implicância gratuita.\n\nJá antecipo o comentário padrão: *“mas comigo funciona”*. Bom pra você — de verdade. Só que “funciona comigo” nunca provou que a cerimônia é o que fez funcionar. O que fez funcionar foi você saber o que queria. A cerimônia só estava no mesmo ambiente.\n\n## O meu recibo\n\nEntre janeiro e maio eu fiz uma [maratona de IA](/2026/05/14/terminando-maratona-ia-sucesso-ou-fracasso/) e publiquei [mais de 30 repositórios públicos](https://github.com/akitaonrails?tab=repositories). Tem ferramenta que eu uso todo dia — [ai-memory](https://github.com/akitaonrails/ai-memory), [ai-usagebar](https://github.com/akitaonrails/ai-usagebar), [ai-jail](https://github.com/akitaonrails/ai-jail) — e tem app pessoal pra coçar a minha própria coceira: [Frank Manga+](https://github.com/akitaonrails/frank_mangaplus), [Frank Scanlation](https://github.com/akitaonrails/frank_scanlation), [Frank Geary](https://github.com/akitaonrails/frank_geary), e por aí vai.\n\nSabe o que eu nunca senti vontade de fazer nesse meio tempo? Complicar meu setup de IA. Não tenho um [Pi super customizado](/2026/05/25/primeiras-impressoes-usando-oh-my-pi-e-opencode/), não tenho Hermes, não tenho grafo de agentes orquestrado, não tenho pipeline de specs numeradas. Graças ao ai-memory, **eu troco de harness como troco de cueca**: todo dia, sem limitação. Claude Code de manhã, Codex à tarde, Kimi CLI de noite — a memória do projeto vai junto, então o harness vira detalhe.\n\nE detalhe é o ponto. A maioria dos harnesses é otimizada pro LLM da própria casa. Mas “otimizado” não quer dizer “mágico”, e eu tenho dados pra isso.\n\n## O que o meu benchmark diz sobre harness\n\nNo [meu LLM Coding Benchmark](/2026/08/15/llm-benchmarks-qwen-3-8-glm-5-3-gemini-3-7/) eu rodo os mesmos modelos em harnesses diferentes, em condições controladas. O resultado é o oposto do que o mercado de cursos sugere:\n\n**Pra modelo fraco, o harness resgata.** O Grok 4.3 não construiu nada no OpenCode pelado (18 pontos) e entregou um app de verdade no grok CLI (55). O Gemini 3.1 Pro saiu de 62 pra 88 no harness do Google — mas o problema ali era um bug de transporte do OpenRouter, não falta de “engenharia de harness”.**Pra modelo de fronteira, o harness é ruído.** Grok 4.5: 92 no OpenCode, 91 no grok CLI. Grok 4.6: 92 e 93. Diferença de um ponto, dentro da margem. Nenhuma engenharia de harness move um modelo bom.**Onde o harness morde de verdade é no bolso.** A rodada do Grok 4.6 saiu por $1,19 no grok CLI contra $6,33 no OpenCode via OpenRouter —**mais de 5x mais barato** pelos mesmos ~11 milhões de tokens, porque o CLI oficial usa o cache nativo da xAI. Mesma história no Codex: o GPT 5.6 Terra custou $6,77 blended porque 21 dos 21,7 milhões de tokens bateram no cache; o Sol, da mesma família e mesma nota, saiu por uns $45.\n\nOu seja: escolher um harness decente importa — pra custo e pra dar estrutura a modelo fraco. Mas isso é uma tarde lendo documentação e olhando a fatura de tokens, não uma disciplina nova com trilha de aprendizado.\n\nJá que citei o Hermes lá em cima, vale explicar: o [Hermes Agent](https://github.com/NousResearch/hermes-agent) é um framework open source da Nous Research pra você montar o *seu* agente pessoal — você define as tools, escreve os loops, configura roteamento por modelo, fallback local/nuvem, gateways de Telegram e Discord, e ele ainda “aprende skills” com o uso. É o paraíso de quem monta setup.\n\nTambém é um segundo emprego: cada peça dessas vira sua responsabilidade de manter, atualizar e depurar, pra sempre. E no fim das contas o motor continua sendo o mesmo Claude, GPT ou Qwen de todo mundo — o chassi customizado não melhora o motor. O que o Hermes resolve de verdade, continuidade de contexto entre sessões e entre ferramentas, um harness decente com um ai-memory da vida já cobre — sem você virar administrador de infraestrutura do próprio assistente.\n\nSe você quer um assistente no seu hardware por hobby ou por privacidade, é ótimo motivo, vai fundo. Como pré-requisito de produtividade, não é.\n\nPra guardar:harness bom é o que cobra menos e não atrapalha. O resto é o modelo. E modelo bom não precisa de “harness engineering” — no máximo precisa que o transporte não esteja quebrado.\n\n## Loop Engineering, Graph Engineering, Spec-Driven Development\n\nVamos aos nomes, porque eles descrevem coisas reais — só que minúsculas.\n\n**Loop Engineering** é o nome da vez pra projetar o ciclo que um agente repete: executa, verifica com evidência, itera até uma condição de parada. Os guias listam modos de falha reais — o agente declarar “pronto” cedo demais, o objetivo ir derivando a cada volta. Só que a mitigação recomendada é “um verificador independente conferindo evidência objetiva”. Isso tem nome faz cinquenta anos: **teste e revisão**. Um agente num loop com suíte de testes é o básico de sempre com nome novo.\n\n**Graph Engineering** é desenhar o workflow do agente como um grafo explícito de nós, ramos e junções — a LangChain tem [três anos dessa história](https://www.langchain.com/blog/3-years-of-graph-engineering-with-langgraph). Faz sentido quando o fluxo é genuinamente ramificado. Só que a maioria esmagadora dos projetos é uma linha reta com um `if`\n\nno meio. Modelar isso como grafo é comprar um quadro branco gigante pra desenhar uma seta.\n\n**Spec-Driven Development** é escrever uma especificação detalhada primeiro e tratar o código como artefato gerado a partir dela — a spec vira a “source of truth” e o código, subproduto. Guarda esse, que o argumento forte vem já embaixo.\n\nRepare no padrão: cada nome pega uma prática real e pequena — rodar em loop com verificação, desenhar um fluxo, escrever o que você quer antes de fazer — e infla até virar “disciplina”. A inflação é o produto. Nome novo cria curso, curso cria certificação, certificação expira em seis meses e te vende a recertificação.\n\nPra ser justo: os guias sérios desses temas já trazem a ressalva — o [guia de graph engineering](https://www.aibuilderclub.com/blog/graph-engineering-guide-2026) mais lido diz na cara que “você provavelmente não precisa” e manda dominar o loop antes de abrir um grafo, e a LangChain tem uma seção inteira de “quando não usar grafos”. O guia está certo; o estrago vem do funil, que joga a ressalva fora e vende o resto como default pra todo mundo.\n\nOs dois que mais vendem curso — orquestração pesada de agentes e spec-driven development — merecem mais que definição. Merecem o argumento.\n\n## O argumento forte contra a super-orquestração\n\nTem uma matemática simples que os diagramas de agentes orquestrados nunca mostram. Se cada etapa do seu pipeline acerta 90% das vezes — e isso é otimista —, uma cadeia de dez agentes acerta 0,9^10, ou seja, **~35% das vezes**. Cada nó é um ponto novo de falha, e cada aresta é token gasto com agente conversando com agente em vez de trabalhando.\n\nNão precisa acreditar na conta: eu medi isso sem querer no benchmark. O MiniMax M3 rodado debaixo de um orquestrador parecia Tier D, com 24 pontos. O mesmo modelo, limpo, fez 91, Tier A. Uma diferença de até 69 pontos entre condições de harness significa o oposto do que o vendedor de orquestração diz: **quando o plumbing domina o resultado, você parou de medir o modelo e passou a medir o encanamento.** O melhor resultado de todo o benchmark não veio de nenhum enxame orquestrado: veio de um modelo forte, sozinho, num loop simples — Fable 5, 96 pontos, Claude Code, fim.\n\nFaz sentido quando você lembra que coordenação escala mal. Cada agente a mais não adiciona só capacidade; adiciona arestas, contratos de mensagem, estado compartilhado e versões conflitantes da verdade. O roteador que decide “qual agente cuida disso” vira ao mesmo tempo o gargalo e a fábrica de bugs. Um comitê de agentes medianos com regente não bate um agente capaz com boas ferramentas e memória.\n\nIsso eu já testei diretamente. Em abril eu rodei [três rodadas de “modelo forte orquestrando modelo barato”](/2026/04/25/llm-benchmarks-vale-a-pena-misturar-2-modelos/) — planner + executor, delegação forçada, o pacote completo. Resultado: **nenhuma combinação multi-agente bateu o Opus sozinho** num harness maduro. Numa tarefa coesa como construir um app, o planner precisa ler cada output do executor antes de despachar o próximo passo — os dois viram sequenciais, com latência triplicada e uma fila de coordenação no meio. É o comitê de novo: muita conversa, pouco software.\n\nNão é só o meu benchmark. A Cognition, que vende o Devin, publicou o [“Don’t Build Multi-Agents”](https://cognition.com/blog/dont-build-multi-agents) com um mecanismo mais afiado que a minha conta de 90%: **toda ação carrega decisões implícitas que os outros agentes não veem** — um subagente desenha o fundo estilo Mario, o outro desenha um pássaro incompatível, e nenhuma confiabilidade individual conserta a divergência.\n\nA própria Anthropic, que tem um sistema multi-agente de pesquisa, [admite no post de engenharia](https://www.anthropic.com/engineering/multi-agent-research-system) que multi-agente gasta **15x mais tokens**, que coding é um domínio ruim pra isso — a maioria das tarefas de código não é paralelizável de verdade — e que 80% da melhoria deles veio de simplesmente gastar mais tokens, não da arquitetura.\n\nQuando Berkeley mediu o que realmente roda em produção, [86 sistemas em 26 domínios](https://arxiv.org/abs/2512.04123): 68% dos agentes em produção executam no máximo 10 passos antes de intervenção humana. O que existe de verdade por aí é loop simples supervisionado — não a constelação de nós coloridos do diagrama do consultor.\n\nOnde a orquestração é legítima: trabalho genuinamente paralelo e independente — varrer dez mil arquivos, rodar dez mil análises descartáveis. Map-reduce existe faz vinte anos e nunca precisou de nome pomposo. E tem um recanto sério além dele: agente rodando de madrugada, sem ninguém olhando, com credencial na mão — aí verificador independente e orçamento duro viram questão de segurança, não de estilo. Mas isso é operação de frota, não o coding do dia a dia que o curso te vende. Fora desses nichos, a maioria das “arquiteturas multi-agente” é o trabalho de um agente só, com YAML extra.\n\nTem um motivo pra você ouvir tanto sobre isso: orquestração é complexidade **visível**. Tem diagrama, tem nó colorido, tem dashboard. Um agente bem dirigido não tem nada disso — não tem slide, não tem certificação, não tem o que vender.\n\nPra guardar:cada agente a mais multiplica os modos de falha. Se o resultado do seu sistema muda quando você troca o orquestrador, o seu sistema é o orquestrador — e o modelo era figurino.\n\n## O argumento forte contra spec-driven development\n\nO SDD parece maduro porque soa como “escrever documentação”. Mas presta atenção no que ele realmente propõe: a spec vira a fonte da verdade e o código vira artefato gerado. O problema é que **uma spec precisa o bastante pra gerar código correto já é um programa** — só que escrito em prosa, e prosa não compila. Cada ambiguidade da spec é um bug que nenhum compilador pega, num meio sem teste, sem linter, sem feedback. O SDD não remove a parte difícil, que é pensar com precisão; ele move a parte difícil pra um formato onde erro não grita.\n\nPra guardar:uma spec precisa o bastante pra gerar código correto já é um programa — só que em prosa. E prosa não compila.\n\nMesmo que você escreva a spec perfeita, ela começa a morrer no primeiro hotfix. O bug aparece em produção, alguém conserta direto no código, e a spec vira mentira. A gente conhece essa lei faz décadas — é por isso que documentação apodrece. Chamar a spec de “fonte da verdade” não muda o incentivo de ninguém.\n\nA gente já fez esse experimento, aliás. UML, MDA, “o código se gera a partir do modelo” — vinte e poucos anos atrás era a mesma promessa com outras siglas. Colapsou sempre pela mesma razão: o modelo nunca era a realidade; o código era. O SDD é o MDA com um LLM pendurado. E [não sou só eu que vejo o Waterfall 2.0 ali](https://www.alexcloudstar.com/blog/spec-driven-development-2026/).\n\nQuem testou as ferramentas com seriedade chegou no mesmo lugar. A Thoughtworks colocou spec-driven development no anel [“Assess” do Technology Radar](https://www.thoughtworks.com/radar/techniques/spec-driven-development) — não “adote”, “avalie” — depois de ver as ferramentas inflarem tarefas pequenas em cerimônia, e cravou a frase que resume: estamos talvez *“reaprendendo uma lição amarga: regras detalhadas feitas à mão pra IA simplesmente não escalam”*. É a Bitter Lesson do Rich Sutton batendo na porta de novo — estrutura artesanal perde pra escala, sempre perdeu.\n\nTem ainda a inversão temporal. A grande lição do agile foi que você descobre o que quer **construindo** — working software over comprehensive documentation. O LLM acabou de deixar a iteração barata como nunca na história. E o que o SDD propõe? Expandir a fase de planejamento, justo agora que iterar ficou barato. Resposta errada, na direção errada, na hora errada.\n\nÉ a tese que eu venho martelando desde os primeiros posts de [Agile Vibe Coding](/2026/02/23/vibe-code-fiz-um-indexador-inteligente-de-imagens-com-ia-em-2-dias/): **software emerge, não se planeja**. [Escrevi isso em fevereiro, com recibo](/2026/02/20/do-zero-a-pos-producao-em-1-semana-como-usar-ia-em-projetos-de-verdade-bastidores-do-the-m-akita-chronicles/): as features mais importantes do M.Akita Chronicles nasceram de problema que apareceu no meio do caminho — um job que falhou em silêncio, um site que bloqueou a gem, um crash que deixou email em limbo. Nenhum spec do mundo prevê isso. O sistema correto emerge da iteração, não da especificação.\n\nO processo ficou documentado de novo quando o ai-memory cresceu na mão de 26 contribuidores em 24 dias: [software bom é escultura de barro, não torre de Lego](/2026/06/14/ai-memory-arquitetura-emergente-e-software-maleavel/) — maleável, sempre ajustável, nunca pronto. Quem tenta desenhar a arquitetura inteira antes da primeira linha constrói uma camisa de força, não um sistema. Só amador ainda acredita que dá pra especificar o software inteiro antes de codar. Modelagem de verdade não vem de template nem de curso — [falei disso anos atrás no Akitando 144](/2023/08/11/akitando-144-modelagem-de-software-e-dificil-ver-vs-enxergar/): ela nasce de repertório com problema e código reais. Não tem receita pronta; nunca teve.\n\nO SDD tenta ressuscitar a ideia de que dá pra planejar software adiantado — a ideia que a indústria enterrou depois de décadas de projeto entregue atrasado, errado e superfaturado. O LLM não revalidou essa ideia; só deu a ela um PowerPoint novo.\n\nAté quem escreve guia a favor separa as duas coisas: [“spec-as-source é onde mora o hype; spec-anchored é onde está o valor hoje”](https://dev.to/krlz/spec-driven-development-in-2026-what-it-is-the-tooling-and-how-teams-actually-use-it-2fk2). O meu alvo aqui é o primeiro. Onde a spec pesada é legítima: time grande, codebase legado, trabalho assíncrono que atravessa fuso e sprint — o bom e velho documento de design, que sempre existiu e sempre teve valor. O que não cola é vender isso como o novo default pra todo mundo.\n\nO meu prompt de benchmark, pra constar, é uma página de objetivos. A diferença é que eu não confio na prosa: eu valido rodando. Precisão mora em teste, não em parágrafo.\n\n## O que você realmente precisa\n\nEu já escrevi tudo isso aqui no blog, com recibo de projeto real. Chama [Agile Vibe Coding](/2026/02/23/vibe-code-fiz-um-indexador-inteligente-de-imagens-com-ia-em-2-dias/), e cabe num parágrafo:\n\nÉ XP (eXtreme Programming, o agile raiz) com LLM: testes, [Clean Code](/2026/04/20/clean-code-para-agentes-de-ia/), CI (integração contínua), pair programming e deploy. Você dirige o agente como dirigiria um pair muito rápido: diz o que quer, acompanha a execução, corrige enquanto o erro é barato. A ideia é 10% do trabalho; os outros 90% são engenharia de software normal, a de sempre. [Esquece framework e template de três páginas](/2026/04/15/como-falar-com-o-claude-code-efetivamente/): o que você precisa é saber o que quer, saber o que não quer, e saber validar quando chega. E precisa de equilíbrio: [nem largar o volante pro agente, nem virar fiscal de vírgula](/2026/04/11/vs-code-e-o-novo-cartao-perfurado/).\n\nForam mais de 600 horas disso, mais de meio milhão de linhas, dezenas de projetos no ar. Nenhum grafo, nenhuma certificação, nenhum loop com nome em inglês.\n\nPra guardar:a ideia é 10% do trabalho; os outros 90% são engenharia de software, a de sempre.\n\n## A peça que me deixa trocar de harness: ai-memory\n\nTem uma ferramenta minha que é o oposto de taxonomia: o [ai-memory](https://github.com/akitaonrails/ai-memory). Ele nasceu de um problema concreto. Todo harness guarda a sessão no formato dele, e quando a conversa fica longa, ele compacta o histórico pra caber na janela — e a compactação joga fora justamente os detalhes que explicam por que cada decisão foi tomada. Aí você troca de ferramenta e começa do zero, com o projeto inteiro pra reexplicar.\n\nO ai-memory resolve isso do lado de fora do harness. Ele lê a sessão nativa sem tocar no arquivo original e guarda tudo num ledger pesquisável: mensagens, chamadas de ferramenta com resultados, resumos de compactação, checkpoint do git — cada evento marcado com a origem (veio do Claude, do Codex, do OpenCode). Quando eu abro outro harness, ele ganha a sessão nativa dele e recebe só o delta que ainda não viu. Quando eu volto pro anterior, o ai-memory retoma no formato daquele cliente e entrega o que aconteceu nos outros enquanto isso.\n\nÉ por isso que “troco de harness como troco de cueca” não é força de expressão. **O conhecimento do projeto mora no projeto, não na sessão de uma ferramenta.** Se a Anthropic mudar preço, limite ou modelo amanhã — e vai mudar —, eu troco o motor sem jogar fora a viagem. Os detalhes de como isso funciona estão [neste post](/2026/07/20/novidades-no-meu-ai-memory-cada-vez-melhor-pra-usar-com-suas-ias/).\n\nTem ainda uma inversão aqui que despacha o SDD de brinde. O spec-driven development diz que a fonte da verdade é um documento escrito **antes** do trabalho, tentando prever o futuro, e que o código deve obediência a ele. O ai-memory faz o contrário: a fonte da verdade é uma [wiki destilada do próprio trabalho](/2026/06/16/ai-memory-memoria-longo-prazo-karpathy-wiki-auto-aprendizado-hermes-projetos/) — cada sessão vira evidência, e o que merece sobreviver (decisões, regras, gotchas, tentativas que falharam) é consolidado em páginas Markdown curtas que qualquer agente lê antes de começar.\n\nA spec tenta adivinhar o projeto; a wiki registra o projeto. Documento escrito antes apodrece no primeiro hotfix, porque ninguém é obrigado a atualizá-lo. A wiki é alimentada pelo próprio ato de trabalhar — e quando desatualiza, você percebe na hora, porque os agentes tropeçam nela toda sessão.\n\nRepare que isso é harness engineering de verdade: uma ferramenta, escrita uma vez, resolvendo um problema meu. Nenhum curso, nenhuma sigla, nenhuma certificação.\n\n## Conclusão: pede o recibo\n\nNão gaste tempo nem dinheiro com curso de “harness engineering”, “loop engineering” ou qualquer taxonomia da semana. É tentativa descarada de te cobrar por coisas que você já faz se souber engenharia de software básica.\n\nEsse filme a gente já viu, aliás. O [Pedro Arantes lembrou no X](https://x.com/arantespp/status/2089752215380426951): *“Microservices, clean architecture, hexagonal e Domain-Driven Design são tudo bullshit pra vender mais horas de consultoria e cursos.”* Mesma história, mesmo roteiro. Cada um deles nasceu de um problema real — e virou default de quem não tinha o problema. Microservice pra time de três pessoas, arquitetura hexagonal pro CRUD (o cadastro cria-lê-atualiza-apaga de sempre), DDD pra nunca mais escrever código. A técnica passa, a taxonomia fica, o curso vende.\n\nPra ninguém se fazer de desentendido: **nada disso é inútil**. Loop com verificação funciona. Grafo funciona quando o fluxo é um grafo de verdade. Spec pesada salva time grande. Microservices resolveram problemas reais de quem tinha escala de verdade; DDD brilha em domínio complexo de verdade. O problema nunca foi a ferramenta — é vender a ferramenta como **bala de prata**, o martelo universal que você precisa aplicar em tudo. Bala de prata não existe, nunca existiu. Quem te vende uma não está vendendo solução; está vendendo curso.\n\nEntenda o mecanismo psicológico, porque ele é velho e eficiente: esses termos existem pra te dar **FOMO** (Fear of Missing Out — o medo de estar perdendo o bonde). Pra te deixar ansioso, achando que está ficando pra trás, que está deixando produtividade na mesa, que todo mundo já migrou pro novo paradigma e você não. Ansiedade vende. Depois que você está inseguro, eles te cobram pra implementar algo de que você nunca precisou. FOMO é real — e aqui, é o modelo de negócio.\n\nO modelo ainda é recorrente — repare na elegância. Primeiro te vendem a metodologia que **gera** artefatos — specs, grafos, boards, diagramas. Os artefatos se multiplicam, ninguém mais sabe onde está nada, e adivinha quem aparece? A mesma consultoria, agora vendendo a ferramenta que **gerencia** os artefatos, o curso que te ensina a gerenciar a ferramenta e o workshop de governança dos artefatos. É o vendedor de pá te parabenizando pelo buraco que você cavou — e te oferecendo uma pá maior.\n\nA Gartner tem até nome oficial pra isso: [“agent washing”](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027) — pegar produto existente, pendurar a etiqueta “agentic” e revender. A estimativa deles: só umas **130 das milhares** de empresas que se vendem como “IA agêntica” são reais, e a previsão é de 40% dos projetos do tipo cancelados até o fim de 2027, por custo, valor incerto ou risco mal controlado. Aqui não tem implicância minha: é o ciclo do hype, medido, com previsão pública e tudo.\n\nDa próxima vez que um influencer ou consultor tentar te empurrar esses produtos, faz uma pergunta simples: **onde estão as suas dezenas de projetos open source de alta qualidade que ficaram melhores por causa dessas “técnicas”?**\n\nEles não têm o que mostrar. Eu tenho — [está tudo público](https://github.com/akitaonrails?tab=repositories), com código, benchmark e processo documentado. Quando a tecnologia vira commodity, o dinheiro migra pra taxonomia. Não seja o cliente dessa migração.", "url": "https://wpnews.pro/news/hot-take-harness-loop-engineering-graph-engineering-sao-bullshit", "canonical_source": "https://www.akitaonrails.com/2026/08/18/hot-take-harness-loop-engineering-graph-engineering-sao-bullshit/", "published_at": "2026-08-18 13:00:00+00:00", "updated_at": "2026-08-21 04:15:00.821349+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-tools", "ai-research"], "entities": ["Fabio Akita", "Grok 4.3", "Grok 4.5", "Grok 4.6", "OpenCode", "grok CLI", "OpenRouter", "Gemini 3.1 Pro"], "alternates": {"html": "https://wpnews.pro/news/hot-take-harness-loop-engineering-graph-engineering-sao-bullshit", "markdown": "https://wpnews.pro/news/hot-take-harness-loop-engineering-graph-engineering-sao-bullshit.md", "text": "https://wpnews.pro/news/hot-take-harness-loop-engineering-graph-engineering-sao-bullshit.txt", "jsonld": "https://wpnews.pro/news/hot-take-harness-loop-engineering-graph-engineering-sao-bullshit.jsonld"}}