Depois de rodar por pouco tempo, tive a impressão de que o hermes perde menos memória do que o openclaw, e descobri que isso acontece porque ele tem uma lógica de replay do contexto da sessão em situações como reinicialização ou fallback do modelo. O openclaw também segue melhorando continuamente os recursos relacionados à memória, então talvez isso melhore no futuro.
A função de autoaperfeiçoamento também é impressionante, porque quando um processo de trabalho complexo é detectado, existe uma lógica que o transforma automaticamente em uma skill, além de uma estrutura em que o código-fonte fica baixado via git no próprio workspace e acessível diretamente para modificações. No entanto, não há absolutamente nenhum gerenciamento de mudanças entre o git do código-fonte no workspace e o repositório oficial no GitHub, então ao atualizar as alterações locais acabam sendo resetadas. Estou tentando encontrar uma forma de contornar isso com git worktree, mas não está ficando muito elegante... hmm...
Ainda é verdade que não há uma diferença perceptível para quem não é desenvolvedor.
A diferença entre o Hermes Agent e o OpenClaw vem da estrutura de memória e da capacidade de autoajuste, mas em um estado inicial em branco logo após a instalação essas coisas não ficam aparentes.
Quando usei o Claude Code pela primeira vez, falei para uns amigos estrangeiros: "acabei de experimentar vibe coding pela primeira vez!". Mas, depois de ouvirem o que eu estava contando, eles responderam: "não, isso não é vibe coding; vibe coding de verdade é programar sem nem olhar o código". Parece que o que costuma ser chamado de "vibe coding" aqui na Coreia é definido de forma muito mais ampla do que no Ocidente. O vibe coding de que se fala no Hacker News é, de fato, definido como "não fazer code review".
Depois que o evento de 2x acabou, eu também senti isso claramente, então não era só impressão minha. Não foi simplesmente porque o evento de 2x terminou; a velocidade de consumo ficou muito mais rápida do que antes...
Eu uso o Claude Code acoplado ao Glm, então nunca cheguei a passar por isso.
Acho que a principal causa provavelmente está no lado da resposta do servidor da Anthropic.
É preciso microgerenciar até os detalhes mais triviais para produzir código com uma qualidade minimamente convincente. Acho que autonomia total simplesmente não faz sentido, exceto talvez para produzir boilerplate de verdade em massa. Quem fala em autonomia total é uma de duas coisas: ou não entende muito do assunto, ou é picareta.
Parece mais uma crítica que conclui que vibe coding é igual a não fazer code review e depois cola justificativas para sustentar isso.
Além disso, também não faz sentido trazer Claude Code para a conversa. Se for cobrar esse nível de qualidade, isto é, princípios de engenharia no nível de manutenção do Linux, não se aborda problema de qualidade de código de forma tão fragmentada. Quase tudo é uma abordagem propagandística, daquele tipo de “ouvi dizer”, sem ter testado diretamente.
É parecido com dizer que o design dos prédios da Samsung é ruim e que ela ainda está longe de alcançar a Sony.
Este é um problema que vem persistindo desde o fim recente do evento de 2x. No Reddit e em comunidades relacionadas, continua sendo um tema quente, então é surpreendente que isso ainda não tenha saído aqui como notícia.
Enquanto fazem FULL AUTO MATION com AI AGENT, automatizando completamente geração de código, merge, review e validação, e tratam como se já estivesse tudo resolvido se o código for montado de forma totalmente autônoma e o desenvolvedor só precisar intervir de vez em quando quando os agentes se embolam, acabou se espalhando um clima de considerar anormais os desenvolvedores que não conseguem fazer isso, como se não acompanhassem a tendência... Aí, quando vejo esse pessoal que provavelmente vive espalhando código boilerplate e sequências de padrões repetitivos, recebendo salários altos, e agora fica falando pelos cotovelos que com IA nem precisa mais programar, é algo simplesmente patético.
Entendo que, considerando que LLMs também simplesmente coletaram muita informação, isso não seja visto como um ato tão “maligno”, mas não sei se é algo para se assumir com tanta naturalidade assim.
Depois de ver isso, me esforcei bastante... para testar. E também acabei publicando no GeekNews um texto sobre por que isso não funciona. haha
É legal que ele pega automaticamente na seção de bons textos para ler junto no GeekNews! :) Por que a orquestração de múltiplos agentes não funciona bem?
"calcular o menor salário anual que a pessoa aceitaria"
Também é parecido com quando lojas da vizinhança, em conluio, definem um teto para o valor por hora ao contratar trabalhadores temporários.
No nosso país...
Depois de rodar por pouco tempo, tive a impressão de que o hermes perde menos memória do que o openclaw, e descobri que isso acontece porque ele tem uma lógica de replay do contexto da sessão em situações como reinicialização ou fallback do modelo. O openclaw também segue melhorando continuamente os recursos relacionados à memória, então talvez isso melhore no futuro.
A função de autoaperfeiçoamento também é impressionante, porque quando um processo de trabalho complexo é detectado, existe uma lógica que o transforma automaticamente em uma skill, além de uma estrutura em que o código-fonte fica baixado via git no próprio workspace e acessível diretamente para modificações. No entanto, não há absolutamente nenhum gerenciamento de mudanças entre o git do código-fonte no workspace e o repositório oficial no GitHub, então ao atualizar as alterações locais acabam sendo resetadas. Estou tentando encontrar uma forma de contornar isso com
git worktree, mas não está ficando muito elegante... hmm...Então não era só eu que estava sentindo isso…
Ainda é verdade que não há uma diferença perceptível para quem não é desenvolvedor.
A diferença entre o Hermes Agent e o OpenClaw vem da estrutura de memória e da capacidade de autoajuste, mas em um estado inicial em branco logo após a instalação essas coisas não ficam aparentes.
Quando usei o Claude Code pela primeira vez, falei para uns amigos estrangeiros: "acabei de experimentar vibe coding pela primeira vez!". Mas, depois de ouvirem o que eu estava contando, eles responderam: "não, isso não é vibe coding; vibe coding de verdade é programar sem nem olhar o código". Parece que o que costuma ser chamado de "vibe coding" aqui na Coreia é definido de forma muito mais ampla do que no Ocidente. O vibe coding de que se fala no Hacker News é, de fato, definido como "não fazer code review".
No fim, tudo volta para Win32?!!
O título e o conteúdo são diferentes…?
Depois que o evento de 2x acabou, eu também senti isso claramente, então não era só impressão minha. Não foi simplesmente porque o evento de 2x terminou; a velocidade de consumo ficou muito mais rápida do que antes...
Eu uso o Claude Code acoplado ao Glm, então nunca cheguei a passar por isso.
Acho que a principal causa provavelmente está no lado da resposta do servidor da Anthropic.
É preciso microgerenciar até os detalhes mais triviais para produzir código com uma qualidade minimamente convincente. Acho que autonomia total simplesmente não faz sentido, exceto talvez para produzir boilerplate de verdade em massa. Quem fala em autonomia total é uma de duas coisas: ou não entende muito do assunto, ou é picareta.
Parece mais uma crítica que conclui que vibe coding é igual a não fazer code review e depois cola justificativas para sustentar isso.
Além disso, também não faz sentido trazer Claude Code para a conversa. Se for cobrar esse nível de qualidade, isto é, princípios de engenharia no nível de manutenção do Linux, não se aborda problema de qualidade de código de forma tão fragmentada. Quase tudo é uma abordagem propagandística, daquele tipo de “ouvi dizer”, sem ter testado diretamente.
É parecido com dizer que o design dos prédios da Samsung é ruim e que ela ainda está longe de alcançar a Sony.
Mds
Este é um problema que vem persistindo desde o fim recente do evento de 2x. No Reddit e em comunidades relacionadas, continua sendo um tema quente, então é surpreendente que isso ainda não tenha saído aqui como notícia.
Na página de divulgação do modelo no huggingface também tem benchmark próprio...
https://huggingface.co/litert-community/gemma-4-E4B-it-litert-lm
Google AI Edge Gallery - app de galeria de LLM totalmente offline de código aberto
Também tem no Google Play
https://play.google.com/store/apps/…
Enquanto fazem
FULL AUTO MATIONcomAI AGENT, automatizando completamente geração de código, merge, review e validação, e tratam como se já estivesse tudo resolvido se o código for montado de forma totalmente autônoma e o desenvolvedor só precisar intervir de vez em quando quando os agentes se embolam, acabou se espalhando um clima de considerar anormais os desenvolvedores que não conseguem fazer isso, como se não acompanhassem a tendência... Aí, quando vejo esse pessoal que provavelmente vive espalhando código boilerplate e sequências de padrões repetitivos, recebendo salários altos, e agora fica falando pelos cotovelos que com IA nem precisa mais programar, é algo simplesmente patético.Entendo que, considerando que LLMs também simplesmente coletaram muita informação, isso não seja visto como um ato tão “maligno”, mas não sei se é algo para se assumir com tanta naturalidade assim.
Depois de ver isso, me esforcei bastante... para testar. E também acabei publicando no GeekNews um texto sobre por que isso não funciona. haha
É legal que ele pega automaticamente na seção de bons textos para ler junto no GeekNews! :)
Por que a orquestração de múltiplos agentes não funciona bem?
Hehe, e agora o que eu faço?
"calcular o menor salário anual que a pessoa aceitaria"
Também é parecido com quando lojas da vizinhança, em conluio, definem um teto para o valor por hora ao contratar trabalhadores temporários.