Blog · July 1, 2026 · Knox Hutchinson
Hardware People Are Allowed to Use AI
Software and hardware people are culturally in two different places right now.
Spend a day in each world and you feel it immediately. On the software side, the conversation is always about what’s next. On the hardware side, the conversation is about what’s stable, what’s supported, and what won’t page you at 2 a.m. Neither instinct is wrong. But the gap between them is going to decide who gets a decade of compounding leverage out of AI — and who watches from the sidelines.
Two decades of badges
For almost two decades, the software badge of honor was the stack you built on. Anyone remember Angular vs. React vs. Vue? Docker vs. Podman? Kubernetes vs. Swarm? Your résumé was a list of bets, and the flex was being early on the right one.
In 2026 the flex just moved up a layer. Now it’s your agentic loop architecture — which model is the orchestrator, what each subagent is responsible for, how you fan work out and gather it back. Same energy, new noun.
Meanwhile, in the racks
I won’t say hardware has been the opposite, because that’s not true. In the same window we watched SDN boom, and network automation went from a dead lightbulb to a slightly flickering one. That’s real progress.
But I genuinely can’t remember the last time I heard a systems or network engineer talk about the cutting-edge tech they’re running in production — let alone the AI they’re running. On our side, the badge of honor isn’t “what’s new.” It’s “what hasn’t broken.”
There’s a good reason for that
The reason is simple, and it’s a good one.
A developer can break an app on their laptop because — who cares. git revert, and no production user ever has to know. You can afford to take risks when the downside is a bad afternoon and the upside is a faster, more stable, easier-to-support app.
Hardware people don’t have that luxury. There is no git revert for a change that black-holes a building. One wrong command and the lights go out, the incident bridge fills up, and you are the one explaining it. When that’s your blast radius, conservatism isn’t timidity. It’s the job.
So why won’t infrastructure touch AI?
So I understand why the reflex, across most orgs, is: “AI just isn’t ready to touch our hardware, so we won’t use it at all.”
I want to challenge that. Because — as the kids would say — it’s a skill issue.
Here’s the failure mode I actually see. A network engineer watches a developer post “I just used Claude Code to build an app,” and reasonably concludes: great, I can build any app to fix any problem I have. Their heart is in exactly the right place. They have a real problem, and they want to solve it.
But without the years a software engineer spent learning what happens after the code gets written — the tests, the reviews, the deployment strategy, the migration plan, the rollback — the result is AI slop. The demo works; the thing falls over the moment it touches production. One experience like that, and the whole department writes off AI. Not because AI couldn’t help them, but because it was pointed at the wrong target.
Scope it to what you already know
The fix isn’t “avoid AI.” It’s “aim it at your domain.”
You will not out-engineer a career software developer at shipping a web app on day one, and you shouldn’t try. But you have something they don’t: deep, hard-won expertise in an environment where being right actually matters. Point AI at that, and the gains are real — 10x, 20x, 30x on the work you already do well. Reading a config you didn’t write. Correlating output across a dozen devices. Turning “why is this neighbor flapping” from an hour of show commands into a five-minute conversation.
A few things separate the engineers who get that leverage from the ones who generate slop:
- Master the tool, not just the trick. Learn how it behaves, how to prompt it, where it’s confident and where it’s guessing. Learn its safety controls cold.
- Understand the fear before you dismiss it. Your environment is scared of AI for specific reasons — blast radius, credentials, auditability, change control. Name each one and work out what actually addresses it. “Trust me” is not a control.
- Don’t overextend on day one. Ease in. Start where a mistake is cheap and the output is easy to verify. Build the reps and the trust together.
Used that way, AI isn’t a replacement for your judgment. It’s a force multiplier on your judgment — which only works because you have the judgment in the first place. You do. That’s the whole point.
Why we built Transit the way we did
This is, honestly, the entire reason Transit exists.
We didn’t build an AI that reaches into your network and starts making changes, because that’s the version that earns the “not ready for our hardware” reflex — and earns it fairly. We built one that stays inside the lines an engineer already respects: read-only by architecture, every proposed command gated by a per-vendor allowlist and your explicit approval, secrets it structurally cannot reach. A force multiplier scoped to your domain, with the kind of safety story you’d need to get it past your own security team.
If you want the specifics — four abilities and no more, default-deny allowlists per vendor, a build check that fails if the AI can even reach a credential — we wrote those up in Why We Made the AI Read-Only.
The software world will keep flexing its agentic loops. Infrastructure doesn’t have to sit this one out. We just have to use AI the way we use every other tool we’ve ever trusted near production: carefully, on purpose, and scoped to what we already know.