There is a pattern here.
We’ve seen it before.
In the late 1990s, the internet exploded into public consciousness and with it came a flood of people who could use tools but did not understand systems. They learned FrontPage. They learned Dreamweaver. They could upload files, wire together scripts, and make something blink on a screen.
They called themselves developers.
Investors funded them.
Media celebrated them.
Reality corrected them.
Billions evaporated.
What survived wasn’t the hype.
It was the infrastructure — protocols, databases, operating systems, security primitives — built quietly by people who understood failure, not demos.
We are back there again.
Only this time, the stakes are far higher.
Tool Use Is Not Engineering
Today’s version of the same delusion sounds more sophisticated, but it’s not.
“I orchestrate agents.”
“I use no-code.”
“I call APIs.”
“I shipped an AI product.”
No — you assembled abstractions you did not design, on top of systems you do not understand, under failure modes you cannot explain.
That is not engineering.
Engineering is not making something work.
Engineering is making something safe to exist under adversarial conditions and over time.
If you cannot answer:
what happens when this fails,
how it fails closed,
who has authority to act,
how execution is constrained,
what is irreversible,
what the blast radius is,
then you did not build a system.
You built a demo.
The Most Dangerous Phrase in Tech Right Now
“AI will handle it.”
This phrase is doing more damage than almost anything else in modern software.
Because AI does not “handle” authority.
Large models generate probabilistic outputs. They do not possess identity. They do not resolve permission. They do not understand boundaries. They do not know what they are allowed to do.
When you give an AI the ability to:
send emails,
change accounts,
move money,
grant access,
trigger workflows,
without invariant authority resolution before execution, you have already broken the system.
Not when something bad happens.
Not when it’s detected.
Not when a regulator shows up.
The system was invalid at design time.
Why This Collapse Will Be Worse Than the Dot-Com Bust
In the dot-com era, most bad startups lost money.
Today’s bad startups can:
leak sensitive data,
lock users out of accounts,
create regulatory liability,
trigger automated actions at scale,
move real assets in real time.
This is not banner ads and pets.com.
This is execution authority being handed to people who do not understand what that phrase means.
And the market is funding them anyway — because narratives are easier to sell than invariants.
Read This Before You Argue With the Next Section
Before taking a position on this — for or against — resist the urge to start by defending slogans like:
“no-code is bad”
“people aren’t real developers”
“AI tools are dangerous”
Those are downstream conclusions.
They are easy to strawman and easy to miss.
Start with the fundamentals instead.
Ask yourself — honestly:
Do you agree that some software systems are allowed to take real-world actions?
Almost everyone does.
Then ask:
Do you agree that some of those actions are irreversible?
Emails sent.
Money moved.
Access granted.
Records changed.
Again — almost everyone does.
Then ask the only question that actually matters:
Who or what is responsible for determining whether those actions are allowed to occur before they occur?
Every serious discussion about AI, automation, or software safety begins there.
Everything else is commentary.
How This Happens Without Anyone Realizing It
It’s not just that today’s bad startups can do these things.
They can do them without realizing they did them — because the people building them were never taught what a system is.
Nothing in their background trained them to recognize when:
an execution boundary was crossed
authority was exercised
an irreversible commitment was made
Not because the signals were hidden — but because they were never taught to look for them.
These are not engineers who ignored architecture.
They are people who were never exposed to it at all.
AI companies dropped powerful orchestration tools into the hands of non-technical roles — secretaries, managers, analysts, department heads — and told them they were now “AI builders.”
String together prompts.
Call an API.
Send email.
Access customer data.
Integrate some google sheets or excel.
Deploy a workflow.
Overnight, anyone who could operate a UI was implicitly granted the power to construct systems that act, decide, and execute — without any grounding in systems design, failure modes, authority resolution, or irreversibility.
This did not democratize engineering.
It abolished the distinction between using tools and owning consequences.
So when something “just happens,” it isn’t a mystery or a bug.
It is the predictable result of handing execution authority to people who were never trained to understand what execution authority is.
By the time something goes wrong, discovery is always post-hoc — because no one involved was taught how to recognize the moment when possibility becomes commitment.
And once commitment is made, reality does not rewind.
Ethics, Governance, and Compliance Start Too Late
A common response is:
“We’ll add guardrails.”
“We’ll monitor behavior.”
“We’ll govern outputs.”
“We’ll audit decisions.”
All of that happens after the system has already formed an executable state.
If your architecture allows an inadmissible action to exist — even theoretically — then governance is just documentation of failure.
Ethics cannot rescue a system that never resolved authority.
Compliance cannot fix an architecture that allows ambiguous execution.
Monitoring cannot prevent what has already been permitted to happen.
This is not a moral problem.
It is not a policy problem.
It is not a tooling problem.
It is an architectural admissibility problem.
The Real Divide (And It’s Not Political)
Ignore the noise. The divide is simple.
On one side:
People who think in screens, prompts, and flows
Who optimize for demos and narratives
Who have never designed for abuse, drift, or time
Who mistake abstraction for mastery
On the other:
People who think in states, boundaries, and invariants
Who assume failure by default
Who separate proposal from commitment
Who design systems that fail closed, not loudly
One group builds things that work.
The other builds things that are allowed to exist.
History is very clear about which group survives.
Most of This Will Disappear
A huge percentage of today’s no-code, low-code, AI-wrapper startups will vanish.
Not because AI failed.
Not because users didn’t want them.
But because reality eventually enforces invariants whether you designed for them or not.
Capital will be lost.
Reputations will reset.
The same people will claim they “saw it coming.”
They didn’t.
They just weren’t paying the cost yet.
The Quiet Work That Will Outlast the Cycle
What survives every bubble is not the hype.
It’s the work that:
didn’t trend,
didn’t demo well,
didn’t fit on a pitch slide,
didn’t promise magic.
The work that obsessed over:
authority,
admissibility,
irreversibility,
time,
and failure.
That work is being done right now — mostly ignored, mostly unfunded, mostly misunderstood.
And when this cycle collapses, it will quietly become the foundation everyone pretends they supported all along.
Final Thought
Ask yourself the hinge question:
“Who or what is responsible for determining whether those actions are allowed to occur before they occur?”
Using tools does not make you a builder.
Shipping demos does not make you an engineer.
Calling an API does not give you authority over reality.
If your system cannot explain why it is allowed to act before it acts, then it has no business acting at all.
Reality is unforgiving.
It always has been.
The only question is how much damage we allow before we remember that.