Prompting Across a Codebase

When you prompt an AI to write a single function, the context fits in a paragraph: what the function takes, what it returns, what it should do. When your project has grown to twenty files with interdependencies, the same task may require the AI to understand a database schema, an API contract, a utility library, and a set of conventions you established three sessions ago. Getting useful output from an AI at this scale is not harder in kind — it is harder in organization. The developer who masters multi-file prompting is not smarter; they are more deliberate about context.

What the AI Actually Sees

A large language model, for purposes of code generation, does not have a live view of your project. It has only what you put in the prompt — the text you send, plus whatever your tool of choice automatically includes (open files, selected snippets, pasted context). This is called the context window: the finite text the model can reason about at one time. Context window (definition): the total amount of text — measured in tokens, where a token is roughly four characters of English — that a model can process in a single interaction. Modern models range from tens of thousands to over a million tokens, but the practical limit for reliable reasoning is usually much less than the technical maximum. Implication: if your project has ten thousand lines of code and you paste them all into a prompt, the model may technically receive them all, but its attention and reasoning quality degrade as the context grows. Selective, precise context usually outperforms dumping everything. What you include matters more than how much you include. A carefully chosen excerpt of the database schema plus the interface definition for the module you are working on gives the AI what it needs. Twenty files of unrelated code create noise that degrades the output.

A practical framework for multi-file prompting has four elements: 1. Anchor: Begin with a one-paragraph summary of the project — its purpose, its major components, and the conventions already in place (naming style, error-handling approach, data formats). This anchor prevents the AI from making assumptions that contradict decisions already embedded in your codebase. 2. Scope: Identify precisely which part of the project you are working on in this loop. 'I am adding a new API endpoint to the back-end' is scope. 'I need the endpoint to accept a POST request to /expenses, validate that the amount field is a positive number and the category field is one of the five allowed strings, write the record to the database using the existing db.insert helper, and return the new record as JSON' is precise scope. 3. Relevant excerpts: Include only the code the AI needs to match. If you are adding a route, include the existing route file so the AI can match the pattern. Include the schema definition so it knows the field names. Include the db.insert helper signature so it uses it correctly. Do not include the front-end code or unrelated utilities. 4. Expected output: Specify the format of what you want back. 'Return only the new route handler function, with the same style as the existing routes above.' This prevents the AI from rewriting your entire file or adding unrequested features. Example anchor for the expense tracker introduced in Lesson 1: 'This is a Node.js/Express back-end for a personal expense tracker. The database is PostgreSQL accessed via a helper module that exports db.insert(table, record), db.query(table, filters), and db.delete(table, id). All routes use async/await, return JSON, and call next(err) on failure. The database has one table: expenses, with columns id (uuid), amount (numeric), category (text), date (date), note (text, nullable).'

Maintaining Consistency Across Sessions

A codebase accumulates conventions over time: how errors are named, how database calls are structured, how functions are documented. These conventions exist not in any single file but as patterns spread across many files. When you return to a project after a break — or when you work on a part of the project that was generated in a different session — you must re-establish those conventions for the AI. The most reliable approach is a project brief: a short document (one to two pages) that records the architecture, the data models, the naming conventions, and any non-obvious decisions. Before each prompting session, you paste the relevant sections of the brief into your anchor. This document becomes your single source of truth and prevents the AI from 'forgetting' decisions you made three sessions ago. A second practice is modular prompting: instead of asking the AI to work on 'the project,' always identify the specific module, file, or function you are addressing. This keeps each loop small, reviewable, and consistent. It also makes it easier to spot when the AI has generated something that contradicts an established pattern.