It's generally and simply an encoding of what amounts to binary machine code which you translate via assembly code acting as a deterministic compiler from assembly to machine code if you are doing it manually.
LLMs aren't a deterministic process and human languages aren't as clear as machine code and assembly.
The CDC recommends against heating milk in a microwave[0] whether it's human milk or formula meant for a baby due to the creation of "hot spots" and also the potential destruction of nutrients.
"Flappy Bengt"[0] is broken at least on my browser it's not playable as a human (nor LLM) due to requiring too large of an APM for anything but TASbot or a special purpose mechanical robot to play.
Which ones are you claiming have already been achieved?
My understanding of the current scorecard is that he's still technically correct, though I agree with you there is velocity heading towards some of these things being proven wrong by 2029.
For example, in the recent thread about LLMs and solving an Erdos problem I remember reading in the comments that it was confirmed there were multiple LLMs involved as well as an expert mathematician who was deciding what context to shuttle between them and helping formulate things.
Similarly, I've not yet heard of any non-expert Software Engineers creating 10,000+ lines of non-glue code that is bug-free. Even expert Engineers at Cloud Flare failed to create a bug-free OAuth library with Claude at the helm because some things are just extremely difficult to create without bugs even with experts in the loop.
This discussion and distinction used to be well known, but I'm happy to help some people become "one of today's lucky 10,000" as quoted from https://xkcd.com/1053/ because it is indeed much more interesting than the alternative approach.
> Meanwhile, my cofounder is rewriting code we spent millions of salary on in the past by himself in a few weeks.
Code is not an asset it's a liability, and code that no one has reviewed is even more of a liability.
However, in the end, execution is all that matters so if you and your cofounder are able to execute successfully with mountains of generated code then it doesn't matter what assets and liabilities you hold in the short term.
The long term is a lot harder to predict in any case.
Interesting and thanks for clarifying that aspect. I have a few more questions if you would be able to answer any of them at any level of detail I would appreciate it.
How much would you be willing to pay to continue using Claude on a monthly basis before you stopped?
Do you currently maintain the new (as of two weeks ago) cash reserve to ensure it continues working when limits are reached and how much do you reserve for said reserve?
Finally, do you send your customer's code or data directly to Claude or do you use it indirectly on generic stuff and then manually specialize the outputs?
It sounds like you use your personal Claude Code subscription for work of your employer, but that is not something I would ever consider doing personally so I imagine I must be mistaken.
Can you elaborate slightly on what you pay for personally and what your employer pays for with regards to using LLMs for Enterprise ERP?
Thank you for the explanation, but I did fully understand that is what you were saying.
What I don't fully understand is how you can characterize that as "not limited" with a straight face; then again, I can't see your face so maybe you weren't straight faced as you wrote it in the first place.
Hopefully you could see my well meaning smile with the "absolutely right" opening, but apparently that's no longer common so I can understand your confusion as https://absolutelyright.lol/ indicates Opus 4.5 has had it RLHF'd away.
> The $200/month plan doesn't have limits either... once you've expended your rate limited token allowance... pay for the extra tokens out of an additional cash reserve you've set up
You're absolutely right! Limited token allowance for $200/month is actually unlimited tokens when paying for extra from a cash reserve which is also unlimited, of course.
LLMs aren't calculators; for example, your calculator always gives you the same outputs given the same inputs.
Long division is a pretty simple algorithm that you can easily and quickly relearn if needed even your LLM of choice can likely explain that to you given there's plenty of writing about it in books and on the internet.
It seems we're still collectively trying to figure out the boundaries of "delegation" versus "abstraction" which I personally don't think are the same thing, though they are certainly related and if you squint a bit you can easily argue for one or the other in many situations.
> We've gotten claude code to handle 300k LOC Rust codebases, ship a week's worth of work in a day, and maintain code quality that passes expert review.
This seems more like delegation just like if one delegated a coding task to another engineer and reviewed it.
> That in two years, you'll be opening python files in your IDE with about the same frequency that, today, you might open up a hex editor to read assembly (which, for most of us, is never).
This seems more like abstraction just like if one considers Python a sort of higher level layer above C and C a higher level layer above Assembly, except now the language is English.
There's a section on "why not printf" which is Standard C, but I can't find any section on "why not std::format"[1] which is Standard C++ since C++20 and works on all major compilers today in 2025.
They do mention "std::print"[2] from C++23 (which uses std::format) and compile times, but, they don't touch on "std::format" at all.
> Why though?
> Using zstd in Rust is already supported via the zstd crate, so why bother with a whole new implementation?
Separately, I'd say their end goal seems to be replacing the C library dependency in Rust's zstd-rs:
> We have our own fork of the zstd that uses libzstd-rs-sys instead of the C library. We'd like to upstream this at some point.