Tag: systems thinking

Categories
Architecture Infrastructure

The Architecture of the Indestructible

We are conditioned to look for the center of things. When we try to understand an organization, we ask for an organizational chart. When we look at a nation, we look to its capital. Traditional architecture—whether of a building, a company, or an army—relies on a classic playbook: a strong hub, radiating outward. You find the center, you secure it, and the system holds.

But what happens when you try to decapitate an enemy, or a technology, that has no head?

In 1964, a brilliant engineer named Paul Baran sat at his desk at the RAND Corporation, trying to solve a Cold War nightmare: How do you maintain a communications network after a catastrophic nuclear strike? Baran realized that traditional networks were centralized—like a wheel with spokes. If you destroy the hub in the center, every single spoke becomes useless.

His solution was the distributed network, the foundational blueprint for what would eventually become the Internet.

“Under the proposed system, each station would need to be connected to only a few of its nearest neighbors… The system would be highly reliable, even if a large fraction of the stations were destroyed.”

Baran mathematically proved that if you remove the center, the edges don’t die. They simply reroute. A few decades later, telecom engineers used a remarkably similar logic to build cellular telephone networks. Instead of one massive, high-power radio tower serving an entire city, they broke the terrain into a grid of small, low-power cells. If one tower goes offline, the network degrades gracefully rather than collapsing. It bends, but it refuses to break.

There is a profound, poetic irony buried here. The United States government originally funded Baran’s research to create a distributed network so that its centralized monolith could survive. Decades later, asymmetric adversaries across the globe adopted that exact architectural philosophy for their physical defense doctrines—creating “Mosaic Defense” systems designed specifically so that when you destroy the center, the edges keep fighting.

They copied our homework to survive our strength.

I find myself thinking about this tension far beyond the realms of military strategy or software engineering. It is a metaphor for how we construct our lives. We often build centralized lives—anchored entirely to a single identity, a single career, or a single institution. We project a monolith of strength to the world. But monoliths are brittle. When the center is struck, the whole architecture crumbles.

The lesson of our modern architecture is becoming increasingly clear, whether you are managing a network, building an organization, or navigating the quiet complexities of a human life. The fragile monolith is an illusion of safety.

The future belongs to the web that knows how to reroute.

Categories
AI Programming Prompt Engineering Software Work

The Great Inversion

For twenty years, the “Developer Experience” was a war against distraction. We treated the engineer’s focus like a fragile glass sculpture. The goal was simple: maximize the number of minutes a human spent with their fingers on a keyboard.

But as Michael Bloch (@michaelxbloch) recently pointed out, that playbook is officially obsolete.

Bloch shared a story of a startup that reached a breaking point. With the introduction of Claude Code, their old way of working broke. They realized that when the machine can write code faster than a human can think it, the bottleneck is no longer “typing speed.” The bottleneck is clarity of intent.

They called a war room and emerged with a radical new rule: No coding before 10 AM.

From Peer Programming to Peer Prompting

In the old world, this would be heresy. In the new world, it is the only way to survive. The morning is for what Bloch describes as the “Peer Prompt.” Engineers sit together, not to debug, but to define the objective function.

“Agents, not engineers, now do the work. Engineers make sure the agents can do the work well.” — Michael Bloch

Agent-First Engineering Playbook

What Bloch witnessed is the clearest version of the future of engineering. Here is the core of that “Agent-First” philosophy:

  • Agents Are the Primary User: Every system and naming convention is designed for an AI agent as the primary consumer.
  • Code is Context: We optimize for agent comprehensibility. Code itself is the documentation.
  • Data is the Interface: Clean data artifacts allow agents to compose systems without being told how.
  • Maximize Utilization: The most expensive thing in the system is an agent sitting idle while it waits for a human.

Spec the Outcome, Not the Process

When you shift to an agent-led workflow, you stop writing implementation plans and start writing objective functions.

“Review the output, not the code. Don’t read every line an agent writes. Test code against the objective. If it passes, ship it.” — Michael Bloch

The Six-Month Horizon

Six months from now, there will be two kinds of engineering teams: ones that rebuilt how they work from first principles, and ones still trying to make agents fit into their old playbook.

If you haven’t had your version of the Michael Bloch “war room” yet, have the meeting. Throw out the playbook. Write the new one.

Categories
Living Mathematics

The Curve That Blinds Us

There is a fundamental mismatch between the hardware in our heads and the software of the modern world. We are linear creatures living in an exponential age. We can be stunned by exponential growth.

Our ancestors evolved in a world where inputs matched outputs. If you walked for a day, you covered a specific distance. If you walked for two days, you covered twice that distance. If you gathered firewood for an hour, you had a pile; for two hours, you had a bigger pile. Survival depended on the ability to predict the path of a spear or the changing of seasons—linear, predictable progressions.

But nature and technology often behave differently. They follow a curve that our intuition simply cannot map.

If a lily pad doubles in size every day and covers the entire pond on the 30th day, on which day does it cover half the pond? Our linear intuition wants to say the 15th day. But the answer, of course, is the 29th day.

For twenty-nine days, the pond looks mostly empty. The growth is happening, but it feels deceptively slow. We look at the water on day 20, or even day 25, and think, “Nothing is happening here. This is manageable.” We mistake the early flatness of an exponential curve for a lack of progress.

This is the “deception phase” of exponential growth. It is where dreams die because the results haven’t shown up yet. It is where we ignore a virus because the case numbers seem low. It is where we dismiss a new technology because the early versions are clumsy and comical.

Ernest Hemingway captured this feeling perfectly in The Sun Also Rises when a character is asked how he went bankrupt. His answer:

“Two ways. Gradually, then suddenly.”

That is the essence of the exponential. The “gradually” is the long, flat lead-up where we feel safe. The “suddenly” is the vertical wall that appears overnight.

The tragedy is not that we fail to do the math—we can all multiply by two. The tragedy is that we fail to feel the math. We judge the future by looking in the rearview mirror, projecting a straight line from yesterday into tomorrow. But when the road curves upward toward the sky, looking backward is the fastest way to crash.

To navigate this world, we must learn to distrust our gut when it says “nothing is changing.” We have to look for the compounding mechanisms beneath the surface. We have to respect the 29th day.