The Problem Is Not Prompting. It Is Context Decay.

The first AI coding problem looks like prompting.

How do I ask better questions? How do I give clearer instructions? How do I make the model produce the shape of answer I want?

That matters.

But after enough sessions, a different problem becomes more important: useful context keeps dying.

An agent helps me reason through a design. It explains a trade-off. It discovers a constraint. It rejects an approach. It learns how a part of the codebase works.

Then the session ends.

The code diff remains. The reasoning mostly disappears.

Next time, I explain the same things again.

Prompting helps the next answer

A good prompt can improve the next response.

It can frame the task, define the output, add constraints, and steer the model away from obvious mistakes.

But serious software work does not happen in one response.

It spans days. It crosses files. It changes assumptions. It produces decisions that should matter later.

A prompt is too temporary for that job.

The question becomes less "how do I prompt this agent?" and more "where does the project remember what we already learned?"

Context decay is expensive

Context decay shows up in small ways at first.

You restate the same architecture rule.

You remind the agent again that routes should not contain domain logic.

You explain again how request context works.

You repeat the same testing convention.

You reject the same wrong implementation pattern.

Each repetition looks minor. Across dozens of sessions, it becomes a tax on the whole workflow.

Worse, the agent may not just forget. It may infer the wrong pattern from whatever code is closest.

If the durable context is missing, local context wins.

Repository-local knowledge changes the shape of the workflow

The best improvement is not always a better prompt.

Sometimes it is moving knowledge into the repository.

An AGENTS.md file can explain how work should be approached.

Architecture notes can define boundaries.

Conventions can describe naming, testing, error handling, and folder structure.

Decision logs can preserve why a path was chosen.

Specs can turn intent into something reviewable before implementation.

Tests can become executable examples of expected behavior.

This kind of context does not depend on one chat window. It becomes part of the project.

Context engineering is information architecture

I now think of context engineering less as prompt craft and more as information architecture.

What should be in the current prompt?

What should live in the repository?

What should be retrieved only when relevant?

What should be encoded as tests rather than prose?

What should become a convention because I have repeated it too many times?

The goal is not to stuff everything into the context window. The goal is to make the right knowledge available at the right distance from the work.

Some knowledge belongs in the immediate task.

Some belongs in local project files.

Some belongs in long-term decisions.

Some belongs in code structure itself.

The AI builder's memory problem

When building with AI, memory is not only a model feature.

It is a project design problem.

If the project does not remember its own rules, every agent session becomes a negotiation.

Should this logic live in the route or the application layer?

Should this tenant value be trusted?

Should this component fetch data client-side?

Should this mutation own the transaction?

The more often those questions are answered in temporary chat, the more fragile the workflow becomes.

The principle

Prompting helps the next answer.

Durable context helps the next month of work.

That is the shift that matters: from better prompts to better project memory.

An AI-assisted codebase should not depend on me re-explaining the same judgment every time. The judgment has to move into places the next agent, and the next version of me, can actually find.