A Giant Sucking Sound
I don't believe in psychics, astrology, or a product roadmap slide with dates on it.
They all sell false certainty about a future nobody can see. Which is exactly why I'm not getting consumed by the fear-mongering about AI and its impact on the white-collar job market.
In 1992, a plainspoken billionaire named Ross Perot ran for president as a third-party candidate and warned that a trade deal called NAFTA would send American jobs south — a “giant sucking sound,” he called it, of work leaving the country. His predictions were not perfect, and no prediction about economic disruption ever is. But he was directionally correct about the pressure NAFTA and globalization would put on the American blue-collar workforce. The problem was real. The framing was right. What got lost was a practical path forward.
The later answer — asking factory workers to “learn to code” — was never a serious solution for an entire displaced workforce.
So I'm not going to make predictions either. And I'm not going to hand you a tidy answer, because there isn't one. What I do know: the people who come through disruptions intact rarely guessed right. They got ready for several futures, not one.
For me, that preparation comes down to a handful of strategies and systems I've been putting in place.
This piece is about the first.
The Lines You've Drawn
Start with an honest inventory. Not just of what you do today, but of where your current value stops.
If the worry is that your job gets deleted, the instinct is to defend it — to guard the thing you already do and hope the wave breaks somewhere else. That is the move that fails. A fixed job description is not a shelter. It is a target.
So the real question is not “How do I protect what I do?” It is “How much more can I do now?”
The Wall That Wasn’t
Here is one example of what that looked like for me.
I am not a software developer, and I never set out to be one. For a network and security architect, automation and scripting are essential skills — but that is a long way from building real software. Years ago, I made a deliberate decision that writing applications was not where my time belonged.
That was the right call then. On paper, it is still the right call now.
What changed is that the decision stopped being a wall.
Here is what I mean.
A customer of mine was interested in a new security solution that enforces controls at the level of individual AI tool calls — the kind of thing you want in place as AI agents start reaching into real systems. I wanted to show it to them properly.
The catch is that a security solution like this obviously doesn't come with anything to secure — that's not its job. It protects applications; it doesn't ship them. And while it could be demonstrated easily enough with VS Code as the stand-in, that approach didn't show well. It buried the point.
So I had a choice anyone in my role will recognize. I could run the standard canned demo and put the room to sleep. Or I could spend a week building out an application tier that wasn’t the point of the exercise — the security functions were the point — just to have something realistic to protect. Neither was good.
One was lazy; the other was a time sink aimed at the wrong target.
I didn’t have to pick. I sat down with Claude Code and described what I needed: a believable pseudo-application that emulated a sales quoting tool, with a handful of functions simple enough that anyone watching would immediately understand them.
It wrote the application. Then it wrote the MCP server that let that application talk to an AI chat client, so the security layer had something genuine to enforce against.
About an hour of back-and-forth, and I had a clean, legible demo built around the thing that actually mattered.
It didn’t stop at the application. I needed the demo self-contained, running in a virtual machine on my MacBook. So I spun up a bare Ubuntu image, handed Claude Code the SSH credentials, and told it to build out the environment — install and configure everything the demo needed.
At one point the setup called for an IPsec router to bring up tunnels to the security cloud back-end, and I had no interest in the overhead of standing up a dedicated network appliance for it.
I asked Claude to pull down Strongswan, install it, and configure the tunnels. I reviewed the result, but I didn’t spend the afternoon learning the syntax and configuring it by hand.
The part I didn’t expect was what it did to the refinement process.
Normally every change to a demo carries a cost, so you ration them — you live with some rough edges because polishing will cost time that you simply don’t have. That calculation disappeared. Every time I wanted the flow cleaner or clearer, I just asked, and Claude made the change. I spent my time on the security story. The plumbing took care of itself.
Now, the easy way to talk about all this is the way everyone talks about AI: look how much time I saved. And I did. But that’s not the point.
The important part is not that I compressed a week of work into a few hours — it is that the better version of the work only existed because the AI tool moved the boundary of what I could reasonably attempt. That demo did not exist in the world where my only options were “boring and canned” or “spend a week on the wrong layer.” AI didn’t make me faster at something I could already do. It let me do something I couldn’t have attempted at all.
That is the inventory worth taking — not just what you are good at, and not just what is in your job description, but where you have quietly drawn a hard line around your own usefulness.
For years, software development was one of those lines for me. I had good reasons for drawing it, and I still do. The difference is that the line no longer marks where I stop. It marks a place I can reach into when the work demands it.
That is the shift worth watching. Not the fantasy that everyone becomes a developer, a data scientist, or an AI expert overnight. Something narrower and more durable: the edge of your skill set no longer has to be the edge of your usefulness.
The opinions expressed in this blog are my own views and not those of my employer.