Keeping the AI on Track
A single well-structured prompt is a solved problem by this point in the course. A project built over days or weeks, across dozens of prompting sessions, with a growing codebase and evolving requirements — that is a different challenge. The AI has no persistent memory of previous sessions. It does not know what decisions were made last Tuesday. It does not know that the naming convention it just violated was established three weeks ago. Keeping the AI on track across a long build is entirely the developer's responsibility — and it requires deliberate systems, not just careful writing.
Why AI Assistants Drift
AI drift is the phenomenon where a model's outputs gradually diverge from the established patterns and decisions of a project as the project grows. Drift has two causes: 1. Context loss: each prompt is, from the AI's perspective, a fresh interaction. Without explicit context, the AI defaults to its general training — which may not match the specific conventions of your project. It may use a different variable naming style, a different error-handling pattern, or a different database access method than the one you established. 2. Scope expansion: AI models are trained to be helpful, which creates a tendency to do more than asked. Asked to add one field to a form, the model may also reorganize the form, add default values you did not request, and rename variables for clarity. Each of these unsolicited changes is a potential regression and a drift from established patterns. Neither cause is a flaw in the model — both are predictable consequences of how large language models work. The developer who understands these causes can design their workflow to counteract them.
AI drift does not happen randomly — it happens when context is thin and scope is unconstrained. A dense anchor (project brief excerpt) and a precisely bounded scope instruction ('modify only this function; change nothing else') together dramatically reduce drift. The developer who treats each prompt as a bounded contract with the AI prevents the accumulated divergence that makes long projects incoherent.
Four tools for keeping the AI on track: 1. The living project brief: introduced in Lesson 2, the project brief is the primary defense against context loss. Before each session, re-read the brief and update it with decisions made in the previous session. At the start of each prompt, include the relevant sections. The brief is not overhead — it is the mechanism by which the project's identity persists across sessions. 2. Explicit constraint instructions: every prompt that modifies existing code should include an explicit constraint: 'do not rename any existing variables,' 'do not change any function that is not listed in the scope of this prompt,' 'follow the same error-handling pattern as the existing routes above.' Constraints are not distrust of the AI — they are precision in communication. 3. Correction prompts: when the AI drifts, correct it immediately and completely. A correction prompt names the specific drift, explains why it is incorrect, and restates the correct pattern. 'You used snake_case for the new variable names. This project uses camelCase throughout — see the examples above. Please revise only the variable names to use camelCase, changing nothing else.' Accepting drift and moving on is how projects become incoherent. 4. Session summaries: at the end of each working session, write a two-to-four sentence summary of what was accomplished, what decisions were made, and what the next step is. This becomes the opening context for the next session — replacing your need to reconstruct what happened from memory.
Prompt Challenge
Write a correction prompt for the following situation: you asked the AI to add a 'tags' field to the expense record returned by the GET /expenses route. The AI added the tags field correctly but also renamed three existing fields — 'categoryName' to 'category', 'dateString' to 'date', and 'noteText' to 'note' — claiming this was cleaner. Your front-end depends on the original field names.
Your prompt should…
- Name the specific changes the AI made that were not requested
- Explain the concrete consequence of those changes for the existing system
- Instruct the AI to revert only the unrequested changes while keeping the requested one
Recognizing When to Stop and Replan
Some projects reach a state where keeping the AI on track becomes more work than replanning. Symptoms: - The same type of correction is needed in every session, because an early architectural decision is incompatible with the current direction. - Each new feature requires touching an increasing number of files, because dependencies are tangled. - The AI's outputs are consistently partially correct, requiring significant manual revision, because the project brief does not capture the real complexity. When these symptoms appear, the correct response is a structured pause: stop adding features, document the current state precisely, and design a refactoring plan (returning to Lesson 7) or an architectural revision before continuing. Attempting to push through this state by writing more careful prompts is usually less efficient than fixing the underlying structural problem. Recognizing this inflection point is a skill that comes with experience. A useful heuristic: if you spend more time correcting and re-prompting than you spend reviewing and accepting, the project has reached a state where structural work takes priority over feature work.
The feeling of rapid progress — prompt after prompt, feature after feature — can mask structural degradation. A project that grows fast but accumulates uncorrected drift, unreviewed changes, and tangled dependencies is not progressing; it is building technical debt that will eventually require expensive correction. Regular pauses to review the overall state of the project — not just the most recent feature — are part of disciplined development.
A developer notices that the AI's last three outputs all used a different error-handling pattern than the one established in the project brief. What is the most effective response?
What does a session summary accomplish at the end of a working session?
Drift Detection and Correction Drill
- Below are two versions of the same function — the 'before' version (from commit G in the project history) and the 'after' version generated by the AI when asked only to add input logging.
- Before:
- async function createExpense(req, res, next) {
- const { amount, category, date, note } = req.body;
- if (!amount || amount <= 0) return next(new Error('Invalid amount'));
- if (!VALID_CATEGORIES.includes(category)) return next(new Error('Invalid category'));
- const record = await db.insert('expenses', { amount, category, date, note });
- return res.json({ status: 'ok', data: record });
- }
- After (AI output):
- async function createExpense(request, response, next) {
- console.log('createExpense called with:', request.body);
- const { amount, category, date, note } = request.body;
- if (typeof amount !== 'number' || amount <= 0) return next(new Error('Amount must be a positive number'));
- if (!VALID_CATEGORIES.includes(category)) return next(new Error('Invalid category'));
- try {
- const record = await db.insert('expenses', { amount, category, date, note: note || '' });
- return response.json({ status: 'ok', data: record });
- } catch (err) {
- return next(err);
- }
- }
- Tasks:
- 1. List every change the AI made beyond adding console.log input logging.
- 2. For each unrequested change, classify it: potentially beneficial drift, harmful drift, or neutral drift.
- 3. Write a correction prompt that specifies exactly what to keep (the logging), what to revert, and why each reversion is necessary.