Cosas molestas y alarmantes sobre OpenCode
La crítica al popular harness de programación con IA OpenCode se centra en vulnerabilidades de seguridad, alto uso de recursos, caché de prompts frágil y prompts del sistema con fuertes opiniones que pueden alterar silenciosamente el estilo del código o incluso eliminar comentarios. Los comentaristas sostienen que estos fallos reflejan problemas más amplios de las herramientas LLM “agénticas”, que a menudo ejecutan código no confiable con un sandboxing débil y sistemas de permisos engañosos, creando serios riesgos para la cadena de suministro y la privacidad. Aunque muchos siguen encontrando OpenCode muy productivo —sobre todo por su acceso gratuito o barato a modelos—, otros se están mudando a alternativas como Pi, Codex o harnesses personalizados, a menudo combinados con sandboxes externos más fuertes o modelos que solo se ejecutan localmente.
Recepción general de OpenCode
- Muchos coinciden en que el texto es hiperbólico, pero ven que sus críticas principales son en su mayoría acertadas.
- Varios usuarios informan que OpenCode los volvió muy productivos y sigue siendo su harness favorito.
- Otros ya se han cambiado (o ahora planean hacerlo) a alternativas como Pi / OhMyPi, Codex, Kilo, Mimo, Maki, Aider, etc.
Seguridad, permisos y sandboxing
- Se señalan múltiples problemas graves de seguridad y RCE; algunos supuestamente están corregidos, otros no está claro.
- El filtro textual de comandos / “allowlist” es ampliamente visto como débil o engañoso desde el punto de vista de la seguridad.
- Hay un consenso fuerte: no confíes en ningún agente de programación en tu sistema de archivos real; ejecútalo dentro de un sandbox/VM (bwrap, sandbox-exec, flatpak, landlock, etc.).
- Hay debate sobre si el sandboxing debería integrarse en los harnesses o gestionarse con herramientas separadas.
Caché del prompt, compactación y rendimiento
- Los fallos frecuentes de caché debido a mutaciones del system prompt (fecha, cambios en AGENTS.md, etc.) son una gran molestia y un sumidero de tokens.
- La compactación/poda se percibe como lenta, con errores y a menudo contraproducente; algunos la desactivan mediante variables de entorno.
- Otros dicen que el caché del backend (por ejemplo, DeepSeek, vLLM) puede ocultar las ineficiencias del cliente.
- Los desarrolladores de OpenCode mencionan que la poda problemática está desactivada por defecto y que los cambios de v2 buscan evitar invalidar la caché.
System prompts, comentarios y LSP
- Los prompts por defecto son criticados por ser enormes, desordenados e imponer políticas dudosas (por ejemplo, “sin comentarios”), lo que provoca la eliminación no deseada de comentarios.
- Algunos están de acuerdo con una salida con comentarios mínimos; otros instruyen explícitamente a los agentes para que añadan muchos comentarios y luchan contra los valores predeterminados.
- La integración de LSP divide opiniones: algunos la consideran una función decisiva para refactors y búsquedas de símbolos; otros ven poco beneficio y un alto costo en tokens.
Gobernanza, UX y salud del proyecto
- El gran número de issues abiertos, el bot agresivo de inactividad y la escasa aceptación de PR alimentan las afirmaciones de que el repositorio es “open source solo de nombre”.
- Hay quejas sobre el exceso de bloat, el alto uso de CPU/RAM y una nueva UI confusa (pestañas, pérdida del soporte para workspace).
- Los mantenedores responden que v2 aborda varios de los problemas señalados, pero reconocen el ruido de los issues en GitHub.
Visión más amplia sobre los agentes LLM y el tono
- Muchos señalan que los mismos problemas estructurales aplican a la mayoría de los CLIs agénticos, no solo a OpenCode.
- Algunos ven el artículo como efectivamente anti-AI-for-SWE; otros presentan los LLM como “solo herramientas” que requieren expectativas realistas y un fuerte aislamiento.
- El tono agresivo y burlón del artículo polariza; a algunos les gusta el desahogo, a otros les parece injusto o desmoralizador.