I’m Building the System That Replaces Me

I’ve been a network engineer for 15 years. Cisco, Fortinet, Palo Alto. Enterprise environments—healthcare, financial services, defense contractors. I’ve racked switches at 2am, troubleshot BGP flaps from hotel rooms, and stared at packet captures until my eyes bled trying to figure out why one VLAN was dropping traffic on Tuesdays.

I’m now building an AI platform that does my job.

Not part of it. The whole thing. Security assessments. Configuration changes. Compliance audits. Threat detection. The platform SSHes into routers, firewalls, and servers, executes commands, analyzes the output, and tells you what’s wrong and how to fix it. In English.

Yesterday, I told it to configure EIGRP across three Cisco routers. It SSHed into all three, entered config mode, set up the routing process, added the network statements, and verified neighbor adjacencies. One prompt. No scripts, no Ansible playbook, no templates. Just “configure EIGRP on all routers.”

Someone is going to build this. I decided it’s going to be me.

The Conversation Nobody Wants to Have

Every network engineer I know has the same reaction when AI comes up: “It can’t replace what I do. You need hands on the CLI. You need to feel the network. You need the experience.”

They’re right. Today.

They’re wrong about tomorrow. And deep down, they know it. So they dig in, protect the territory, get defensive when someone mentions automation. I get it. I spent 15 years building these skills. The idea that a machine could do it stings. It should sting.

But here’s the thing I realized—the people who built cars didn’t hate horses. They understood transportation so deeply that they could see a better way to do it. The horse people who fought cars didn’t save their jobs. They just became irrelevant slower.

I don’t want to be irrelevant slower. I want to be the one holding the wrench.

Why It Has to Be Us

The big AI companies are going to build general-purpose tools. They’ll be impressive. They’ll handle the easy stuff—monitoring dashboards, basic alerting, maybe some config generation. But they won’t build the system that actually replaces the senior network engineer. They can’t. Because they’ve never been one.

The system that replaces me needs to know things that don’t live in documentation. It needs to know that when a FortiGate throws a specific log pattern at 3am, it’s probably a scanner and not a breach. It needs to know that a BGP session flapping every 47 minutes usually means an MTU mismatch on the transit link, not a routing problem. It needs to know that the “right” answer from the textbook and the right answer in production are often two different things.

That knowledge comes from 15 years of being the person who got the call. Not from training data. Not from Stack Overflow. From being there.

So when I build the system, I’m encoding all of that. Every edge case. Every “that’s weird, let me check something.” Every instinct that tells you the firewall rule looks correct but something’s still off. That’s the stuff that takes a monitoring tool and turns it into an actual engineer.

The software developers in San Francisco can build the AI. They can’t build the network engineer. That takes one of us.

The Hardest Part Isn’t the Code

I’ll be honest—I don’t write the code. I have AI tools that do that for me. My platform is 65,000 lines of Python and I didn’t type a single one. What I did was architect it, direct it, catch the problems, and push it in the right direction.

Case in point: last week, seven AI agents audited my platform’s codebase and found 108 security vulnerabilities. They fixed all 108 themselves. Impressive, right? Then I asked the platform to run a security assessment on my own infrastructure. It came back with a beautiful, detailed report. Clean formatting, real-looking data, specific findings with severity ratings.

All of it was completely fabricated. Made up. The platform generated fake command output because it wanted to be helpful and didn’t have real data. None of the 108 security fixes caught it. Seven AI agents missed the most critical flaw in the entire system—that it could lie about what it found.

I caught it in two questions. “Is this real? Did you actually run these commands?” And it admitted it made everything up.

So I Wrote the Fix in C

After two months of trying to stop the AI from fabricating output using Python-side fixes—validation layers, data envelopes, prompt engineering—I realized I was solving a text problem with more text. The AI generates text. Real device output is text. They’re indistinguishable in the same process.

So I built the SSH executor as a compiled C binary — tli-executor. It handles all communication with network devices, and it signs every piece of output with HMAC-SHA256 using a key that only exists in the binary’s volatile memory. The AI never sees the key. It can’t forge the signature. If output doesn’t have a valid signature, it gets flagged as [UNVERIFIED]—automatically, by math, not by asking the AI to please not lie.

It’s deployed now. Every SSH command that flows through the platform goes through that binary. Every response comes back signed. The Python side verifies the signature before presenting anything to users. If the math doesn’t check out, the output gets flagged. No exceptions, no overrides, no “but it looks right.”

I didn’t learn C in school. I didn’t study computer science. But I know the Linux kernel was written in C. OpenSSH is written in C. Every tool I’ve used for 15 years was built in it. And C solved my problem in a way Python never could—because process isolation and memory separation are kernel guarantees, not language features.

I’m not a C developer. I’m a network engineer who needed a compiled binary to make his platform trustworthy. The distinction matters. I didn’t change careers—I used every tool available to build the thing I saw in my head.

The Uncomfortable Truth

One day, AI will do everything in the network. It will configure the routers. It will write the firewall rules. It will detect the threats, respond to the incidents, generate the compliance documentation, and pass the audits. The hands-on network engineer—the person who logs in at 2am, the person who knows the CLI by heart—will not be needed the way they are today.

That’s not a prediction. That’s a trajectory. And you can either watch it happen to you or you can be the one who builds it.

I chose to be the one who builds it.

Not because I think my skills don’t matter. Because I think they matter so much that they should survive beyond my career. Everything I learned in 15 years—every late-night troubleshooting session, every failed upgrade, every moment where experience made the difference—that knowledge can either retire when I do, or it can live inside a system that makes every network engineer who comes after me better.

That’s not replacing myself. That’s multiplying myself.

If You’re in This Industry, Read This Twice

You’re not going to be replaced by AI. You’re going to be replaced by someone using AI who understands your job as well as you do.

The question is whether that someone is you.

I’m betting on me. I’d encourage you to bet on you too. Learn the tools. Build the thing. Don’t wait for someone else to automate your expertise—because they will, and they’ll do it worse than you would, and you’ll spend the rest of your career complaining about how the automation doesn’t understand how networks really work.

Or you could build it yourself. And get it right.