When AI hallucinated 'systemd' and 'cron' on my Windows machine: The 'context blindness' trap of LLMs

Hey, it's Grandpa Oji (@oji_ai_dev) here.

I'm a 38-year-old developer who tinkers with AI bots in my side hustle and works as a full-time engineer during the week. Recently, I decided to start a simple dev blog – separate from my notes – to properly document my personal projects.

Naturally, I wanted to leverage AI for some of the article generation to boost efficiency. As a first step, I asked it to write a setup guide for a simple bot I run periodically via Windows Task Scheduler.

I fed it the logs and source code, then vaguely prompted: "Explain how to set up this bot." When I read the first draft, the opening lines immediately threw me for a loop.

"First, register it as a service using systemd. Place the following unit file in /etc/systemd/system/..."

...Huh? systemd?

My bot runs on a plain old Windows 11 machine, not Linux. systemd doesn't exist there. Reading further, it continued: "For periodic execution, it's convenient to register a schedule using crontab -e." It had completely mistaken the operating system.

This was rough. It strung together plausible-sounding technical terms, but the content was pure fantasy. It was a spectacular moment of AI 'context blindness.'

The Cause: Implicit Assumptions Don't Translate

Why did this happen? One hundred percent, it was because my prompt was too vague.

My instruction to the AI was literally just, "Write a blog post explaining this script." I completely omitted crucial, seemingly obvious information like the OS being Windows and that it was scheduled with Task Scheduler.

When an LLM receives incomplete information, it attempts to fill in the gaps with the "most probable, general knowledge" from its vast training data. When the topic shifts to demonizing or periodically executing scripts on a server, the vast majority of technical articles in the world assume a Linux environment.

So, the AI reasoned with a ridiculously simple inference: "Okay, this person wants to run a bot on a server. Servers typically mean Linux, right? Therefore, I should talk about systemd and cron."

From my perspective, I'm thinking, "No, it's my Windows machine humming in the corner of my room," but the AI doesn't pick up on that 'vibe.' Any context that I consider 'obvious' must be explicitly stated in words, or the AI won't grasp it.

The Fix: Give AI a Map in the Form of 'Constraints'

The way to prevent this 'context blindness' is simple: clearly define "constraints" in your prompt.

For example, in this case, my initial vague prompt looked like this:

# Bad example
Write a blog post explaining how to periodically run the following Python script.

# --- Script ---
import time
from pathlib import Path

def main():
    log_file = Path("log.txt")
    with log_file.open("a", encoding="utf-8") as f:
        f.write(f"Executed at {time.time()}\n")

if __name__ == "__main__":
    main()

With this, the AI felt free to interpret and started talking about Linux.

So, I gave it a "map" in the form of the execution environment:

# Good example
Write a blog post explaining how to periodically run the following Python script.

# Constraints
- OS: Windows 11
- Execution Method: Task Scheduler
- Audience: Beginners using Python on Windows

# --- Script ---
import timerom pathlib import Path

def main():
    log_file = Path("log.txt")
    with log_file.open("a", encoding="utf-8") as f:
        f.write(f"Executed at {time.time()}\n")

if __name__ == "__main__":
    main()

By explicitly stating the OS and execution method under "# Constraints," the accuracy of the AI's output dramatically improved. When I regenerated with this prompt, it correctly provided sensible steps for a Windows environment, starting with "Open Task Scheduler, then 'Create New Task'...".

The Lesson: AI is Smart, But Not Psychic

This incident reinforced my view that LLMs are like "incredibly competent, but utterly clueless, new hires."

If your instructions are ambiguous, the AI, with good intentions, will fill in the gaps with general knowledge. But if that knowledge doesn't align with the actual situation (i.e., the execution environment), the output won't just be useless – it can be actively harmful.

Especially when having AI handle technical content, you must communicate the "execution environment context" upfront, even if it feels tedious. This includes the OS, library versions, frameworks, and hardware configuration. Neglecting this will result in it confidently generating non-existent commands or code that won't run due to version mismatches.

The generated content often looks plausible, which means there's a serious risk that someone less knowledgeable might believe it. Tragedies like debugging incorrect systemd configuration files for hours could easily happen.

Delegating tasks to AI is convenient, but you can't escape the need for precise "prompt engineering" and the "human oversight" of checking the final output. Slack on these fundamentals, and you'll only end up causing yourself trouble.

This was a good failure log that made me rethink how I interact with AI.

---

I build and run small Python systems — trading bots, RAG APIs, scheduled automation — and write up whatever breaks along the way.

If a provider-agnostic RAG Q&A API is useful to you, mine is MIT-licensed on GitHub: rag-faq-api. It runs and passes its full test suite **with no API key* (offline stub LLM + hashing embedder), swaps to Claude / Gemini / OpenAI via one env var, and ships a retrieval-quality harness (Hit@k / MRR / Recall@k) with a chunking sweep.*