Table of contents of the article:
Let's start with a necessary premise, so we can immediately avoid the chorus of indignant people: LLMs are a huge revolutionProbably the greatest technological acceleration of recent decades. Questioning the usefulness of tools like Anthropic's Claude, ChatGPT, Gemini, or the like would be as ridiculous as banning an architect from using a calculator because "you have to know how to count in your head."
We're not nostalgic for the "time was better when we compiled kernels blindfolded by hand." We have no intention of becoming command-prompt veterans with a medal pinned on our chest. At Managed Server Srl, we use AI, and how. We use it to write, analyze, compare, speed up, automate, document, test hypotheses, and save time on repetitive tasks.
But between use an LLM well and using it in CDC (haphazardly), there's the same difference between buying a Formula 1 car and knowing how to drive it without crashing at the first corner. The problem isn't Claude. The problem isn't ChatGPT. The problem is you when you sit down in front of a language model, ask three generic questions, copy a well-formatted response, and suddenly feel like a senior systems engineer, cloud architect, security specialist, and Oracle of Delphi with a monthly subscription.
“Claude told me” is not a technical test
There's a new category of humans that deserves a dedicated circle in the IT hell: the user who cites the LLM as the definitive sourceThe one who comes in with the tone of a McKinsey consultant after reading three lines produced by a template and explains how to configure NGINX, optimize MariaDB, secure SSH, or “scale Kubernetes” because Claude responded with a neat paragraph and two bullet points.
“Well, ChatGPT says that you just need to increase the max_connections value.” Sure. Like saying that to lose weight, you just need to eat less. Technically, it's not always false, but if you apply it without context, you can end up doing more harm than good. Increasing max_connections Without looking at available memory, real workload, slow queries, threads, indexes, locks, I/O, application pool configuration, and traffic patterns, it's like fixing a water leak by turning on all the faucets because “it flows better that way.”
The point is simple: An LLM is not a substitute for expertiseIt supports it, amplifies it, if it exists. It simulates it poorly, if it doesn't exist. And this is the part many don't want to hear, because AI is democratic in its access but ruthless in its results: it provides an answer even to those who don't know how to formulate the question. And when someone doesn't understand the domain, they can't even grasp how dangerous the answer they receive is.
The Dunning-Kruger effect with turbo
Dunning-Kruger syndrome didn't start with artificial intelligence. It existed before, especially in Facebook groups of "SEO experts," and in forums where advice was given. chmod 777 as if it were aerosol, and in the LinkedIn comments of those who talk about “infrastructural resilience” without ever having seen a full disk at three in the morning.
What's new is that today the LLM gives this incompetence a presentable guise. Previously, the amateur would write grammatically incorrect nonsense. Now, he or she writes beautifully formatted nonsense, with a confident tone, technical vocabulary, and perhaps even a comparison table. The content may remain as fragile as a sandcastle, but the appearance remains that of a white paper.
And this is where AI becomes dangerous: not because it will “take over,” not because it will “steal our jobs,” not because “machines think.” It becomes dangerous because transform ignorance into self-confident ignoranceAnd self-assured ignorance, in systems engineering, isn't folklore: it's downtime, data loss, security holes, indecent configurations, unverified backups, and customers who then call in despair saying, "But it was working until yesterday."
The prompt is not experience
A systems engineer is not someone who knows the right command. That's a caricature of the profession. A systems engineer is someone who knows when use that command, because use it, what happens next, what side effects it produces and how to go back when the castle starts smoking.
Anyone who's worked on Linux servers since 1996, and professionally since 2005, hasn't simply "memorized commands." They've seen filesystems corrupt, RAID degrade, kernel panics in production, mail servers blacklisted, databases saturate with I/O, DNS configured like voodoo rituals, certificates expired at the worst possible times, deployments performed on Friday nights by people clearly lacking any instinct for self-preservation.
You don't download this stuff from a template. You don't get it with a prompt like "act like a DevOps expert." That's cosplay. Useful, perhaps, to get an initial idea. But it's still cosplay. Experience is a layering of errors, diagnoses, accidents, recoveries, audits and responsibilitiesIt's knowing that the most elegant answer isn't always the right one. It's understanding that sometimes the best solution is to leave nothing untouched until you've looked at the right logs.
"AI says it can be done": A phrase to be engraved on the server's tombstone.
One of the most disturbing phrases you might hear today is: "AI says it can be done." Wonderful. Even a satellite navigator can tell you to turn into a lake, but that doesn't mean you should christen the Panda.
An LLM produces plausible answers, not operational guarantees. It can be brilliant, useful, even surprising. But it doesn't have your full context. It doesn't truly understand your infrastructure, the customer's constraints, the history of previous problems, inherited configurations, compromises made years ago, or the reason that seemingly absurd service is still there. And above all, it doesn't pay when you break everything.
The model doesn't hear the phone ring. He doesn't have an angry client. He doesn't have to explain why the management software won't start, why the website is down, why emails aren't arriving, why the backup was there but no one ever attempted a restore. The LLM doesn't take responsibility. You do. Or at least you should.
AI as an exoskeleton, not a replacement brain
Used well, AI is a cognitive exoskeleton. It allows you to move faster, compare hypotheses, generate drafts, write documentation, transform raw logs into insights, produce checklists, simulate scenarios, and quickly find alternatives. It's also incredibly useful for explaining complex concepts to clients, developers, or stakeholders who might otherwise confuse "server" with "hosting" and "hosting" with "that thing I pay for every year."
But an exoskeleton works if there's someone inside who can walk. If there's someone inside who stumbles while standing still, the exoskeleton doesn't create Iron Man: it creates a motorized idiot.
The difference lies here. The professional uses AI to accelerate a reasoning he already has. The amateur uses AI to replace a reasoning he never had. The former asks, verifies, compares, tests, reads official documentation, checks logs, and assesses risk. The latter copies, pastes, restarts, and then opens tickets with the subject "URGENT."
The problem isn't being wrong. It's not knowing that you don't know.
Anyone who works seriously in IT knows that making mistakes is part of the job. No one is born knowing, no one always has the answer ready, no one can know every technology, every version, every bug, every edge case. The point isn't to expect infallibility. The point is to have awareness of one's limits.
The LLM, on the other hand, has a devastating psychological effect: it makes you feel competent before you actually are. It gives you vocabulary, structure, and confidence. It allows you to discuss topics you don't master with a fluency you wouldn't have had before. And this fluency is mistaken for understanding.
But being able to repeat "reverse proxy," "TLS termination," "connection pooling," "horizontal scaling," "zero trust," "observability," and "immutable infrastructure" doesn't mean you know what you're doing. It just means you've learned to pronounce expensive words. It's like walking into an operating room saying "scalpel, anesthesia, laparoscopy" and pretending to be a surgeon because the terminology is correct.
When the LLM proves the client right
One of the most grotesque aspects is the customer who arrives with the AI response to dispute the technical work. He doesn't ask for explanations. He doesn't ask for a discussion. He arrives already convinced. "I asked ChatGPT and they told me that the problem is solved this way."
Great. So let's also ask ChatGPT if the bridge is holding, if the CT scan is negative, if the fiscal balance is correct, and if the noise from the car is really the clutch. The rule of thumb now is: if an answer is well-written, then it's true.
The relationship between client and professional should be based on trust, expertise, and responsibility. AI can help clients understand better, ask more intelligent questions, and gain orientation. But when it's used as a cudgel to say, "I know as much as you do because I asked ChatGPT," then we're looking at a masterpiece: artificially increased ignorance.
How to Really Use an LLM in Systems Engineering
We're not saying don't use Claude or ChatGPT. That would be stupid. We're saying use them as tools, not as digital holy cards. An LLM can be very useful for:
- summarize long logs and identify suspicious patterns;
- generate operational checklists before a migration;
- write more readable technical documentation;
- compare different architectural approaches;
- prepare scripts for review, not blind execution;
- explain to a non-technical person why a certain request is dangerous.
The key word is to reviewEvery output must be checked. Every command must be understood. Every configuration must be adapted. Every change must be tested. Every procedure must be accompanied by backups, rollbacks, and common sense. Above all, common sense, a rare commodity not yet available via API.
Competence remains the filter
The future won't belong to system administrators who ignore AI. They'll end up like those who rejected Git because "I rename files with _final_definitivo_v3." But it won't belong to runaways who think they'll become experts because they learned to write dramatic prompts.
The future belongs to those who integrate powerful tools into a robust method. Those who understand Linux, networking, security, databases, performance, backup, monitoring, and incident response. Those who can read a log without first asking a chatbot's permission. Those who use AI to accelerate, not to mask a vacuum.
Attention is all you need It was, for modern artificial intelligence, an epochal transition. We can easily consider it a watershed formula, like those ideas that change the world and after which nothing really goes back to the same. But be careful: a revolutionary discovery doesn't automatically make those who misuse it revolutionary.
Nuclear energy can light cities or cause disasters. Internal combustion engines can propel ambulances or produce idiots who rev at roundabouts. The LLM can help a professional work better or turn an amateur into a danger with a conversational interface.
Claude is handsome, but learn the trade first
Claude is cool. ChatGPT is cool. LLMs are amazing tools. No serious person should dismiss them, ridicule them, or pretend they're a passing fad. They're here to stay and will profoundly change the way we work.
But precisely because they are powerful tools, they must be used with skill. They are not a professional license. They are not an instant degree. They are not twenty years of experience compressed into a chat window. They are accelerators. And an accelerator, in the hands of someone who doesn't know how to drive, doesn't produce speed: it causes accidents.
So yes, use AI. Use it every day. Make it part of your workflow. Ask it for drafts, alternatives, checks, explanations, ideas. But when it comes to servers, security, infrastructure, data, and business continuity, at least have the decency to remember one thing: a plausible answer is not a validated solution.
And above all, before explaining to a systems engineer who's been doing this job since many "AI experts" were still learning to tie their shoelaces, maybe ask yourself a simple question: are you really making a technical contribution or are you just reading aloud what a model has spat out?
Because Claude is handsome, sure. But let's not get hung up on him.
