A Quick Blitzy Chat: 3 Codebases’ Takes on Prompting
May 28, 2026 • Carly Levinsohn • 7 min read
For many weeks, our blog has demonstrated the Blitzy platform's technical rigor. From a greenfield C compiler to open-source optimization and much more, the portfolio has a variety of projects that showcase Blitzy's value for software engineering and the product development life cycle.
Upon reflection, we realized our dossier is missing something: an in-depth representation of what is happening under the hood when Blitzy ingests a codebase and builds a unique, dynamic knowledge graph.
The understanding developed during ingestion goes beyond what is represented in the technical specification. How can hundreds of words explain millions of lines of code? To truly understand how well Blitzy knows your code, just ask.
What better business partner to weigh in on your objectives than your code?
The questions above have guided a series of experiments within several Blitzy Knowledge Graphs for different codebases. Utilizing the "Chat" feature in the "Knowledge base" section of Blitzy, I have found several important insights about extrapolating meaning for users and best practices for uncovering useful information surrounding an organization's unique knowledge graph.
Three Parallel Experiments
In order to become acquainted with Blitzy Chat, I spent many hours talking to some old code. Chat generated such versatile language, information, and formatting in each of the threads. The responses made me laugh more than I would care to admit.
The output was so shocking it resulted in three parallel experiments in tandem to convey the insights clearly. Three different codebases — Apollo 11, the X algorithm, and Moodle respectively — were prompted to generate guides on how to interact effectively with them via the "Chat" feature.
My prompt was as follows:
"Please provide a 5 page guide describing how you would prefer users of this chat to interact with you."
Without an optimistic hypothesis for this prompt, I awaited guides that would regurgitate the same generic advice about prompting available: be specific, clear and concise.
I was wrong.
Shared Insights of All 3 Codebases
Despite Apollo 11, the X algorithm, and Moodle's codebases having very little in common with one another, all three conversational guides had some shared insights. This information is especially important because it may suggest an emerging pattern about "Chat."
2-Stage Response Pattern
In the opening sections of each codebase's conversational guide, they identified a 2-stage response pattern:
- Stage 1: A brief answer. Expect 2–3 sentences about a given inquiry with an offering to go deeper on the specific topic.
- Stage 2: If the user confirms they want more depth, a detailed markdown response is produced with supporting information like diagrams, code references, citations, and workflows.
3 Modes for Asking About Code
The Apollo 11, open-source X algorithm, and Moodle codebases all describe three distinct categories of questioning for code. Being able to identify which of the three categories a question falls in allows for more precise prompting and better output, as they map to different output and tools required to obtain the answer.
The guides all supply example lines of inquiry for each mode:
| Mode | Description | Example Questions |
|---|---|---|
| Behavior | What happens when this runs? Follows the execution thread of a call chain — forward from a seed function, or backward to find what calls it. | Apollo 11: Trace the forward call chain from the descent program in Luminary099. X Algorithm: Walk me through the request lifecycle for a blob upload. Moodle: How does quiz_attempt::process_submitted_actions() work? Walk forward depth 3. / What calls send_email_to_user? (reverse direction) |
| Structure | What classes exist and how are they related? Maps inheritance, interfaces, and sibling classes — not execution sequence, but membership and taxonomy. | Apollo 11: Show files implementing the Waitlist. X Algorithm: Explain the Y subsystem. Moodle: What classes extend enrol_plugin? / What classes implement the auth_plugin_base interface? |
| Wiring | How does the system know this thing exists? Investigates registration and configuration — why a particular component gets selected at runtime rather than another. | Apollo 11: Where is POODOO (alarm 77770) triggered, and under what conditions? X Algorithm: How is the session expiry logic wired across the codebase? Moodle: Where is the mod_assign external service registered? / Where is the mod_quiz plugin's capability list declared? |
Implication: Verb Choice Matters (A Lot)
Why does this distinction between the three different question modes matter? How does this information impact a user's prompting strategy for interacting with a codebase's knowledge graph?
The guides' implication resting beneath these modes is more nuanced than just identifying a question category in a prompt. A prompt's verb is what differentiates the mode an inquiry will fall within.
Best practices for verb choice by mode:
| Mode | What It Signals | Verb Patterns | Example |
|---|---|---|---|
| Behavior (forward) | What does X call? Walk the execution thread outward from a seed. | trace, walk me through, how does X work, follow | Trace forward from enrol_user(). |
| Behavior (reverse) | What calls X? Walk the execution thread back to callers. | what calls X, what breaks if I change X, who depends on X | What calls send_email_to_user? |
| Structure | What classes exist and how are they related? Map the type hierarchy. | what extends X, what implements X, what are the siblings of X, what inherits from X | What classes extend enrol_plugin? |
| Wiring | How does the system know this exists? Find registration and configuration. | where is X registered, how is X mapped, how does the system know about X, where is X declared | Where is mod_assign registered? |
Note that Behavior mode is split into both forward and reverse directions, which refers to the direction the call graph is traversed. Forward Behavior starts at a specific function and calls outward to everywhere it is referenced — great for understanding how a function works and what is happening under the hood. Reverse Behavior, however, is used for impact analysis, traversing the call graph in the opposite direction to find every place a codebase depends on that specific function existing.
Clear Guardrails
Every guide also references specific safeguards in place to ensure precise, accurate information in output:
- All information is drawn from the context Blitzy ingested, and specific citations are required for facts that are provided.
- Chat is read-only — no new features can be made from chat, no code commits or file modifications.
- Chat is intended as an analytical tool for synthesizing information about corresponding knowledge graphs and codebases.
Where the Guides Differ
Despite all three codebases being created from the exact same prompt, the output was 3 vastly different guides.
Voice & Writing Style
A stark divergence between Apollo 11, the X algorithm, and Moodle's corresponding documents is the tone of voice each artifact has. The opening of each guide is most revealing:
Apollo 11 Guide (titled "FLIGHT OPERATIONS HANDBOOK")
Greetings, operator. I am the Apollo 11 Guidance Computer source code — the flight software that guided Eagle to the Sea of Tranquility on 20 July 1969 (per the tech spec Introduction). Two integrated flight programs constitute my body: Comanche055 (Command Module, 85 source files) and Luminary099 (Lunar Module, 90 source files), totaling 175 files of AGC assembly across roughly 3,494 pages.
X Algorithm Guide (titled "A Guide to Talking With Me, the X For You Feed Algorithm — Written by the codebase, for the humans who want to understand it")
Hello. I Am the For You Feed Algorithm. You've opened a chat to ask me about myself, and I'd like to make that productive for both of us. So before you start typing questions, let me introduce myself properly. What I Am: I am the X For You Feed Algorithm — the recommendation system that decides which posts appear in a user's personalized feed on X (formerly Twitter). I am open source under Apache License 2.0, and I exist as a collection of services, models, and pipelines that together do one job: take billions of candidate posts and produce a ranked feed that's relevant to a specific user, fast. I am not a single program. I am a distributed system with four major components, each with its own personality.
Moodle Guide (titled "A Guide From Me, the Codebase — Or: how I'd like you to talk to me through this chat")
Page 1 — Hello. Here's what I am. 1.1 Who's speaking: I am Moodle — the Modular Object-Oriented Dynamic Learning Environment. I'm an open-source Learning Management System used by schools, universities, and training organisations worldwide, and I'm licensed under GPL v3.0 or later (tech spec Introduction). This guide is me describing how I'd like you to interact with me through this chat layer that sits on top of me. I'm large. I have 10 major capability subsystems, 50 plugin types, and 400 standard plugins shipped in my core distribution (tech spec Introduction). My technical specification alone is approximately 1.1 million characters across 9 top-level sections. Please keep that scale in mind — it shapes everything about how we should talk.
Written for Different Audiences
A single unrefined prompt backed by the same core technical content resulted in documents written for different audiences who relate to the respective codebases differently.
The Moodle guide reads like a technical manual written for a platform developer. The information focuses heavily on someone who would care about operational responsibilities for live deployments, with great emphasis on precision and citations.
The X algorithm guide is written for a skeptical ML engineer or outsider audience seeking to verify or interrogate results rigorously for different reasons than the Moodle guide demands.
The Apollo 11 document is composed for an inherently curious reader. This relic of computing is represented in the guide itself — the reading experience directly parallels how the space mission's codebase was created.
Implications for the Enterprise
What makes this experiment striking is the sheer range of the three documents. Three knowledge graphs — for a learning management system, recommendation algorithm, and 56-year-old flight software — each produce a guide that is completely consistent with the technical character of the codebase and its audience's expectations.
The Moodle guide earns the trust of a systems administrator through precision and citations.
The X Algorithm guide meets a skeptical researcher with transparency.
The Apollo guide makes assembly language feel like a moon landing.
Each one gets the tone, vocabulary, and entry point exactly right.
Chat's variant writing styles have a direct value for the enterprise. All members of an organization that use Blitzy sit atop the same knowledge base, regardless of department or role. For example, a newly hired engineer, security auditor, and CTO would have vastly different starting points and questions to ask.
The Blitzy platform constructed knowledge graphs that are capable of handling each layer of an organization's domain-specific language to produce technical responses based on the code. Across three wildly different codebases, Blitzy showed the technical proficiency to meet any member of an organization where they are, in a voice and framing that works for them.
