Case study 05 · Concept · Systems design · Initiative
The other four case studies I built at my own desk. These I built inside Intel's validation labs, on the clock, for people who are still using them. Same instinct, since 2019, and a job title that says technician.
Stop before you do something irreversible. The drive cleaner finds what it found, shows you, and asks before it wipes. The bringup script asks separately about kernels, because a test system pinned to a specific build is destroyed by the update any sane default would have run. Neither is a technical nicety — both are somebody deciding what this tool must never do to the person using it, then building backward from that. It's the same call I made years later when a finance app of mine turned out to delete records silently.
In 2021 the lab held over a thousand pieces of pre-production silicon across several labs and no way to find any of it — locating one part meant a thirty-minute hand search. I was tired of losing the half hour, so I designed the coding scheme and built the database. It's still what the lab uses.
The four since are the same move. A script that reclaims USB drives which Linux installs have left unreadable — the reason it matters isn't the drives, it's that engineers were interrupting their own work, and each other's, hunting for one that worked. A bringup script that takes a fresh machine from unusable to working, since a new system can't update at all until the corporate proxy configuration is in place and that was being typed by hand every time. A Windows utility that discovers the active COM ports and maps them for serial capture, because the machine already knows which ports are live and making a person retype that is the actual defect. And a PowerShell tool that updates KVM and PDU firmware across the lab and logs what it did, so somebody can audit it afterwards.
I wrote these; AI compressed the work. That's a different claim from the other four products, where I set the principles and directed the build against them — and the difference is worth stating rather than blurring. What AI changed here was how fast a noticed problem becomes a shipped fix. It didn't do the noticing.
It's also on the other side of the job, and that side is the one worth hiring. I use AI to troubleshoot systems, and it's wrong often — which isn't a complaint. A wrong answer isn't a failure of the tool; it's a hypothesis. Root cause analysis is the business of killing hypotheses until one survives, and AI generates them faster than I can. That's exactly what I want from it.
A remote desktop service stopped working after a routine point release. The model kept returning to the same fix — switch off the security layer — because that is the answer the internet has for those symptoms. It was wrong, and it was wrong in a way worth understanding: the fault was newer than anything the model had read, so it reached for the most common answer rather than the right one. A model with nothing to draw on doesn't say “I don't know.” It says the most common thing. Knowing that's how it fails is worth more than catching any single wrong answer — and you don't disable a security control to make a service start.