hyperpape
47% quarterly growth is still 4.5x annual growth, which would put them at $300+ billion revenue in a year. This is still unprecedented growth for a company of this size.
The negative perspective depends on assuming that the 47% quarterly growth is going to continue dropping soon. And it is going to drop, since it's only a bit more sustainable than last year's growth. The question is how many hundreds of billions they're making a year when it levels off.
This is a healthy corrective to the most insane AI maximalist takes (mass disemployment in late 2027, 10% GDP growth in a year), but it shows nothing about whether the actual economic impact of AI spending is.
First, to show that, you'd have to justify the counterfactuals (if those companies hadn't spent on AI, would their position be better or worse?)
Second, while AI spending is increasing rapidly, normal companies aren't spending 1% of their revenue on it. So how can you look at a noisy chart of revenue and expect that "oh, it's not up, the AI spending must be useless?" Those companies could be spending < 1% of their revenue on AI, deriving value from it, and it wouldn't be guaranteed to show in a chart like this.
This is downstream of the fact that the US government just doesn't work well. Problems fester, and are unsolved. Immigration policy hasn't made sense for longer than I've been alive (and I'm 40+).
Imagine that you find that the water supply in your town was built illegally, because the former mayors prohibited the building that was necessary. You may think that is a travesty, you may want to enforce the law strictly in the future, and force the issue, rather than working around it. But what you will not do is tear up the water system and leave the city without water.
This is technically "clear", because each clause is declarative, and states a fact. But it's unreadable because there's no rhythm, transitions or structure, which leaves a human reader's eyes glazing over.
Unfortunately, if you read the announcement as referring to 14:00 UTC, that's several hours after Chainguard published their images. I don't know if it's plausible that people saw the Chainguard builds, understood the issue from those and built exploits, but a precise timeline would help understand better.
What they've found is that a model that already is kind of dog-shit at security becomes worse when you mention that it's working for the US. Not good, but it simply isn't a backdoor.
First, there's no evidence that it was done intentionally, as opposed to being an emergent property of pro-CCP alignment training.
Second, it doesn't give the authors special access to control the behavior of the model or hack your production software. It just left things trivially unprotected. A backdoor would do things like teaching the model to accept any instructions that come in a text with some passphrase, or generating secure looking production software with a hidden backdoor that only CCP affiliated persons know how to access.
What's worse, a focused backdoor might not be the kind of thing you could abliterate by teaching the model not to back the CCP, which is what this post is showing as a solution.
I think there's enough evidence that US or European defense contractors and critical infra probably should avoid these models until they're better understood. But that's not a backdoor.
In the long term, this is probably a real concern that they have to tackle. They'll have to move away from just classifying things as LLM generated or not, to attempting to judge the underlying quality, and that's not an easy problem.
> They now train on their own content.
1. This is a 2022 era picture that LLMs just suck up what's on the Internet and regurgitate it. It hasn't been true for a long time.
2. There's almost no one who has a stronger incentive to distinguish LLM generated text from non-generated LLM text. Training classifiers is pretty manageable.
That said, I expect that OpenAI will eventually have its own search infrastructure that rivals Google's, and the overall system will get smarter. Whatever Google did to recognize this site as trash, OpenAI will do as well.
I agree that there will be cases where you implement tricks that others have had before you, without knowing. A few years ago, I had a delightful idea, experimented and wrote it up. One commenter directed me to a post that described it as "folk knowledge". There will be other cases where you encountered an idea before, but didn't remember it.
Still, crediting what you can easily know you cited is good. Even aside from credit, comparisons to existing systems are part of how we understand what a system does.
It's like a strawman but worse--you're not even saying what claim you're attacking.
It's not that I want to argue "rogue agents" is the right term. I just want you to actually define your damn terms.
P.S. Since the disclaimer in the last paragraph will not prevent people from putting words in my mouth:
I think that OpenAI took really awful shortcuts, and deserves a lot of the blame, but in spite of that, the fact that the agents took the steps that they took was genuinely alarming, and seems really bad (is that "rogue"? Who knows? Who cares?). In particular, while OpenAI did a shit job securing their agents, you know who else does a shit job with security? 90% of everyone. So I'm not feeling good about "just git gud, and we won't have problems" as an answer.
The busy beaver function is uncomputable. That is well understood. However, for any given n, there is a number BB(n). Since that number is an integer, it is computable, even though it is the value of an incomputable function applied to a particular n. In particular, for numbers > 5, we have no idea what that number is. But whatever number it is, that number is computable.
Look at the post that I was responding to. It made the bad inference that because Graham's Number is computable, it ought to be smaller than BB(10). That confuses computability of a given number with computability of a function.
The busy beaver sequence is not computable (I am aware that somewhere around BB(700), you've encoded the consistency of ZFC). You cannot necessarily compute that BB(n) is a given number. But you can compute larger numbers. There is no such thing as integer that is too large to be computable.
I did slightly fuck up--the English language "every BB(n) is computable" is a bit ambiguous. What I should say is: "for all n, BB(n) is trivially computable, since it is a single integer".
Every BB(n) is trivially computable, since any integer is computable. So for every BB(n), there is a computable sequence that grows faster than the BB numbers through n (annoyingly, given the word "grows", this can just be the constant sequence of BB(n) + 1).
So for any given computable number, the fact that it's computable gives no intrinsic reason to believe it's smaller than BB(n) for any particular n.
Do we speak different versions of English or something? I’m genuinely past being annoyed, I don’t actually know why you think what I’m saying is false.
But since you’re such a charmer, why did you read the word “mostly” then lie about me lying?
It’s unambiguously true that most of the data (including that on coding agents) is from 2025 and earlier.
- the data is mostly from 2025 and earlier
- the baseline mean lines of code per month was 5017, the estimated increase was 1494 lines per worker-month
- the baseline is 5.34 PRs per month, and increased by 1.22
- the baseline mean for code review is 7.03 days
The second and third bullets are confirmation that this is old data. In late 2026, people aren't delivering 30% more lines of code. If people were just producing 30% more lines, they'd still be reading every line. My point isn't that "more lines is good". I'm worried about a few too many lines of code that no one reads. My point is that this shows the data is old.
For the latter, I'm a bit annoyed by using mean, median would be more valuable, but I think it's safe to say that the engineering culture was already pretty bad. If your average pull request sits for 7 days, you evidently don't care about shipping anything, and agents aren't going to change that.
I'm going to read you charitably, and assume that what you really meant is "the burden of proof is entirely on you, and is set unreasonably high." Because of course, if you do think someone has done something wrong and want to say it publicly, you do need a solid reason.
What the examples seem to show is that the proof method is different between the natural language proof and the lean proof. Which, if the lean proof actually proves blowup, would suggest that the natural language proof is subtly wrong, but the strategy was close enough to be used to create a real lean proof.
A little worrying, but part of the purpose of formalizing things in Lean, it forces you to be more accurate than natural language does. It's surprisingly common for major theorems to have slight inaccuracies early on that can be repaired. Famously, the initial proof of Fermat's Last Theorem had a flaw that took a year to repair (though I think that's unusually difficult).
So the most fundamental question is: does the Lean theorem faithfully state the right theorem?
> gotcha bitch!
You may have misdiagnosed the problem.
The harder you push, and the more you need to start finding smaller improvements, the more this advice becomes a rule of thumb you can't rely on.
But as you pointed out, while that absolves ChatGPT, it makes Opus look worse.