HOOK

A junior network engineer is troubleshooting a Cisco switch that's dropping packets. She asks ChatGPT for the CLI command to check port statistics. The AI confidently returns:

switch# show port-stats detailed summary

She runs it. Command not found. She tries variations. Nothing works. She spends 45 minutes banging her head on this before escalating to a senior engineer, who immediately knows the real command: show interfaces.

The AI didn't refuse or say "I'm not sure." It hallucinated a plausible-looking command that doesn't exist and presented it as fact. That's an AI hallucination, and in IT Operations, hallucinations aren't just wrong, they're dangerous. They're confidently wrong.

This lesson teaches you what hallucination actually is, why it happens, and how to spot it before it breaks production.

Purpose

By the end of this lesson, you'll understand:

• What a hallucination actually is (not magic, not intelligence failure, a fundamental property of how AI language models work)
• Why AI *must* hallucinate sometimes. It's baked into the architecture
• The specific ways AI hallucinations manifest in IT contexts (fake commands, invented configs, non-existent error codes, impossible package versions)
• How to recognize hallucinations before they hit production
• The organizational cost of trusting hallucinations

Why This Matters for IT Operations Professionals

Hallucinations are the single biggest safety risk from AI in operational contexts. Here's why:

• 
  AI sounds confident. It doesn't say "maybe" or "probably." It says "the command is show port-stats detailed summary" as if it's a fact.
• 
  **Hallucinations often *look* correct.** They follow the right syntax. They have the right structure. If you don't know the system intimately, you might not catch it.
• 
  The cost of discovery is high. When a human makes a mistake, you often catch it immediately ("command not found"). When AI hallucination is discovered in production, you've already deployed it.
• 
  IT contexts are hallucination-prone. AI trained on the internet has seen millions of bash commands, but it hasn't seen *your* company's custom scripts, proprietary tools, or infrastructure-specific settings. This knowledge gap is where hallucinations thrive.

Understanding hallucination is your first line of defense. You can't prevent it entirely, but you can design workflows to catch it before damage is done.

Core Concepts

1. What Hallucination Actually Is (Technically)

Key insight: Hallucination isn't a bug. It's a mathematical consequence of how language models work.

Language models (like the AI that answers your questions) work by predicting the next token (word or sub-word) based on probability. At each step, they choose the token with the highest probability given what came before.

Here's the critical part: They don't have access to ground truth or a knowledge base. They can't look up "Is show port-stats detailed summary a real command?" They can only generate text that *statistically resembles* text they learned from.

A simplified example:

Your AI was trained on millions of lines of text including:

• "show interfaces"
• "show interfaces detailed"
• "show ip route"
• "show port status"
• Thousands of similar commands

When you ask "show me the command for port statistics," the AI sees:

• You want a "show" command (that pattern is common)
• You want something about ports (that word appeared with "show interface", "show port status")
• "detailed" is a common modifier

So it blends these patterns together: show port-stats detailed summary

It *looks* right because it's assembled from real patterns. But it's an invented combination. It's a hallucination.

Hallucinations are more likely when:

• You ask about something niche or specialized (your company's proprietary tools)
• There's little training data (newer technology)
• You're asking for something that sounds plausible but doesn't actually exist
• The AI is pressured to give an answer rather than admitting uncertainty

2. Why IT Operations Is Hallucination Heaven

Key insight: The knowledge gap between what AI has seen and what your infrastructure actually is creates a hallucination minefield.

The AI was trained on public internet text: GitHub repos, Stack Overflow, documentation, blog posts. But it has never seen:

• 
  Your company's internal tools. You use a proprietary monitoring system that looks like Prometheus but has custom endpoints. You ask "What's the API to fetch metrics?" The AI hallucinates an endpoint that sounds reasonable but doesn't exist.
• 
  Your infrastructure specifics. You run Kubernetes on AWS with custom networking. You ask "How do I check the IP of a pod?" The AI provides a kubectl command that works in vanilla Kubernetes but not with your network plugin.
• 
  Your recent changes. The AI was trained on static data (knowledge cutoff in my case is February 2025). You're using a tool released last month. It hallucinates commands or configuration for a feature that doesn't exist yet.
• 
  Your organizational history. You have a legacy system that's still running. The AI doesn't know why. It generates a "better" config that breaks the system because it doesn't know about the 10-year-old vendor constraint that requires that exact format.

This is why IT hallucinations are particularly dangerous: they often *almost work*, making them hard to catch immediately.

3. Common Hallucination Patterns in IT Contexts

Pattern 1: Fake CLI Commands

Real command
$ systemctl status nginx

Hallucinated variant the AI might suggest
$ systemd-check status nginx # HALLUCINATION
$ systemctl check-service nginx # HALLUCINATION
$ show systemd status nginx # HALLUCINATION

The AI invents commands that follow the right naming conventions but don't exist. When you run them, you get "command not found", and if you're new to the system, you might not realize it's a hallucination. You might assume the tool isn't installed.

Pattern 2: Fake Configuration Syntax

Real Kubernetes deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
replicas: 3
template:
spec:
containers:
- name: app
image: myapp:1.0

Hallucinated variant
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
scalingPolicy: "aggressive" # HALLUCINATION - not a real field
spec:
replicas: 3
autoScaling: true # HALLUCINATION - wrong structure
template:
spec:
containers:
- name: app
image: myapp:1.0
memoryLimit: "soft" # HALLUCINATION - not a valid value

The YAML looks syntactically correct (valid indentation, right structure), but it has fields and values that don't exist in the Kubernetes API. Kubernetes will reject it with a validation error, but if you're in a hurry, you might miss why.

Pattern 3: Non-existent Error Codes

You ask: "What does error code 34987 in nginx mean?"

AI response: "Error 34987 indicates insufficient worker processes. Increase worker_processes in nginx.conf."

Reality: Nginx doesn't have an error code 34987. The AI invented both the code and the explanation. You spend 2 hours increasing worker processes, and the problem doesn't go away because you were solving for a fictional error.

Pattern 4: Fake Package Names and Versions

Real package
$ apt-get install libssl-dev

Hallucinated variants the AI might suggest
$ apt-get install libssl-security-dev # HALLUCINATION - doesn't exist
$ apt-get install openssl-1.2.4-ubuntu # HALLUCINATION - version never existed
$ pip install numpy==1.24.999 # HALLUCINATION - version doesn't exist

The AI generates plausible-sounding package names and versions. When you try to install them, you get "package not found" or version mismatch errors. But to a junior engineer, these look like legitimate package names they've just never encountered.

Pattern 5: Fabricated Metrics and Thresholds

You ask: "What's the normal CPU usage for a PostgreSQL database?"

AI response: "PostgreSQL typically runs at 8-12% CPU under normal load. If you see > 35%, investigate query performance."

Reality: CPU usage depends entirely on your workload. A CPU-intensive OLAP database normally runs at 60-80%. A transactional OLTP database might run at 5%. The AI provided a made-up "normal" because it doesn't know your system.

If you implement an alert at 35% CPU, you'll either:

• Get ignored alerts (normal for your system)
• Miss actual problems (because you're alerting too late)

Pattern 6: Invented Port Numbers

Real PostgreSQL default
port: 5432

Hallucinated variants
port: 5433 # Sounds right, but commonly postgres uses 5432 or custom
port: 5432a # HALLUCINATION - invalid port syntax
port: 54320 # Might be made up for your system

The AI invents port numbers that sound plausible. Port 5433 is actually used by some systems, so it's especially dangerous. You configure an application to use port 5433, but your PostgreSQL is on 5432. Connection fails. You spend time debugging when the real issue is you didn't verify the port.

4. Why Hallucinations Are Hard to Catch

Key insight: Hallucinations are confident, syntactically correct, and semantically plausible. They fail the smell test only if you already know the right answer.

Consider this hallucinated explanation from an AI asked why a server is slow:

The issue is likely high inode utilization on the root partition.
Check with: df -i /

If inodes are > 95% utilized, run: inode-cleanup --aggressive --prune-old
This will remove old inode entries and free up space.

This sounds authoritative:

• "inode utilization" is a real concept
• df -i / is a real command (and correct)
• inode exhaustion is a genuine problem that slows systems
• inode-cleanup --aggressive --prune-old *sounds* like a real command

An experienced sysadmin would immediately know: "inode-cleanup doesn't exist. You clean inodes by deleting files, not with a magic command."

But a junior engineer might:

1. Run df -i / (correct, will show real data)
2. See high inode usage (real problem)
3. Try to run inode-cleanup (fails)
4. Spend 30 minutes looking for this tool
5. Eventually figure out the hallucination

Meanwhile, the real diagnostic was correct (high inodes), but the solution was invented. The real solution would be "identify and delete old files in the partition."

5. The Compounding Problem: Hallucinations in Context

Key insight: One hallucination often leads to another, and the AI doubles down on its own fabrications.

Example: You ask an AI for a Terraform configuration:

AI generates:
resource "aws_instance" "web" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"

tags {
Name = "web-server"
environment = "prod"
cost-center = "engineering"
}

auto_shutdown = true # HALLUCINATION - not a real field
}

You ask: "Why did you use auto_shutdown?"

AI responds: "The auto_shutdown parameter automatically terminates the instance after 30 minutes of inactivity, reducing costs in development environments."

This is a completely fabricated explanation for a completely fabricated field. The AI, faced with its own hallucination, generates a plausible-sounding reason for why the hallucination exists. It's confidently bullshitting itself.

You might implement this and wonder why it never works (because the field is silently ignored by Terraform, and the instance never shuts down).

6. Hallucinations Compound With Time and Scale

Key insight: As AI systems generate more content, hallucinations multiply. What starts as one wrong command becomes a thousand copies of that wrong command on the internet, and the next AI learns the hallucination as fact.

Real example: Stack Overflow has several highly upvoted answers with hallucinated regex patterns for common problems (email validation, IP addresses). Millions of developers have copied these patterns. New AI systems train on Stack Overflow and learn the hallucinated patterns. Those systems generate documentation or tutorials with the same hallucinations. More people copy them.

In IT Operations, this manifests as:

• Hallucinated configuration examples that get copied into runbooks
• Hallucinated CLI commands that propagate through documentation
• Hallucinated error explanations that become the "accepted wisdom"

By the time you discover the hallucination is wrong, it's embedded in your organization's practices.

Practical Use Cases: Where Hallucinations Happen

Use Case 1: Generating a Critical System Configuration

Scenario:

Your team is migrating MySQL to a new server. The database is critical: 500 requests per second, 2TB of data, strict latency requirements.

You ask an AI: "Generate the optimal my.cnf configuration for a production MySQL database with 128GB RAM, serving 500 req/sec."

The AI generates:

[mysqld]
max_connections = 5000
innodb_buffer_pool_size = 100G
innodb_log_file_size = 1024M
query_cache_size = 8G
query_cache_type = 1
thread_cache_size = 256
sort_buffer_size = 2M
bulk_insert_buffer_size = 16M

Performance tuning
innodb_flush_method = O_DIRECT
innodb_file_per_table = 1
slow_query_log = 1
log_queries_not_using_indexes = 1

This looks reasonable. It's well-formatted. It shows knowledge of MySQL tuning parameters.

The Hallucination:

Three problems:

• 
  Query cache. Modern versions of MySQL (5.7.20+) deprecated query_cache. Newer versions removed it entirely. If you're running MySQL 8.0 or MariaDB 10.6+, this will fail or be silently ignored. The AI generated configuration for a MySQL version that's 5 years out of date.
• 
  Buffer pool size too aggressive. At 100GB on a 128GB server, you leave no room for OS, other caches, or application overhead. In production, this will cause memory pressure and swapping, actually *slowing* the database.
• 
  Log file size. 1024M (1GB) log files are dangerously large for a 500 req/sec database. If there's a crash, InnoDB recovery could take 1+ hour. The AI chose a big number because "bigger is more performant," which is wrong for this context.

What Happens:

You deploy this configuration. For the first 4 hours, everything works fine. Then:

• Memory pressure increases (buffer pool is too big)
• System starts swapping
• Query latency jumps from 10ms to 200ms+
• Customers report timeouts
• You emergency rollback

Investigation takes 2 hours because the configuration looks reasonable. Meanwhile, you've lost $50k in revenue from the service degradation.

The Lesson:

AI can generate syntactically correct configurations. It cannot reason about performance trade-offs, your specific workload, or your infrastructure constraints. Every configuration from an AI needs review by someone who understands your system.

Use Case 2: Hallucinated Troubleshooting Steps

Scenario:

Your Kubernetes cluster is experiencing node failures. You ask an AI: "Kubernetes nodes are crashing with CPU at 100%. How do I diagnose and fix this?"

The AI provides a step-by-step guide:

1. SSH into the node
   2. Run: cgroup-monitor --check-limits
   3. If output shows "cpu_group_exceeded", run: kernel-tune --cpu-optimize
   4. Restart kubelet: systemctl restart kubelet
   5. Run: verify-node-health --full-check
   6. Problem should be resolved

Steps 1, 4, and parts of 5 are real. Steps 2 and 3 are hallucinated. Those tools don't exist. Step 2 in particular is dangerous because it suggests there's a tool to check cgroup limits (there isn't. You'd use cat /sys/fs/cgroup/...).

You follow the guide. When you try to run cgroup-monitor, you get "command not found." But now you've lost the time you could have spent on actual diagnosis. The real cause (a misbehaving pod consuming 100% CPU) would have been caught by checking top or kubectl top node.

What Happens:

By the time you realize the AI-generated commands are fake, 15 minutes have passed. The node stays crashed. Pods are evicted. Customers experience degradation.

The Lesson:

Troubleshooting steps from AI are a starting point, not a recipe. Verify each command before running it, especially in production environments.

Use Case 3: Hallucinated Error Codes and Meanings

Scenario:

Your application log shows:

[ERROR] DBCONN_ERR_47362: Failed to establish connection to database

You ask an AI: "What does error code DBCONN_ERR_47362 mean?"

The AI responds: "This error indicates that the database connection pool has reached maximum capacity. Increase connection_pool_max_size from 50 to 100 in the configuration."

You implement the change. The error persists.

After 30 minutes of debugging, you realize:

1. The error code was hallucinated by the AI (your application never generates that code)
2. The real error code is DBCONN_ERR_4736 (missing last digit, your eyes skipped it)
3. DBCONN_ERR_4736 actually means "SSL certificate verification failed"

The real fix: Update the SSL certificate. The AI's suggestion (increasing pool size) was completely unrelated.

What Happens:

You've wasted 30 minutes and deployed a pointless configuration change. More importantly, you now *have two problems*: the original SSL error still exists, and you've made a config change that doesn't address it.

The Lesson:

Never trust AI-generated explanations of error codes without verifying them in your actual codebase or documentation. Error codes are exact, if the AI can't cite where the code comes from, it's guessing.

Use Case 4: Hallucinated Package Dependencies

Scenario:

You're containerizing a legacy application. The Dockerfile needs to install some packages. You ask an AI: "Generate a Dockerfile for a Python 3.8 application that uses numpy and scikit-learn."

The AI generates:

FROM python:3.8-slim

RUN apt-get update && apt-get install -y \
libopenblas-dev \
liblapack-dev \
libatlas-base-dev \
build-essential \
python3-dev

RUN pip install numpy==1.21.0 scikit-learn==0.24.2 flask==2.0.1

CMD ["python", "app.py"]

This looks legitimate. All the packages are real. The pip packages are real versions.

But there's a hallucination: For Python 3.8 on a slim image, some of these dependencies are wrong or suboptimal:

• python3-dev is unnecessary when using the python:3.8 image (it's already included)
• libopenblas is optional and adds significant image size
• numpy==1.21.0 is compatible with Python 3.8, but it's not the current version (the AI didn't know to suggest a more recent version that's also compatible)

What Happens:

1. Docker build succeeds (all packages genuinely exist)
2. Image size is larger than necessary (200MB instead of 120MB)
3. Startup time is longer because of unnecessary dependencies
4. Deployment is slower
5. In a microservices environment, that 80MB difference × 100 services = real infrastructure cost

The Dockerfile isn't *wrong*, but it's suboptimally hallucinated. The AI included packages it *thinks* you need, not packages you actually need.

The Lesson:

AI-generated dependency lists should be verified. Remove anything unnecessary. Test the image and compare size to a hand-built version.

Anti-Patterns: Where Hallucinations Destroy Production

Anti-Pattern 1: Accepting AI Explanations for Errors You Don't Understand

The problem:

Your application throws an error you've never seen. You ask an AI what it means. The AI provides a detailed explanation. It sounds authoritative. You implement the suggested fix.

Three days later, you discover the AI fabricated the explanation. The real error came from a third-party library update, not the cause the AI suggested. You've wasted 3 days and deployed a fix that addresses a non-problem.

Why it's dangerous:

You don't know enough to catch the hallucination. The AI is confident. You trust authority.

How to avoid it:

• Always cross-check error codes against your actual source code or documentation
• If an AI suggests something new, verify it in the official docs before trusting it
• Search your codebase for the error, if you can't find where it's generated, the explanation is likely hallucinated

Anti-Pattern 2: Using AI-Generated Commands Without Testing

The problem:

An AI generates a bash one-liner that supposedly will "find and delete all files modified more than 30 days ago":

find /var/log -mtime +30 -delete

You run it in production without testing first (it's "just" a find command, right?). It deletes more files than you expected because -mtime +30 includes files from 30+ days ago, and you only wanted files 30+ days old *in certain directories*.

What happens:

You've deleted application logs that your compliance team needs. Audit failure. Legal involvement. Lessons learned meeting.

How to avoid it:

• Always test commands in a non-production environment first
• Break complex one-liners into separate steps so you can verify each step
• Use find -delete with extreme caution, always test with -print first

Anti-Pattern 3: Trusting Hallucinated Performance Metrics

The problem:

An AI tells you: "Redis typically uses 2-4GB of RAM for a million keys."

You size your Redis infrastructure based on this. But "typical" depends entirely on your key size, value size, and memory management strategy. A million small keys might use 500MB. A million large values might use 50GB.

You either:

• Over-provision (wasteful)
• Under-provision (performance problems)

How to avoid it:

• Always test with your actual data
• Use redis-cli info memory to measure actual usage
• Calculate expected size: (key_size + value_size + redis_overhead) × num_keys

Anti-Pattern 4: Copying Hallucinated Configurations Into Your Documentation

The problem:

An AI generates a configuration. It looks good. You add it to your internal wiki as a "template for future use."

Six months later, a new engineer copies this template. It has a subtle hallucination that breaks their deployment. They assume the wiki is canon and don't question it.

Now your hallucination is embedded in your organizational knowledge.

How to avoid it:

• Tag any AI-generated content as "AI-generated, requires verification" in your wiki
• Have peer review before adding anything to canonical documentation
• Update documentation as reality diverges from templates

Anti-Pattern 5: Assuming AI-Generated Code is Tested

The problem:

An AI generates a Python script that supposedly handles "all edge cases" for file processing. You deploy it to production.

A week later, an edge case appears: the script assumes all files are UTF-8, but one file is ISO-8859-1. The script crashes. This "tested" code wasn't tested at all, the AI generated it without verification.

How to avoid it:

• Treat AI-generated code as untested drafts
• Write tests for edge cases *before* deploying
• Have another engineer review the code

Human Judgment Checkpoints

Checkpoint 1: Can I Verify This in My Own System?

When AI provides a suggestion, ask: "Can I check this myself?"

• Suggested command? Run it in a test environment first.
  - Suggested configuration value? Check your actual system.
  - Suggested error explanation? Search your codebase for the error.

If you can't verify it easily, be skeptical.

Checkpoint 2: Does This Match My Understanding?

If the AI suggests something that contradicts what you know about your system, don't trust it.

Example: AI says "Increase query_cache_size for better performance." You know you're running MySQL 8.0, which removed query_cache. The AI hallucinated, because it doesn't know your MySQL version.

Checkpoint 3: Is This Too Specific or Too Generic?

Hallucinations often live in the extremes:

• Too specific: "Add this exact line to your config." (Might be fabricated.)
  - Too generic: "CPU usage should typically be 20-30%." (Depends entirely on your workload.)

Real answers from someone who knows your system usually have nuance: "CPU usage depends on your workload, but you should monitor for sustained > 80% and investigate."

Checkpoint 4: Can I Find This in Official Documentation?

Before trusting AI:

• Search the official docs for the technology (Kubernetes docs for kubectl commands, PostgreSQL docs for config options)
  - Check Stack Overflow for common problems
  - Ask yourself: "Would this be in the official docs if it were real?"

If the AI suggests something that should be in the official docs but isn't there, it's probably hallucinated.

Checkpoint 5: What's My Rollback Plan If This Is Wrong?

Before implementing AI suggestions in production, ask:

• If this is a hallucination, how will I know?
  - Can I roll back quickly?
  - What's the blast radius if it's wrong?

For "change a config file," rollback is easy. For "run this delete command," rollback might be impossible.

Real Hallucination Examples from IT Operations

Example 1: The Phantom TCP Window Size

What happened:

An engineer asked an AI for network tuning suggestions. The AI recommended:

sysctl -w net.ipv4.tcp_window_size_preset=32768

The engineer added this to their production sysctl configuration. The system failed to boot because this sysctl parameter doesn't exist.

Why it's a hallucination:

The AI knew about tcp_rmem and tcp_wmem (real parameters that tune TCP window size). It synthesized a plausible name that *sounds* like it should exist, but doesn't. When the system tried to apply a non-existent sysctl, it failed startup validation.

Cost:

Production outage until the bad sysctl was removed. 30 minutes of downtime.

Example 2: The Non-existent Docker ENV Variable Syntax

What happened:

An AI generated a Dockerfile with:

ENV DATABASE_URL $DATABASE_URL

This is the wrong syntax. The correct syntax is:

ENV DATABASE_URL=${DATABASE_URL}

With the hallucinated syntax, the environment variable is set to the literal string "$DATABASE_URL" instead of the value of the DATABASE_URL variable.

Why it's a hallucination:

The AI mixed up Docker syntax with shell syntax. In a shell script, $DATABASE_URL works. In a Dockerfile ENV instruction, it doesn't. The AI generated something that's syntactically valid Docker but semantically wrong.

Cost:

Application can't connect to database because DATABASE_URL is literally "$DATABASE_URL". Takes 20 minutes to debug why. Partial outage for users.

Example 3: The Invented Systemd Property

What happened:

An AI suggested a systemd service file for a custom application:

[Service]
Type=simple
ExecStart=/opt/myapp/bin/myapp
Restart=on-failure
RestartSec=10
MaxRetries=5

The MaxRetries property doesn't exist in systemd. Systemd ignores it silently. The actual property is handled through StartLimitBurst and StartLimitIntervalSec.

The engineer deployed this service. When the application failed, it kept restarting indefinitely (no actual max retry limit), consuming CPU and logs.

Why it's a hallucination:

The AI knew systemd has restart policies. It invented a property name that *should* exist but doesn't.

Cost:

Resource exhaustion. Logs fill up. System becomes unresponsive. Takes 2 hours to diagnose and fix.

Key Takeaways

Understand that hallucination is fundamental to how AI works. AI doesn't have access to ground truth. It generates text probabilistically. Sometimes that generation is correct. Sometimes it's plausible-sounding fiction. You can't eliminate hallucinations entirely. You can only build systems to detect them.

Recognize that IT contexts make hallucinations particularly dangerous. Your infrastructure is specific. Your tools are proprietary. Your recent changes are unknown to AI. This knowledge gap is where hallucinations thrive.

Verify everything before production. Commands in a test environment. Configurations against your actual system. Error codes in your source code. Package versions in your package manager. Every AI suggestion needs a verification step.

Build organizational skepticism into your culture. Don't assume AI knows your system better than you do. Require peer review of AI-generated critical content. Document things as "verified" or "not yet verified" in your wiki.

Remember: Confidence is not accuracy. AI sounds confident even when it's hallucinating. A human saying "I'm not sure, let me check the docs" is more reliable than an AI confidently providing a made-up answer.

*Next lesson: Understanding the limits of AI's reasoning in troubleshooting, why pattern matching isn't the same as diagnosis.*