LLM Inevitabilism: The 'Inevitability' Trap and the Engineer's Identity Crisis

The debate you lost before you opened your mouth

Have you ever argued with someone who is seriously good at debating? I have. It sucks. You get thrown off balance over and over, forced to respond to a point you never saw coming. You find yourself defending the weak edges of your argument while the main thrust has already been abandoned somewhere behind you. Then you lose momentum, lose confidence, and eventually, the argument.

A close friend of mine used to win international debate competitions for fun back in university (he’s a fairly successful criminal barrister now). He told me one thing I never forgot: the only trick in the book, once you boil it all down, is to make sure the conversation gets framed in your terms. Once that framing is in place, the rest is just procedure.

Tom Renner wrote “The sound of inevitability” exactly at the moment he realized he was inside a debate that had already been framed for him, and the person doing the framing was not an engineer.

Inevitabilism: a borrowed word, a perfect weapon

Earlier this year Tom read The Age of Surveillance Capitalism by Professor Shoshana Zuboff (Harvard). One of the book’s greatest achievements is that it puts names to abstract phenomena that a lot of people feel but cannot articulate. Once you have a name for something, you can build an argument about it, explain it to strangers, and most importantly, unite opposition around it.

The key term here is Inevitabilism. When you read The Age of Surveillance Capitalism, you should notice this trap is not an LLM invention. It was running smoothly for two decades before that, just aimed at a different target: instead of “behavioral data will be collected, so accept it,” it’s now “AI will write your code, so accept it.”

The mechanism of Inevitabilism has two layers, and the second one is the dangerous one:

• Layer one - the future claim: The inevitabilist asserts that the future they perceive will inevitably come to pass. Not “could,” not “if we choose so.” Inevitably.
• Layer two - closing the space for discussion: Because that future is inevitable, the only response considered sensible is to prepare for it as best you can. The question “do we actually want this future?” gets replaced by “how do we adapt to it?”.

Layer two is what makes Inevitabilism an almost perfect debating technique. Anyone who sees a different future gets brushed aside with a single line: “you’re ignoring reality.” And the only conversations still worth engaging are those that already accept your premise. The framing is installed. The rest is procedure.

Three sentences that framed an entire industry

Tom quotes a few statements verbatim. I want to pin them up here so you can look closely at their structure, not to attack anyone personally:

“We are entering a world where we will learn to coexist with AI, not as its masters, but as its collaborators.” - Mark Zuckerberg

“AI is the new electricity.” - Andrew Ng

“AI will not replace humans, but those who use AI will replace those who don’t.” - Ginni Rometty

And the sharper modern version: Sam Altman with “AGI in a few thousand days,” a number far enough away that nobody can verify it, yet close enough to create a countdown feeling.

Read the structure inside these three sentences again. “AI is the new electricity” is not a technical description. Electricity is something inevitable, something you cannot avoid, something where anyone not using it is excluded from the economy. The sentence borrows the authority of a history that already ended in order to impose a future that hasn’t happened yet. “Those who use AI will replace those who don’t” is the purest form of the inevitabilist formula: it isn’t about where the industry is heading, it’s telling you that you will be replaced if you don’t get on board. And “coexist as collaborators” is interesting because it paints two parties as equals, while in reality you are the one paying for the tokens.

The economics underneath: why ‘inevitability’ must be manufactured

This is where you need to dissect things with dry numbers, because Inevitabilism isn’t a gratuitous psychological game. It’s a business strategy with a balance sheet.

Big Tech has poured hundreds of billions of dollars of CapEx into datacenters and GPUs over the past few years: Nvidia H100/H200, Blackwell clusters, optical interconnect, water-cooled infrastructure. This is not a small expense. GPU depreciation is brutal because the hardware loses value both to time and to generational progress (a Blackwell from this year doesn’t just get older, it gets replaced by the next generation). A locomotive can run for 40 years. An H100 cluster has only a few years to generate returns before a newer generation makes it uncompetitive.

That creates a very physical constraint, with nothing philosophical about it: that capacity must be filled with continuous compute demand.

For their older business lines, sales have already stabilized:

• Advertising: search and display have growth ceilings.
• Traditional cloud: close to commodity, margins squeezed.
• Phones, operating systems, app stores: no remaining headroom.

The only segment with room to multiply is selling or renting AI compute. So inevitability becomes the cheapest and most effective marketing tool they have. If every engineer believes AI is an irreversible future, then:

1. Companies start buying LLM subscriptions for their entire staff, without anyone evaluating ROI.
2. Engineers voluntarily move massive workloads onto their cloud (because the strongest models run there), opening up token-based revenue at margins far higher than IaaS cloud.
3. Startups and competitors feel forced to follow, creating an arms race, and that spending flows back into the same handful of datacenters.

Put simply: Inevitabilism isn’t just leadership psychology, it’s inventory that needs to be absorbed. Anyone who understands this understands why questions like “should we use an LLM for this?” are rarely received as a technical discussion. They’re received as resistance.

Meanwhile, on the engineer’s side

In June 2026, a post went viral: “LLMs are eroding my software engineering career and I don’t know what to do”. The author is a backend engineer who worked deeply in the finance and payment processing domain. I’d urge you to read the original, because this is not a complaint post. It’s a structured case study: the author describes three pillars that made up his professional identity, and each pillar collapses in order, with timestamps.

Note the eerie coincidence: those three pillars are precisely what Zuboff’s book and Renner’s post are talking about at the macro level, measured at the micro level of one person. One side is framing the future; the other is that future happening inside a single career.

Pillar one: domain knowledge becomes a commodity

The author learned a lot about the domain: PCI-DSS compliance, double-entry ledgers, escrow, reconciliation, payment lifecycle, idempotency for bank transfers. These aren’t things you pick up from a weekend blog read. They’re the kind of understanding that only forms after years of handling real situations by hand, usually after getting a few things wrong first.

The breaking point comes from a conversation with his manager: “you’re delivering code at a good pace, but you’re taking too long to write those Design Docs. Are you using AI? You should use more AI.” A superficially reasonable management request. But it pushes the author to use AI exactly where he believes himself irreplaceable: the part where disconnected pieces of the domain get connected into a correct design.

The result: the model could do it. Not perfectly, but well enough that the competitive advantage disappeared. And this is the single most important line in the whole post, so let me translate his meaning directly: all the knowledge he had accumulated - the trade-offs between implementations, how acquiring works, how to structure idempotency to prevent double-charges, everything - became useless. It’s now promptable.

That word “promptable” deserves a pause. Economically, a skill is valuable because it’s scarce. Promptable means it can be regenerated at a marginal cost roughly equal to the price of tokens. Everything promptable gets pushed down to the floor of inference cost.

Pillar two: debugging distributed systems

The author realized this before AI could even write code, so he thought of it as his last lifeline and kept it as his employability ticket. Debugging race conditions, deadlocks in production, distributed systems lacking observability, bugs that he states plainly were ones “I couldn’t solve in the past.”

Then the curve unfolded exactly the way backend engineers should pay attention to:

• Claude 4.5: solved about 60% of bugs given a stack trace plus context, usually a Sentry link with Sentry MCP. Sometimes it gave a solution that sounded plausible but was totally wrong.
• By 4.6, 4.7, GPT 5.5, Opus 4.8, plus the DataDog MCP: the one-shot rate jumped to 90%, including bizarre race conditions, unexpected corner cases, and especially third-party integration issues - exactly the zone where documentation is never complete, so an LLM supposedly couldn’t “learn” it. This is the counterintuitive part: the documentation is on the internet. It’s crawlable. It’s fine-tunable.

The author’s note - “bugs across distributed systems that lack distributed observability” - is an interesting detail, because it says the model isn’t just solving well-logged bugs. It’s solving bugs that humans had to grope through. I still think this conclusion deserves more careful reading than the author gives it: a model has no intuition about a system, it has a very strong form of correlation between code patterns and symptoms. But for economic purposes, those two things produce the same outcome. The author concludes about himself: “I’m just another off-the-shelf engineer now. I have no domain expertise that another Sr. engineer steering an LLM cannot match.”

Pillar three: code quality and architecture, downgraded to “taste”

The last pillar is where I find it most important technically, and also easiest to overlook. The author spent his career on Clean Architecture, Hexagonal, DDD, SOLID, refactoring, writing ADRs. Then he realizes two things at once:

1. Agents do a really bad job at keeping codebases organized. If you don’t steer them, they hit circular dependency issues faster than you’d think, duplicate code, meaningless comments, mix pure functions with side effects, disregard SOLID.
2. But the industry no longer values preventing that with an A-grade codebase. C or D code is now good enough. Because code is written for LLMs to read, not for humans to read.

I don’t want to rush to call the second conclusion correct. But I’ve seen a version of it firsthand many times and it’s genuinely scary: when the reviewer is another agent, “easy for humans to read” loses its economic reason to exist. And when that reason disappears, short-term maintainability constraints remain, but the incentive to comply with them does not.

This is where the author touches a very real staffing problem: he realizes he’s still employed, but he’s become a commodity. The company he mentions dropped “Software Engineer - Area” and switched to a plain “Software Engineer,” with team assignment decided after the offer is signed. That’s the signature of a labor market standardizing. The problem isn’t that you lost your job. The problem is that you lost your lane.

The technical cost of swallowing Inevitabilism whole

Now for the part I really want to say to my fellow backend engineers. When an engineer panics, they start putting LLMs where an LLM plainly doesn’t belong: validators, rule engines, cronjobs, search filters, ETL pipelines, state transitions. The reason is mundane: “I need evidence that I’m using AI.”

This pattern has a name in system design. It’s generalization overreach - using a general-purpose probabilistic tool for a deterministic problem. And the cost shows up on four measurable axes:

1. Non-determinism with no error ceiling

A regexp or a finite state machine produces identical results on identical input, forever (ignoring Unicode normalization and locale issues). Cognitively, this is an extremely strong property: you can reason about it, you can prove it, you can use it as an assumption in later reasoning steps.

An LLM call has an error rate you don’t know exactly at any moment. Temperature 0 doesn’t guarantee stable output: GPU batching, floating-point reduction order, and a provider silently updating the model all break invariance. In other words, you’re trading a property of the type “correct on every run” for a component that’s only correct “most of the time.” In a transaction system, that’s not a trade-off about coding speed. That’s a trade-off about what kind of system you’re operating.

2. Latency: from sub-millisecond to seconds, and the tail is what kills you

Concrete numbers: a validation loop in Go over a small struct runs at microsecond to sub-millisecond levels. On the same machine, no network hop. An LLM call, even a small model, is:

• At least one network round-trip: 20 to 300ms depending on location, and that location is frequently cross-region because models only run in a handful of datacenters.
• Provider-side queueing: when the provider is under load, latency grows non-linearly, and you don’t control it.
• Token generation time, which scales with output token count, not with the difficulty of the problem.

The average already hurts, but p99 is where your architecture collapses. LLM providers have very heavy tail latency, and you have no capacity planning on your side. That means the timeout budgets at your callers - the ones you carefully built after several postmortems - are now decided by an external system you have no SLO with. In an architecture with multiple layers calling each other, one component with a p99 dozens of times higher than the others reshapes the entire critical path, dragging in places you assumed were “unrelated.”

3. State drift and the debugging nightmare

This is the most serious and least-discussed consequence. A deterministic core can be verified with invariants: total debits equal total credits, balances always reconcile, no silent negative money. An invariant is a strong guarantee because it can be checked at every point in time, not just in tests.

When an LLM sits on the critical path of a state transition, you lose that ability. Individual steps may look reasonable, but errors accumulate without anyone noticing. And the worst part is that you can’t reproduce the bug. You have a wrong transaction in the database, no log tells you what the model “decided” on that run, and re-running the same input gives a different result. With a deterministic system, debugging is re-tracing the path and reading the trace. With an LLM in the middle, debugging is probability. You’re not debugging anymore, you’re gathering evidence.

4. Reversibility

Part of the cost isn’t at runtime, it’s in migration. When you push an LLM into a layer that should be deterministic logic, changing the model, changing the prompt, changing the API version all become migrations with a blast radius you can’t measure. In good architecture, changing a component’s implementation shouldn’t change its contract. Here, changing the model version changes the contract in a fuzzy way.

A design principle: Deterministic Core, Probabilistic Edge

I don’t mean “don’t use LLMs.” I’m saying something narrower and testable: LLMs are very powerful at the edge and very dangerous at the core. The boundary between those two zones isn’t an aesthetic opinion, it’s an architectural decision that can be written down, reviewed, and defended before any postmortem happens.

The classification criteria I usually use:

The diagrams below compare two flows. The first is the wrong architecture (all-in LLM on the critical path). The second describes a clean core with the LLM sitting at the edge.

graph TD
    subgraph "Anti-pattern: All-in LLM"
        A1["`HTTP Request
        POST /payments`"] -->|"network hop 30-300ms"| A2["`LLM Classifier
        decides transaction type`"]
        A2 -->|"network hop, unmeasurable p99"| A3["`LLM Validator
        checks business rules`"]
        A3 -->|"2% hallucination"| A4["`Postgres Write
        no invariant check`"]
        A4 --> A5["`State drift
        bug not reproducible`"]
    end

graph TD
    subgraph "Deterministic Core"
        B1["HTTP Request"] --> B2["`Validate & Decode
        struct tags, in-memory, ~5us`"]
        B2 --> B3["`State Machine
        valid transition from a compile-time table`"]
        B3 --> B4["`Postgres Transaction
        SERIALIZABLE + UNIQUE constraint`"]
        B4 --> B5["`Outbox Event
        written in the same transaction`"]
    end
    subgraph "Probabilistic Edge"
        B5 -->|"async, off the critical path"| C1["`Log Analyzer
        summarizes anomalies`"]
        C2["`NL Query Interface
        asks in plain language`"] -->|"read-only, pre-aggregated data"| B4
    end

The key point of the second diagram: the LLM is still present, still delivering value, but it touches the system in two safe ways. One, it only reads pre-aggregated data. Two, it only writes off the critical path and never writes into the state of a monetary system. No arrow goes from the probabilistic edge into the deterministic core in the write direction.

Battle-tested code: a state machine for the order lifecycle in Go

Enough theory. This is the example I use to show junior engineers on my team the difference between “an LLM decides” and “the code decides.”

Start with the wrong one. This is the type of code I’ve seen most often in reviews over the past few months:

// DON'T DO THIS.
// The LLM decides whether a transition is valid. Non-deterministic at the core.
func (s *OrderService) Transition(ctx context.Context, orderID string, action string) error {
	order, err := s.repo.Get(ctx, orderID)
	if err != nil {
		return err
	}

	prompt := fmt.Sprintf(
		"The order is currently in state %q. The requested action is %q. "+
			"Return JSON {\"allowed\": bool}.",
		order.Status, action,
	)
	resp, err := s.llm.Complete(ctx, prompt)
	if err != nil {
		return err
	}

	var d struct{ Allowed bool `json:"allowed"` }
	if err := json.Unmarshal([]byte(resp), &d); err != nil {
		return err
	}
	if !d.Allowed {
		return ErrInvalidTransition
	}
	// No transaction, no locking, no real audit trail.
	return s.repo.UpdateStatus(ctx, orderID, action)
}

There are four independent problems in this snippet, and none of them is “code quality.” They are semantic problems:

1. Race condition. Get followed by UpdateStatus is not a transaction. Two concurrent requests can both read StatusPending, both see it as valid, and both write. This bug has nothing to do with the LLM, but the LLM makes it harder to see.
2. No single source of truth. The set of valid transitions lives in the prompt, meaning it’s outside both the code and the schema. Nobody can review it. No type checking. No tests.
3. Unverifiable. You can’t write an invariant test for “only move from Pending to Canceled if funds haven’t been captured,” because that logic was never written in a checkable form.
4. Prompt drift. A provider updates the model and your business rules change silently.

Now the correct version. The transition table is defined at compile time, persisted to the database, and protected by optimistic concurrency.

package order

import (
	"context"
	"database/sql"
	"errors"
	"fmt"
)

type Status string

const (
	StatusPending   Status = "pending"
	StatusPaid      Status = "paid"
	StatusShipped   Status = "shipped"
	StatusDelivered Status = "delivered"
	StatusCanceled  Status = "canceled"
)

// transitionRules is the single source of truth.
// A map literal is type-checked by the compiler. No magic strings scattered around.
var transitionRules = map[Status]map[Status]struct{}{
	StatusPending: {
		StatusPaid:     {},
		StatusCanceled: {},
	},
	StatusPaid: {
		StatusShipped:  {},
		StatusCanceled: {},
	},
	StatusShipped: {
		StatusDelivered: {},
	},
	// delivered and canceled are terminal states.
}

var ErrInvalidTransition = errors.New("order: invalid transition")

// ApplyOrderTransition performs exactly one transition, atomically.
// The entire "is this allowed" decision is deterministic.
func ApplyOrderTransition(
	ctx context.Context,
	tx *sql.Tx,
	orderID string,
	from, to Status,
) error {
	if legal, ok := transitionRules[from]; ok {
		if _, allowed := legal[to]; allowed {
			// Conditional UPDATE: WHERE status = $from.
			// If a concurrent request wrote first, rowsAffected = 0 and we fail
			// instead of overwriting. This is optimistic concurrency, not locking.
			res, err := tx.ExecContext(ctx, `
                UPDATE orders
                   SET status = $1, updated_at = now()
                 WHERE id = $2
                   AND status = $3`,
				string(to), orderID, string(from),
			)
			if err != nil {
				return fmt.Errorf("order: update status: %w", err)
			}
			n, err := res.RowsAffected()
			if err != nil {
				return err
			}
			if n == 0 {
				// Not a system error: this is a signal that another writer
				// won the race. The caller should re-read and decide.
				return ErrConcurrentModification
			}
			return nil
		}
	}
	return fmt.Errorf("%w: %s -> %s", ErrInvalidTransition, from, to)
}

Note three properties of this version. First, the transition table is a map, and the type system ensures you can’t mistype a status name. Second, the “is it valid” check and the write happen in the same conditional UPDATE statement, so the race condition between two requests no longer exists. Third, it costs no network, no tokens, no odd tail latency. It’s just logic.

What about idempotency? This is worth noting because it’s a genuinely hard problem that an LLM may “appear” to solve. The deterministic way is to let the database do the work, not the model:

// IdempotencyKey is stored in a dedicated table with a UNIQUE constraint.
// Inserting a duplicate key returns a unique violation, and the caller knows
// this request is a retry of one already handled.
const insertIdempotency = `
    INSERT INTO idempotency_keys (key, order_id, response_hash, created_at)
    VALUES ($1, $2, $3, now())
    ON CONFLICT (key) DO NOTHING`

Here, the invariant isn’t guaranteed by Go code, it’s guaranteed by a database constraint. That’s a stronger level of guarantee: it stays true even if another process, another service, or some upstream bug writes into the same table. When you must choose between protecting an invariant with code and protecting it with a constraint, choose the constraint wherever possible.

And here’s where an LLM is actually useful in that same system:

// logDigest is a worker behind the Outbox. It only READS pre-aggregated data
// and writes to an operator notification channel.
// It never writes to orders or idempotency_keys.
func (d *Digester) SummarizeAnomalies(ctx context.Context, window time.Duration) (string, error) {
	events, err := d.repo.RecentFailedTransitions(ctx, window)
	if err != nil {
		return "", err
	}
	if len(events) == 0 {
		return "", nil
	}
	// If the LLM errors out or returns garbage, we lose a summary.
	// We don't lose data, don't lose money, don't corrupt state.
	return d.llm.Summarize(ctx, events)
}

This is the entire argument compressed into three functions. ApplyOrderTransition is the core, and it doesn’t know the LLM exists. SummarizeAnomalies is the edge, and it cannot write to state. This boundary is what you need to protect, not the model’s capabilities.

The questions Inevitabilism makes you forget to ask

After reading both source posts, I notice a list of questions that public discussion almost never reaches, because they’ve already been pushed outside by the “how do we adapt” framing. I list them here because these are the kinds of questions a staff engineer should ask during an architecture review:

• What’s the marginal cost of a request, and who bears it? A regex rule costs nothing. An LLM call costs money, every time, forever. In a system handling hundreds of millions of requests a day, that difference is infrastructural.
• Does your system stay correct if the provider goes down for six hours? If the answer is “no,” you’ve added a dependency entirely on a party you have no SLA contract with and no ability to self-host.
• Who is accountable when the output is wrong? Not the model. Technically, the accountable party is the person who signed the ADR saying “we decided to put an LLM here.” Do you want to sign that exact ADR?
• Has anyone measured it, or is it just belief? If nobody has data on the hallucination rate for your specific problem, every claim that “the model solves 90% of bugs” is an anecdote. Anecdotes are not a basis for system design.
• What knowledge are you throwing away that will take another ten years to rebuild?

That last question is the one I think about most. There’s an effect I see repeating across many teams: when the ability to reason from principles goes unused for a few years, the organization loses diagnostic capability. Not because people get worse, but because technical knowledge lives in tacit form. It exists inside the people who once went through a production incident at three in the morning. If nobody goes through one anymore, it dies with the generation.

Our side of it: technology is not destiny

This is where I want to speak plainly, because Tom Renner ends his post at exactly this point and I fully agree:

I am not convinced LLMs are the future. I’m even less convinced they’re the future I want. But what I’m most certain of is that we have choices, about what our future should look like and how we use machines to build it.

The argument that “technology is neutral” sounds reasonable but it skips a step. Technology is not destiny; technology is a set of tools humans choose in order to solve real constraints. Every choice has a group that benefits and a group that bears the cost. When someone presents a choice as if it were a law of physics, they’re hiding that choice step. And that hidden step is exactly where your agency gets stolen.

On the engineering identity question, I think the author of the viral post is looking at the right problem but concluding too quickly toward pessimism. The three pillars he describes are eroding, but the fourth axis he nearly touches is growing:

The ability to judge what should and shouldn’t be probabilistic.

This is not a skill called “taste” in the aesthetic sense. It’s a specific technical skill: read a problem and classify which zone it belongs to. Is this problem a deterministic problem disguised as a language problem? Does this problem need a guarantee, or just a good-enough estimate? If it goes wrong here, can we roll back, or do we lose data permanently? The person who can make that classification is the person who can build the right architecture, and the number of people who can do it is remarkably small when everyone is busy stuffing LLMs everywhere.

A real engineer is not someone “against AI.” That label is manufactured by Inevitabilism itself, so that you have no stance left except compliance. A real engineer is someone who knows exactly when NOT to use AI, and has enough confidence to write an ADR saying that at this layer, on this critical path, with this monetary data, we use a 0.2-millisecond state machine and a UNIQUE constraint, not a model call.

Wrap-up

The name Inevitabilism is valuable because it gives you a word for the mechanism. When a discussion gets bent from “do we want this?” into “how do we adapt to it?”, that’s not an objective technical fact asserting itself. It’s a debating technique, and there’s a balance sheet behind it.

On the technical side, the answer isn’t to oppose the tool. It’s to hold a clear boundary between the deterministic core and the probabilistic edge, and to have enough discipline not to move that boundary under organizational pressure. Your state machine, your idempotency keys, your constraints, your invariants: those are the things that don’t depend on whether the model gets updated.

And on the career side: if the value of your ten years of experience gets downgraded, don’t chase the framing that downgraded it. Learn the thing that framing can’t measure. Because the framing will change a few more times, while your judgment accumulates.

Technology is not destiny. Don’t let anyone frame the debate for you.