Coisas irritantes e alarmantes sobre o OpenCode
As críticas ao popular harness de codificação com IA OpenCode se concentram em vulnerabilidades de segurança, alto uso de recursos, cache de prompts frágil e prompts de sistema opinativos que podem alterar silenciosamente o estilo do código ou até remover comentários. Os comentaristas argumentam que essas falhas refletem problemas mais amplos nas atuais ferramentas LLM “agentic”, que muitas vezes executam código não confiável com sandboxing fraco e sistemas de permissão enganosos, criando sérios riscos de supply chain e privacidade. Embora muitos ainda considerem o OpenCode altamente produtivo — especialmente por causa do acesso gratuito ou barato a modelos —, outros estão migrando para alternativas como Pi, Codex ou harnesses próprios, frequentemente combinados com sandboxes externos mais fortes ou modelos apenas locais.
Recepção geral do OpenCode
- Muitos concordam que o texto é hiperbólico, mas veem suas críticas centrais como em grande parte precisas.
- Vários usuários relatam que o OpenCode os tornou muito produtivos e continua sendo seu harness favorito.
- Outros já migraram (ou agora planejam migrar) para alternativas como Pi / OhMyPi, Codex, Kilo, Mimo, Maki, Aider, etc.
Segurança, permissões e sandboxing
- Múltiplos problemas sérios de segurança e RCEs são apontados; alguns teriam sido corrigidos, outros não estão claros.
- O filtro textual de comandos / “allowlist” é amplamente visto como fraco ou enganoso do ponto de vista de segurança.
- Há forte consenso: não confie em nenhum agente de programação no seu filesystem real; execute-o dentro de um sandbox/VM (bwrap, sandbox-exec, flatpak, landlock, etc.).
- Debate sobre se o sandboxing deve ser integrado aos harnesses ou tratado por ferramentas separadas.
Cache de prompt, compactação e desempenho
- Misses de cache frequentes devido a mutações no system prompt (data, mudanças em AGENTS.md, etc.) são um grande incômodo e um dreno de tokens.
- Compactação/poda é vista como lenta, bugada e muitas vezes contraproducente; alguns a desativam via variáveis de ambiente.
- Outros dizem que o cache do backend (por exemplo, DeepSeek, vLLM) pode mascarar ineficiências do cliente.
- Os desenvolvedores do OpenCode mencionam que a poda problemática está desativada por padrão e que mudanças na v2 visam evitar quebrar o cache.
System prompts, comentários e LSP
- Os prompts padrão são criticados por serem enormes, bagunçados e imporem políticas questionáveis (por exemplo, “no comments”), o que causa remoção indesejada de comentários.
- Alguns concordam com saída com poucos comentários; outros instruem explicitamente os agentes a adicionar muitos comentários e lutam contra os padrões.
- A integração com LSP divide opiniões: alguns a consideram um recurso matador para refatorações e buscas por símbolos; outros veem pouco benefício e alto custo em tokens.
Governança, UX e saúde do projeto
- Grande backlog de issues abertas, bot agressivo de stale e aceitação esparsa de PRs alimentam alegações de que o repositório é “open source só no nome”.
- Reclamações sobre inchaço, alto uso de CPU/RAM e uma nova UI confusa (abas, suporte a workspace perdido).
- Os mantenedores respondem que a v2 aborda vários dos problemas levantados, mas reconhecem o ruído das issues no GitHub.
Visão mais ampla sobre agentes LLM e tom
- Muitos observam que os mesmos problemas estruturais se aplicam à maioria das CLIs agentic, não apenas ao OpenCode.
- Alguns veem o artigo como, na prática, anti-AI-for-SWE; outros enquadram os LLMs como “apenas ferramentas” que exigem expectativas realistas e forte isolamento.
- O tom agressivo e zombeteiro do artigo divide opiniões; alguns gostam do desabafo, outros o consideram injusto ou desmotivador.