There’s a _very_ good reason. Humans have a much richer mental mental model of the codebase, design decisions, external factors, etc.
Of course Humans can make errors when translating that to English. But if you’ve read any amount of Claudish it should be obvious that interpolating the code to documentation with an LLM typically produces a significantly worse result in almost every way. Except for superficially “sounding” correct.
That’s just not true especially when the author designed the language with the LLM like he says in the end (the AI is very good at forcing you to be specific and make decisions on ambiguous terms): all decisions can be included in the repository in a way the computer can follow and understand, which is a pattern called specification graphs. You can just document things in the docs as well if you want a more basic method.
If you are claiming this language is worse in every way than others that were made by humans alone, could you be specific?? What are the bad things you’ve found? What part of the docs are incorrect? Or are you just commenting without having looked at any of that?
Above all, I think I like human docs because then I not only know someone has a deep understanding of it, but also that someone can actually be queried about it. With Claude, there is always the accountability problem. If something seems off, do I even have someone other than Claude that understand it all and who is accountable ?
That is not necessarily true if the codebase is written by AI unless the human chose to be involved. That was also not necessarily true before AI either. Human skill level is wildly variable
You’re engaging in bad faith, and parroting the same false equivalence between security and user freedom that Apple uses to keep a chokehold on their software distribution monopoly.
Having some way to unlock an iPhone doesn’t at all imply it must be done in a way that reduces security, or trusts the average user with upholding it.
Use your imagination. They could require you to have an apple developer account. Or visit an apple store. Or even limit it to a special developer unlocked iPhone flavor.
Uhh, what? Clearly nobody is arguing that "arbitrary remote execution is good." Apple could easily satisfy everyone by simply allowing users to unlock their own bootloader.
How would that help anyone? The unlocked bootloader on the Apple Silicon Macbooks still hasn’t resulted in a truly viable alternative to macOS. The iPhone is much, much harder. And why would carriers trust the result?
You’re missing the point. Hackers (in the tinkerer sense) just want to program their own devices, with full access to the capabilities of the underlying hardware. Apple could obviously allow that if they wanted to, in a convenient way that doesn’t increase the attack surface for malware.
Consider that their point is not just about this specific use case.
Apple spends a huge amount of effort maintaining two different operating systems for what is pretty much the same machine under the hood. Don’t be naive and try to rationalize their bad behavior. They clearly just want to maintain their lucrative software distribution monopoly.
And this is of the typical quality of what you’d get.
80% incoherent narration of random numbers, all down to the 1’s place so it looks super duper precise and impressive if you squint and don’t think too hard, like the “author” seems to have done.
When is the last time you used a frontier model? Any chance you work someplace that forces you to use last year's model (or any American open weight model)?
I use them every day, in systems programming. They produce a solution, but it’s often several orders of magnitude away from an optimal one in various dimensions. That’s still quite useful, but for some problems that doesn’t cut it.
To reach a more optimal solution, significant human steering is reqiured for every tiny decision. It’s the same as how early models needed hand holding on the basics, playing out again in the finer details. Human experts need to inject “eureka moments” from the outside.
And no feedback loop that I’ve tried has been able to conjure an understanding of these finer details that, as far as I can tell, just aren’t represented in the weights.
Modeling the basics of software engineering was easy, since things like writing code that passes some tests is easy to RL. But for anything not easily RL-able, we’ve basically ran out of human generated tokens to distill from.
Without some breakthrough in generalization, I remain unconvinced that we’ll be able to model the finer details of software engineering by looping the existing training corpus back into itself. Garbage in, garbage out.
reply