If you ever need to explain path dependence (or why you need to understand where a system has been to understand what is doing now or how to shift it) here's an illustration.
The Student List had no party machinery. It operated through university assemblies, protests and hiking between cities & towns.
They had 2% of national TV political advertising airtime vs 93% for Vučić.
This is one of the most remarkable grassroots democratic victories in modern European history.
The achievement of Serbian students overthrowing Aleksandar Vučić can't be overstated.
In 2024, they began protesting. In 2025, they transformed a protest movement into civil dissidence. In 2026, they became a political party — and two months later, crushed a corrupt state-entrenched authoritarian.
As skills in writing code and safe refactoring deteriorate with increased use of GenAI, something I observed myself, GenAI becomes increasingly necessary, to the point of becoming a must.
How the world changed for me with GenAI code generation: bad code slowly piling up, or bad to, at best, mediocre code piling up 10x faster while the team's mental model of how the system they build and own works dissolves.
Some good things to work on this week as collapses and power grabs surround and the operating instructions of the industrial growth domination and supremacy worldview are further revealed and clarified (remember apocalypse means "uncovering")
If you think the effects of dissolving the team's mental model of the system, by removing humans (authors and reviewers) from the path to production, will show up soon enough to reverse course safely, I have news for you.
No amount of upfront experimentation can compensate for the inherent delays in complex systems. Effects take time to feed through. By the time they do, you might already be setting up an email account at your next gig, while your previous company will be living with the consequences.
He had grown up in a country run by politicians who sent the pilots to man the bombers to kill the babies to make the world safe for children to grow up in.
There's a big difference between emergence (in complex systems) and stochasticity, and there's often confusion of the latter with the former when reasoning about LLMs and their properties.
Independence as a means of scaling is often a mirage.
Systems will always find a way to prove to you how interdependent things are.
"Dancing with the system" starts with recognizing interdependence, not seeking the holy grail of independence.
As a result, this is how I now judge LLMs: Are they a good pair programmer or assistant.
Can they follow instructions, can they be taught good design principles, can they be taught not to do stupid workarounds?
I don't care how genius the are, good maintainable code requires mastering the basics.
This is also why big up-front planning is not sufficient. You can't predict all the guardrails and architecture rules the agent will hit during implementation (although you should try to anticipate as much as possible IMO).
Everything I see points to software engineers being augmented by AI.
And this is why you need to stay close to the code as an engineer. So you can actually understand and contribute to these discussions. You still own the design.
It's interesting to think about the dynamics between product enshittification, which I feel has been on a sharp rise over the last couple of years, and central banks raising interest rates.
What strikes me is that leverage in the financial system (eventually leading to higher volatility) also translates into leverage in products' perceived value and experience.
If deleveraging is a regression to the mean, or "what it should have been all along," then our perception of products built during nearly 15 years of very low rates was also unrealistic and unsustainable. For a lot of people, that era is all they've ever known of digital products they use today.
It's interesting to think about the dynamics between product enshittification, which I feel has been on a sharp rise over the last couple of years, and central banks raising interest rates.
The more expensive borrowing is, the tighter funding gets, the harder investors push for profitability, and the more aggressively companies try to monetize previously subsidized products. And remember that runway is a stock, not a flow, so rate hikes show up in product decisions with a lag.
Collaboration - of which throwing PRs over the wall is likely the most suboptimal way to go about it, if it can be called collaboration at all - was never only about making sure the code is correct.
And I can understand that a mental model that reduces collaboration to that goal can be drawn to the idea of an LLM dark factory, with harnesses and constraints that attempt to rein in LLMs' code-generation output.
But let's not confuse the output for the process that created it.
If teams' utilization is so high that it causes a non-linear increase in delays, adding more people while keeping the same utilization rate won't help reduce the delays you wanted to reduce by adding more people.
Software delivery measurement vendors would like you to improve the metrics, but not to the point where you change the way of working (XP) to the point that you no longer need the vendor or the measurements.
The purpose of all automation and cost reduction we got as a result of technological improvement since the start of the Industrial Revolution was to spend more time on social networks and consuming polarizing and addictive content.
The purpose of the system is what it does. (POSIWID).
The right time to intervene in systems where an exponential, reinforcing feedback loop is dominating the system's behavior is when it seems it's too soon.
"Let's wait and see" is a guarantee that it'll be too late.
We used to say..."we cannot afford to wait and see on climate change." We did all sorts of teaching about the delays and momentum and how because of them, once it got bad it would be too late, and now it's bad but that presumed action that the bad would unlock, well...there were other forces....
“A numerical goal leads to distortion and faking, especially when the system is not capable of meeting the goal. Anybody will meet the quota (goal) allotted to him. He is not responsible for the losses so generated.”
W E Deming, in “The New Economics”
The problem is that people deciding if developers should be writing code are very often the ones who have never had enough experience with writing code to have a good idea what the value of writing code is and the purpose it serves, but they are convinced they know.
The counterintuitive idea about managing flow is that the leverage is most often much less about speeding up slow parts and much more about slowing down parts that are running too fast when taking into account the whole system.
I've seen comments about accepting LLM-generated code in that we don't/can't understand it and excusing that because:
"There's always code in the system that we don't understand"
Except, LLM-gen'd and human-written code are different.
One was written by someone with a mental model. Modified by humans with another mental model (correct or not), etc.
The other is generated by statistical, stochastic methods with constraints.
These are not the same.
Slides from my talk "Agentic Coding - A Systems Perspective" or how not to inflate the elephant traveling through a boa constrictor.
The talk combines Theory of Constraints, Systems Thinking, XP, and Lean lenses of agentic coding.
drive.google.com/file/d/14YVq...
Does it ever hit home that the ascendancy of AI is taken to be assured, but the shifting of human society to fit into earth system limits is seen as everything from a head-scratcher to a longshot to an impossibility?