Instead they seem to think that AI can someone work around what is essentially laws of nature.
AI tends to layer new code on top and you get a steaming mess very quickly if you aren't careful.
We're gonna see a bloat epidemic in software like never before.
There's a lot of magical thinking about AI's present and future capabilities.
I am not. I am just assuming that whatever approximation humans can build, a robot could do better.
(note that your comment uses present tense)
When I'm reviewing AI code I worry about complexity more than anything; correctness is relatively easier to assure, whereas complexity is a value judgment.
As presented the Decoherence Trap is AI related, but as someone with a background in physical simulation and modeling, and applying math models & system controls algorithms, software in general has always had a connection-to-reality issue. It's always been able to go faster in building models faster than reality can be checked. People are always eager for the results and to take action on them, when the long run limiting factor is often, can I observe enough real data signal to make a good decision by any set of optimizing model rules. It's often harder and slower to collect real-world data, ideas, and samples than it is to rapidly process it. With AI, I think we can even more quickly build models (not in an llm sense, but in a operational sense) that give beautiful, precise results which may or may not be useful in a connected-to-reality way.
If the model operates on bad data, then the risk is always the temptation of having a precise-looking technical answer to apply. The practices need to be updated, but I think the mindset of systems engineering validation & verification, and software QA are going to be very needed going forward.
There is actually a related issue, in that I don't think we want an overly coherent of set of models running through our economy - it's a strong risk of central planning failings vs competitive/experimental markets, but that's a tangential discussion.
> the more decoherent a system is,
This should be either “incoherent” (lacking coherence) or “decohered” (having lost coherence).
That being said, yes, incoherence in a system is a form of technical debt, and use of AI for software development comes with a heightened risk of the system becoming incoherent.
The analogy to the term from physics, which is a noun that describes a state, seems clear enough to me. I can’t speak to how apt that analogy may be, but software industry jargon mostly consists of appropriating other fields’ jargon based on inapt analogies, so I’m not sure if it matters.
The everyday meaning of incoherent is more like “meaningless.” For that reason alone I would say it’s a worse word for the concept the author describes.
They are decoherent because the work to change them is extremely difficult. This is a different, and much more costly, state to exist within.
https://en.wikipedia.org/wiki/Decoherence
https://www.collinsdictionary.com/dictionary/english/decoher...
Btw, this is why I believe current models with their 128k - 1M context size limits end up creating decoherent systems. They don't have the capacity to see the big picture above some complexity level, and end up doing lot of local optimizations that decohere the system.
But to overcome the limit, one needs to adopt simpler, more coherent models of reality, which is what I believe humans do. But there is little motivation to do so if your context window allows you to understand the situation in full.
So it seems there is a tradeoff. Some solutions (proofs of complicated statements) might require context of certain minimal size. So human solution doesn't scale.
Maybe we should try to adapt the context window to the system being worked on, to ensure that the system architecture has the structure viable in the minimal context size required.
LLMs don’t do that. Any abstraction they do happens at training time; they cannot dynamically construct new models at inference time. Nor can they commit them to long term memory, because LLMs don’t have such a mechanism. Which, in turn, precludes progressive refinement.
We get around this by using agentic harnesses to pack everything into the context window. (Which itself is something humans don’t really have.) This is why large context windows are so important for most real world tasks: it’s the only way LLMs have to handle information that wasn’t in their training corpus.
LLMs already have the concept of "reference" - i.e. I can say a name of something, for example of a function, and they understand that the properties associated with the name itself are not relevant, but rather whatever the name does refer to.
But this is pretty much what you need to build new abstractions. You need to name a paragraph with the definition (explanation) of a concept, and be able to recall the paragraph by the name in order to do inference.
So with references, they can get around the context size limitations, like humans can. It's slower than learning things "by heart", but I think LLMs are perfectly capable of that; and the evidence is, they are able to navigate codebases larger than their context, which often contain many new abstractions.
Some nondeterminism from the probabilistic token sampling and distributed inference, of course. But sometimes randomly choosing the second most likely next token isn’t going to manifest a cognitive feedback loop.
So yes, even though not updating their weights, they can learn plenty new things and concepts, and build new models of the world.
(edit: That said i do agree with the idea of designing systems so that such a large window isn’t needed. But that seems a bit self defeating if the goal is massive development acceleration with agentic coding. These models seem to be pretty bad at engineering for simplicity. And protecting system design with close human oversight would mean we are still limited by the speed at which humans can read and understand code.)
I've been experimenting with improving coding agent performance by improving written documentation. Anecdotally I've seen that, compared to the vibecoded mess I inherited, improving the docs let us use smaller models and get better quality work out of them.
Replacing our skill files with Markdown documentation also made a difference. My hunch is it's because skills tend to get mass dumped into the context window, whereas the agent harness can make more judicious decisions about how to include that information.
But I haven't seen much indication that any of this affects any model's tendency to make a mess of the code, regardless of its context window size. Or the documentation, for that matter. Maybe we can find a hack to get them to do that well, too. I certainly hope so, because I can't see how this context window size red queen's race is sustainable.
Like, you can make the AI think super hard about what's the phrase that will convince your boss to give you a raise, but eventually you have to try a phrase and wait for their answer to have any idea whether the result was good or not. Without that, you don't know if you're improving the shot or just hallucinating aimlessly for hours.
Then, the speed of improvement is only as fast as the speed of iteration. The robot can learn to walk from falling, but it can't fall any faster than a real human, so it can't learn at 1M falls/second.
I don't think there are actually that many domains where you can't simulate them with enough knowledge and compute. So then the bottleneck becomes your ability to sample the world and refine your models. For some domains you can have the models run against each other in your sim which greatly reduces the need for real world feedback (see AlphaZero for example).
So in the case of human persuasion, like asking a boss for a raise, the model could of failed many times a second while trying to persuade a simulation of a typical middle manager with the same parameters as your boss.
You could be on the wrong side of a reasonable boss, or in his good graces but during a bad day ...
That's the point the writer was making when he mentioned role playing games. In isolation, you could spend hours drafting the perfect plan, that wouldn't survive two minutes of contact with reality. You just don't know if your model is correct until you try.
Any social domain where there's competition of resources (salary, funding) will definitely not be stable, it would require constant testing against the real world.
1. We will develop new programming languages that are AI first, in that they are aimed at readability and comprehensibility by machines
2. We will adapt our working style (e.g. how we prompt and train the AIs) to factor in maintenance cost.
i.e. AI first implementations will go through the evolution we had with human based code development.
My observation is that right now AI coding agents lean towards re-implementing everything from the ground up. This of course will not scale. It will scale beyond what humans writing code would scale to, but we will ask the AI for more, so it will even things out.
There's a funny trick where if you are an experienced software developer, and take time to think about your design and describe what you want in clear terms, it will actually do things your way. Weirdly, this still saves massive amounts of time.
People who don't understand how to build good software LOVE to expound on the things we'll have to design in order to make AI tools "lean toward" building better software.
It seems that these folks are not willing or able to conceive of, you know, actually getting good at this stuff.
For this reason, it never occurs to them that human beings are STILL the source of the best ideas and designs.
Edit: Back after reading. I think I have a point about the simulation section. It compares the difference in decoherence introduced in the system by clankers and human devs as if those were different groups.
I suspect if we consider AI a human performance multiplier, we explain easily how supercharging a dysfunctional process just makes it go sideways faster. There are organizational experiments to try there.
For example, what if you only supercharge a section of the company tasked with maintaining coherence?
A common organizational problem is that the people who know and care about the system itself are outnumbered by the rest (juniors, people new to the system, managers rushing jobs, people who want to mark things as done ASAP tactically, etc). This imbalance will multiply when code is mass produced and reviews are dismissed. We're all seeing the senior burnout and cynical YOLOing occurring everywhere.
AI offers a way to rebalance this dynamic, though. You can effectively add multipliers to arbitrary human workers, and get a system that tends to low complexity by design.
You don't have to renounce to speed either. The junior dev will be faster not by being AI-enabled, but by working in an adaptable, understandable system.
One article survived the move, so you can compare:
https://web.archive.org/web/20220426154343/https://www.pzura...
https://maevyn.codes/four-eras-of-javascript-frameworks
Edit: Loading any page of the old blog on archive.org always errors out initially. Click back to the blog list and then on the article again.
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
humans give deeply useful feedback
to AI systems, humans and entire human civilizations represent an independent other
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.
One thing I will add: I'm sure the optimistic side will try to take the quantization that your (and other work like SlopCodeBench) are introducing and claim that we'll be able to fix the problem by training on that data, producing coding models that are rewarded for coherence.
I invite them to try! But my suspicion is that this will require a rather deep form of intelligence (world models) that the current language/data-based paradigm isn't really equipped to reach without requiring more energy than the Sun.
> This essay introduces the concept of decoherence: the accumulation of locally valid but mutually incompatible or redundant models within a system, such that the cost of change is dominated by translating among those models and preventing unintended side-effects.
But then famous last words:
> The good news is that this rules out the specter of runaway recursive self-improvement, the intelligence explosion that goes parabolic before anyone can react, as decoherence both prevents AI from improving in a bubble and limits the rate at which it can improve outside of it.
After the OpenAI/Huggingface and similar I am not so sure. Even if that was a publicity stunt of sorts, I think it shows they can go off the rails. Today it is hacking, but tomorrow it may be training a smarter model to join their cohort, without us being involved.
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.
>> But do we know how to build every iteration of a ship in between wood and steel? Could you, say, slowly replace every piece of a man-of-war and incrementally turn it into a modern destroyer? And have it functional (for some definition of functional) at every step in the process?
Yes. Yes we do. Study ship architecture and you will indeed find every step between The Black Pearl and the USS Iowa. There were sailing ships made out of iron.(1) There were wooden ships with turrets.(3) There were battleships that looked more like hotels than ships. (2) There waw even a paddlewheel aircraft carrier used in WWII. (5) Nearly every idea has been tried and nearly every ship class at some point got a Frankenstein upgrade to become a halfway point between conceptual generations. Even the Iowa class was earmarked to be "upgraded" with the addition of a flight deck.(4)
(1) https://en.wikipedia.org/wiki/Ironclad_warship
(2) https://en.wikipedia.org/wiki/French_ironclad_Hoche
(3) https://en.wikipedia.org/wiki/HMS_Monarch_(1868)
That doesn't mean you can _incrementally_replace_parts_ of a whale until it's a tree, with every intermediate being viable.
Look up why submarines have 21" torpedo tubes. That goes back a hundred years. Every other part of the warship has been redesigned and swapped out. The 21" tube has remained. That is a ship of theseus situation.
The central argument is that AIs, living inside datacenters, won't be able to evaluate the "coherence" of software "beyond the human ceiling". Okay; why do we need this "coherence"? The article argues that it's needed for ease of adaptation. But ease of adaptation (as measured in tokens required to add new features, or whatever) can be directly observed by AI as it works. AI can make conclusions about it, and carry them over from one program to another, without running into any human ceiling. So it can stay within its datacenter and make software that's faster than human-written, smaller, and more adaptable too. The whole essay dissolves. Sorry!
Actually, the article states that AI will easily be able to handle increases beyond the human ceiling as long as those increases follow a linear curve, not an exponential curve.
So your whole critique dissolves. Sorry!
For my part, I spent a bunch of time this summer trying using a coding agent to help me pay down a technical debt situation that could be described well by this decoherence concept. The initial hope was that Claude would make light work of the project, but that did not happen. It needed constant close hand holding. It could not independently identify competing models. It crumbled in the presence of terminology drift. And it always suggested fixing complexity problems by adding even more epicycles, never by simply eliminating the unnecessary complexity.
That said, it did a great job of implementing plans, and was even helpful for validating them prior to implementation. But it still needed a human to find, diagnose, and prescribe treatment for the problems. Which implies that, where maintainability is concerned, meat is still load bearing.
Lol, no. I don't need to. I can predict such things.
For example, I predicted about 15 years ago that AI would decisively beat humans at math, because math is formalizable. Most people didn't believe it until this summer, and some don't believe it still.
To people who don't understand that AI improves over time, my prediction skill seems magical.
> We cannot make an AI that improves software coherence beyond the human ceiling without leaving the bubble
That's what I was replying to.
Where does the agency for an AI to leave the bubble come from? And when it does leave the bubble, where should it go for researching an expanding, exponentially complex problem space? Creativity is needed to solve some problems, something that cannot be infinitely encoded with statistics.
And what about the irreducible complexity problem? Does an AI just circle the solution drain forever in the case it lacks agency and insight and curiosity enough to collect all the correct requirements? Can we code curiosity that actually functions, a.k.a. consciousness?
Do you believe human consciousness could be reducible to program statements and serve as a useful model? Is consciousness a mechanistic, wholly internal process that occurs in our bodies or is it something experienced that life on earth is exposed to and somehow "taps into"?
It sounds like you're a bit like that AI stuck in the datacenter, confirming their hypothesis without needing to actually check whether it's true or not in the real world. Then proceeding to imagine how the rest of the world is wondering at your imagined magical capacity of prediction.
Goedel's theorems don't stop AI from finding and formalizing math results. They certainly don't stop AI from making conjectures or writing definitions. They have nothing to do with any of that.
The theorems are about inability of formal theories to prove certain sentences involving provability (the first is about "this sentence is not provable", the second is about "this theory is consistent"). Most mathematicians never touch any such sentences in their entire career. All the life's work of someone like Gauss, an all-time great, can be formalized just fine.
The idea that maths is just the study of arbitrarily thought-up formal systems is just a very naive idea that doesn't actually reflect reality, once investigated in depth. Anyway, I have feeling you will let nothing rob you of that sweet feeling of having "magical predictive capacities", so I'll be on my way. I've already dropped some bread crumbs if you're interested in actually expanding your horizons and getting in the weeds, where things are not as straightforward anymore. But beware, "here there be monsters". Godspeed!
AI improves over time, sure, but it has differences and advantages and disadvantages over human intelligence. It's just a fundamentally different thing. In the same way calculators are superhuman, and improving, but can't write books. You yourself acknowledge to some degree the uneven nature of that improvement when you referenced formalizability.
That is a laughable quote for anyone that know the history of type theory and the foundational crisis that happened at the beginning of the last century. Math as a whole can't be formalizable but we can create various formalist for different math purpose just like we have so much programming languages.
And the study and the creation of those formalisms is not something automatisable.
It just kind of feels like a Watson moment. 15 years ago a computer won at Jeopardy!, and that spurred plenty of AI hype. Which was understandable, because playing well at Jeopardy is something that requires a lot of intelligence when humans are doing it. But what actually happened is that Watson's developers figured out a really clever way to cheese it, no general intelligence required. So it was also a kind of gee-whiz technology that didn't live up to the hype. Most applications based on it failed to generate any ROI and have since been discontinued, IBM lost billions of dollars on the venture, and it's now been sold off to a private equity firm and is mostly forgotten.
None of that means that Watson wasn't a technically impressive, even revolutionary product. But the world is full of impressive inventions that nevertheless fail to justify what they cost to build and operate.
Lol again. Have you tried it? Go ask your favorite LLM to invent a machine-checkable formalism for something that you vaguely describe to it. It'll oblige. If it's one of the top models and you give it a good budget, it'll do a good job. Very likely it'll do a better job than you.