Live data from Hacker News

Annoying and alarming things about OpenCode

wren.wtf

271–280 of 309 posts

Re: Annoying and alarming things about OpenCode

#271
post #164

This prose feels extremely angry and ungenerous; abstractly, I agree with a lot of the points, but when I read this: > My conclusion is that OpenCode is clown-car turboslop with a security posture of “let me bend over for you daddy”. Everyone using it should stop using it. I do not want to keep reading. There are regular people who wrote this software. When did it become normal to talk about open source like this? Ho…

I agree with your sentiment, but to answer your question: Since forever. (At least I know examples in the 90's). In the old days of comp.lang.lisp, there were certain individuals who would really get off on denigrating people who wrote code that was not up to their ivory tower level. Some people left because of it. Others took it as a badge of honor falsely believing that the dressing down was necessary for them to i…

Poorly socialized people tend to have poorly developed social mores.

And a lot of developers, especially on the internet, tend to be poorly socialized.

Salt that with the fact that they often are more fact-intelligent than the people around them in real life, and you get a propensity to shitpost whenever thry feel it's warranted, especially about technical things.

Re: Annoying and alarming things about OpenCode

#272
post #254

Earlier quoted context omitted.

Author here. Just wanted to say: thank you for posting this. You've given me something to think about, and I regret writing this post the way that I did.

please don't regret writing the post the way you did, I for one enjoy well-written rants

Maybe the important take-away would be to recognize that this was a rant.

Ownership and honesty about things is healthy, as is letting out strong opinions sometimes.

Nothing wrong with saying "I wanted to write a (technically-informed) rant about something that's really bothering me, and I did."

F.ex. "clown-car turboslop" would be fairly polite by the standards of younger Torvalds (though he admittedly recognized later in life that wasn't a great communication style)

Re: Annoying and alarming things about OpenCode

#273
post #88

I use CC at a client because that's their stack. I use (a particular version of) OpenCode for my own work, because it is so much better. Reading this post makes me sad. Because everything matches and explains oddities I've seen and forgiven. So despite the hyperbole and the places where the authors' general sentiment are not mine, he's basically right, and I need to find a different harness. If the post resonates for…

I'd offer that the AI harness ecosystem is discovering the same thing any rapidly-growing software space did before it -- lines of code are a maintenance burden.

That's not something a team sees when they're doing greenfield, forward development. (Most projects, now)

It only crops up when they have enough on-the-books code that features / bugfixes start requiring introspection of existing code. (Now to ~1 year from now)

And a lot of these projects don't seem to be approaching codebase size growth from a future code debt perspective...

Re: Annoying and alarming things about OpenCode

#274
post #270
post #257

Earlier quoted context omitted.

Well - pretty much everyone knows it's lousy security, because you know, it's pretty obvious. But maybe some people think it's not obvious, and point it out because they think they're clever? I suppose that's possible.

I think you're vastly overestimating the technical competence and background of most people using agentic coding harnesses today. The downside to democratizing code creation is... it puts it in the hands of non-developers. F.ex. a team I work with asking OpenClaw "What is SRE?"

Well - maybe. But as I understand it - you can't buy Mac minis right now because agentic coders are buying all of them, so they can properly sandbox their agents. Which means a LOT of people know they need to sandbox their agents.

I'm beginning to think that the true issue here is that people who dislike AI are largely ignorant of the current state. Because willful ignorance.

I say that because I repeatedly see people making extremely silly statements that they really should know better about. But for some reason they don't.

Obviously I could be wrong. Time will tell.

Re: Annoying and alarming things about OpenCode

#275
post #269
post #172

Earlier quoted context omitted.

You did not hit max depth - you hit a timer designed to prevent rage posting. My question stands - if you accept that LLM harnesses are designed to allow the building and testing of executables - how do you imagine you can prevent the building and running of executables? Respectfully.

Going from "build and running executables" to that needing to be done on the same system and under control of the LLM is a large leap. Separation of duties and ephemerality are well-known security mechanisms that many harnesses jump right over in the pursuit of easier UX. Mingling permissions + trusting vibe-coded security boundaries in the harness itself (developed by folks whose appetite for risk would make even an…

It does not need to be on the same system - but that is currently how it is done by nearly everyone in the field because it seems to be the most effective way. Which is why coding harnesses build AND execute code.

I'm not sure why you disbelieve agents can do "guaranteed to never fail". Proving correctness is one of their strengths. Proofs in general, in fact, much much better than the typical human coder.

Re: Annoying and alarming things about OpenCode

#276

Earlier quoted context omitted.

Hey! I work on OpenCode, so thank you for this measured reply ;) Just wanted to add a few things: - We actually don't do tool-call pruning any more. But compaction is a necessary evil for the time being. There's only so much context window, and if you wish to keep working on the same task for a long time, the model needs to summarize its current progress so it can continue without hitting its token ceiling. - With V2…

Can you shed some light on what's the deal with the new interface (web/desktop)? I updated one of my opencode containers today and had to downgrade it back because: 1. Worktree/workspace support is gone altogether. No way for agent to work in parallel on different things safely except prompting it directly to create a worktree. 2. Seeing multiple sessions properly now requires opening tabs for those? 3. In general, s…

And it was chaotic like that a year ago when I tried it for a month. By itself it’s kind of competing with large players but unstable. And to get any useful work out of it you need additional stuff on top like ‘ohmyopencode’, which brings its own bucket of pain. I’m glad I’ve moved on.

Re: Annoying and alarming things about OpenCode

#277

Earlier quoted context omitted.

OpenCode requested to be removed from OpenRouter rankings: https://github.com/anomalyco/opencode/issues/11926#issuecomm...

Why is stated: > a lot of apps run 100% of traffic through openrouter while for us it's a small subset > but companies we were trying to work with used openrouter as a source of truth on popularity so they thought products that were much smaller were bigger than us

"Our ranking on some metric wasn't as high as we would have liked" seems like a bad reason to self-exclude.

Re: Annoying and alarming things about OpenCode

#279
post #204

Earlier quoted context omitted.

Can you shed some light on what's the deal with the new interface (web/desktop)? I updated one of my opencode containers today and had to downgrade it back because: 1. Worktree/workspace support is gone altogether. No way for agent to work in parallel on different things safely except prompting it directly to create a worktree. 2. Seeing multiple sessions properly now requires opening tabs for those? 3. In general, s…

Yeah it's a big change. Workspace support is being worked on, it was half-implemented before, so we are taking a proper pass at it now. For switching between sessions, can you tell me about your workflow from before? Because a tab can hold a session from any project. Are you saying that opening up a tab is too heavy of an action? GitHub issues though has been a problem from us, we deal with a ton of noise/spam.

I'm in the same boat as the parent comment. OpenCode has been my daily driver for a while (love the custom agents that I can easily create).

I'm working at the same time with 3-4 different projects and multiple tasks inside the same project.

Earlier with the sidebar I could easily go back to review previous chats, as I'm often working on multiple separate but somewhat connected tasks inside the same branch. Having just a tab for context is both visually limiting (personal preference probably).

The worktree support could use a configuration for setup, running and teardown (look at Jean for that - works pretty well) as a way to have more complex setup. In my case with Rails + Vue apps, each worktree would then have separate db, rails+vite ports, etc so that I can visually check multiple completed tasks in isolation.

Re: Annoying and alarming things about OpenCode

#280
post #258

Earlier quoted context omitted.

That's a pretty oddly narrow & specific definition of what LLM harnesses are for & it certainly doesn't match my experience. In fact I'm genuinely struggling to think of any scenario where an agent CLI would need to execute a build artifact. Sure many devs might ask it to for convenience of not having to spend 3 seconds typing & running the command themselves but I can't see it ever being explicitly necessary. I will…

> In fact I'm genuinely struggling to think of any scenario where an agent CLI would need to execute a build artifact. You should look into "testing". It's when you run the code you just wrote to make sure it works. For example, in LLM harnesses, it's used to ensure the produced code has the desired properties. It is the key element needed to allow agents to continue to work until they have succeeded. Anthropic's har…

You're definitely referring to fully autonomous harnesses as I suspected - these are generally quite well suited to VM deployment (quite possibly in the cloud) if you're concerned with sandboxing as they don't typically run into the same challenges as an interactive LLM UI.

For ad hoc task/investigation-oriented fully interactive agent UIs the requirements are more complex & there's all a lot of advantages to running locally on host, but e.g. for builds & testing in that context there's less of a requirement for the LLM to have full control over every execution given user presence. Basically the use-case being discussed here is LLMs-as-assistance/pair programmers/active digital colleagues, rather than fully automated autonomous harnesses (legit but separate use-case).

Post reply on HN