Rendered at 15:12:50 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
rnd33 6 hours ago [-]
Great article. I feel most people, even great software engineers, seem to lack the intuitive understanding that building software is essentially modeling a system, and that every model faces the same limit: the number of interactions between its part grows combinatorially as the system grows. If some of those parts or interactions produce no value (bloat), then complexity is added for no gain. This is true regardless of who created the model or wrote the code.
Instead they seem to think that AI can someone work around what is essentially laws of nature.
bunderbunder 3 hours ago [-]
If anything I’ve seen AI become a multiplier. The low initial cost to add new features eliminates the only brake many organizations have on accumulation of bloat.
vconnor 15 minutes ago [-]
Laziness is a feature and a very important filter to have in a software engineer. Imagine having in the team a lot of eager (AI) developers that are able to implement in seconds the most overcomplicated or ultimately useless features that will still have to be tested and maintained for years, with no cost-benefit analysis ever made. All it takes is a project manager to have a random idea on a whim, to have to drag it along forevermore.
We're gonna see a bloat epidemic in software like never before.
10111001 46 minutes ago [-]
> Instead they seem to think that AI can someone work around what is essentially laws of nature.
There's a lot of magical thinking about AI's present and future capabilities.
anax32 5 hours ago [-]
And migrating from one system-model to another is an additional system-model - the building of which is an even rarer skillset.
voidhorse 2 hours ago [-]
Yes, I don't think many software devs have a proper conception of what it is they are actually doing. They view their job mostly as "make computer do thing" and not "model and represent some aspect of reality as a system of computable functions". Yes I know it sounds overly academized and pedantic but there actually is a huge difference in these perspectives and imo it's only when you adopt something closer to the latter that engineering really happens.
digikata 5 hours ago [-]
This points back to a more general problem. I love to haul out the quote "All models are wrong, but some models are useful", and it's actually attributed to a statistician talking about statistical models. The quote was written well before AI, from a mathematician working in a time even before computer science dug into data science/eng.
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.
“Decoherence” denotes a process (losing coherence), not a state, but the article uses it like a state: “Well, for one thing, it creates decoherence.” The state would be “incoherence“ (the lack of coherence).
> 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.
bunderbunder 2 hours ago [-]
The article’s opening sentence states that it is introducing a new term. So the author gets to define it how they like, and nobody can reasonably complain that this sense of the word isn’t already in the dictionary. Of course it isn’t. It’s an intentional neologism.
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.
pegasus 1 hours ago [-]
"Incoherent" has a static connotation, "decoherent" OTOH is dynamic and has an associated verb, which is very handy when describing a gradual process which (almost) inevitably occurs as features are added to a system. Since confusion with the usage from quantum physics is unlikely, I too think we can safely and fittingly overload the term like the article does.
codethief 5 hours ago [-]
Agreed! Moreover, the term "decoherence" has a very specific meaning:
I think we can safely overload the term since the domains are separated enough. No one will think you're referring to quantum states when complaining that the system has been decohering too much lately. I can see why the author choose the term: "decohere" is a verb, which is fitting since it denotes a process, something that happens to systems gradually as change accumulates. There's no such connotation and associated verb to "incoherence".
n4r9 6 hours ago [-]
In my experience in academia (although it's been over a decade now) "decoherent" is used as a rough synonym for "decohered".
tomaskafka 6 hours ago [-]
Great term/concept to have at disposal!
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.
js8 3 hours ago [-]
I disagree. LLMs might create incoherence not because of context size limit is too low, but because it's too high. The limit is vastly higher than for humans.
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.
bunderbunder 1 hours ago [-]
Humans get an understanding of large scale systems into their head by developing and refining abstract models, and committing them to memory.
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.
js8 13 minutes ago [-]
I am not sure you're correct. Yes, from the physical perspective of LLMs design, the above is correct. But they are also systems that evolved to do things through training; so you cannot discount the possibility they can emulate building of new abstractions in another level.
LLMs already have the concept of "reference" - i.e. I can say a name of something, for example a function, and they understand that the properties associated with the name itself are not relevant, but rather the whatever 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.
baxtr 6 hours ago [-]
I agree. Although local optima is what most humans already operate on. So it’s sounds like an engineering solution could be possible since group of humans are also able to divide and conquer complex systems.
tomaskafka 4 hours ago [-]
I agree, but that seems to no longer be an engineering solution, but management/org design solution.
samuelknight 26 minutes ago [-]
I can appreciate the complexity argument, but that assumes that AIs can't standardize common patterns into pathological cases. For example our AIs today can code slop, but the slop doesn't try to re-create the IP stack. Why does the author assume we can't make AIs that optimize for better long term design view much like they can optimize for easier goals today like code throughput or program speed?
thenoblesunfish 5 hours ago [-]
I am not really comforted by this argument against the singularity. It seems to rely on the fact that the evolving intelligence doesn't have access to the real world. Okay, but I wasn't really worried about the singularity inside a datacenter. I was worried about it once we wired up all the robots and sensors and power switches to AI controlled systems. We are still doing that, right?
torben-friis 4 hours ago [-]
the point is not lack of access to physical space, as much as that iteration fundamentally only gains speed by staying 'inside a mind', the moment you interact with the world you're bottlenecked.
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.
Game_Ender 2 hours ago [-]
The way this is done in every domain where the real is a bottle neck is with simulation. So the actual argument is: What domains do we think are not practical to simulate even with extreme intelligence making the simulation and the ability to bring immense amounts of computing power to bear while running.
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.
lbreakjai 2 hours ago [-]
That's a very "Spherical cow in a vacuum" approach. You would need to accurately model the boss, as well as all your interactions with the boss up until your raise request, as well as the boss' environment when you make your request.
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.
rnd33 2 hours ago [-]
But how do you source the observations used that would be the basis of your simulation? Or are you assuming the real world won't change? At least in my mind I don't see many domains that remain static enough where continuous sampling of the real world will not be required. Go and Chess are artificially stable domains, the rules are fixed.
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.
sim04ful 3 hours ago [-]
Excellent article. This incoherence is a side-effect of a system built far faster than it is consolidated and thought about from an external behavioral standpoint.
I've created a skill that the agent runs after significant codebase work has been done: https://gist.github.com/scroobius-pip/adb87dffca64b11bad3dd1...
flufluflufluffy 4 hours ago [-]
When we humans have realized we created a system too incoherent, at some point we just create a new one, porting all or some of the data/functionality. But also, we are already presented with problems that all of the current compute on the planet cannot solve. If a software system becomes one of those problems, I'm not that bothered, because it isn't as pressing as real-world one. I don't know, I see it as an argument against the singularity, but I'm not nearly afraid of it as the author seems to be.
torben-friis 6 hours ago [-]
Apologies for opening the discussion with a half related topic, since I haven't finished the article yet, but... Damn, that is one beautiful website.
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.
baxtr 6 hours ago [-]
It’s pretty plain, no?
FreakLegion 6 hours ago [-]
I wouldn't say plain, but it's a generic LLM design. Which made me curious whether the blog was around with a different look before AI was commonly used for such things, and it turns out it was, at https://www.pzuraq.com (which now redirects to the current site).
One article survived the move, so you can compare:
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.
paid_dot_expert 5 hours ago [-]
First through as I read this: Microservices.
> 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.
neebz 5 hours ago [-]
In pure software architecture and design term, this would have been convincing until the recent models who are let’s be honest better than humans in architecture and design.
weakfish 20 minutes ago [-]
They're not better than I am. Faster? Sure. Better? No.
sandworm101 4 hours ago [-]
Good article but uses a bad metaphor.
>> 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)
This is very high effort, but the central argument is wrong.
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!
notpachet 3 hours ago [-]
> The central argument is that AIs, living inside datacenters, won't be able to evaluate the "coherence" of software "beyond the human ceiling"
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!
cousin_it 2 hours ago [-]
I think you maybe didn't read my comment carefully. The article says AI will have to talk to outside the datacenter to do this, I'm saying it won't.
2 hours ago [-]
bunderbunder 2 hours ago [-]
Your premise about coding agents’ ability to manage complexity and decoherence for themselves sounds conjectural to me. Have you seen it reliably do this?
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.
cousin_it 2 hours ago [-]
> Have you seen it reliably do this?
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.
pegasus 2 hours ago [-]
But math is not formalizable (ask Goedel why). And no, computers have not decisively beat humans at maths, that's a laughable assertion. Sure, laymen always imagined math as being about proving theorems, but there's a saying among mathematicians: good mathematicians prove theorems, great mathematicians make conjunctures, the greatest mathematicians write definitions. But maybe you already thought they've solved math when they were able to calculate a zillion digits of pi, lol.
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.
cousin_it 1 hours ago [-]
(Sighs)
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.
pegasus 36 minutes ago [-]
I'm not surprised your understanding of Gödel's findings and their implications is just as superficial as that of maths and philosophy of mathematics in general. Gödel's work has implications way beyond self-referential logic games, and cannot be swept in a corner where it can be safely ignored. For example, there are certain diophantine equations that have no general solution due to Gödel. Also, worth discussing are the Continuum Hypothesis, Whitehead's Problem and stuff like Paris–Harrington Theorem, Goodstein’s Theorem, etc. Not to mention the huge impact on computer science with the Halting Problem, Rice's Theorem and others. In fact Gödel's work actually spawned CS as a field of study.
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!
cousin_it 27 minutes ago [-]
This is obviously pasted from an LLM, so yeah, bye.
2 hours ago [-]
bunderbunder 2 hours ago [-]
15 years, though. Meanwhile, work wants me working today.
cousin_it 2 hours ago [-]
The article makes claims about the future, such as:
> We cannot make an AI that improves software coherence beyond the human ceiling without leaving the bubble
Instead they seem to think that AI can someone work around what is essentially laws of nature.
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.
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.
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 a function, and they understand that the properties associated with the name itself are not relevant, but rather the whatever 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.
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.
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.
> 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.
>> 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)
(4) https://en.wikipedia.org/wiki/Battlecarrier
(5) https://en.wikipedia.org/wiki/USS_Sable
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.
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!
> We cannot make an AI that improves software coherence beyond the human ceiling without leaving the bubble
That's what I was replying to.