robjellinghaus

Not Microsoft.

In my experience with Claude Code and Sonnet, it is absolutely possible to have architectural and design-oriented conversations about the work, at an entirely different and higher level than using a (formerly) high-level programming language. I have been able to learn new systems and frameworks far faster with Claude than with any previous system I have used. It definitely does require close attention to detect mistakes it does not realize it is making, but that is where the skill comes in. I find it being right 80% of the time and wrong 20% of the time to be a hugely acceptable tradeoff, when it allows me to go radically faster because it can do that 80% much quicker than I could. Especially when it comes to learning new code bases and exploring new repos I have cloned -- it can read code superhumanly quickly and explain it to me in depth.

It is certainly a hugely different style of interaction, but it helps to think of it as a conversation, or more precisely, a series of individual small targeted specific conversations, each aimed at researching a specific issue or solving a specific problem.

Hindenburg indeed killed hydrogen blimps. Of everything else on your list, the disaster was in the minority. The space shuttle was the most lethal other item -- there are lots of cruise ships, oil rigs, nuke plants, and jet planes that have not blown up.

So what analogy with AI are you trying to make? The straightforward one would be that there will be some toxic and dangerous LLMs (cough Grok cough), but that there will be many others that do their jobs as designed, and that LLMs in general will be a common technology going forward.

I felt the same way until I tried Claude Code. Moving from an autocomplete-based workflow to a conversation-based workflow changed everything. I find traditional Copilot useless by comparison.

No worries, I didn't interpret your comment as belittlement. I agree the project was over-ambitious and overly complex, but it was also visionary and influential.

I was there (you'll find my name in the Wired article), and on the whole I would agree that Xanadu's reach far exceeded its grasp. Compared to the simplicity of the http protocol, Xanadu's complexity was high enough and its performance low enough that there was little opportunity for a genuine competition.

But I will say that Xanadu was conceptually not centralized; the peer-to-peer exchange of arbitrary information at scale was definitely part of the architecture. However, the major and systemic performance problems entirely prevented any scaling up of the system, which effectively means the distributed architecture was never proven.

I agree to a certain extent with the Chandler analogy, insofar as there was a lot of "architecture astronautics" that added complexity to the system beyond the ability of the team to manage -- especially given the limitations of early 1990s development machines.

One could refer to the article itself for Walker's own view of the sad outcome:

'Rather than push their product into the marketplace quickly, where it could compete, adapt, or die, the Xanadu programmers intended to produce their revolution ab initio.

'“When this process fails,” wrote Walker in his collection of documents from and about Autodesk, “and it always does, that doesn’t seem to weaken the belief in a design process which, in reality, is as bogus as astrology. It’s always a bad manager, problems with tools, etc.—precisely the unpredictable factors which make a priori design impossible in the first place.”'

He wasn't wrong. Xanadu tried to leap fully formed into the world as a megalithic architecture capable of arbitrarily large data structures supporting arbitrarily small comparisons and transclusions, and it couldn't compete with HTTP's fully open specification and implementations, low barrier to entry, and extreme simplicity.