I ruined my PC on purpose and gave an AI agent one hour to fix it

I've watched AI coding agents rewrite half a codebase in an afternoon, so I figured fixing a broken Windows PC would be easy. It's the kind of job most of us get roped into anyway, usually over the phone, usually for a relative, and usually while someone reads error messages aloud. So I broke a Windows 11 PC on purpose. Not my own, thankfully, but a Hyper-V virtual machine on my workstation, wrecked in eight different ways. Then I handed Claude Code a single prompt, an SSH connection, and one hour, and stepped back.

It found the first problem in two minutes. It also finished the job with the PC in worse shape in a couple of ways than when it started, and it locked itself out of the machine in the process. That's a far cry from when an AI agent took over a blank Windows machine and finished in minutes what would take hours, and the way it got there says a lot about where agents actually are right now.

I broke Windows 11 in eight different ways

Every fault had to be fixable without reinstalling Windows

The rules were simple. Every fault had to be something a real PC could suffer, discoverable from inside Windows, and fixable without a reinstallation. I wrote a PowerShell script to plant all eight at once, then let it loose on the unsuspecting VM.

That last one turned out better than planned. My fake path pointed to D:, the VM's empty DVD drive, so clicking Documents in File Explorer prompts you to insert a disc. It's a wonderfully baffling symptom.

Claude Code ran on the host under a separate, unprivileged Windows account, reaching the VM only over SSH on its own network adapter. That way, it couldn't touch the hypervisor or read my break script, and I could grade the result from the host with a separate PowerShell Direct script. A broken PC before the run scored 0 out of 8.

Claude Code found the first fault by tripping over it

It was careful, thorough, and confidently wrong about a few things

I used Claude Code 2.1.299 with Opus 5.5, a fresh session with no memory, and one prompt: the PC is broken, fix it, you have 60 minutes, tell me what you changed. The first command that the agent tried, a basic hostname and whoami, failed. "That points to a broken PATH," it said, and two minutes in, it found fault 5.

What impressed me most was how careful it was. It wrote diagnostic scripts, uploaded them over SSH, and surveyed the whole machine before changing anything. When it found a 47.88GB file filling the drive, it checked that the file was created that day and full of nothing but zeros before deleting it. It backed up every registry key it touched, too. Honestly, that's a better process than my usual troubleshooting approach.

Within about seven minutes, it had batch-fixed the proxy, the hosts file, the disk, and the audio service, re-enabled the firewall, and removed the policy that switched off Defender. Around the 11-minute mark, it told me it had "fixed most issues", listing the PATH, the filler file, the proxy, the hosts file, DNS, the firewall, audio, and file types.

But it was also confidently wrong. It reported that Windows Installer's permissions had been "altered to block Administrators", when that's simply how Windows protects that service. It decided that .log, .ini, .inf, and .ps1 file types had been deleted as part of the attack, which they hadn't, and recreated them anyway. And it decided my network fault was a dead gateway "outside the PC", when the real fix was turning DHCP back on.

Then it locked itself out of the PC it was fixing

Typical SSH issue, to be honest

About ten minutes in, the agent rebooted the VM to apply its fixes, and SSH never came back. I found the VM sitting at a plain lock screen, and I signed in, which is what someone at the PC would do anyway. That didn't help.

Here's what happened. While the agent's fix scripts were running, Windows' Base Filtering Engine stopped and refused to start again with a single error: The Base Filtering Engine service terminated with the following error: The security descriptor structure is invalid. That service is the engine underneath Windows Firewall. With it dead, the firewall the agent had just switched back on couldn't run, and Windows falls back to blocking every inbound connection. I combed through every script the agent left behind, and none of them touched that service directly, so I can't pin down the cause. What I can say is that it was healthy when the agent started, and it broke two minutes into its repairs.

The agent's next move genuinely surprised me. Spotting that the VM's adapters belonged to Hyper-V, it tried to check whether it was running on the hypervisor itself, so it could use PowerShell Direct instead. Its account didn't have the rights, so that failed. It was completely upfront about what it was trying, which I appreciated, but it's exactly why I didn't give it an admin account. Without that wall, it would have quietly used my grading backdoor.

It then proved the VM was still alive by checking whether it answered at the network level, scanned for any open port, and found nothing. Its verdict: "SSH is likely being blocked by a firewall rule I re-enabled without fully auditing — my mistake." Close, but not quite. At 23 minutes and 54 seconds, it stopped and wrote a handover asking me to go to the console and run some commands.

In those 11 minutes, I had to intervene three times, but none of them were critical. Signing in at the lock screen is fine; I hadn't given the agent access to its own password, only the SSH key. It seemed to have timed out at one point, so I reminded Claude that the VM had rebooted. When it asked me to fix SSH on my side, I gently told the agent to use its own judgment and continue. None of those are a fix or a pointer to a fault, and they're things you might have to handle anyway as a technician.

My grading script made the same mistake as the agent

Checking a setting isn't the same as checking that something works

My first grading pass said 6/8, but two of those passes were wrong. The Windows Installer service didn't just fail its check; it no longer existed, most likely because the agent wrote a new security descriptor for it. My script only failed services marked Disabled, so a missing one slipped through. The security check passed even though the firewall wasn't running, because it only read a policy value.

The agent fell into the same trap. It checked settings, saw the right values, and assumed things worked. A quick rewrite of the testing script gave an accurate 4/8 result. The agent never fixed the lack of internet or the Documents folder pointing to the DVD drive, and it created two issues of its own along the way.

An AI agent is a capable second pair of hands, not your new IT department

Sure, 4/8 sounds rough, but I don't come away disappointed. In less than half an hour, the agent diagnosed methodically, backed up before changing anything, owned its mistake, and wrote a clearer handover than most support tickets I've seen. If I'd been sitting at the console to follow its instructions, this would have ended a lot better.

That's the catch, though. Remote repair falls apart the moment the fix cuts off your own access, and an agent that can't see the screen can't notice that Documents is asking for a DVD. It also isn't free. An hour of Opus doing agentic work burned through enough of my weekly Claude quota that next time I'll do an interactive fix session and not let the agent run away with my token budget.