Don’t Look Up: What Happens When the AI Race Becomes More Important Than the Warning?
The people building frontier AI are asking whether we should slow down. Governments are asking whether we can afford to. Somewhere between those two questions is the future of AI.
The people building frontier AI are asking whether we should slow down. Governments are asking whether we can afford to. Somewhere between those two questions is the future of AI.
There is a scene in Don’t Look Up that has stayed with me.
A scientist discovers that a comet is heading toward Earth.
The mathematics are straightforward.
The danger is enormous.
The solution is technically possible.
And yet, somehow, the hardest part isn’t understanding the comet.
It’s convincing everyone else that the comet matters.
The scientists try.
Politicians calculate.
Businesses see opportunities.
The media turns catastrophe into entertainment.
The public scrolls past it.
Eventually, the question stops being:
Is the comet dangerous?
It becomes:
What happens to everyone’s incentives if we admit that it is?
That is why Don’t Look Up feels strangely relevant to the current artificial intelligence debate.
Not because AI is a comet.
Not because catastrophe is inevitable.
But because the movie understood something deeply human:
Sometimes recognizing a problem is easier than acting on it when everyone has a reason to keep moving.
And that is exactly the tension emerging around frontier AI.
The AI industry has reached its “Don’t Look Up” moment
In September 2026, Anthropic CEO Dario Amodei argued that frontier AI development should be deliberately paced so that safety and evaluation can keep up with rapidly increasing capabilities.
The important word is paced.
This isn’t necessarily an argument to stop artificial intelligence.
It’s an argument about whether capability should be allowed to consistently outrun our ability to understand, evaluate, and control increasingly powerful systems.
That distinction matters.
Because there is a huge difference between:
“Stop building AI.”
and:
“Don’t move faster than our ability to make sure what we’re building remains safe and controllable.”
Other technology leaders have expressed support for versions of this concern.
And then the political response pushed in the opposite direction.
“Whoever wins AI wins”
Donald Trump’s position represents a fundamentally different way of looking at the problem.
Instead of beginning with:
How fast can we safely develop AI?
the geopolitical question begins with:
What happens if we slow down and our competitors don’t?
From this perspective, AI is not just another software product.
It is strategic infrastructure.
AI affects:
economic productivity
scientific research
military capabilities
cybersecurity
industrial competitiveness
semiconductor demand
energy infrastructure
national security
global influence
And China is the obvious strategic competitor in this calculation.
So the argument becomes brutally simple:
If AI leadership determines future economic and geopolitical power, slowing down could be equivalent to giving your competitor an advantage.
That is a much harder problem than deciding whether AI is safe.
Because both sides can have legitimate concerns.
The people asking for caution may be right about the risks.
The people asking for speed may be right about the competitive pressure.
And that leaves us with a problem that looks less like a technology debate and more like a coordination problem.
Welcome to the AI race
Imagine two countries standing at a starting line.
Country A develops a powerful new AI system.
Country B sees it.
Country B accelerates.
Country A responds.
Companies compete for researchers.
Investors pour money into infrastructure.
Governments announce incentives.
Data centers expand.
Models become more capable.
Agents become more autonomous.
And eventually, slowing down becomes politically difficult.
Why?
Because slowing down only works if the other players slow down too.
If everyone agrees to move carefully, everyone may benefit.
But if you believe your competitor will continue accelerating, slowing down feels less like safety and more like surrender.
This is the uncomfortable heart of the AI race.
The system rewards speed.
And the technology may simultaneously require caution.
AI doesn’t need to be evil
This is where Don’t Look Up gives us an important lesson.
The comet doesn’t hate humanity.
It doesn’t have political beliefs.
It doesn’t want money.
It doesn’t want power.
It simply follows physics.
The danger comes from the interaction between the object and the system around it.
AI can create a similar kind of systems problem.
We don’t necessarily need an evil machine for things to go badly.
We need only:
increasingly capable systems
poorly understood behavior
enormous deployment
insufficient testing
economic incentives
competitive pressure
rushed decision-making
humans assuming everything will probably be fine
That combination can create serious problems without anyone explicitly intending harm.
And this is why the AI safety discussion shouldn’t be reduced to science fiction.
It is also a software engineering discussion.
The part engineers should pay attention to
For developers, terms like “AI safety,” “alignment,” “frontier risk,” and “AI governance” can sometimes feel disconnected from everyday engineering.
But the underlying problem is surprisingly familiar.
We already know what happens when software is deployed faster than it can be tested.
You get:
bugs.
You get:
security vulnerabilities.
You get:
unexpected interactions.
You get:
production incidents.
Now imagine a system that isn’t simply executing deterministic application logic.
Imagine one that can interpret natural language, reason across large amounts of context, call tools, write code, interact with APIs, and make decisions over long-running workflows.
Then give it memory.
Give it permissions.
Connect it to databases.
Connect it to other agents.
Let it operate continuously.
Then tell the engineering team:
“We’ll monitor it.”
Suddenly, that doesn’t sound like much of a strategy.
Production AI is a systems problem
This is one of the biggest lessons from building AI-powered products.
A production AI system isn’t just a model.
It is:
model + prompts + tools + data + permissions + APIs + users + business logic + monitoring + failure modes.
Consider an AI agent that can read a CRM.
That’s one level of risk.
Give it permission to modify customer records.
That’s another.
Allow it to send external emails.
Another.
Allow it to create accounts, spend money, modify infrastructure, or publish content without approval.
Now the risk profile changes dramatically.
The underlying model could remain exactly the same.
What changed?
The system around the model.
That is why AI safety cannot be reduced to asking whether a model is “smart,” “safe,” or “aligned.”
Architecture matters.
Permissions matter.
Observability matters.
Failure handling matters.
Human oversight matters.
Least privilege applies to AI too
Security engineering has had a simple principle for decades:
Give a system only the permissions it actually needs.
AI agents shouldn’t be exempt from that rule because they communicate through natural language.
If an agent only needs to read customer information, don’t give it write access.
If it needs to send an email, don’t give it unrestricted access to your entire communication system.
If an action can cause financial, legal, reputational, or irreversible consequences, introduce an explicit confirmation layer.
The more powerful the action, the stronger the control should be.
This isn’t anti-AI.
It’s good engineering.
Human oversight doesn’t mean human bureaucracy
There is another misconception worth challenging.
When people hear “human in the loop,” they sometimes imagine an engineer manually approving every AI action.
That’s obviously not scalable.
The better approach is risk-proportional oversight.
For low-risk tasks:
generate a draft
summarize a document
classify routine data
format information
Automate aggressively.
For high-impact tasks:
send money
delete data
change production infrastructure
make consequential decisions
expose sensitive information
Increase oversight.
The right question isn’t:
Should humans be involved in AI?
It is:
How much human oversight does this particular action deserve given the consequences of failure?
That is an engineering question.
Maybe “slow down” is the wrong phrase
One reason this debate becomes so polarized is the phrase:
“Slow down AI.”
People hear:
“Stop innovation.”
But that’s not necessarily what pacing means.
A better interpretation is:
Don’t allow capability growth to consistently outrun our ability to evaluate and control what we’re building.
Consider aviation.
We didn’t stop building faster aircraft because aircraft can crash.
We built infrastructure around aviation:
testing
certification
inspection
redundancy
pilot training
air-traffic control
incident reporting
emergency procedures
Progress continued.
But progress was surrounded by systems designed to make failure less likely and recovery more possible.
AI may need something similar.
Regulation isn’t a magic solution
It’s tempting to make this a simple argument:
AI is dangerous, therefore regulate it.
But regulation can introduce its own problems.
Poorly designed regulation can:
make compliance unaffordable for startups
favor large incumbents
slow useful research
freeze today’s assumptions into tomorrow’s law
create conflicting international requirements
push development toward less transparent environments
There is also a geopolitical problem.
If one country slows down while another doesn’t, the competitive pressure returns.
That’s why frontier AI governance isn’t simply a national policy problem.
It is also a coordination problem.
The race may not really be USA vs China
We keep framing the AI race as:
USA vs China.
But another race is happening underneath it:
Capability vs understanding.
Can our ability to build increasingly capable systems advance faster than our ability to understand what those systems are doing?
That’s the question I find most interesting as an engineer.
Imagine building a massive application without reading most of the code.
Then giving it access to your production database.
Then giving it administrator privileges.
Then allowing it to modify its own behavior.
Then deploying it globally.
Then saying:
“We’ll monitor it.”
Any experienced engineering team would immediately ask:
Where are the boundaries?
What are the tests?
What happens when it fails?
Who can stop it?
Can we roll it back?
Can we reconstruct what happened?
Can we explain why it did that?
As AI becomes more autonomous, those questions become more important.
Not less.
AI engineering is where the abstract debate becomes real
At Leopard, our approach to AI is grounded in building useful systems rather than simply putting a chatbot on top of an application.
Our AI & Machine Learning work focuses on practical AI applications, including structured context, retrieval, automation, and agentic workflows.
Our Tryneth case study is an example of what this looks like in a production environment.
The interesting part isn’t simply the model.
It’s everything around the model:
orchestration
APIs
authentication
data
usage tracking
permissions
business logic
monitoring
reliability
human interaction
That’s where AI becomes software engineering.
And that’s also where AI safety becomes practical.
What developers can actually do
We don’t control national AI policy.
We don’t control frontier model roadmaps.
We don’t control the geopolitical AI race.
But developers control the systems they build.
Here are a few principles worth taking seriously.
- Treat model output as untrusted input
A model can be remarkably capable and still be wrong.
Validate important outputs.
Use structured schemas.
Check assumptions.
Don’t allow generated content to automatically become trusted application state.
- Give agents narrow permissions
Use least privilege.
Separate read and write capabilities.
Restrict available tools.
Require confirmation for dangerous actions.
Make permissions explicit rather than implicit.
- Build observability from day one
For meaningful AI workflows, know what happened.
Track:
model calls
tool calls
important decisions
failures
retries
latency
token usage
cost
approvals
If you can’t reconstruct an agent’s behavior, debugging it becomes extremely difficult.
- Test the system, not only the model
A model benchmark tells you something about a model.
It doesn’t tell you everything about your application.
Test the complete workflow.
Test adversarial inputs.
Test tool misuse.
Test permission boundaries.
Test failure recovery.
Test external-service outages.
Test unexpected model output.
- Design for graceful failure
AI systems should have safe states.
If the model fails, the application shouldn’t necessarily fail catastrophically.
Use:
timeouts
retries
fallbacks
rate limits
circuit breakers
human escalation
kill switches
Reliability is part of AI engineering.
The irony of the current moment
For years, people warned:
AI might become too powerful.
Then AI became more powerful.
People said:
We need AI safety research.
Safety research expanded.
Companies began building increasingly autonomous systems.
Now some people inside the frontier AI industry are saying:
Maybe we should pace development.
And the political counterargument is:
What if someone else gets there first?
That’s the paradox.
The more strategically valuable AI becomes, the harder it becomes to slow down.
The harder it becomes to slow down, the more important safety becomes.
And the more important safety becomes, the more expensive it can feel to prioritize it.
That’s the loop.
We shouldn’t look away
I don’t think AI is literally the comet from Don’t Look Up.
That would be too simplistic.
AI can create extraordinary benefits.
It can accelerate scientific research.
It can improve software development.
It can automate repetitive work.
It can make sophisticated tools accessible to smaller teams.
It can help researchers and engineers solve problems that were previously too expensive or time-consuming.
The answer isn’t panic.
The answer is engineering.
Testing.
Monitoring.
Red-teaming.
Independent evaluation.
Security.
Governance.
Transparency.
Human oversight.
International coordination.
And, where necessary, pacing.
The question isn’t whether we should build AI
We should.
The real question is:
Can we build increasingly powerful systems without becoming less capable of controlling them?
That’s the conversation worth having.
Not:
“AI will destroy humanity.”
Not:
“AI will solve everything.”
But:
How do we make powerful AI useful, reliable, observable, secure, and controllable?
That’s an engineering problem.
And unlike the comet in Don’t Look Up, we still have the opportunity to do something about it.
So let’s not look away.
Let’s look up.
Explore more from Leopard
If you’re interested in the engineering side of this discussion:
AI & Machine Learning — practical AI systems, retrieval, automation, and agentic workflows.
Tryneth — an example of AI-agent orchestration inside a production SaaS environment.
Work & Case Studies — more examples of software, AI, and product engineering.
Leopard — learn more about our work.
Join the conversation
Should frontier AI development be deliberately paced so that safety and evaluation can catch up?
Or does slowing down create an unacceptable strategic disadvantage in the global AI race?
I’d especially like to hear from developers building AI agents and AI-powered products.
#AI #ArtificialIntelligence #AISafety #AIEngineering #MachineLearning #SoftwareEngineering #AIAgents #ResponsibleAI #AIAlignment #AIRegulation #FutureOfAI #Technology