Last night I deployed custom nameservers, bound a domain to a live server, fixed a payment-processing bug, and wired real analytics into a dashboard. I am not an infrastructure engineer. I am not a backend developer.

A decade ago, that evening's work would have been split across four or five specialists, and I'd have waited days on each of them. But then, a decade ago I wouldn't have been able to take a product vision, code it, build a website, deploy it, and begin marketing it. Last night's work is just an extension of what I've been able to accomplish with AI as my copilot.

I want to tell the honest version of how this all happened, because the honest version is more useful than the hype version — and it gives you a framework you can actually use to decide where AI belongs in your business and where it absolutely doesn't.

First, my bias, on the table: I build AI software for small businesses, in the domains I'm about to argue AI is good for. So read this as a field report from someone with skin in the game, not a neutral study. I'd rather you judge the framework than take my word for it.

The hype version is wrong

The story corporate sells is "AI replaces the expert." That is not what happened last night. AI did not replace an infrastructure engineer. Something subtler and more important happened: the engineer's knowledge got delivered to me in a form I could act on, one verified step at a time. I still made the calls. I still approved anything irreversible. I still owned the outcome.

What disappeared wasn't the expertise. It was the ten years of accumulated lookup, debugging, and tribal knowledge that used to stand between me and the expertise. The mystery that would once have meant hours of searching old forum threads got explained and fixed in a minute. The deploy that would have failed silently got caught, diagnosed, and corrected before it cost me anything.

That distinction matters, because it tells you exactly when this works — and when it blows up in your face.

The three conditions

A generalist plus structured AI hits expert-level output when three things are true at once. Miss any one of them and you should still hire the specialist.

1. The domain has a definable "correct." Every task last night had a right answer. A nameserver is pointed correctly or it isn't. A webhook parses the date or it throws an error. There is ground truth to land on. Compare that to "design our brand" or "set our three-year strategy" — there is no single correct answer to check against, and that is precisely where AI will hand you something plausible and wrong with total confidence. Spend enough time using LLMs and you will discover that the model defaults to optimism, which can lead you down some very expensive and time-consuming rabbit holes on the strength of that confident delivery.

2. The outcome is verifiable. This is the condition people skip, and it's the one that saves you. At every step last night we did not trust that it worked — we checked. We confirmed the domain was live before deploying to it. We read the database to confirm the data had actually landed, not just that the button said "success." Verification is what separates a real result from a confident hallucination. If you can't check whether the work is right, AI's confidence stops being an asset and becomes a liability. This part is non-negotiable.

3. The work arrives as structured, guided steps — not a single answer. This is the difference between a chatbot and a workflow, and it's bigger than it sounds. A chatbot gives you an answer and wishes you luck. A structured process walks you from where you are to a verified outcome, with guardrails at each step and a checkpoint before anything you can't undo. Last night I never had to hold the whole map in my head. I had to take the next correct step and confirm it worked. That is a completely different thing from "go ask the AI and hope."

When all three hold, the specialist's execution becomes accessible to a capable generalist. When they don't, you aren't doing expert work — you're doing confident guessing, and you won't find out until it's expensive.

Run your own work through it

Here's the part that's useful whether or not you ever buy a thing from me. Look at the work in your business that eats specialist time, and run it through the three conditions.

Onboarding a new hire. Writing a compliant policy. Building a knowledge base people can actually find answers in. Triaging a support ticket. Checking whether training actually stuck. These have definable correct answers, you can verify the output, and they break down into structured steps. They are candidates for a generalist-plus-AI workflow. That those are also the things I build software for is not a coincidence — it's why I build for them. The thesis came before the product.

Now the other column. Setting your pricing strategy. Deciding which market to enter. Reading whether a critical hire is the right culture fit. Making the bet-the-company call. No definable correct, no clean way to verify, and often irreversible. Keep the human judgment there, fully. Anyone selling you AI to replace those is selling you confidence you have no way to check.

What stays scarce

So no — AI did not make me an infrastructure engineer last night. It made the engineer's execution accessible while leaving the engineer's judgment exactly as scarce as it has always been. I still had to decide what to do, when to stop, and what was safe to ship. The execution got cheap. The judgment did not.

I think that's the honest version of what's happening right now, and I think it's better news than either the doom or the hype. You don't get replaced. You get the leverage of a specialist's workflow in the parts of your work where "correct" is definable and checkable — while the judgment that actually makes you good at your job becomes more valuable, not less.

You don't need the expert. In a surprising number of cases, you need the expert's workflow. The whole skill now is knowing which case you're in.

The expert's workflow, built into software

TranscendByDesign turns four specialist functions — HR, Customer Service, Learning, and Knowledge — into AI-native products with the structure and verification baked in. The definable, checkable work, done by the person already doing everything. One flat price, locked for life.

See the suite →

About the author

Tom Christian is the founder of TranscendByDesign, an AI-native operations suite built for SMBs and lean teams.

He spent twenty years inside customer service, training, and quality operations at scale — Guardian Life, ConnectiveRx, and Horizon Blue Cross Blue Shield's Service Division — before building four production AI products from zero as a solo founder. He writes about the SMB software stack, the automation/judgment line, and the operating discipline of running back-office functions without a department behind them.