YOLO Saved my GPU
I Put an LLM in YOLO Mode on a Dying RTX Pro 5000 Workstation
I had just installed a new RTX Pro 5000 in a large workstation built to run mostly headless on my network. Not long after the card went in, the system started crashing about a minute after boot.
I tried debugging it manually once. SSH worked, so access was not the problem. The problem was the window. A minute was barely enough time to connect, run a command, and read part of the output before the machine disappeared again.
A useful investigation required collecting evidence, interpreting it, deciding what to inspect next, running another diagnostic, and preserving the results before the next crash. I could have ground through that across enough reboots. It was an awful fit for the situation.
So after one attempt, I gave Claude Opus running in Claude Code access to the machine and put it in what people call YOLO mode.
YOLO mode means the agent has full permission to operate without stopping to ask me for approval. It is reckless by definition and should be used with the utmost discrimination. I would never point it at a production database, a wallet, customer data, or any environment where one bad command creates a much larger problem.
This situation had a limited blast radius. The machine was already unusable. The important data lived elsewhere. Most of the available actions involved inspecting logs, running diagnostics, changing software configuration, copying evidence off the box, and rebooting it. I had already accepted that the system could fall over at any moment.
I gave the agent SSH access, not magnets and a screwdriver.
Debugging Through a One-Minute Window
The agent connected over the network, inspected the environment, pulled logs, ran diagnostics, and adjusted its approach based on what it found. That beat having a chatbot hand me commands one at a time, because I did not have enough uptime to act as the middleman for every step.
The agent could prepare its next actions while the machine was down, connect as soon as the network came back, collect evidence, and preserve the results before the system died again. It did not spend half of the available window remembering a path or deciding which command to run.
Each boot became another investigative pass. One attempt collected the previous boot’s journal. Another inspected driver state. Another tested a theory or confirmed that a change had no effect. When the workstation crashed, the evidence and the state of the investigation survived.
That turned a series of disconnected failures into a coherent debugging session.
Systemd Logs Are Mother’s Milk for LLMs
System logs are close to ideal material for language models. They are timestamped, repetitive, verbose, and full of component names, service states, process IDs, exit codes, dependency failures, and hardware messages. A human opening a large journal dump sees a wall of noise, with the useful signal buried among thousands of routine lines and followed by a cascade of secondary failures.
The finding here came out of that noise. Across boot after boot, the shape was the same. Normal startup, the GPU coming online, then a hard crash about a minute in. No service failure that took the box down with it. No userspace process that could be disabled and retested. The crash sat at the same point in the sequence every time, and the only thing that had changed about this machine was the card sitting in that slot.
No single boot showed that. It only appeared by lining up many of them, which is exactly the kind of work I did not have the uptime to do by hand.
Worth saying plainly: a model reading logs will happily assert causation that is not there, and a journal dump is a bad place to catch that. What made this one credible was repetition. The same correlation held across every boot, and nothing on the software side moved it.
The Test the Agent Could Not Run
The agent had a shell. That was the whole of its reach. It could rule out configuration, drivers, and services, and it could show me where in the boot sequence the machine died. It could not open the case.
So the conclusion arrived at the edge of what the agent could touch. Everything it could reach had been tried. What remained was physical.
I put on headphones, took a screwdriver to the case, and pulled the card. The system booted and kept running. Nothing else I tried had bought a single extra minute.
That also left me with something useful for the warranty process. Instead of describing an intermittent failure from memory, I had a record of the crashes, the repeated pattern across boots, and the software explanations that had been investigated and ruled out.
YOLO Mode Has Its Place
The fact that this worked does not make unrestricted agent access safe in general. The decision depended on the environment. This workstation was already unusable, the important data was elsewhere, the available actions were observable through logs and command history, and rebooting was already part of every attempt. The agent could make the software state messier. It had very little ability to create a disaster larger than the one I was already in.
A healthy production system would demand a very different permission model. So would customer data, payment infrastructure, a storage array holding the only copy of something, or any operation capable of causing irreversible physical or firmware damage.
The question is how much damage the environment can absorb when the agent makes a bad call. Here the downside was contained and a fast, thorough investigation had real value. That made the recklessness tolerable. It did not make it disappear.
The agent read every boot until the pattern was undeniable. I put on headphones, took a screwdriver to the case, and the crashing stopped.