· 7 min read

A 368-Point Hacker News Thread Says AI Is Quietly Making Engineers Worse at Debugging Their Own Systems. Solo Operators Have No One to Catch Them.

A post titled "AI handles incidents, engineers lose touch with their systems" hit 368 points on Hacker News this week, and the argument inside it is uncomfortable in a way that doesn't go away once you close the tab. The claim: the better AI gets at resolving routine production incidents, the less practice human responders get at the exact pattern-matching skill they need for the one incident automation can't solve. I run my own infrastructure with an AI agent watching most of it. I don't have a clean rebuttal.

The actual argument, not the headline

The thread's core point is narrower than the title suggests, and narrower is what makes it convincing. Nobody is arguing AI incident response is bad at its job. The claim is that routine incidents are how engineers build intuition for how their systems fail: what a memory leak looks like at 2am, what a bad deploy does to latency graphs, what "this is fine" actually means versus what it doesn't. When an agent handles the routine cases end to end, the human on call stops accumulating that experience. The skill doesn't erode because the tool is bad. It erodes because the tool is good enough that you stop practicing.

That's a different failure mode than the usual "AI made a mistake" story, and it's why the thread got traction instead of turning into another generic AI-skepticism pile-on.

The pilot comparison people kept bringing up

Commenters repeatedly reached for the same analogy: commercial airline pilots. Under FAA rules, Part 121 air carrier captains have to complete a proficiency check or approved recurrent training within a rolling six-month window, on top of an annual aircraft check, specifically so that rare emergency scenarios like an engine failure on takeoff stay rehearsed even though autopilot and modern avionics handle almost everything else. Nobody assumes a pilot who flies with autopilot on for 99% of a route will still have sharp hand-flying instincts for the 1% that matters. The industry built a mandatory training cadence around that assumption instead of hoping it isn't true.

Software engineering has no equivalent requirement, and most solo operators have no equivalent habit either.

Why this hits differently if you work alone

On a team, deskilling is bad but recoverable. If the AI-handled incident turns out to be the one it got wrong, there's a senior engineer who's been paged before, who still remembers what a real outage feels like, and who can take over. As a solo operator, that backup doesn't exist. If your own instincts have atrophied because your monitoring and your AI agent have been quietly absorbing every routine incident for the last year, the day the ambiguous one shows up, it's just you, and you're worse at this than you were a year ago without having noticed.

There's a workforce dimension to this too. Lenny Rachitsky's 2026 workforce survey, one of the largest of its kind, found the tech workforce splitting into distinct groups by how they relate to AI tools, and included a line from a respondent that's stuck with a lot of people: "I feel like I don't think hard enough anymore, I just follow Claude." That's not a claim about incident response specifically, but it's the same mechanism: capability that used to require active thought gets outsourced, and the thinking muscle goes quiet when it isn't used.

What skill debt looks like in practice

Skill debt doesn't show up on a dashboard. It shows up as a gap between how confident you feel about your own infrastructure and how much of that confidence is actually borrowed from a tool. A few honest questions surface it fast: when did you last read a raw log file instead of an AI summary of it? When did you last diagnose something without asking an agent first? If a deploy went sideways at 3am and every AI tool you use was simultaneously unavailable, do you know what you'd actually check first, or would you be relearning your own stack from scratch under pressure?

I don't like my own answers to all of those questions, which is part of why this thread got under my skin instead of scrolling past.

What I'd actually do

Run your own fire drills. Not constantly, and not as security theater, but on a real cadence: once a quarter, deliberately debug something in your stack without touching an AI tool at all, starting from raw logs and your own memory of how the system is wired. Pick something that actually matters, a real slow query, a real memory creep, not a toy problem. It's the closest thing a solo operator has to a recurrent proficiency check, and it costs an afternoon.

The honest counter-take: I could be pattern-matching my own anxiety onto a Hacker News thread that's really just the usual "kids these days" complaint dressed up in incident-response language. Engineers have always outsourced cognitive work to tools, from man pages to Stack Overflow to IDE autocomplete, and the field didn't collapse. Maybe AI incident response is just the next rung on that ladder, and the skill that matters shifts rather than disappears. I don't fully believe that counter-argument, but I can't rule it out either, and it's the reason I'm running quarterly drills instead of writing a doom post about it.

Author

Sources

Stay in the Loop

Get new posts delivered to your inbox. No spam, unsubscribe anytime.

Newsletter coming soon. Set PUBLIC_CONVERTKIT_FORM_ID in .env to activate.

Related Posts