The answer may lie in artificial intelligence. And Big Tech may simply be where the pattern is easiest to see.
Big Tech has never had so much capacity to turn ideas into products.
New products and features arrive every week. Interfaces change overnight. Products that once required entire teams can now be prototyped by one person over a weekend, usually with suspicious amounts of coffee and an artificial intelligence chatbot insisting that everything is production-ready.
Yet the systems we depend on seem increasingly fragile.
Between the first quarters of 2024 and 2025, average downtime for APIs increased by 60%. Weekly downtime rose from approximately 34 to 55 minutes, according to Uptrends, based on two billion production API checks. [1]
In its report covering the first half of 2026, IncidentHub recorded 30,246 incidents across 1,082 cloud and SaaS providers. The figures depend on what each provider publishes and how incidents are classified, but they reveal the enormous number of failures hiding beneath an ordinary working day. [2]
These measurements use different methodologies. They cannot be neatly merged into a graph titled “Everything Is Getting Worse,” however tempting that graph might be.
Nor do they prove that artificial intelligence is causing Big Tech outages.
Still, the overlap deserves more than a shrug.
We are producing more software, changing it more frequently and automating more decisions. Meanwhile, configuration errors, cascading failures and interruptions continue to appear across some of the most sophisticated technology organizations in the world.
Perhaps these trends are merely sharing a timeline.
Perhaps they are beginning to share a cause.
An Economist and a Calculator
This thought began with two events that seemed unrelated.
The first involved an economist rebuilding a company website with artificial intelligence.
He had no traditional software engineering background. Yet he could describe what he wanted, generate pages, modify components and gradually turn an idea into a functioning product.
A few years ago, that would probably have required a designer, a developer and several meetings in which someone promised that the missing button would arrive in the next sprint.
Now he could build it himself.
That is impressive. It is also where the harder questions begin.
Building the page is one problem. Preserving the reasoning behind it is another. As the project grows, someone still has to balance design, security, architecture, infrastructure costs, scalability and long-term maintenance.
Years spent designing systems—and watching them fail in ways nobody predicted—cannot be compressed into a clever prompt. Experienced engineers still make mistakes. Experience simply makes them better at recognizing which questions deserve suspicion.
What happens when the person guiding the model does not know which context is missing?
The second event began with the Windows Calculator on my PC refusing to open.
I ran integrity checks and inspected the system. When that failed, I tried reinstalling the application. The reinstall failed too, suggesting broader corruption in the Windows application and update subsystem.
After a few hours, the answer arrived from somewhere far beyond my computer.
Microsoft was experiencing an Azure outage affecting Windows Update, Microsoft Store downloads and related services. [3]
Hours of reasonable investigation had been consumed by another Big Tech outage.
The first scene showed how AI lowers the barrier to building software. The second showed that experience, large engineering teams and sophisticated processes still cannot eliminate failure.
The uncomfortable part is what both scenes have in common: more code, more automated decisions and less human attention available for each change.
If the most experienced technology organizations are struggling to keep reliability aligned with production speed, what happens when a company’s software engineer is, quite literally, an economist with a chatbot?
Five Times Faster Is Hard to Ignore
I have seen the benefits directly, no hype required.
Across my projects, artificial intelligence has increased delivery speed by roughly two to five times compared with last year.
An integration that previously required several days can sometimes be drafted in hours. Legacy code can be mapped and explained. Errors can be investigated across thousands of lines.
A working prototype can emerge while the product discussion is still fresh, before everyone forgets why the meeting was scheduled in the first place.
Outside software teams, the effects may be even more transformative.
A finance department can build a dashboard that consolidates information from multiple sources. A small business can turn a spreadsheet-based process into an internal application instead of waiting months for a traditional project.
This is a genuine expansion of human capability.
It also changes the bottleneck.
Writing the first version becomes cheaper. Determining whether that version is correct, secure and sustainable remains expensive.
Research from the DevOps Research and Assessment program, known as DORA, found this tension at an organizational level. In its 2024 data, a 25% increase in AI adoption was associated with a 1.5% reduction in delivery throughput and a 7.2% reduction in delivery stability. The researchers suggested that faster code generation could lead to larger batches of changes, making review slower and instability more likely. [4]
By 2025, the relationship with throughput had improved. DORA found that AI could increase delivery speed, but often at the cost of stability when the organization’s foundations were weak. Its broader conclusion was that AI acts as an amplifier, magnifying the strengths and weaknesses already present inside a company. [5]
Speed was never the whole system.
AI simply made that easier to forget.
When Plausible Becomes Dangerous
Artificial intelligence is very good at producing plausible solutions.
Plausible is a useful quality in a presentation. It is less reassuring in a system responsible for money, customer data or access permissions.
An AI-generated feature may work perfectly during a demonstration and duplicate transactions when a user clicks twice.
A website may look polished while quietly damaging accessibility, search visibility or security.
The integration handles the ideal path beautifully, right until the connection drops halfway through a payment.
The code may compile.
The interface may open.
The automated tests may pass.
And the underlying decision may still be wrong.
This is software’s version of AI slop: output that is cheap to generate, convincing at first glance and expensive for someone else to review.
A 2026 preprint analyzing 1,154 posts across Reddit and Hacker News found recurring concerns about review friction, codebase degradation, declining trust and costs transferred to maintainers. [6]
A related paper described the result as a tragedy of the commons. Generating another block of code, pull request or bug report is nearly free for the person using the tool. The cost arrives later, on someone else’s screen. [7]
AI has made the first draft almost free.
Ownership of the fifth revision remains stubbornly expensive.
And that assumes the AI still remembers what happened in the first revision.
It gets worse.
The Project Grows. The Context Does Not.
Every mature system contains a history larger than its code.
A strange validation rule may exist because of a customer incident three years ago.
A field may remain apparently unused because an integration still depends on its presence.
An awkward architectural decision may be the least dangerous outcome of five previous awkward architectural decisions.
Humans struggle to retain all this context. Ask any senior engineer who has spent ten years at the same company why a seemingly useless piece of code still exists. The answer often begins with, “Because in 2020…”.
Artificial intelligence has an additional constraint: it can only reason over the information currently available to it.
As a coding session grows, the model’s context fills with messages, files, command outputs and previous decisions. Important information receives less attention—or is summarized, compressed and eventually pushed aside to make room for whatever comes next.
Research on long-context models found that performance can decline depending on where relevant information appears. Models often did better when evidence sat near the beginning or end and worse when it was buried in the middle, even when designed for long contexts. [8]
Anthropic documents similar limitations in coding workflows: context fills quickly, performance degrades, and long sessions accumulate files and command outputs that distract the model. [9]
Meanwhile, the real project continues outside the window.
It lives in contracts, production data, business rules, forgotten discussions and the memories of people who no longer work there.
As the gap grows, the model can make locally sensible decisions that contradict the wider project.
It may revive an obsolete requirement.
It may ignore a restriction introduced several weeks earlier.
It may identify a pattern where there is only coincidence.
It may correctly change one component while quietly breaking an assumption elsewhere.
The larger the system becomes, the more convincing an incomplete answer can look.
When the Reviewer Trusts the Suspect
There is another participant in this story: the human who is supposed to catch the mistake.
Microsoft Research surveyed 319 knowledge workers and collected 936 firsthand examples of generative AI use at work. Greater confidence in AI’s ability was associated with less reported critical thinking. Greater confidence in the workers’ own ability to perform and evaluate the task was associated with more critical engagement. [10]
This does not demonstrate that AI is making people incapable of reasoning. The study measured reported behavior and perceived cognitive effort.
It suggests a quieter problem.
When a tool produces good results often enough, users may gradually spend less energy challenging it.
This matters because reviewing a complex solution can require more expertise than producing its first version.
A persuasive report may hide a false premise.
A test suite may simply confirm the assumptions that produced the bug.
A polished explanation may confidently describe something that never happened.
Language models can produce plausible but false statements while preserving the tone and structure of a correct answer. Even as models improve, confident errors remain a persistent technical problem. [11]
Confidence, after all, is among the cheapest things a language model can generate.
The risk becomes sharper when the same AI acts as the sole interface for the entire process.
It writes the code.
It generates the tests.
It interprets the results.
It reviews the implementation.
Finally, it reports that the task has been completed successfully.
One mistaken interpretation can quietly survive every stage without ever meeting an independent perspective.
The model may overlook a serious flaw or invent one that never existed. Either way, the explanation often looks more complete than the investigation behind it.
The feedback loop sustains itself.
AI produces a plausible solution.
The human reviews it less carefully because the previous ones were good.
The mistake enters the project.
Next time, that mistake returns as context.
The model reads yesterday’s error as today’s established decision and builds accordingly.
Yesterday’s slop becomes tomorrow’s specification.
Agentic systems extend this problem beyond suggestion. Models can now plan, use tools and execute multi-step workflows with less supervision. Every additional degree of autonomy expands both what they can accomplish and how far a mistaken interpretation can travel. [12]
We are still discovering where autonomy improves the work, where it compounds mistakes and how much supervision each process requires.
This is Where You Come In
At this point, it would be comforting to dismiss all of this as a Big Tech problem.
Smaller companies do have simpler systems. They also tend to have thinner review processes, less test coverage and weaker monitoring, which is less comforting than it sounds.
The danger may not initially appear as a spectacular outage.
It may appear as a report with slightly incorrect numbers.
A customer may receive the wrong notification.
A financial process may silently exclude transactions.
A permission rule may expose information to the wrong user.
A feature may work today while making every future change slower and riskier.
Nothing crashes.
The system can remain online while the business process underneath it is failing.
The sensible response is to preserve the acceleration and strengthen the braking system.
In projects where we achieved two to five times greater delivery speed, sustainable gains required reviewing architectural decisions, separating changes into smaller units, testing abnormal behavior and validating outputs against the real business process.
Monitoring, rollback and independent review became more important than ever.
The first version became less precious, while the evidence that it worked became far more valuable.
The economist rebuilding his website represents something extraordinary. Technology creation is becoming accessible to people previously excluded by cost, time or specialized knowledge.
The Calculator incident represents the other side of that opportunity. Even mature systems can become so interconnected that a remote failure sends someone searching through the wrong machine for hours.
Between those two scenes sits the promise of artificial intelligence, followed closely by the bill.
We are learning to build faster than we are learning to remain responsible for everything we build.
The progress is real.
But visible progress can be deceptively shallow.
A screen that loads, a test that passes or a confident report can be evidence that something works. None of them, alone, proves that the system is correct, resilient, affordable or maintainable.
Perhaps artificial intelligence is contributing to the recent instability seen across large technology platforms.
If so, Big Tech outages are not merely distant failures in unusually complex systems. They may be the most visible expression of a broader imbalance: organizations gaining the power to change software faster than they can understand the consequences.
Which means this article was never really about Microsoft, Google or Amazon.
If your company can now produce five times more changes, can it also understand five times more consequences?
References
[1] Uptrends, The State of API Reliability 2025
https://www.uptrends.com/state-of-api-reliability-2025
[2] IncidentHub, H1 2026 Cloud and SaaS Reliability Report
https://blog.incidenthub.cloud/h1-2026-cloud-saas-reliability-report
[3] Microsoft, Windows Message Center
https://learn.microsoft.com/en-us/windows/release-health/windows-message-center
[4] DORA, Impact of Generative AI in Software Development
https://dora.dev/ai/gen-ai-report/
[5] DORA, State of AI-assisted Software Development 2025 and 2025 Year in Review
https://dora.dev/research/2025/dora-report/
https://dora.dev/insights/dora-2025-year-in-review/
[6] Baltes, Cheong and Treude, “An Endless Stream of AI Slop”: How Developers Discuss the Burden of AI-Assisted Software Development
https://arxiv.org/abs/2603.27249
[7] Baltes, Cheong and Treude, AI Slop and the Software Commons
https://arxiv.org/abs/2604.16754
[8] Liu et al., Lost in the Middle: How Language Models Use Long Contexts
https://aclanthology.org/2024.tacl-1.9/
[9] Anthropic, Best Practices for Claude Code
https://code.claude.com/docs/en/best-practices
[10] Microsoft Research, The Impact of Generative AI on Critical Thinking
https://www.microsoft.com/en-us/research/wp-content/uploads/2025/01/lee_2025_ai_critical_thinking_survey.pdf
[11] OpenAI, Why Language Models Hallucinate
https://openai.com/index/why-language-models-hallucinate/
[12] Anthropic, Trustworthy Agents in Practice
https://www.anthropic.com/research/trustworthy-agents
