Why This Time Is Different: Following the Chain of Consequences

I have been thinking a lot about where software engineering is heading, and I keep arriving at the same conclusion: this time is different.

I know how that sounds. Whenever people worry about the tech industry, the usual reassurance is that we have been here before. There was the dot-com crash, then the financial crisis, and both times the industry recovered and came back bigger.

I do not think that reassurance holds anymore, and I want to show why rather than just say it. When I want to rely on a system, I list what it depends on and check whether each dependency still holds. So that is how I approach this. First I describe how I see past recoveries working, then I follow what is happening now one link at a time, and look at which of those dependencies are still in place.

How the old recovery loop worked

The way I see it, past downturns followed a recognizable sequence:

1. Demand fell, or money got expensive.
2. Companies reduced staff to match.
3. The people who left kept their skills, and many stayed close to the industry.
4. Demand returned.
5. Companies rehired, and because the work still needed juniors, juniors were trained again.

It was painful, but it was a loop, and loops correct themselves. For this one to close, four things had to be true:

• A. The cut was about demand, not about the work. The jobs were paused, not retired. When demand came back, the roles came back.
• B. Knowledge survived the cut. It lived in people who could be rehired, or who could teach.
• C. The training pipeline restarted. Seniors taught juniors on real work, because real work still had to be done by people.
• D. Failure was loud. When a company cut too deep, something visibly stopped working, and that signal reached the people who make budget decisions.

Underneath all four sits a quieter fifth assumption:

• E. Change moved at human speed. Systems changed about as fast as people could understand the changes.

Now the chain. Each link below is a decision or a consequence, and each one touches at least one of these assumptions.

Link 1: The cut is framed as substitution, not demand

Some companies now explain workforce reductions with a new reason. Not "demand has fallen", but "this work will be done by AI."

That changes what the cut means. A demand cut carries an implicit plan to rehire when demand returns. A substitution cut carries the opposite plan: the role is considered finished. There is no condition under which it comes back, because the reasoning never depended on demand in the first place.

Consequence: the trigger that used to reopen roles is gone. Assumption A no longer holds.

Link 2: Substitution starts with the entry-level work

Which tasks are easiest to hand to an AI tool? Well-defined ones. Boilerplate, small fixes, writing tests, updating documentation, triaging tickets, first drafts of configuration.

Those are exactly the tasks juniors used to learn on. They were never only output. They were the training ground: small enough to be safe, real enough to teach how the whole system fits together.

Nobody has to decide to stop training people for training to stop. It is enough to automate the work that the training happened inside.

Consequence: the apprenticeship layer thins out as a side effect. Assumption C no longer holds.

Link 3: Knowledge leaves, and it was never written down

Every long-lived system carries knowledge that is not in the code. Someone knows that an odd-looking setting is deliberate. Someone remembers the incident that explains why a particular validation exists. Someone knows which customer workflow cannot tolerate a certain kind of change.

That knowledge is part of the system. It just is not stored anywhere a tool can read.

In a demand cut, that knowledge sat in people who could be hired back. In a substitution cut, fewer seniors remain, no juniors are absorbing what they know, and the tools that replaced them can only read what was written. What was never written is simply gone.

Consequence: the system now encodes more about itself, in behavior nobody can explain, than its operators know about it. Assumption B weakens sharply.

Link 4: The rate of change goes up

Automation is very good at producing change. An agent can open more pull requests, generate more configuration and apply more fixes in a day than a small team could in a week.

So at the same moment that understanding of the system is shrinking (Links 2 and 3), the amount of change flowing into it is growing. The ratio of changes to people who understand those changes moves in the wrong direction from both ends.

Consequence: systems start changing faster than anyone can follow. Assumption E no longer holds.

Link 5: Errors travel instead of stopping

This is the technical heart of the chain.

When traditional software fails, it usually fails in a recognizable way. It throws an exception, crashes, times out, or returns something malformed that a type check or a schema rejects. The failure stops at a boundary.

A language model fails differently. Its wrong answers are well-formed, confident and plausible. They have the right shape, so any check that only looks at shape lets them through.

Now put several automated steps in a row. Step one makes a small contextual mistake. Step two treats step one's output as fact, because it looks like fact. Step three builds on step two. By the end, a misunderstanding has become state: records written, decisions taken, configuration applied.

Distributed systems have always had cascading failures. What is new is a participant whose mistakes look exactly like its successes.

Consequence: a small error in context becomes a system-wide error in state, and nothing along the way objects.

Link 6: Failure goes quiet

Put Links 3, 4 and 5 together.

Fewer people know what correct looks like. Change arrives faster than they can review it. And the component producing the errors makes them look correct.

The result is not an outage. Outages are loud, and loud is useful: an outage is a signal that travels all the way up to whoever controls the budget. The result is drift. A record that is slightly wrong. A customer who is quietly mis-served and leaves without saying why. A report that is off by an amount nobody thinks to check.

From the outside, the organization looks fine. The dashboards are green. So the conclusion drawn is that the cuts worked.

Consequence: the signal that used to tell a company it had cut too deep never arrives. Assumption D no longer holds.

To me, this is the most important link. The old recovery loop never depended on companies being wise. It depended on failure being visible. Take away visibility and the loop has nothing to respond to.

Link 7: The correction comes late, and it costs more

Drift does surface eventually. A regulator asks a question, an audit finds numbers that do not reconcile, or a customer raises something that cannot be ignored.

At that point the organization needs people who understand the system. The ones who did have moved on. The juniors who would have become those people were never hired, and it takes years to grow an engineer who can reason about a system end to end. That capability cannot be bought back quickly, and what can be brought in from outside comes at a premium.

So the correction is delayed twice: once by the time it takes a silent failure to become visible, and again by the time it takes to rebuild the skills to fix it.

Consequence: the recovery, when it comes, is slower and more expensive than the savings that started the chain.

The chain at a glance

Assumption the old loop relied on	Past downturns	Now
A. Cuts follow demand, so roles return	Largely held	Roles framed as retired
B. Knowledge survives in people	Largely held	Leaves, and tools cannot read what was never written
C. Training restarts	Held, after a dip	The training ground itself is automated
D. Failure is loud	Largely held	Plausible errors produce drift, not outages
E. Change moves at human speed	Held	Change outpaces understanding

So when someone tells me "we have been here before," this is my answer. In earlier downturns, the thing that shrank was demand. The capability to do the work stayed intact, waiting for demand to return. This time the capability itself is being taken apart, and the mechanism that would normally tell us to rebuild it is going quiet at the same time.

What would prove me wrong

This is my opinion, and I would rather name where it could be wrong than pretend it is certain. Here is where I could be:

• If organizations write down their implicit knowledge, Link 3 weakens considerably, and AI tools get the context they currently lack.
• If companies deliberately keep hiring juniors and give them meaningful work, Link 2 no longer follows from Link 1.
• If failures in AI-assisted systems are made visible by design, Link 6 does not happen, and the old feedback loop returns.

Notice something about that list. None of it depends on AI getting smarter. Every item is a decision about the system around the AI. That is the part I find genuinely hopeful.

Where engineers can repair the chain

Every link above is something engineering already knows how to address. None of it is glamorous, and all of it matters more now than it did before.

Keep people learning inside the loop (Link 2). Reviewing AI output is real engineering work, and it teaches. A junior who reviews each change an agent proposes, with a senior reviewing that review, can learn a system faster than one who spent a year writing boilerplate.

Write down the why (Link 3). Decision records, runbooks, and comments that explain intent rather than restate the code. Written context outlives the person who held it, and it has a second benefit: it is exactly the context an AI tool needs to stop making suggestions that are locally reasonable and globally wrong.

Put deterministic boundaries around probabilistic parts (Links 4 and 5). Validate meaning, not only shape. Run preflight checks before a change is applied. Keep human approval for consequential actions: production infrastructure, financial records, anything a person relies on. The architecture should always know the difference between "the AI suggested this" and "the system has verified this is safe to do." Those are two completely different statements.

Make failure loud again (Link 6). Every failure should produce a signal a person can read and act on: a clear message, a logged reason, an alert that reaches someone. This is the standard I build my own work around. I call it No Silent Failure, and it comes down to one line: software should never fail a person in silence.

Closing

AI is often described as a force arriving from outside and changing everything it touches. I think it is closer to a mirror with an amplifier attached. Give it a well-run organization, with good tests, written context, sensible permissions and careful review, and it amplifies all of that. Give it an organization reducing costs faster than it can understand its own systems, and it amplifies that instead.

This time is different, but not because the technology is so much smarter. It is different because the loop that used to correct our mistakes depended on three things: people who understood the systems, a pipeline that produced more of them, and failures loud enough to notice. The current path is removing all three at once.

The good news is that each of those is something we know how to build. It is careful, unglamorous work, and I think it is the most important engineering work of the next few years.