I reject the idea that humans have no role to play in the future of software development. Not because I think AI will fail to become more powerful, flexible, or capable. It will. I reject it because the value of software is ultimately determined by humans, not by AI.

This is not a new question. Asimov asked it long before LLMs: if another intelligence can make better choices for humanity, should humanity let it? The answer his stories return to is uneasy but clear. Humans may accept help from another intelligence, even brilliant help, but they rebel against surrendering the right to decide what is good for them. The Wachowskis asked the same question in The Matrix and arrived at the same answer. A system can optimize for survival, comfort, or order and still miss the human point entirely.

As long as the human universe is the center of our universe, only humans can decide what is good for humans. Another intelligence may decide what is good for itself. It may even discover solutions for humans that humans would not have found on their own. But the final judgment still belongs to the human.

In practice, this means an LLM can produce a clever algorithm, a cleaner abstraction, or a faster implementation. But whether that solution is worth the token cost, whether it handles the corner cases that matter, whether it satisfies the usability expectations of the people who will rely on it, and whether it is worth maintaining are judgments only humans can make.

So, what is the role of humans in software engineering? It is the same role the human has always had. Software engineers did not exist to build software for machines. We existed to build software for other humans. Our job was always to translate human needs into instructions a computer could execute. That translation remains valuable because the difficult part was never only making the machine do something. The difficult part was deciding what was worth doing.

There is always a cost to producing anything. There are easy ways and hard ways. There are choices that make future work easier and choices that make it harder. Those are engineering trade-offs. But beneath every trade-off is a human value judgment: what matters, who it matters to, what risk is acceptable, what complexity is justified, and what outcome is actually good.

AI may change the mechanics of software development. It may change the speed, the leverage, and the shape of the work. But it does not remove the human role, because the human role was never merely typing code. It was understanding human needs deeply enough to decide what the machine should be asked to build.

I have come here to gloat and observe.

When I was at VMware, a lot of the code written in Python was being used in production. In my mind, that was an awful technical decision because VMware was shipping a packaged appliance. Every CPU cycle we spent on Python was a CPU cycle the customer was spending, essentially imposing a tax on them for our convenience. The issue I had wasn’t just that we were spending it for our convenience, but that we were using a technology that was intrinsically unsafe due to its lack of type safety.

So, I would engage in intense debates and arguments with some of the Python enthusiasts. They would vehemently assert that Python was robust, reliable, and even superior. They would go on to explain that it was easier to code in and prototype with Python.

I couldn’t deny that if you’re trying to build a prototype, Python’s simplicity, speed, and ease of use are undeniable advantages.

But when you finally ship code, you are no longer prototyping. You know what you’re shipping, so you’re no longer experimenting. So that value is zero.

Fast forward a few years, and I end up at Nutanix. I’m looking at LLMs, AI, and generated code, and I’m wondering about my choices in terms of backend languages. I did some research and realized that Python is actually a very good language to use because the token cost is very low since it’s very expressive. Also, for personal projects and the kinds of things I was doing, most of the libraries and tooling that I want, use it.

So, having done my research and having given it some thought, I said, “Okay, Python is the language.” I figured I don’t really have to learn all of the vagaries of Python, and the performance is going to be dominated by the LLM. If I ever get to the point where this matters, I’ll figure it out.

I kind of lived in that happy bubble until I got this project that I downloaded from GitHub, a really great project. (https://github.com/nashsu/llm_wiki) The author was using JavaScript and Vue for the front end, and to my surprise, they were using Rust on the back end.

The back end of their server was entirely written in Rust, and I was like, “Well, that makes no sense.” First, I thought it was a case of an engineer trying to be clever, cute, or experimenting. At the end of the day, it’s an open-source project. They’re not being paid, and if they want to do something in Rust because that’s what they want to do, that totally makes sense.

But then another friend of mine told me that, well, actually, that’s a new emerging pattern. The reason is that using Rust is a much more token-efficient way of writing code once you have product feature lock. In other words, once you’ve shipped version 1, every subsequent iteration costs fewer tokens because of the context Rust gives to the computer and the fact that it catches a whole bunch of bugs as a result of the type safety. So, the net effect is you’re using fewer tokens per iteration afterward.

That made me smile because literally, the AIs figured out exactly what I had figured out 15 years ago, and what Niklaus Wirth figured out 50 years ago. And now people figured it out on their own.

Back then in 2015 when I got in front of all those Python engineers and told them that they would never write another Python service as long as I was architect and they should all go learn Go, I felt kind of bad. I was basically making an assertion with no data. But now I’m happy to say I was right, and yes, I’m going to gloat about it.

But.

It’s kind of cool to see that there are certain facts about software engineering that are not tied to human cognition but to cognition and information in and of itself. That to me is the most interesting thing about this.

Notes from moving a D&D distillation off the API and onto two boxes I own.

The run that hung

I was running the whole campaign through a new extraction pipeline. Fifty-six sessions of Out of the Abyss, fanned across two DGX Sparks. Most of it ran fine. Then four units at the tail hung for an hour and forty-four minutes on one box, while the other Spark sat there doing nothing.

I was sure I knew what it was. vLLM degradation, the decode running away toward the token ceiling. So that’s where I went looking.

That wasn’t it. The metrics showed zero preemptions and an almost-empty cache. Nothing was slow. The laptop driving the run had gone to sleep. The Python processes froze with their sockets to vLLM half-open, and when the laptop woke the sockets were dead and the reads behind them never came back.

Nothing had degraded. A read was just hanging forever. That isn’t a slow box and it isn’t an error. You can’t wait it out and you can’t retry it. You put a clock on it.

I’d had a timeout in an old script. A rewrite dropped it. I put it back, added a read timeout on the client, and moved on.

That’s the kind of bug this whole project was made of. The bug isn’t the interesting part. The interesting part is that I could afford to chase it at all.

What I was actually doing

The job hasn’t changed since I last wrote about this tool.

Take 56 campaign sessions and distill them into a world_state.md — a compact doc that says who’s alive, who’s angry, what’s on fire right now. The thing I scan before every session.

The old version did it with the Claude API. Chunk the bible, extract per chapter, one big synthesis call. It worked.

It also costs real money every run. So I ran it once, looked at the output, and lived with what I got.

That last part is the whole problem. I didn’t see it until the meter went away.

How the ensemble actually happened

I, of course, would like to say that I read the research, used my brilliant insight, and designed a five-lens ensemble.

And that would be … well, less than true?

It started with one prompt.

Read a chapter, emit the facts. Six thousand tokens at a time. I ran it. It gave me some facts.

Then I ran it again.

Different facts.

I asked about it and got the standard answer: that’s normal, it’s non-determinism, the model isn’t deterministic, and you live with it. Which is true, and is also the kind of true that makes you stop thinking.

So I didn’t quite accept that. What if I just do it multiple times?

So I ran it twice and took both. And the union was better than either run alone — not because the model got better, but because two samples of a noisy process see more than one. That’s where self-consistency came from.

Then, looking at what I had, I saw that facts were clearly being missed. Things in the text that just weren’t getting emitted. So a sweep was added to get every named fact.

Then I noticed timelines were getting dropped. A whole sequence of events would collapse into a single fact, and the when would vanish.

Which sounds easy to fix until you sit with it. What is a number? What is a timeline? “Three days later” is a fact. “On the eighth day” is a fact. “After the rockfall” is a fact about ordering with no number in it at all. Figuring out what we even meant by temporal took its own round of tests. That’s the temporal lens, and it was not obvious.

Then a subtler one. The facts were interpreting when they should have been recording. The model would read a scene and tell me what it meant. It wouldn’t tell me that the character held another’s hand; it would tell me that the character liked the other. I wanted facts, not meaning.

And now I had too many facts. So time to merge.

Merge showed me something I couldn’t see before. The sweep pass, the one told to be exhaustive, was packing several facts into one. It read like one fact, if you think one fact is a sentence with three facts connected by and statements. So back to the prompt: one fact equals one state-change, with worked wrong-and-right examples. The tell turned out to be the ellipsis. If the model reaches for … to stitch a quote together, it bundled. Split it. That alone took bundling from 15% to 1%.

And only then, with a prompt stack that actually worked, did the real engineering question show up:

How do I run this?

Five prompts, multiple samples each, against two boxes.

So I had five prompts, but how do I run them correctly? The problem is that now any bug in how the prompts are run is going to cost money. Make a bug in your orchestration logic that comes from my pocket. That hurts. That would have stopped me there. I needed orchestration that fans all of it across both Sparks and merges it deterministically and I couldn’t afford a bug, unless, the cost of doing a run was free. And it was, *free*. So I could build the ensemble. And debug it. Like when the laptop hung.

Then I tried it on a few sessions. Then on six. Then, on the whole campaign.

By the end, the union of those passes was as good as the distill script.

This is the price of iteration

Read that sequence back and count the steps.

One prompt. Notice non-determinism. Run it twice. Notice missing facts. Add sweep. Notice dropped timelines. Argue about what a timeline even is. Add temporal. Notice interpretation creeping in. Split recording from inference. Build the merge. Discover the sweep is bundling. Fix the prompt. Then build the ensemble to run everything. Then scale it up in three steps.

Not one of those steps was a plan. Every single one was a reaction to something the previous run did wrong, which I could only see because I’d run the previous one and stared at the output.

That’s the part the meter kills.

Each of those steps is a run. On the API, each run is a charge, and most of them produce a result whose entire value is “huh, that’s wrong in a new way.” A null result, which costs you money. It made you smarter, but it cost you money. You can’t justify “let me run it twice to see if the non-determinism is hiding recall” when the second run costs money and might just confirm the first. So you don’t. You take the first okay-ish output, and you stop.

And if you stop at “run it twice,” you never see the missing facts, so you never add the sweep, so you never hit the bundling problem at merge, so you never write the bundling fix. The chain exists only because each link was cheap enough to follow on a hunch.

The ceiling wasn’t Qwen. Qwen could always do this. The ceiling was how many times I could afford to be wrong on the way to finding out.

That’s the price of iteration. When you’ve already paid it as capex, you can afford to pay it over and over.

What beat what

The local models didn’t win. Qwen did not outwrite Claude. The final synthesis still runs on the big API model because it’s low-volume, cross-entity, quality-critical, and not where I want to save money. And by the time it runs, the input has been reduced from 537K tokens to about 40K, so it’s a cheap call.

Local to explore. API to finish.

The better world_state came from the chain, and the chain only exists because each run was cheap enough to follow on a hunch. The old API result was never the API’s ceiling. A well-iterated API run could probably have matched it. I just couldn’t afford to be wrong that many times in a row, because under a fixed budget, every null result is pure loss, and the chain is mostly null results until the end.

But it’s even worse, because I had already distilled the data, with Anthropic’s API, I couldn’t justify trying to make it better.

A meter doesn’t only cap how many experiments you run. It biases you toward timid ones. It makes the weird, probably-won’t-work shots feel irresponsible.

Owning the box doesn’t make you smarter. It stops punishing you for looking.

Where this doesn’t hold

And here’s where we have to be careful.

Utilization is carrying that word “free.” The power was pennies, but the amortized cost per run is only low if the boxes stay busy. An idle Spark has a high effective cost per token. For an occasional personal pipeline, the money case is thin, and the real reasons are data locality, iteration freedom, and learning.

The engineering is the actual bill. Speculative execution, the timeout, the dead-socket hunt, that’s labor the API path externalizes to Anthropic’s SRE team. Own the serving, and you pay it yourself, in time, and you pay it again every time the stack drifts. It was the highest real cost here, by a lot.

And free experiments erode discipline. A budget imposes a crude “think before you spend” rigor. Remove it, and it’s easy to run 50 variants when 5 would have told you the same thing. Local doesn’t free you from experimental discipline. It just shifts the responsibility for supplying it from the meter to you.

Plenty of organizations are sitting on idle GPUs. The question worth asking isn’t whether to buy hardware. It’s whether there’s a sunk, underused inference asset you can route verifiable bulk work onto that’s reviewable, iterative, bounded, and fine to run in minutes instead of milliseconds.

Aggregation hit all four. It went local. Synthesis hit one. It stayed on the API.

Eight pull requests were what it took to find that line, one cheap experiment at a time. Including the four that did nothing, and the one where I was sure it was vLLM, and it was a laptop taking a nap.

That one was free, too.

---

The pipeline lives in CampaignGenerator — ensemble_extract.py, synthesise_world_state.py, spell_canon.py, and the per-lens prompts under config/agents/. The robustness work is PRs #64–#71. This is the retrospective, not the code.

Working Thesis

Software encodes culture. Culture increasingly depends on software. Therefore, the survivability of software systems determines the survivability of the societies that rely on them.

Origin of the Idea

I did not arrive at this concept through academic study.

I was exposed to cultures that had already survived:

• through family
• through relationships
• through lived experience

These were systems that:

• persisted across disruption
• adapted without disappearing
• survived even when institutions failed

At the same time, my professional life was focused on:

• backup
• disaster recovery (DR)
• business continuity (BC)

At some point, the connection became unavoidable:

The same principles used to keep software systems alive are the principles that allowed cultures to survive.

Once seen, it cannot be unseen.

The Core Question

What allows a system—cultural or technical—to persist over time, especially under disruption?

Not:

• correctness
• performance
• reliability

But:

Survivability

Definition of Survivability

A system is survivable if it can be re-created, adapted, and continue functioning after its assumptions about the environment break.

The Survivability Framework

A system survives only if it satisfies four properties:

1. Portability — Can it move without breaking?

Definition:

The ability to operate across environments without fundamental redesign.

Key Idea:

If it cannot move, it cannot survive change.

Failure Mode:

• vendor lock-in
• environment-specific assumptions
• tight coupling to platform

Diagnostic Question:

How long would it take to run this somewhere else?

2. Redundancy — Can it be re-instantiated independently?

Definition:

Multiple independent ways to recreate and operate the system.

Key Idea:

Copies are not enough—independent capability is required.

Failure Mode:

• single team knowledge
• “hero engineers”
• backups that cannot be restored

Diagnostic Question:

If the original team disappeared, could this system be rebuilt?

3. Sovereign Substrate — What do you control?

Definition:

The degree to which a system controls its environment.

Key Idea:

You cannot rely on what you do not control.

Failure Mode:

• external pricing/licensing control
• platform dependency with no exit path
• reliance on opaque infrastructure

Diagnostic Question:

What parts of this system could be taken away from us?

4. Identity Preservation — Can it change without dissolving?

Definition:

The ability to evolve while maintaining coherence and purpose.

Key Idea:

Too rigid → extinction

Too fluid → loss of identity

Failure Mode:

• breaking changes
• fragmentation
• drift without shared understanding

Diagnostic Question:

What must remain true for this to still be the same system?

The Hidden Layer: Assumptions

Every system encodes assumptions about its environment.

Survivability depends on how wrong those assumptions can be before the system collapses.

Portability Without Assimilation

Core Idea

A system must be able to move into a new environment without becoming indistinguishable from it.

The Trade-Off

Strategy	Benefit	Cost
Assimilation	Maximum local optimization	Loss of independence
Portability	Survivability, flexibility	Friction, constraints

Key Insight

The more perfectly a system fits its environment, the less likely it is to survive a change in that environment.

Important Clarification

Portability is not:

• avoiding all platform features
• building lowest-common-denominator systems

Portability is:

• controlled integration
• clear boundaries
• replaceable dependencies

You can use the environment—you just cannot become it.

The Cost of Portability

Portability introduces:

• friction
• constraints
• reduced short-term optimization

This is real.

But:

Portability trades short-term efficiency for long-term survivability.

Refined Principle

Assimilation optimizes for stability. Portability prepares for change.

Cultural Survivability (Observed Patterns)

From lived experience and exposure:

Systems survived when they were:

• carried by people
• replicated across many independent actors
• able to move across environments
• able to change without losing identity

They did not survive because they were:

• stable
• protected
• centrally controlled

Critical Insight

A culture written down is not alive. It survives only when it is continuously executed by people.

Mapping Culture → Software

Cultural Property	Software Equivalent
Carried by people	Portability
Many independent communities	Redundancy
Spaces of self-governance	Sovereign substrate
Continuity through change	Identity preservation

Backup, DR, and Culture

BDR Concept	Cultural Equivalent
Backup	Distributed memory (people, practices)
Disaster Recovery	Ability to re-establish in new environments
Business Continuity	Maintaining function during disruption
Infrastructure Control	Cultural autonomy

Key Realization

Backup and disaster recovery are not just technical practices—they are survival strategies for any system that must persist.

Modern Risk: Software as Cultural Substrate

Today, society depends on software for:

• identity
• finance
• communication
• knowledge

Which means:

We are encoding culture into systems that may not be survivable.

The Risk

Many modern systems:

• are not portable
• lack redundancy
• do not control their substrate

Therefore:

We are building cultural systems that cannot survive disruption.

Survivability Debt

Every time you sacrifice portability, redundancy, or control for convenience, you incur survivability debt.

This debt is only paid when:

• the environment changes
• assumptions break

The Engineer’s Blind Spot

Most engineers optimize for:

• performance
• integration
• correctness

But rarely ask:

Will this system survive if the environment changes?

The Survivability Test

Evaluate any system:

1. Can it move?
2. Can it be rebuilt independently?
3. Does it control its environment?
4. Can it evolve without losing identity?

If any answer is “no”:

The system is fragile—even if it appears reliable.

Core Principles

• Survivability > Reliability
• Optionality > Optimization
• Independence > Convenience
• Execution > Preservation

Final Insight

Systems do not survive because they are correct. They survive because they can adapt, be carried, and be re-created across changing environments.

One-Line Summary

If culture runs on software, then software survivability becomes a prerequisite for cultural survival.

Closing Perspective

I did not learn about survivability from systems that worked.

I learned it from seeing what remained when systems failed.

And now the question is:

Are we building systems that will remain?

Next Steps (Optional Expansion)

• Case Study: Vendor lock-in and infrastructure dependency
• Case Study: Long-lived cultural systems
• Practical: Survivability audit checklist for engineers
• Patterns: Designing for portability without losing capability

If you want, I can next:

• convert this into a PDF or nicely formatted essay,
• expand each section into full chapters, or
• build a practical engineering checklist/toolkit from this.