Linkfest #9

Every couple of weeks I send you a curated stack of Internet reading that stayed with me. Culture, technology, science, software. Things that made me pause and think.

This round circles around systems and responsibility. Senior developers trying to explain complexity to a business that fears uncertainty. AI companies promising productivity while economists warn about demand and democracy. Architects searching for purpose while organizations lose their memory. Infrastructure that quietly runs the world, from vacuum tubes to airline PNRs. And a reminder that faster coding is meaningless if maintenance eats you alive. It is all the same theme in different clothes: we build systems, and then those systems shape us.

Enjoy! -- Christoph (CTO @ Basilicom)

The Surprisingly Long Life of the Vacuum Tube

https://www.construction-physics.com/p/the-surprisingly-long-life-of-the

We think of vacuum tubes as museum pieces, replaced by semiconductors decades ago. This article shows how wrong that is. From radios and early computers to magnetrons in microwaves, klystrons in particle accelerators, X ray machines and fusion experiments, tube technology never really left. It just moved into niches where its physical properties still matter. The story also traces the scientific breakthroughs that came out of these devices, including the discovery of the electron.

This is a good reminder that technological progress is rarely a clean replacement. Old S curves overlap. In enterprise IT we often talk as if the new stack will erase the old one. In reality, the old systems stick around, sometimes for very good reasons.

Why Senior Developers Fail to Communicate Their Expertise

https://www.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise

This piece frames a company as two loops running at the same time. One loop chases market feedback and tries to reduce uncertainty through speed. The other loop serves paying customers and tries to reduce complexity to keep the system stable. Senior developers often live in the second loop, speaking in terms of maintainability and long term stability, while the rest of the business speaks in terms of learning velocity. The result is a communication gap. The proposed fix is simple: translate complexity concerns into uncertainty reduction language, and separate speed work from scale work.

I like this because it explains a tension I see in almost every client project. The trick is not to win the argument about complexity, but to show how less code can mean faster learning. In an AI-heavy world, where everyone can generate features in minutes, the responsibility to keep systems understandable becomes even more valuable.

The Dead Economy Theory

https://www.owenmcgrann.com/p/the-dead-economy-the-dead-economy-theory

This essay argues that large scale AI adoption could hollow out the labor market that sustains demand. If companies replace workers to cut costs, profits rise in the short term. But if many companies do it at once, consumer spending shrinks and the market erodes. The author connects this to economic research on automation, inequality, and political stability, and questions whether democratic systems can handle a world where labor is no longer needed in the same way.

The tone is intense, but the core question is serious. Who is the customer in an economy that automates its customers away? Even if the scenario plays out more slowly than described, leaders should think about second order effects. Efficiency is not the only variable in a system.

The Essence of Architectural Work - Part 1

https://www.ufried.com/blog/essence_of_architecture_1/

This is the start of a series about the why, what, when, and how much of architecture. The author argues that many teams debate tools and techniques but rarely discuss purpose. Without a clear why, architecture turns into ritual. He also points out how AI has triggered a kind of collective amnesia, where old lessons about requirements and design are rediscovered and sold as new insights.

I appreciate the focus on purpose. In client work, architectural discussions often drift into diagrams and frameworks without anchoring them in business and human outcomes. Revisiting fundamentals is not a step back. It is usually the only way forward.

Six Characters

https://ajitem.com/blog/iron-core-part-2-six-characters/

A deep dive into the six character PNR code on an airline ticket. From there, the author unpacks IATA standards, fare construction in NUC, record locators, and the decades old infrastructure that keeps global aviation running. It is a tour through cryptic terminal commands and data structures that still hold together an industry moving billions of people each year.

I love pieces like this. They show how much invisible infrastructure surrounds us. When we talk about modern platforms and AI agents, it helps to remember that some of the most robust systems in the world are built on standards from the 1960s and 1970s, still doing their job.

You Need AI That Reduces Maintenance Costs

https://www.jamesshore.com/v2/blog/2026/you-need-ai-that-reduces-your-maintenance-costs

James Shore models software productivity as a function of maintenance cost. Every line of code creates a long tail of future work. If AI doubles your output but also doubles maintenance effort, you lose in the long run. The only sustainable scenario is one where AI reduces maintenance cost in proportion to increased output, or makes maintenance itself more efficient.

This hits home. Many teams celebrate faster feature delivery without measuring the maintenance curve. In our projects, we already see the risk: more generated code, more hidden complexity. Speed is exciting. Sustainability is harder, and far more important.

The Configuration Complexity Clock

https://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html?m=1

A classic from 2012. It describes a journey from hard coded values to configuration files, to rule engines, to DSLs, and finally back to something that looks like hard coding again, just in a worse language. The lesson is that beyond a certain level of complexity, configuration can become as heavy as code, with its own tooling, testing, and learning curve.

This is relevant again with AI generated configuration and low code systems. Externalizing logic feels flexible, until the abstraction becomes a product of its own. Sometimes the least evil option really is clear, well tested code.

When Everyone Has AI and the Company Still Learns Nothing

https://www.robert-glaser.de/when-everyone-has-ai-and-the-company-still-learns-nothing/

This essay looks at the messy middle of AI adoption. Tools are everywhere, usage is uneven, and individual gains do not automatically become organizational learning. The author proposes ideas like loop intelligence and feedback harnesses to capture what actually changes in workflows, without turning the whole thing into surveillance.

For me, this is one of the most practical AI pieces in a while. The real challenge is not buying licenses. It is turning local experiments into shared capability. If we cannot make learning travel, we will end up with expensive tools and very little transformation.