achompas

Joined 16 years ago

Karma
3,838
Submissions
1,321
Member since
Aug 21
I do things with AI, machine learning and software.

Reach me at achompas+hn [at] Google's email [dot] com.

http://acompa.net http://github.com/acompa

[ my public key: https://keybase.io/achompas; my proof: https://keybase.io/achompas/sigs/KdHH4LRgVwgb9n-pCR99fnRFnF9gH-kmTCR0P8_jFRg ]

View on Hacker News

Recent submissions

Comment · 2 months ago
One thing I’m observing in these comments is a willingness of folks to project their own predictions onto Ed’s statements when validating their plausibility. Eg. “I think he’s wrong about the timing but I do expect AI companies to go to zero.”

You can do that, but then you’re no longer discussing his predictions. You’re discussing your predictions, and your own positioning.

Those differ from Dan’s essay, which engages with the literal text of Ed’s numerous predictions during 2024 and 2025 which are demonstrably invalidated by their measurable outcomes.

Comment · 2 months ago
I actually think you’ve got it backwards

I think one of Zitron’s problems is that his moral righteousness has blinded him to how embarrassingly incorrect he is about the AI space.

It’s similarly hubristic with the benefit of shielding from his adversarial framing.

Comment · 2 months ago
But I think anyone who evaluates their claims understands that they’re talking their own books.

Zitron’s problems are more subtle. He benefits financially from his own claims, while also touting his impartiality and capacity for objective thought.

Comment · 2 months ago
But we’re talking about Gemini, which is one of Dan’s point: the surface area is so large that any prediction is almost laughable. Zitron’s prediction here is laughable in fact because he claims both (1) Pichai is jamming AI everywhere and (2) the 500M number is impossible. Those statements are immediately contradictory to anyone who understands the scale of Google’s products.
Comment · 2 months ago
A prediction definitionally includes an outcome, and it _can_ include a timeline. (if you’re serious about your forecasting, then you generally include a timeline; forecasting is non-actionable if it does not include a timeline).

You might choose a different timeline for Ed’s outcomes. Okay: those are now your predictions, not his.

Zitron has done us the favor of including timelines with his predictions, so that Dan can invalidate almost all of them.

Comment · 7 months ago
The onus isn’t on me. It’s on anyone contradicting findings by most benchmarks, because most of them show a clear advantage for Opus and GPT over OSS models.
Comment · 7 months ago
The problem isn’t the SDK but the API usage.

Users will say this-or-that about choice etc etc. It’s about subsidized tokens. Otherwise th users (and OpenCode) would have stopped pushing the workarounds months ago.

Comment · 7 months ago
I’m sorry but you’re demonstrably incorrect.

Listen, I want more open weight models in the world. They create entrepreneurial opportunities and support use cases which the foundation labs don’t want to support.

But open weight models are consistently three to six months behind on performance compared to closed models, as confirmed by both benchmarks and personal use. They’re closer on coding and much further away on non-coding tasks.

There are theories as to why these models lag, which I won’t get into. But anyone claiming open-weight models are close to closed-weight models is ignoring significant evidence to the contrary.

Comment · 7 months ago
This is both true and immaterial to Microsoft’s net profits.
Comment · 7 months ago
Yep, well said and great, sharp explanation.

I think we can attribute a bunch of consternation here to drift between assumed and actual licensing terms.

The actual licensing terms for Claude Code expressly prohibit use of the product outside of the Claude Code harness. If you want Opus outside of CC, the API is available for your use anytime.

Some percentage of the community seems to assume their Claude Code subscription licenses allow free usage of CC across any product surface - including competing products like OpenCode. While this is a great way to save on API costs, the assumption is incorrect. In fact, it is *so* incorrect that Anthropic has encoded their licensing terms into their Terms of Service, and a result can take legal action against any violating parties.

We can have separate discussions about Anthropic’s use of the Common Crawl in pre-training, or whether foundation labs adhere to robots.txt conventions. But those don’t directly impact Anthropic’s right to bring litigation.

——

Outside of that I think angry users have their own stated preferences v revealed preferences here. They claim they want Opus on their terms, and Anthropic’s actions infringe on their user rights.

Angry folks: Opus is right there! You just need an API key! The reality is you want Opus in your devtools of choice at discounted rates. You could at least be honest about your consternation

Comment · 7 months ago
Yes, it is true that companies often litigate against customers who violate their Terms of Service. The TOS is put into place to protect the company’s interests from user abuse.

Paying customers of Claude Code don’t receive a free-use license for any desired application. They’re paying to use Claude Code. Anthropic can take steps to litigate usage outside of those terms, even if customers find that fact really annoying.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton