...did they just squash the repo to 1 commit for v2.0.4? Why? Yall should know that in this age of AI trust is the real currency... and nuking your history is one hell of a way to raise eyebrows.
> Enjoy bug-free, fast vibe-coded apps! Hints: ask it to write laws for whatever should never break, and to parallelize everything you want running fast. Bend is
young: if anything goes wrong, ask it to open an issue.
Emphasis mine. I don't want to be snarky but like... come on.
There is just a lot of private data and even proprietary code (like SupGen) in the commit story, so I just squashed it. I didn't think that'd be an issue? Why?
Erm, because it looks weird? Do you know any other language projects that squash their repos down to 1 commit? That's a destruction of trust, which is kinda important if you want people to build on your language.
Virtually everyone has AI slop in the commit history. No one's judging you for the commit history. Everyone's code smells, but the fact that you're ashamed/hiding it is... odd.
I for one don't find it strange at all that he squashed the commit history. I suspect many feel similarly. You've demonstrated that you're quite taken aback by it, but without explaining anything wrong with it. It is not a "destruction of trust".
I mean... If you wanna build your project on a language that has no auditable history, reproducible builds, artifacts/releases, force pushes and breaks literally EVERY fork/PR, has no way to build or even see v2.0.3, and doesn't have changelogs... then I guess that's cool. You must be a trusting person; I unfortunately am not like that.
To give you a concrete reason why you should care to preserve the exact history and why it’s a matter of trust: in your paper, you reported the pinned SHA head of the benchmarks you ran. When you destroy the history you make it hard for people to duplicate your benchmark results. Why report the SHA if you are going to destroy the history?
You don’t need to, but if you ever want to really optimise some code, understanding what it turns into on the target CPU really helps. Especially if you know the implications for any particular instruction (cost of memory access, potential branch prediction misses, etc)
The three* letter mnemonics are usually pretty easy to decode, even if you don’t know the architecture: anything beginning with ‘B’ will be branch, so ‘ble’ is branch if less than or equal. L and S based mnemonics are unusually Load and Store from and to memory. After that it’s understanding the stack and registers and you’re pretty much good to go.
Everything in assembly is loading something from memory into registers doing something basic with those registers, like add/divide/etc and then putting the result back into memory or using the result to make a decision to jump to processing instructions from another place in memory.
Most devs won’t ever need to know this stuff, but as someone who grew up with computers that could barely do anything without grinding to a halt (8bit computer, 2mhz processor, 32kb of RAM, 20kb of which is for the screen), knowing this stuff was essential; however I still find this stuff useful today, even with my C# work.
I am a bit of a performance tuning nerd though, so…
C# takes a lot of different roles. If all you're doing is higher level stuff, say you're only working on a local GUI app where you're waiting on the user 99% of the time, you probably don't need to understand it. But you can also treat C# as more of a low level systems language, maybe you need to optimise some number crunching in a server - and then, as with any systems language, being able to read it may help.
Kinda. I use the `disassemble` function in Common Lisp quite a bit, and I can't work backwards to explain what a function is doing based on the disassembly.
BUT what I can do is see which functions are being inlined, which values are in memory versus in registers, see if things are being boxed and unboxed a lot, see if SIMD is being used, etc.
And more importantly I can compare two versions of a function to see which one looks better by those criteria. It's not perfect, but IME it works really well for guiding optimization.
I should add that I read the book "Assembly Language: step-by-step" by Jeff Duntemann, and wrote a Tic-Tac-Toe game in assembly ages ago, so that helps a bit to understand the syntax.
What I wish more languages did was what the guile optimizer does. There is a source->source optimizer which does inlining, DCE, CSE and partial evaluation.
That is very handy, especially when writing macros. I only have to look at assembly when I want to know about optimizations that are not visible in the source->source optimizer.
If I ever want to know if something is reified (which I never do) I can always look at the ASM.
Not really, you only need to know you can get at it. One day you might be doing something like processing images or video and you are finding it slow and getting down to this level can be helpful. But it wouldn't necessarily be the first thing you'd look at.
Assembly is honestly very easy to learn, especially ARM assembly, for the basics (even if whole-program assembly is still difficult). In the worst case, you end up learning something interesting.
FWIW the .NET 10 release also had 2 occurrences of "real" in literally the first paragraph.
I, too, tire of the constant YOU WROTE THIS WITH LLMs outrage. An incredible engineer dumped an ENORMOUS amount of technical knowledge at your feet, and you're commenting on the smell? Is that all you have to contribute?
I saw this too on the Ryan Carniato/SolidJS 2.0 announcement post. A world-class engineer makes a great blog post, and all the comments can focus on are the LLM-smells. Oh well. Any reason not to learn, I guess.
My main issue with this timeline is that AI still has trouble transitioning to the real world. It predicts for 2029:
> There are swarms of insect-sized drones that can poison human infantry before they are even noticed; flocks of bird-sized drones to hunt the insects; new ICBM interceptors, and new, harder-to-intercept ICBMs. The rest of the world watches the buildup in horror, but it seems to have a momentum of its own.
Does anyone really predict insect drones _in production_ 3 years from now, to the degree that we need bird drones to hunt the insect drones? How the hell are these things powered?
Lean/math/millenienium prizes are "grindable" [0]. Wake me up when AI is making order-of-magnitude improvements in ungrindable real world tasks like batteries, hypersonic engine manufacturing, and stealth/silent motors that you can't hear.
> Does anyone really predict insect drones _in production_ 3 years from now
The industrial expansion timelinen as described in AI 2027 is way too compressed; I don't think any AI doomer believes that. The dynamics are plausible though, even without China stealing the weights.
Please elaborate: what dynamics? This is rather vague. My point is that AI can't grind real world physics/chemistry/engineering. What dynamics are in play here?
Right. I was referring to the basic set of conditions/steps necessary for the given scenario to develop.
Off the top of my head:
1. Loss of control in terms of our ability to assess alignment (no longer possible to determine whether an AI is truly aligned); this is happening already (doesn't imply that there are misaligned AIs right now, though)
2. Loss of control in terms of human comprehension of AI outputs - reaching a point where every action or result, including new discoveries, must itself be evaluated through other AIs; we may be close to this, as OpenAI is releasing an internal "AI researcher", yielding recursive AI development
3. Integration of AI into basic aspects and services of society
4. Extensive access by AI systems to physical tools and infrastructure
I think all those points will eventually materialize; sadly I don't see any reason why they won't.
This doesn't solve grinding? If it did, we'd see results by now (Published: 27 January 2026), and there's months of delay between submission and publication.
I'm willing to be wrong, but I'm just not seeing anything worth doomering over. There are multiple companies throwing AI at materials discovery; a research paper about a "data-driven framework" is about as unthreatening to my thesis as it gets. I'm willing to cede the point if say, Radical releases ~3 new materials that have commercial applicability and ~3x some useful metric e.g. tensile strength, but until then, to my amateur eye, it looks like AI+Real World is missing its ChatGPT moment.
What theft? Modern humans learned from the works of past humans, LLMs learned from the works of modern humans, other LLMs learned from those LLMs. Given that the methods by which Anthropic and OpenAI obtained training data remains a legal gray area, it's not so cut and dry to me that distillation is stealing. It's just a continuation of the long tradition of building knowledge on the knowledge of others.
I take it you didn't read AI 2027; it doesn't philosophize about cultural property - it simply narrates that a turning point is China acquiring the Agent's weights through hacking. "Stealing" in this context is simply the strictly legal term.
Gonna note that biology is even less grindable than ordinary chemistry/physics/engineering. We'll have advancements in other real-world fields before AI-powered bioengineering becomes A Thing.
I think the idea is that AI itself is going to massively accelerate its own development, and AI with real-world competence is coming very soon. At the rate things are going, it wouldn't suprise me at all if we had mass production of AI-designed systems in the next six months, actually.
> AI with real-world competence is coming very soon
Disagree, Moravec's Paradox remains undefeated. How long has Elon promised self-driving cars? Or how long have we been seeing humanoid-robot-walking demos? Laundry folding demos?
Let's assume that a magical AI powered robot hand lands tomorrow. How long do you think it'll take to ramp up assembly/production/distribution/sourcing/materials/QA for, say, a million of them? Never mind the legal/integration/maintenance time.
And even once those have landed, and assuming they are ALL put to work on iterating on research testing to build out super-high-capacity-drone-batteries, how long do you think it would take for that to evolve into killer-insect-drones? BTW you should know that even though high capacity silicon carbon batteries exist, they haven't supplanted other Li-ion batteries for a host of reasons. A million things stand between a technology working in a lab and surviving the real world.
And during this entire process, the (geo)political/social/legal process will be churning away, changing the societal landscape in which the killer-robots land. Not to mention that mechanistic interpretability is (likely) somewhat grindable. A lab just needs to dump a billion dollars of compute into it after it declares AGI.
I'm unconvinced we get killer insect drones before we crack mech-interp.
And even once we get killer insect drones, they need to somehow have no kill-switch and then literally exterminate everyone on the globe? Can you see why I have a problem with doomers predicting human extinction within the decade?
I'm putting words in your mouth and not replying to precisely what you said, just the general vibe. LMK if I overstepped.
1. What does the dark forest have to do with this? Because "the most senior OpenAI researchers" are shitposting on social media, we've an answer to the Fermi paradox???
I elaborated on my use of "dark forest" in another reply. We're headed for a dark forest--not amongst interstellar civilizations, but in intellectual work.
I agree that we have not solved the Fermi paradox; I disagree that comments highlighting immature behavior from people who wield enormous power in our world are unproductive.
This clarification substantially changes the flavor/nuance of your OP; may I suggest an edit (assuming the locktime hasn't passed)?
Separately, I disagree that intellectual work has ever been free of "dark forest"-style secrecy. Scientists everywhere have worried about being scooped; AI just magnifies that (as all tools have; e.g. Leeuwenhoek lenses).
And thirdly, if you want to make a stronger case for "I feel even less confident in them as a team to be shepherding this much capital and compute", you should give citations and arguments. From what I've seen, there's drama, it's much OpenAI trying to avoid scooping, and Tristan being stuck in a game of telephone, and Levent being incommunicado.
If you have a better analysis, you should say so instead of being vague.
I don't comment on HN much, and I don't really expect HN comments to hold to rigorous standards. This forum is more casual than other places on the internet where people expect heavy citations. I also wasn't expecting this to blow up, although it is interesting to see that a lot of people react to this announcement with a negative sentiment.
I appreciate your upholding of ideals, and since I respect that, I will honor with final replies:
1. Locktime has passed.
2. Yes, intellectual work has always had elements that incentivize secrecy. If you want to say we were already in a "dark forest", so be it. My suggestion is that the multiplier AI adds to the possibility you get scooped is a step-change, and therefore we now enter a new "dark forest".
3. This is a big thread, and the twitter antics are well-documented, so I would assume someone else has cited them. If not, I think most are aware at this point that the online antics of AI researchers, especially when announcing or citing mathematical advancse, have regularly been childish.
2. Fair, and further I would agree that OpenAI not knowing if prior user prompts were part of training data is concerning and will only lead to more secrecy.
and frankly, I'm unwilling to give Elon any more traffic to dig up drama that ultimately doesn't matter. I'm not seeing anything especially childish, but y'know... I'm not sure I care.
the projectnash link claims it's mathematically valid, the noahpinion link says that it's invalid and has a marvellous proof that the non-walled section is too small to contain.
Ah derp; that's what I get for moving too fast. Genuine thanks for calling me out on my bullshit. (and this is also why I prefer auditable citations instead of casual "my reading of twitter is...")
I retract the projectnash citation; I grabbed it from the Cool World's youtube description, thinking it was a blog version of the video. It was not. I suggest watching the video instead.
Sebastian Raschka, author of Build a Reasoning Model (From Scratch), commented on this:
> Reusing layers does not by itself suppress visible chain of thought. It adds computation in hidden states before the next token is emitted, just as ordinary transformer layers do. But based on the information we have, the only plausible interpretation here is that if a model uses more of these recurrent passes, it may need to generate fewer intermediate reasoning tokens.
Erm, that's to be expected. GPUs ain't free. Anyone can make a free account and cost them potentially infinite compute, so a phone number is a way to lock that down. Might not be the "best" way, but hey: it's free.
You're missing the pattern of behavior from Anthropic. They constantly market like this: the session link, the Co-Authored by Claude, the unwillingness to adopt AGENTS.md. Hell, on workflows on 2.1.246 Claude's been ignoring the "attribution" block in settings.json and gone right back to coauthoring every commit.
What's the odds on them fixing that bug anytime soon.
...did they just squash the repo to 1 commit for v2.0.4? Why? Yall should know that in this age of AI trust is the real currency... and nuking your history is one hell of a way to raise eyebrows.
> Enjoy bug-free, fast vibe-coded apps! Hints: ask it to write laws for whatever should never break, and to parallelize everything you want running fast. Bend is young: if anything goes wrong, ask it to open an issue.
Emphasis mine. I don't want to be snarky but like... come on.
reply