ameliaquining

I don't understand which part of my comment, if any, you're disagreeing with.

I wonder if they'll combine this with the currently-in-closed-beta Sign In with ChatGPT to let people make sites that can make inference calls that get charged to the user's ChatGPT subscription rather than the site owner's API billing account, like Claude Artifacts already lets you do. That would synergize well with ChatGPT Sites being generally more robust and feature-complete than Claude Artifacts.

The argument there wasn't that everyone everywhere would use individually customized software* instead of packaged SaaS; it was that, because AI greatly reduces the cost of building an internal app or service, it improves enterprises' BATNA when dealing with SaaS vendors, which means surplus will shift from producers to consumers. It's not obvious to me that that's not happening, since it may have been masked by a general increase in automation since AI also synergizes significantly with SaaS. (The Stripe Economics post gets into this a little, though it's mostly less curious than I'd like about why the "SaaSpocalypse" didn't materialize. Of course, Stripe has an economic interest here.)

* Some people do think this (e.g., https://sockpuppet.org/blog/2026/09/25/what-even-is-an-os-no...), but I remain somewhat skeptical that this'll be true for the most economically significant applications. This is not because I'm an AI capabilities skeptic (I'm not, I'm more of a doomer), but because even in a world where AI is designing and implementing all the software, there are probably still significant benefits to standardization. I see it as sort of analogous to compilers; we might get a world where compilers are both used and maintained almost exclusively by LLMs, but we probably won't get one where compilers stop being used or maintained at all because LLMs write everything in assembly.

Yep. https://help.openai.com/en/articles/20001339-creating-and-us...

Why would that imply that you wouldn't use a lot of agents?

Presumably the Kafka-compatible API that they say is in the works will address this?

Firecracker has existing solutions to this, which I assume they're using: https://github.com/firecracker-microvm/firecracker/blob/main...

You've misunderstood; the quoted line from the post is most likely subtweeting Steve Yegge (in particular https://steve-yegge.medium.com/why-i-left-google-to-join-gra...).

See https://news.ycombinator.com/item?id=49778162.

My comment was aimed at the particular critique I was replying to, namely, that using XML for ordinary structured data is bad because XML is a markup language. I am not defending SAML more broadly or claiming that none of its mistakes were foreseeable, and particularly am not defending the idea of signing a DOM tree instead of a sequence of bytes. (Though the latter mistake is in principle orthogonal to XML vs. JSON; I confess to not really understanding why they're so correlated.)

As the article points out, it's not really fair to criticize SAML for not using JSON, given that JSON barely existed at the time.

If you needed a serialized representation of structured data, I think it made engineering sense to use XML even if it was more featureful than you needed. The alternatives were ASN.1 or rolling your own format from scratch. It's not at all obvious that those are better.

(You could argue in favor of rolling your own format on the grounds that it wouldn't be vulnerable to XML-specific security problems, but I don't think those problems were fully appreciated at the time. If they had been, probably people would have come up with some kind of quasi-standardizable secure XML variant that just disables the specific features that cause those problems.)

I agree that XML (even without the security-relevant misfeatures) is worse than JSON or other non-markup-language serialization formats for the majority of use cases that don't need a markup language, but this is not a big problem, it's basically just syntax.

Freestanding environments specifically don't have to do this, they get a carve-out. (I dunno if this applies elsewhere though.)

I'm curious, what exactly do you imagine going wrong here?

I recommend this explanation of why UB is good and necessary (but C and C++ are doing it wrong, defining some things as UB that really shouldn't be): https://www.ralfj.de/blog/2021/11/18/ub-good-idea.html

The article, most unfortunately, doesn't explain why anyone would want infinite loops to be UB in the first place. I found this explanation: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1528.htm

LLM style is not literally anticorrelated with quality. There are some things that they tend to do poorly, but you're not going to do those because you're writing the text yourself. If you have it judge your writing, and are careful to avoid the failure modes that the post goes into, it can be helpful by serving as a competent editor that doesn't share your blind spots.

There's no way in hell that wasn't a deliberate joke.

Can you explain in what way you think they could possibly have been covertly involved?

Third-party cybersecurity evaluations. See, e.g., https://www.irregular.com/research/assessing-gpt-5.6-sol, which was published around the same time.

We know for certain. The involvement of Irregular in the other cases was never a secret, they were quite open about what they were working on and the results of the evaluations were being published on their website.

I might try Searchlight Cyber first (it's their service doing this, presumably without their knowledge), and then if that doesn't work go to AWS.

Zig doesn't currently have async/await in the sense that this post is about (i.e., async/await based on stackless coroutines). It previously had this, but it was removed last year (https://ziglang.org/download/0.15.1/release-notes.html#async...).

The 0.16 release earlier this year introduced a much-heralded userland API (https://ziglang.org/documentation/master/std/#std.Io) that can be used to implement various asynchrony and concurrency patterns, including green threads, but it can't do stackless coroutines because support for those has to be baked into the compiler.

There is currently an open proposal to bring back stackless coroutines without dedicated syntax (instead offering low-level bring-your-own-buffer APIs for interacting with suspended coroutines), which could be combined with the aforementioned userland API to produce something more like how async/await works in other languages (https://github.com/ziglang/zig/issues/23446).

Well, they could ask frontier labs to stop publishing math results. I find it telling that they stop short of explicitly doing this.

Scott Aaronson wrote a good post last week on how Hofstadter's theories of intelligence have held up: https://scottaaronson.blog/?p=10046

(The post primarily emphasizes self-referentiality rather than analogy, but I suspect similar things could be said about analogy.)

See https://news.ycombinator.com/item?id=49614484.

I feel like "large language model" should be on these graphs. For better or for worse, it's the answer to these questions for an increasing number of people.

Certainly, but the key word there is "somewhat". Progress is now happening so incredibly fast that I no longer know what to consider implausible.

Elaborate?

If you're alleging that they don't actually have a highly capable model and the work they're attributing to it was actually plagiarized from human mathematicians, well, that would be big if true, but I'd be inclined to take the other side of that bet. With most previous splashy AI results, others have subsequently used the model to do other things around the same difficulty level. Also, it would still be necessary to explain why all these famous open problems are suddenly falling like dominoes, if it's not AI solving them.

If you're saying that the question of whether they actually have a highly capable model is less important than the question of whether there's a plagiarism scandal, I continue to disagree.

There were also some people talking about the Hodge conjecture, because it has some similarities to some LLM-assisted breakthroughs that were considered impressive in the distant past of [checks notes] July 2026. See, e.g., https://xenaproject.wordpress.com/2026/07/20/human-mathemati...