The Graveyard Shift: Lessons from Teaching an AI to Speak with the Dead

The Séance Nobody Expected

Picture the scene: Three developers hunched over laptops at 2 AM, surrounded by energy drinks and the faint glow of Halloween decorations. We’d just signed up for Kiroween — a hackathon where you build with Kiro, an AI-powered IDE that’s basically your coding familiar.

Our pitch? “Repo Necromancer” — an AI that could resurrect abandoned codebases, explaining their twisted logic and proposing escape routes from legacy hell.

The plan was simple: Feed dead code to a powerful LLM, get architectural insights back. Ship it. Win prizes. Go home.

Then we actually tried building it.

What we discovered over that cursed weekend wasn’t about AI capabilities or model sizes. It was something stranger: Building effective AI tools is less like programming and more like binding a ghost that has the same cognitive problems as a sleep-deprived senior engineer.

Our AI familiar:

• Forgets things unless you give it a journal (context windows aren’t infinite)
• Gets expensive to consult repeatedly (tokens cost real money)
• Makes up plausible-sounding nonsense (hallucinations are the AI equivalent of drunk confidence)
• Needs constant reality checks (won’t verify its own work without prompting)
• Gets confused by cute naming conventions (puns in production code hurt humans and AIs equally)

Four brutal truths emerged from our midnight coding sessions. Each one flipped our assumptions about “intelligent systems” on their head.

Truth #1: Your AI Doesn’t Need Better Vision — It Needs a Journal

The Obvious (Doomed) Approach

Someone on the team suggested the “clean” solution: “Let’s just wrap ripgrep. User asks a question, we grep the code, feed matches to the LLM, boom — instant code oracle.”

Stateless. Fast. Elegant in that minimalist way engineers fetishize.

Also completely useless for anything beyond party tricks.

The Horror We Didn’t See Coming

Imagine hiring a consultant to understand your nightmare legacy system. They’re brilliant — truly gifted at analysis. But here’s the catch: After every single conversation, you erase their memory completely.

Every Monday: “What does this system do?” They read everything from scratch.

Every Tuesday: “Where’s the checkout logic?” They start over, no memory of Monday’s work.

Every Wednesday: “How do these services connect?” Ground zero again. Eternal Groundhog Day.

This isn’t a consultant — it’s a cosmic punishment. And it’s exactly what stateless search-based AI tools experience.

How Real Hauntings Work

When a proper ghost haunts a mansion, it doesn’t randomly phase through walls hoping to find something interesting. Over time, the spirit builds what paranormal investigators call “residual knowledge”:

• Which room holds the darkest secrets
• How the architecture actually flows
• Where the bodies are buried (metaphorically… usually)
• Which events matter vs which are just noise

The haunting deepens. The ghost doesn’t just see — it remembers, connects, understands.

Building the Spirit’s Journal

We gave our AI something every ghost needs: a place to write things down.

Our “index” became its grimoire — a persistent record of everything learned. Think of it as the AI’s personal filing system where it stores:

• Basic facts about each file (path, language, size, last modified)
• Summaries of what each file actually does
• Domain tags marking files as related to auth, payments, or that cursed legacy module
• Relationship maps showing which files import each other
• Architecture understanding built up over time

Now when someone asks the familiar: “Show me the payment flow”

The AI doesn’t re-read the entire codebase. It opens its journal and thinks:

“Consulting my notes… Ah yes, payment-related files are marked in my grimoire: the payment gateway service, the checkout handler route, and the transaction model. Let me use my scrying tool (ripgrep) to pull exact incantations…”

It’s mimicking what experienced developers actually do: Build mental models, then investigate specifics.

The Shovel vs The Map

We started calling ripgrep “RIP.grep” (Rest In Pieces grep) — because in our architecture, it’s not the AI’s brain. It’s a grave-digging tool the AI uses strategically.

RIP.grep = the shovel that digs up exact code Index = the cemetery map that shows which graves matter

You wouldn’t excavate every grave in a cemetery looking for one specific corpse. You’d consult the burial records first, then dig.

Our AI learned the same efficiency.

Truth #2: Séances Are Expensive — Stop Summoning Spirits for Trivial Questions

The Nightmare Math

Once you commit to building a memory system with AI-generated summaries, you face an uncomfortable calculation:

10,000 files × “summarize this” = massive token costs + hours of processing + your entire API quota + heat death of your budget

We called this the “token incinerator problem” — turning money into smoke by asking the AI to deep-analyze everything.

Vampires Don’t Waste Blood

Ancient vampires in folklore are strategic feeders. They don’t drain every person they meet. They’re selective predators who:

• Use basic senses for most decisions (smell, sound, movement)
• Save supernatural powers for worthy prey
• Never expend more essence than necessary
• Build hunting patterns based on learned information

The old vampire who survives centuries? That’s the one who mastered resource conservation.

Our Tiered Haunting Protocol

We built a three-phase resurrection ritual that treats the LLM like the precious resource it is:

Phase One: Bone Reading (Zero Tokens)

First, we do a fast scan of the entire repository without calling the AI at all. We’re looking for cheap signals that don’t require deep analysis:

• File extensions tell us the language
• Import statements show us dependencies
• How many other files import this one (centrality score)
• Keywords that hint at domain concepts like “payment” or “auth”
• Obvious junk to ignore: node_modules, .git folders, build artifacts

Cost: Milliseconds. Zero API calls.

This gives you the graveyard’s shape without expensive divination.

Phase Two: Selective Spirit Summoning

Now we get strategic. Instead of summarizing every file, we:

1. Rank files by importance (how central are they in the import graph?)
2. Look for files in key directories (services, routes, models)
3. Find files containing keywords from the README
4. Set a strict budget — maybe 150 files maximum

Only these chosen files get the expensive LLM treatment. We ask the AI to analyze them and extract:

• What does this file do?
• What domain concepts does it touch?
• What’s its role in the system?

We only burn tokens on files that matter — the architectural keystones, the ritual centers, the command chambers.

Phase Three: Hunger-Driven Learning

The really clever bit: We don’t summarize everything upfront.

When a user asks “How does checkout work?”, the system:

1. Extracts key concepts from the question (checkout, payment, flow)
2. Checks what we already know from our index
3. Identifies gaps — relevant files we haven’t summarized yet
4. Spends tokens ONLY on filling those specific gaps
5. Caches the results for future questions

The AI gets progressively smarter about the codebase, like a ghost that:

• Does a quick walkthrough on night one
• Investigates specific rooms when mortals ask about them
• Builds deeper understanding over weeks of haunting

The Conservation Law

Don’t ask your AI oracle to analyze everything equally. Use cheap pattern-matching to triage, expensive reasoning only on what matters.

Treat LLM calls like summoning circles: costly rituals requiring preparation, not casual parlor tricks.

Truth #3: Unbound Spirits Make Terrible Coworkers

The Poltergeist Pattern

Most AI code generators work like mischievous spirits. A typical interaction goes like this:

Developer: “Add authentication” AI: ✨ manifests 200 lines of code ✨ AI: “The spell is woven!” Developer: runs tests Terminal: ☠️ FAILED FAILED FAILED ☠️ Developer: “…great”

The AI is creative, confident, and utterly unaccountable. It’s like a poltergeist that throws furniture around and then vanishes before you can ask “but will this actually work?”

The Master Necromancer’s Method

Real practitioners of dark arts don’t just conjure — they bind. Every summoning includes verification. An experienced necromancer follows a disciplined process:

1. Weave the incantation (write the code)
2. Test the containment circle (run tests)
3. If spirits breach: analyze the failure, strengthen bindings, test again
4. Only release when stable

Professional necromancers don’t release unbounded entities into production. That’s how you get haunted codebases.

Teaching Our Familiar Self-Respect

We gave our AI a tool called run_pytest through MCP (Model Context Protocol). Not as a suggestion—as a mandatory ritual step in its workflow.

The new process became:

• Receive the mortal’s request
• Meditate on the requirement
• Weave code changes
• Invoke test spirits ← The binding circle (cannot be skipped)
• If spirits rebel: interpret the error messages, strengthen the code, retry tests
• Only then report success

What This Looks Like When Demons Cooperate

Here’s a real example from our testing:

Mortal: “Add GitHub URL parsing”

Familiar: writes parse_github_url() function Familiar: casts binding circle by running tests Test Spirits: 💥 BREACH at test_parse_github_url_ssh_format

Familiar: “The circle is compromised. The SSH format git@github.com:user/repo.git broke containment. Reinforcing the pattern…”

Familiar: adjusts regex wards Familiar: recasts binding circle Test Spirits: ✅ All 23 entities properly bound

Familiar: “The incantation is complete and verified.”

The mortal never became the janitor cleaning up manifestation accidents. The familiar took responsibility for its own bindings.

Beyond Code: The Pattern of Accountability

This applies to any AI generation:

Data pipelines: Instead of just generating transforms, the AI validates output schemas automatically

Documentation: Instead of just writing docs, the AI checks links and tests code examples

Infrastructure: Instead of just manifesting Terraform, the AI verifies deployment and tests connectivity

UI Components: Instead of just creating designs, the AI validates accessibility and tests responsive breakpoints

The principle: Creation without verification is chaos magic, not engineering.

True intelligence includes self-correction instincts.

Truth #4: Even Demons Need Professional Names on Their W-2

The Temptation of Pure Aesthetics

We were building a Halloween project. Obviously we wanted maximum spooky vibes throughout the codebase. Imagine functions named things like:

• summon_dead_repo()
• dig_through_corpses()
• raise_ancient_codebase()

Atmospheric! Thematic! Absolutely nightmarish for the AI to work with.

Why Spirits Need Mundane Names

Here’s what broke our assumptions: Kiro (our AI IDE) isn’t just a user of this code — it’s the primary author.

When the AI generates, edits, or debugs code, it needs to:

• Understand function purposes at a glance
• Import modules without metaphor translation
• Parse error messages in stack traces
• Refactor code confidently
• Call APIs without guessing what “summon_ancient_dead” actually does

Every cutesy metaphor adds cognitive friction — for both humans AND AI.

The Two-Identity Revelation

We realized our system needed to live in two worlds simultaneously.

The Theatrical Identity (What Mortals See)

This is the public-facing brand:

• Project title: “Repo Necromancer”
• UI buttons: “Raise Dead Repo”, “Perform Necromancy Pass”
• Tool displays: “RIP.grep” (Rest In Pieces grep)
• Status messages: “Performing necromancy pass on the ancient codebase…”
• Chat persona: “I am a patient elder who resurrects fallen systems from beyond the veil”
• Demo video: Heavy on graveyard metaphors and spooky narration
• README: Full Halloween aesthetic with skull emojis and dark humor

The Technical Identity (What Machines See)

This is the actual implementation, with boring, clear names:

Module structure: indexer.py, scanner.py, flow_tracer.py (not necromancer.py, graveyard_digger.py, spirit_tracker.py)

Function names: index_repository(), scan_files(), trace_data_flow() (not summon_dead_modules(), excavate_burial_grounds(), follow_ghost_trails())

Class names: RepoIndexer, FileScanner, FlowAnalyzer (not NecroMaster, CorpseDigger, SpiritTracker)

API endpoints: /api/index, /api/search, /api/analyze (not /api/raise-dead, /api/dig-graves, /api/summon)

The Folklore Pattern

This mirrors ancient supernatural laws. Every powerful entity in mythology has multiple names:

Demons have summoning names (for mortals to call them) and true names (for binding them)

Gods have sacred names (temple use) and common names (everyday prayer)

Vampires have human aliases (daytime interactions) and night-names (their true nature)

Fae famously guard their true names while using playful aliases with mortals

We intuitively understand: Context determines which name has power.

For our necromantic AI system:

• Human context: Emotional, memorable, theme-reinforcing
• Machine context: Precise, unambiguous, maintenance-friendly

Why This Matters for AI Agents

Clean internal naming isn’t about being boring — it’s about cognitive accessibility.

Imagine the AI trying to fix a bug in themed code where functions are called things like extract_soul(), dark_ritual_config, and graveyard_path. The AI has to constantly translate metaphors while debugging.

Versus clear code where functions are called generate_summary(), indexing_config, and repo_path. The AI immediately understands what each variable represents and can work confidently.

When the AI needs to debug, refactor, or extend — clarity beats cleverness every time.

The Necromancer’s Final Incantation

After three sleepless nights wrestling with our AI familiar, here’s the forbidden knowledge we uncovered:

Building powerful AI systems isn’t about summoning bigger demons. It’s about designing better circles to work with the demons you have.

The Four Rituals Revisited

Memory: Don’t treat AI like it has perfect recall. Build external memory systems — indexes, caches, persistent knowledge bases.

Resources: Don’t burn tokens on everything equally. Triage with cheap methods, use expensive AI strategically.

Verification: Don’t let AI create without checking. Build self-correction loops into the system architecture.

Naming: Don’t use cute names everywhere. Split theatrical branding (UI) from technical clarity (code).

The Unifying Revelation

These aren’t four separate tricks. They’re one principle applied four ways:

Design for AI’s actual cognitive architecture, not the omniscient AI of sci-fi.

AI familiars, like mortal necromancers, are powerful despite having:

• Limited working memory (context windows cap out)
• Expensive cognitive operations (tokens cost money)
• Imperfect persistence (they forget unless you save state)
• The need for reality checks (they’ll hallucinate confidently)

The magic happens when you design FOR those constraints, not against them.

Your Grimoire for the Road

If you’re building AI-powered tools, consult these portents:

The Memory Question: Does your AI rebuild understanding from scratch every query, or does it maintain a persistent knowledge base?

The Economics Question: Are you burning expensive LLM calls on work that cheap heuristics could handle?

The Accountability Question: Does your AI verify its own outputs, or does it generate chaos and leave humans to clean up?

The Identity Question: Is your internal architecture optimized for AI comprehension, or for human aesthetic preferences?

The Graveyard Awaits

The truth about AI agents isn’t that they’re too limited — it’s that they’re limited in exactly the same ways humans are.

And humans, when given the right tools (notebooks, verification processes, clear communication, strategic resource allocation), accomplish extraordinary things.

Your AI familiar can too.

Just remember:

• Give it a journal (memory)
• Don’t waste its energy (token budgets)
• Make it check its work (verification loops)
• Use clear names internally (cognitive clarity)

The dead repositories are out there, waiting to be raised. Now you know the rituals.

Go forth and practice your necromancy responsibly.

P.S. — We didn’t win first place at Kiroween. But we learned more from building Repo Necromancer than from any tutorial. Sometimes the real treasure is the ghosts we bind along the way.