“Decoherence” denotes a process (the loss of 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).
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.
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.
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.
“Decoherence” denotes a process (the loss of 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).
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.
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.
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.
It’s pretty plain, no?