pzuraq

Yes, this is the thinking behind using the term. It’s also different from incoherence because decoherent systems can still make sense in some ways. They still work, they can still be iterated upon.

They are decoherent because the work to change them is extremely difficult. This is a different, and much more costly, state to exist within.

Spoiler alert: Laziness is one of the most important factors for driving the creation of coherence. We have a deep biological desire to do things faster/better/lazier. Will be digging into this more in Open Capital.

Not to mention, software is a fundamentally collaborative process. We build it better by working together to build coherence, and we are capable of doing that over very long periods of time. Agents do not appear to be (the hugging face incident is not IMO an example of building coherence, hacking is about exploiting decoherence/bugs, not the same thing)

LLMs can be extremely dangerous without being capable of achieving super intelligence in a vacuum.

If I hooked up a random number generator such that, if it landed on a specific number between 1 and a trillion, it would launch a nuke, that would be incredibly dumb and incredibly dangerous.

Even more reason to slow down the slop code and stop attempting to achieve super intelligence when it appears that it will not be possible with this technology. The process is dangerous, and the doom race/prisoner’s dilemma logic is faulty.

Yes, this is also my belief. All of this is contingent on just trying to scale the current tech. If we make major breakthroughs on other forms of AI, then the analysis could change.

They can over time, but A) they can only improve to the human ceiling because they only have the set of apps that we have already created as inputs and B) creating new apps requires testing in the real world, which requires either humans or robots to go out and use the apps to do things.

You could try to make plausible apps that you never use, but then you run the risk of drifting. And without new apps to build on, you will be stuck on an artificial maximum that works well for the apps of today, but may not for the apps of tomorrow.

Imagine if AI had never seen a GUI app, if they had existed in the era of the CLI as the primary way of interacting with the server. How would they have known that Futures would be so important? They could try to guess, but most people thought Engelbart was crazy before he demoed his ideas. Hard to imagine an LLM making progress in a vacuum.

Guilty as charged, I did use LLMs to bootstrap the design and much of the site, though I took it in my own direction after the initial pass. But it is generic enough, and I just needed something a little fresher and quick.

At some point I’m going to get the older articles back up, but most of them are very specific to a time that just doesn’t have relevance anymore, even to the Ember.js community. Didn’t want to distract from the newer content.

And at some point I’ll make a new account here too… web handle changes are always a pain

I would argue that yes, it absolutely can and does. Take biological decoherence on Earth, something I thought about discussing but ultimately cut as I researched more because I did feel out of my depth (and the essay was already long).

Genes are a highly decoherent but relatively stable system. Billions of years to harden, real world constraints to guide them, and good general patterns. Sometimes, the structures that exist within them are quite adaptable and generalized (e.g. the brain), but other times they are very flimsy and fail badly to adapt (see: mass extinction events). Either way, genes themselves are not fast to adapt, only the systems built with genes.

And, importantly, they are _entirely_ dependent on the context of life on Earth, the specific evolutionary paths that we landed on. Silicon based life, if it exists, could potentially have _entirely_ different patterns and strategies that none of the patterns on Earth would be able to address.

On the flip side, you do see _some_ general trends and patterns over time (convergent evolution). The constraints of physics _do_ shape the possibility space, but what works well is contingent on every other aspect of the environment as well.

Same applies to coherence generally. It's always contingent on context.

I would argue that there isn't an underlying general pattern of coherence, at least not one that is measurable in a simple way. The simulation in the article simplifies representations of the world into nodes and edges, but reality is often much more nuanced and complex.

I think the section on Futures really points out how difficult problems can be. They were first introduced in the 1970s, they were implemented in the 80s. They didn't become super relevant until the late 80s/early 90s, and even then it took another 20 years of data gathering, experimentation, and distillation across the entire academic domain AND the industry and all of its real world use cases to really nail them down.

This is basically similar to how prices act as a decent signal of value to a point, but break down because they destroy information about what was actually valuable by simplifying it. The same would be true of an abstract measurement of "complexity" when applied universally to all problems, unfortunately.

The issue is that you are always optimizing for the current state of the systems, not the _next_ state of the systems, within the bubble. You may be able to increase coherence for the current known set of problems, but you cannot know if that coherence will hold for the _next_ problem.

This is essentially the same issue as the halting problem. You don't know what you don't know, and you don't know what happens if you go just one more loop or explore just a little more about the universe, if all of the previous structures hold. Black swans happen all the time, and adaptability is about working within that matrix of data, absorbing it, and reconfiguring around it.

That's a good point, definitely not what I meant there. I think in my first draft I actually just said "JavaScript widgets" and when I updated it to jQuery I didn't update the rest of the paragraph. Thanks for pointing that out!

By "full-stack" here I mean frameworks which handle both the frontend and backend simultaneously, in a seamless way. The closest thing framework that I remember from the MVC/P era which attempted this was Meteor.js, but it was really horrendous to use in my experience.

Otherwise, it was very common practice to serve an Ember or Angular app as static files Nginx or directly on a CDN. Wrapping them in a server-side framework was always a bespoke process which required you to effectively maintain two frameworks, and stitch them together yourself (unless you count Ember + Rails in the early days, but even that is a stretch IMO). When SSR was introduced in any framework, it was usually not used to its full potential to be able to accomplish the use cases I discuss in the post, like authentication, API endpoints, etc. It was just used to render the app on the server. It did not fundamentally change the DX of the framework.

I honestly was pretty skeptical of these latest frameworks until I gave them a shot! It doesn't sound that revolutionary until you actually start using them, and things which were previously quite difficult become absolutely trivial. I highly recommend trying them out some time.