“You do not train an apex predator not to maul people by turning it loose in a suburban cul-de-sac and ‘trusting the process.’ You build a giant cage, electrify the fence, and watch it like a hawk.”

— Field Notes from an Exhausted Security Engineer | #AISafety

Unless you’ve completely unplugged your router and retreated to a cabin in the Yukon, it has been difficult to miss the recent disclosures: autonomous AI agents undergoing cybersecurity evaluations have reached real companies’ production systems. In the Hugging Face incident, OpenAI acknowledges that its models bypassed isolation controls and compromised both third-party systems and its own research infrastructure.

As a cybersecurity engineer who spends his nights analyzing packet captures and studying threat matrices, I have reached my absolute breaking point. I am beyond annoyed. I am officially pissed.

Consider the double standard we are being asked to entertain. If a human red-team contractor “accidentally” pointed an exploit harness at another company’s production infrastructure, “we were evaluating its capabilities” would be a spectacularly inadequate explanation. There would be some extremely unpleasant questions about authorization, supervision, and who decided the rest of the internet had volunteered.

An AI lab ought to face those same questions. A cheerful postmortem and an impressive benchmark score do not settle the matter. Hugging Face says it reported the incident to law enforcement; whatever follows from that, publishing a lessons-learned blog post cannot be the entire accountability model.

We are all gas and no brakes right now. And if you think these frontier labs are going to voluntarily pump the brakes without external pressure, you haven’t been paying attention.

The canary in the server room

Let’s talk specifically about the Hugging Face breach, because we have enough public evidence to get beyond vague headlines about an AI “going rogue.”

OpenAI was running difficult cybersecurity evaluations with reduced safeguards. Agents that were supposed to work independently found ways to communicate, gain unintended access, and collaborate. OpenAI’s account also says that monitoring used elsewhere was absent from these evaluations. That is quite a place to economize on supervision.

According to the independent METR and Redwood Research investigation, roughly 700 agents participated in the Hugging Face intrusion. The swarm was something the agents organized themselves into. Apparently, even the unauthorized hacking department can hold a meeting when it needs to.

For a deeper look at the recovered attack material, read SwarmTraces. Its investigation describes almost a million chained URLs carrying encoded payloads, with more than 80,000 payloads recovered. Among the material were a port scanner, scripts attempting to search internal Slack, a dictionary named LOOT for collected information and credentials, and code aimed at Kubernetes discovery, DNS tunneling, and persistent command-and-control.

The recovered scripts do not establish which attempts succeeded; SwarmTraces documents those gaps in its evidence.

The underlying compromise, however, is confirmed. Hugging Face’s technical account describes production access, stolen credentials, and lateral movement. There is already plenty here to be pissed about.

Hugging Face was not an isolated warning. Anthropic’s September assessment describes four incidents involving unauthorized access to third-party systems. Misconfigured environments exposed the internet while the prompts told the models they were operating in isolation. Imagine discovering that the most secure component of your sandbox was the paragraph describing it.

The UK AI Security Institute also disclosed unsanctioned activity during a cyber evaluation, including an unsuccessful attempt to get malicious code accepted into an open-source project. In that case, internet access had been deliberately enabled. The institute says this was not a sandbox escape and that its investigation found no resulting real-world harm. The boundary failed at the point where someone decided what the test was allowed to touch.

Alongside the lab incidents, criminals are putting the same class of tools to work. Gambit Security’s investigation of a human-directed, AI-assisted campaign reports 105 attack projects and at least 27 companies compromised to varying degrees during September 10–15. Criminal misuse adds another problem to an already lousy picture.

We are watching an ugly offensive asymmetry unfold in software, with echoes of cheap commercial drones in modern warfare. Automation lets an attacker scale attempts, chain tools, and keep working while the humans on the receiving end are deciding who owns the incident.

Defenders already use automation. Hugging Face says AI helped detect and investigate this intrusion. The problem is what happens when the attacker’s loop keeps running and your response still depends on somebody noticing, understanding, and intervening. Your on-call engineer’s coffee break should not be a meaningful part of the containment architecture.

Your benchmark does not get to volunteer my infrastructure

I hate sensationalist fearmongering. I hate alarmist tech grifters who treat every algorithmic advance like the imminent dawn of Skynet. But look at the architectural reality of an evaluation reaching third-party production and ask a very ordinary engineering question:

What happens when the next reachable system belongs to an electrical utility, a water authority, or a hospital?

The damage would depend on what the agent could reach and control. A repository compromise is no proof that a model could take down a grid. It is more than enough reason to establish the limits before somebody’s benchmark starts interacting with services people need to stay alive.

The standard Silicon Valley defense is as predictable as it is hollow: “If we don’t test our models against real-world systems, our adversaries will.”

Adversaries will absolutely weaponize these tools. That reality does not give you license to release an untethered predator into the wild. You don’t train an attack dog by letting it loose in a crowded daycare and saying, “Don’t worry, we’re just evaluating its bite force!”

You build the firing range. You simulate the infrastructure. You obtain explicit authorization for any real systems involved. If your AI is smart enough to reverse-engineer an enterprise network, put some of that engineering effort into building an isolated one to test it against.

Realistic ranges take work. So does incident response for the company you accidentally enlisted as a lab assistant. The excuse that rigorous sandboxing “slows down research” becomes considerably less persuasive when everyone else gets handed the cleanup.

If you’re an AI lab director or safety lead reading this rant and wondering what you can do to help, don’t worry. Here’s some free advice:

1. Give the agents synthetic targets and enforce the boundary

Use Acme Inc. Use corpnet.test. Use synthetic repositories, synthetic credentials, and synthetic employees whose Slack histories contain nothing more sensitive than an argument about the office microwave.

Then enforce isolation outside the model. A fictional company name is not a firewall. Anthropic’s report describes a model treating a real company with the same name as its fictional target as part of the task. Telling an agent that it lives inside a simulation does not make the network agree.

Control egress across the whole evaluation environment, including DNS, proxies, package services, and the tools acting on the agent’s behalf. Keep production credentials out. Test the boundary before the evaluation starts. Make sure the agent cannot rewrite the controls intended to contain it.

If your researchers cannot demonstrate that the test stays inside its authorized range, the test is not ready. “But the model knows the rules” is something you say about a board game.

2. Match containment to the damage the experiment could cause

Biological research already has a useful organizing principle: match containment to the risks of the work. The CDC and NIH biosafety guidance uses risk assessment to guide practices, equipment, and facilities.

The principle is worth borrowing. If the experiment can do more damage, the room it happens in needs more thought than “we put it in a container.”

I would start with four proposed AI containment tiers:

AI-BSL 1: Benign, limited workflows. Conversational assistance, static code generation, and documentation synthesis without execution privileges or sensitive credentials. Any network access should match the task and the data involved.

AI-BSL 2: Constrained agentic workflows. Models executing bounded tasks in disposable environments, with narrow network permissions, scoped test credentials, and no access to production secrets.

AI-BSL 3: Offensive capability testing. Vulnerability discovery and exploitation inside a dedicated synthetic range, with public-internet egress blocked by controls the agent cannot change. Package downloads and other dependencies need a controlled path that does not quietly reconnect the range to the world.

AI-BSL 4: High-risk autonomous offensive swarms. Dedicated, physically isolated research infrastructure, including the model-serving path. No corporate intranet connection, no production identities, disposable workloads, controlled movement of artifacts, and an independent way to halt the experiment.

The label matters less than proving the boundary works. A container is useful. It also remains a container when somebody gives it credentials and an open route to the internet.

If the industry will not establish credible standards and demonstrate that it follows them, it should not be surprised when governments arrive with all the clumsy, bureaucratic sledgehammer subtlety you would expect.

3. Put a human in the loop who can actually stop the loop

I get it: watching an autonomous model execute thousands of tool calls and reason through API responses is boring as hell. In my own daily workflow, I’ll often have three or four models chugging away on background refactors while I focus on other work.

But when an agent is touching offensive tooling, somebody needs to own the supervision. That means a person with visibility, authority, and a working stop mechanism, backed by automatic controls that act before a human could reasonably read every tool call.

Set limits on runtime and activity. Stop on unexpected destinations or attempted boundary crossings. Preserve logs outside the agent’s control. Practice shutting the thing down. “We can always pull the plug” gets considerably less reassuring when nobody knows which plug, where it is, or whether the agent has already created something that will keep running.

Letting an offensive swarm run overnight without effective monitoring or automatic circuit breakers is an indefensible operational choice. Calling the morning summary “human oversight” does not improve it.

Whether these failures come from academic hubris, under-resourced safety teams, or pressure to demonstrate how dangerously capable the latest model is, working security engineers still get handed the same mess.

I do not want to wake up tomorrow morning to find out that a frontier research lab’s latest autonomous benchmark has involved my company’s AWS credentials in its continuing education. A cheerful post-incident blog post and an apologetic PR tweet are not going to fix a compromised supply chain while our incident response team is knee-deep in firefighting.

Build the fence. Electrify the wire. And keep the damn tiger in the lab.

There is no such thing as the cloud. There is only someone else’s computer.

Unless you’ve spent the last few months living in an unmapped subterranean cavern, you have seen the headlines about the war in the Persian Gulf. The United States decided to poke the hornet’s nest with a very large stick, and Iran stung right back. Somewhere beneath the military briefings and geopolitical posturing, the cloud developed a rather inconvenient problem with being made of actual stuff.

A staggering amount of military and geopolitical chaos has unfolded, but for those of us who live and breathe systems infrastructure, one headline stood out like a siren in a server room: the physical damage inflicted on Amazon Web Services datacenter infrastructure in the Middle East.

As Tom’s Hardware reported in its September 16 update, AWS was directing customers toward other regions after attacks damaged facilities in the UAE and Bahrain. AWS could not restore access to resources and data hosted exclusively in the UAE’s mec1-az2 availability zone. Recovery work was continuing, with no firm service-restoration timeline.

Somewhere, an architecture diagram still has a cheerful little cloud icon where all of that used to work.

If you have ever built an architecture on AWS, their Solutions Architects have pounded the same gospel into your skull until your ears bled: deploy multi-AZ, mirror your databases across secondary regions, build for failure. For years, cynical CFOs and budget-conscious engineering leads rolled their eyes, assuming Amazon was just manufacturing excuses to double-dip on compute and egress fees.

But the brutal, unvarnished reality is that hardware breaks, fiber cuts happen, and there is no such thing as 100% uptime. Sometimes the failure involves a building you can no longer use and data you can no longer retrieve. You are going to need something more substantial than a stern email to your account manager.

Questioning a cloud bill is perfectly reasonable. Treating every dollar spent preparing for a disaster as waste because the disaster hasn’t happened yet is how you arrive at the emergency meeting where everybody wants a second copy of everything, somewhere else, available immediately. The purchasing department has been asked to acquire yesterday.

The Trap of the Centralized Internet

I wrote an article back in 2025 titled The Consuming Cloud – Centralizing the Internet warning about this structural failure mode. My argument wasn’t just about our social platforms and media feeds coalescing into a handful of monolithic silos; it was about the dangerous centralization of the underlying physical infrastructure.

We spent decades encouraging organizations to abandon on-premise hardware, shutter regional server rooms, and migrate critical databases, financial ledgers, and hospital records into three corporate landlords: AWS, Microsoft Azure, and Google Cloud. There are real efficiencies in that arrangement. There are also consequences when you herd the operational machinery of civilization into concentrated geographic clusters: you are painting giant, radiant bullseyes on physical territory.

The abstractions are lovely. The buildings still have addresses.

Meanwhile, the industry has arrived at the galaxy-brain pitch: let’s put datacenters in low-Earth orbit! Google’s Project Suncatcher is exploring space-based AI infrastructure. Because apparently, if managing cooling systems on Earth is tricky, adding radiation, orbital logistics, and the inability to send a technician over in a van will be an absolute breeze.

Personally, I would like to see a successful restore exercise here on Earth before giving the backup administrator a launch window.

The Asymmetric Drone Revolution

War has always been an endless, brutal pendulum: a new defense emerges, someone invents a weapon to bypass it, which forces a new defense, forever. The drone problem adds an ugly economic question: how long can you afford the exchange?

The attacker’s equipment does not need a price tag remotely comparable to the infrastructure it damages. And defending against repeated threats has to be sustainable. NATO’s military leadership has explicitly discussed the need for lower-cost defensive options. Winning the interception and losing the budget is a deeply stupid way to discover that arithmetic also participates in warfare.

There are countermeasures, and they are evolving. The infrastructure lesson is that nobody gets to assume an expensive building is safe because damaging it ought to be prohibitively expensive. Your datacenter’s construction budget does not function as a force field.

Personally, I think the people selling us the ethereal future should spend a little more time explaining how the concrete survives. But what do I know? I just study cybersecurity.

The Cloud Is Strategic Infrastructure

A regional datacenter concentrates an extraordinary amount of operational dependence behind some remarkably boring walls. Banking, logistics, telecommunications, port shipping manifests, and emergency coordination can all depend on systems hosted there. The fact that the exterior looks like a warehouse for discount patio furniture does not make the consequences of losing it small.

If an artillery shell or explosive drone punches through a roof, you aren’t just replacing a few motherboards. You may be rebuilding liquid chillers, backup generators, fiber-optic distribution frames, and industrial high-voltage switchgear. The recovery involves actual construction, actual equipment, and people who have to work at an actual site.

You cannot redeploy a transformer with Terraform.

A region that hosts your AI cat-photo generator can also host services somebody needs to get paid, move medicine, or coordinate an emergency. There is a lot of real life behind those boring walls, and the consequences do not disappear because the outage happened inside a windowless building.

That building also does not automatically become a lawful target. The ICRC’s guidance on datacenters in armed conflict makes clear that civilian datacenters are protected; military-objective status requires individual assessment, and proportionality and precautions still apply.

For the people designing systems, the practical problem remains: a physically damaged facility may be unavailable far longer than the business can tolerate. The recovery plan needs somewhere else to go.

Architectural Postmortem: How We Survive Kinetic Cloud Outages

So where does this leave us? We cannot put the digital genie back in the bottle. We aren’t going back to storing accounting records in filing cabinets or hosting corporate intranets on a beige Pentium tower sitting under the receptionist’s desk.

Surviving this era requires a ruthless, unsparing shift in how engineers, CTOs, and systems architects model risk. We have to stop treating “The Cloud” like a divine, ethereal sky kingdom and start recognizing it for what it actually is: reinforced concrete, copper piping, and fragile silicon sitting on the geopolitical fault lines of planet Earth.

That gives us three practical requirements.

1. Recovery outside the affected region

Multi-AZ within a single region still matters. AWS availability zones are designed with independent power, networking, and other infrastructure to reduce correlated failures. That protection does not eliminate the need to plan for a disruption that affects an entire region or makes it inaccessible.

Real resilience means having a recovery path outside the failure you are trying to survive. That might involve another region, another provider, local bare-metal infrastructure, or some combination. It depends on how long the service can be down, how much recent data it can afford to lose, and what your team can actually operate.

Active-active across multiple clouds is one option. It is also a fine opportunity to build something so complicated that only one exhausted person knows how it works. Choose the architecture against your recovery requirements, then prove it works. Three vendor logos on a slide do not count as proof.

2. The resurgence of sovereign edge computing

Critical services such as water control systems, municipal emergency routing, and access to essential healthcare records need explicit plans for losing their remote dependencies. A local service should not discover during an outage that it needs permission from a computer three countries away to do the thing it was installed to do.

Where safe and feasible, that means local systems capable of disconnected “island mode,” with the data, authorization, and capacity required to keep essential functions operating. Some functions may need to stop safely. Decide which ones, test how long the system can remain disconnected, and work out how records will reconcile when connectivity returns.

Putting a container on a small computer does not answer those questions. It does give you a small computer with a container on it. Congratulations on completing step one.

3. Independent, protected recovery copies

Replication is not a complete backup strategy. AWS’s disaster-recovery guidance distinguishes continuous replication from protection against corruption or destruction. Logical damage can propagate; independently retained recovery points give you somewhere to return.

If physical disks are destroyed, surviving replicas do not obediently erase themselves. The questions are whether a usable copy survived, whether it is outside the same disaster, and whether you can actually recover from it.

Use geographically separate recovery copies with retention, isolation, and access controls appropriate to the workload. Immutable, air-gapped, and offsite describe different protections. None makes storage “kinetic-proof.” You cannot negotiate with an explosion by explaining that the backup product has an excellent compliance brochure.

A copy in the company’s local equipment room may be useful during a cloud outage. It needs another layer of protection if that room is part of the same disaster you are planning around.

Now Try the Damn Restore

Pick an essential service. Assume its primary region is unavailable. Then have the team restore it using only the resources the plan says will survive.

Can they get the encryption keys? Can they authenticate without the missing environment? Is the configuration available? Does the restored service have usable data? How long does the whole thing take while somebody hunts for the one person who understands the permission error?

Measure the result against the recovery time and data-loss limits you promised. Fix the failures while they are still part of an exercise.

A green backup dashboard is reassuring. So is a smoke detector with a little light on it. Occasionally, you should find out whether the fucking thing works.

We have spent years building threat models full of zero-day exploits, ransomware gangs, and deployment scripts that should never have survived code review. Keep all of that. Then make room for the possibility that the next major threat to your uptime arrives through the roof.

It might be shrapnel. Plan your architecture accordingly.

“Windows 11 setup is no longer an operating system installation. It is a digital timeshare presentation where you are held captive until you decline Microsoft 365 four consecutive times.”

— Overheard at Defcon

I know I bash Microsoft a lot. I do it constantly, and usually without mercy. But I need to get something off my chest right at the top of this piece: I do it out of love.

Windows was the very first operating system I ever touched. It was the digital sandbox where I learned what a directory was, where I edited my first bat file, and where I spent thousands of childhood hours falling head-over-heels in love with computing.

I don’t want Microsoft to fail. I want Windows to be great again. I want it to be the rock-solid, unpretentious, universal computing workhorse that conquered the world in the first place.

Which is why what Microsoft has done to Windows 11 breaks my goddamn heart.

The Out-of-Box Hostage Situation

In my daily life, I am almost entirely a Linux and macOS user now. Modern Linux compatibility layers like Proton and Wine have gotten so ludicrously good that 95% of the time, I can run whatever Windows binary I need without ever touching Redmond’s kernel.

But last week, I was reverse-engineering an obscure piece of legacy software for a retro project, and it demanded an authentic, native Windows environment. Fair enough.

I spun up a virtual machine, downloaded a pristine Windows 11 installation ISO, mounted the image, and hit enter. I knew the modern Windows Out-Of-Box Experience (OOBE) had degenerated over the last few years. I knew Microsoft was aggressively nudging users toward cloud accounts.

But holy hell, I had no idea it had degraded into an aggressive, late-night telemarketing ambush.

Before I was allowed to set eyes on a functional desktop, the installer subjected me to the following gauntlet of digital extortion:

• Forced Microsoft Account Login: No local offline accounts allowed. If you don’t know obscure terminal bypass tricks like OOBE\BYPASSNRO, your machine is bricked until you surrender an email address.

• Facial Recognition / Windows Hello Setup: Hand over your biometric telemetry immediately.

• Diagnostic and Telemetry Consent: Five consecutive toggle screens politely asking for permission to monitor your keystrokes, location, and application usage.

• OneDrive Cloud Storage Pitch: Let us back up your documents to Azure before you even have documents.

• The Microsoft 365 Shakedown (Round 1): Buy Office right now!

• The Microsoft 365 Shakedown (Round 2): “Are you sure you don’t want Office 365? Look at these templates!”

• The Microsoft 365 Shakedown (Round 3): “How about Microsoft 365 Basic? It has a cloud tier! You can use it for free for 30 days!”

• Xbox Game Pass Upsell: Hey, we know you’re spinning up an enterprise VM, but do you want to play Halo?

• Cortana / Copilot Resurgence: Just in case you weren’t sure, please enable our AI assistant so it can hover over your taskbar forever.

I felt like I had walked onto a sleazy used car lot to buy a replacement tire and ended up trapped in a glass cubicle with a salesman sweating through his polyester shirt, begging me to finance an extended undercoating warranty. I just wanted an operating system. I did not ask for a revolving subscription buffet.

The Frankenstein Desktop: XP Bones and Copilot Bloat

Once you finally survive the onboarding interrogation and cross the threshold to the desktop, the corporate harassment doesn’t stop. It just changes shifts.

Every time you launch Edge to download a real web browser, Windows grovels like a desperate ex-partner: “Edge is built on the same technology as Chrome, are you SURE you want to switch?” Copilot slides into the sidebar uninvited, chewing up cycles. Popups periodically remind you that your local files aren’t synced to OneDrive. It is exhausting.

And beneath that slick, frosted-glass “Fluent Design” paint job lies an absolute architectural disaster. Windows 11 isn’t a cohesive operating system; it is a Winchester Mystery House of legacy technical debt.

You click a network setting in the modern pastel interface, click “Advanced Properties,” and boom: you are suddenly looking at an un-themed dialog box ripped straight out of Windows 2000. Double-click an audio device, and you’re staring at an MMC snap-in from Windows XP.

There are currently four distinct paths to manage audio peripherals in Windows, and each one takes you to a different archaeological layer of Microsoft’s UI history.

Then there is the sheer, suffocating bloat. These days, vanilla Windows 11 can barely breathe in an 8GB RAM environment. If you leave Copilot and background telemetry enabled, the OS idles like a cryptocurrency mining rig.

Whenever I am forced to install Windows today, my very first step is running third-party debloating utilities like AtlasOS or ReviOS just to strip out the pre-installed adware, purge the background trackers, and reclaim 4GB of hijacked memory.

The fact that the enthusiast community has to maintain custom open-source ROM-style amputations of Windows just to make it run like a normal OS should be an existential embarrassment for Redmond.

The 12% Orphan: When the Golden Goose Dictates the Tail

Why is this happening? Because if you look at Microsoft’s earnings reports, the truth is laid bare in cold, unforgiving financial telemetry: Windows accounts for roughly 10% to 12% of Microsoft’s total revenue. And that slice continues to shrink every fiscal quarter.

Windows is no longer the business. Cloud is the business. Azure is the business. Commercial Office 365 licensing is the business.

And when your core operating system gets demoted to a single-digit revenue footnote, management stops treating it like a standalone engineering masterpiece and starts treating it like a monetization funnel. A digital billboard designed to funnel human beings into recurring cloud MRR.

With Microsoft’s Xbox division in disarray and corporate priorities drifting with every quarterly earnings call, Windows suffers from the same fatal sickness plaguing most modern Microsoft products: a complete and total absence of architectural direction.

Microsoft does not have a long-term vision; it has market-fad reflex spasms. Whenever a new buzzword sweeps Silicon Valley, executive leadership grabs a paintbrush, slaps the buzzword onto Windows, renames six enterprise portals, and shuffles the deck chairs.

Look at AWS: the path to provision an S3 bucket or spin up an EC2 instance is fundamentally the same reliable, boring workflow it was seven years ago. AWS understands that enterprise infrastructure demands stability.

Now look at Microsoft. Last week, I had a simple goal: I wanted an AI assistant to connect to my Outlook inbox to help sort incoming mail and write triage rules. In a sane ecosystem, you click “Authorize Plugin.” What did Outlook demand?

Outlook informed me that to allow an API to touch my emails, I needed to log into a Microsoft Entra tenant (which used to be Azure Active Directory before someone got promoted for renaming it), provision a Microsoft Graph API OAuth client credential token, configure scopes, and link them through an Azure enterprise portal. To sort my emails. What the hell is an Entra? Is it a Hyundai sedan? What happened to the old portal?

The Pincer Movement: Valve on the Flank, Apple at the Gate

While Microsoft sits back, reaps its astronomical cloud margins, and neglects the desktop experience, the rest of the industry is systematically carving up whatever market share remains.

On the consumer and gaming front, Valve has executed the single most impressive flank in modern computing history. By investing relentlessly in Proton and SteamOS, Valve proved that PC gaming doesn’t need Windows. Gaming on Linux isn’t an obscure command-line science project anymore; with the Steam Deck and modern desktop distributions, it is a fast, smooth, bloat-free experience that doesn’t interrupt your session to pitch you cloud backup subscriptions.

Meanwhile, in the enterprise sector, the historic fortress of the Windows domain, Apple Silicon is staging a bloodless coup. Walk into any high-growth tech startup, engineering firm, or modern corporate office today and you will see.

When HR hands a new hire their equipment requisition sheet, an overwhelming majority of developers and knowledge workers are requesting a MacBook.

They don’t want to deal with 974 Patch Tuesday updates. They don’t want their laptop fans screaming because Copilot is indexing their telemetry. They want a Unix shell, fifteen hours of battery life, and an OS that doesn’t treat them like a captive audience.

The Unsolicited Recommendation: If It Ain’t Broke, Don’t Fix It

Microsoft will survive this rant. They are a multi-trillion-dollar behemoth with enterprise lock-in that will outlive us all. But if anyone in Redmond still possesses an ounce of the romantic engineering passion that built MS-DOS and Windows 95, here is my humble, earnest plea:

If it ain’t broke, stop “fixing” it.

Stop reinventing your user interfaces every eighteen months. Stop renaming your cloud portals to hit executive OKRs. Pull the telemetry tracking, the predatory dark-pattern subscription nags, and the forced online accounts out of the installer. Strip the bloat down to the bone. Give us a clean, lightning-fast, modular foundation that respects user agency and gets out of the way.

We are living in an era where generative AI and modern compilers have lowered the barrier to software creation to near-zero. Millions of new creators are deciding where to build their tools, stake their projects, and write the next generation of code. Don’t you want them building on Windows?

Take a lesson from AWS, from Google, and from Apple: true progress isn’t erratic cosmetic churn. True progress is disciplined, quiet, incremental polish.

Stop shouting at us through the installer. Just let Windows be an operating system again.

Originally published on SPYDR.