Knowledge Priming

Rahul Garg has observed a frustration loop when
working with AI coding assistants - lots of code generated, but needs lots
of fixing. He's noticed five
patterns that help improve the interaction with the LLM, and describes
the first of these: priming the LLM with knowledge about the codebase and
preferred coding patterns.

more…

Knowledge Priming

AI coding assistants default to generic patterns from their training data.
I propose treating project context as infrastructure—versioned files that prime the model before each
session—rather than relying on ad-hoc copy-pasting. This is essentially manual RAG (Retrieval-Augmented Generation),
and I believe it fundamentally changes the quality of AI-generated code.

24 February 2026

Rahul Garg

Rahul is a Principal Engineer at Thoughtworks, based in Gurgaon, India.
He is passionate about the craft of building maintainable software through DDD and Clean Architecture,
and explores how AI can help teams achieve engineering excellence.

This article is part of a series:

Patterns for Reducing Friction in AI-Assisted Development

Contents

• The Default Behavior Problem

• The Knowledge Hierarchy

• What Knowledge Priming Looks Like

• Before and After

• Anatomy of a Priming Document

• 1. Architecture Overview

• 2. Tech Stack and Versions

• 3. Curated Knowledge Sources

• 4. Project Structure

• 5. Naming Conventions

• 6. Code Examples

• 7. Anti-patterns to Avoid

• Priming as Infrastructure, Not Habit

• Common Pitfalls

• The “Too Much” Trap

• Keeping Priming Documents Current

• A Real-World Example

• Trade-offs and Limitations

• Conclusion

When I onboard a new developer, I don't just point them at the codebase
and say “go.” I walk them through our conventions. I show them examples of
code we consider good. I explain why we made certain architectural
choices—why we use Fastify instead of Express, why services are functional
instead of class-based, why validation happens at the route level. Only
after this context-setting do I expect them to contribute code that
fits.

AI coding assistants need the same onboarding.

Many developers experience what might be called a “Frustration Loop” with
AI assistants: generate code, find it doesn't fit the codebase, regenerate
with corrections, repeat until giving up or accepting heavily-modified
output. I have come to believe this friction stems not from AI capability,
but from a missing step—we ask AI to contribute without first sharing the
context it needs.

This article explores what I call Knowledge Priming—the practice of
sharing curated project context with AI before asking it to generate
code.

The core insight is simple: AI assistants are like highly capable but
entirely contextless collaborators. They can work faster than any human, but
they know nothing about a specific project's conventions, constraints, or
history. Without context, they default to generic patterns that may or may
not fit.

The Default Behavior Problem

Here is what typically happens when asking AI to generate code without
priming:

Request: “Create a UserService that handles authentication”

AI generates 200 lines of code using:

• Express.js (the project uses Fastify)

• A utils/auth.js helper (the convention is lib/services/)

• Class-based syntax (the codebase is functional)

• An outdated bcrypt API (the project uses the latest version)

The code works. It is syntactically correct. It might even pass basic
tests. But it is completely wrong for the codebase.

Why? Because AI defaults to its training data—a blend of millions of
repositories, tutorials, and Stack Overflow answers. It generates the
“average” solution from the internet, not the right solution for a specific
team.

This is exactly what would happen if I asked a new hire to write code on
Day 1 without any onboarding. They would draw on their prior experience—which
may or may not match our conventions.

The Knowledge Hierarchy

I find it helpful to think of AI knowledge in three layers, ordered by
priority:

• Training Data (lowest priority): Millions of repositories,

tutorials, generic patterns—often outdated. This is “the average of the
internet.”

• Conversation Context (medium priority): What has been discussed in

the current session, recent files the AI has seen. This fades over long
conversations.

• Priming Documents (highest priority): Explicit project

context—architecture decisions, naming conventions, specific versions and
patterns. When provided, these override the generic defaults.

The hierarchy matters. When priming documents are provided, the instruction
is essentially: “Ignore the generic internet patterns. Here is how this
project works.” And in my experience, AI does listen.

Technically, this is manual RAG (Retrieval-Augmented Generation)—filling
the context window with high-value project-specific tokens that override
lower-priority training data. Just as a new hire's prior habits are overridden
by explicit team conventions once explained, AI's training-data defaults yield
to explicit priming.

There is a mechanistic reason this works. Transformer models process context through
attention mechanisms that operate, in effect, as a finite budget—every token in the context
window competes for influence over the model's output. When the window is filled with generic
training-data patterns, the model draws on the average of everything it has seen. When it is filled
with specific, high-signal project context, those tokens attract more attention weight and steer
generation toward the patterns that matter. This is why curation matters more than volume: a
focused priming document does not just add context, it shifts the balance of what the model
pays attention to.

What Knowledge Priming Looks Like

Knowledge Priming is the practice of sharing curated documentation,
architectural patterns, and version information with AI before asking it to
generate code.

Think of it as the onboarding packet for a new hire:

• “Here is the tech stack and versions”

• “Here is how code is structured”

• “Here are the naming conventions”

• “Here are examples of good code in this codebase”

Before and After

Without priming, a request for a UserService might yield Express.js,
class-based code, wrong file paths, and outdated APIs—requiring 45 minutes of
fixing or a complete rewrite.

With priming, the same request might yield Fastify, functional patterns,
correct file paths, and current APIs—requiring only 5 minutes of review and
minor tweaks.

I cannot claim this is a validated finding, but the reasoning seems sound:
explicit context should override generic defaults. My own experiments have
been encouraging.

Anatomy of a Priming Document

A good priming document is not a brain dump. It is a curated, structured
guide that gives AI exactly what it needs—no more, no less.

I propose seven sections. Each mirrors what I would walk through when
onboarding a human colleague:

1. Architecture Overview

What I tell a new hire: “Let me explain the big picture first.”

The big picture. What kind of application is this? What are the major
components? How do they interact?

## Architecture Overview
This is a microservices-based e-commerce platform.
- API Gateway: Handles routing, auth, rate limiting
- User Service: Authentication, profiles, preferences
- Order Service: Cart, checkout, order history
- Notification Service: Email, SMS, push notifications

Services communicate via async message queues (RabbitMQ).
Each service owns its database (PostgreSQL).

2. Tech Stack and Versions

*What I tell a new hire: “Here's our stack—and watch out for
version-specific APIs.”*

Specificity matters. Version numbers matter—APIs change between
versions.

## Tech Stack
- **Runtime**: Node.js 20.x (LTS)
- **Framework**: Fastify 4.x (not Express)
- **Database**: PostgreSQL 15 with Prisma ORM 5.x
- **Testing**: Vitest + Testing Library (not Jest)
- **Validation**: Zod schemas (not Joi)

3. Curated Knowledge Sources

*What I tell a new hire: “Before you search the internet, here are the docs
and blogs that shaped how we think. Start here.”*

[...]

Original source