The Engineering of Intent, Chapter 3: Context Momentum and Path Dependence

This is Part 3 of a series walking through my book The Engineering of Intent. In the previous chapter, we looked at material disengagement — the silent failure mode where the engineer stops meaningfully engaging with what the agent is authoring. This chapter shifts focus from the human to the codebase: why early decisions cast such long shadows, and how to keep a project steerable as it grows.

Momentum Is a Force. Agents Amplify It.

Every project picks up momentum as it grows. The directions it can still go in narrow. This has always been true, but AI agents amplify it — they read your existing code and produce code that is stylistically and structurally similar. Good patterns propagate. Bad patterns propagate with equal fidelity.

Chapter 3 is about the physics of that momentum — how to set it up correctly on day one, how to measure it when it’s slipping, and how to reverse it without a rewrite.

The First Prompt Trap

The first substantive prompt on a new project is disproportionately important. Whatever the agent produces first becomes the stylistic anchor for everything that follows. Vague first prompt? You get vague code, and every subsequent prompt inherits the vagueness. Precise first prompt — stack, style, domain vocabulary, error-handling philosophy — and the precision compounds for months.

Most engineers do not recognize the weight of this. They type “set up a REST API for managing users” and accept whatever comes back. Whatever comes back determines the next three months.

Entropy and Context Rot

Even in well-run projects, context rots. Decisions made in week one become invisible by week eight. New contributors join who did not see the original prompt. The agent’s working model of the project drifts as conversations accumulate. Entropy, as physicists like to say, wins.

The defense is the same one good engineering teams have always used — documentation that lives in the repository, versioned alongside the code, read automatically by the tools. The difference now is that the documentation is not just for humans. It’s for the agent. That’s what makes an AGENTS.md qualitatively different from a README. The README is a pitch. The AGENTS.md is a binding reference that the agent is expected to honor on every turn.

“The worst possible context file is one that was accurate in month one and has since silently drifted. The agent will still read it. The agent will still honor it. And the agent will produce code consistent with a version of the project that no longer exists.”

Measuring Drift

The chapter introduces three quantitative measures of project drift. None are canonical yet, but all three are useful enough that you should start watching them this week:

1. Idiom variance. The standard deviation, across files, of surface stylistic features — indentation, naming convention, error-handling pattern. Healthy projects have low idiom variance. Drifting projects have rising idiom variance.
2. Test-to-behavior coupling. The ratio of behavior-changing diffs to test-changing diffs. A ratio near 1 means every behavior change is accompanied by a test change. Significantly above 1 means behavior is outrunning tests — a leading indicator of future incidents.
3. Unnecessary novelty. The rate at which the agent introduces new dependencies, patterns, or abstractions without a corresponding external forcing function. Some novelty is necessary. The agent, left unsupervised, will happily reinvent things that already exist in the codebase. The engineer must supply the cost.

Conventions Are a Force Field. They Cost Energy to Maintain.

Every convention a project adopts is pulling against entropy. The code wants to diverge. New engineers want to introduce their favorite patterns. The agent, drawing on a vast training corpus, wants to produce whatever is statistically dominant in the broader world — which is rarely identical to your house style.

Understanding this physics changes how you invest. My rule of thumb, which the chapter defends in detail:

• The top five conventions in your codebase should be actively enforced — checked by a linter, rejected in CI, reported in review.
• The next fifteen should be passively documented in the conventions file.
• Beyond that, you’re in territory where the convention is too specific to the moment and should be discussed per change, not codified.

Projects that try to actively enforce fifty conventions either never ship or spend so much on tooling that the business suffers. Projects that actively enforce none drift into chaos within a year.

One of the chapter’s case studies walks through a platform team at a series-C startup who reversed two years of drift in six months by inserting a single conventions document into every agent session company-wide and adding a small Semgrep ruleset for the top five violations. New-commit compliance jumped from an estimated 30% to 94%. Total cost: about 5% of engineering capacity. The alternative — the “big fix” plan the CTO originally wanted — would have cost 40% of capacity for two quarters and produced a worse result.

Write Conventions for Agents, Not Humans

Most conventions documents I encounter were written for humans. They say things like “prefer readability” and “avoid unnecessary complexity.” These are meaningless to an agent — and honestly only slightly more meaningful to humans.

Conventions for agents should be operational and specific. Not “prefer readability” but “functions longer than forty lines must be refactored.” Not “avoid unnecessary complexity” but “do not introduce a new abstraction unless it is used in at least three places.” Not “handle errors properly” but “wrap external calls in a Result type; never throw from internal utility functions.”

If you cannot make a convention mechanical, consider whether it belongs in the document at all. Conventions that depend on taste should be trained into humans, not documented.

Not All Decisions Deserve the Same Decision Process

Some early decisions are cheap to reverse. Variable naming, file layout, test framework — the agent can migrate these in an afternoon. Others are expensive. Data model shape, authentication model, deployment topology, transactional-vs-eventually-consistent — once made, these shape every subsequent decision. Reversing them is a months-long undertaking.

The instinct under AI-native velocity is to make all decisions at the same fast cadence. This is a mistake. The AI accelerates the cheap decisions. It does not automatically accelerate the expensive ones.

I keep a personal heuristic the chapter lays out in full — the ten-thousand-dollar rule. If reversing this decision two years from now would cost more than $10K of engineering time, I pause before making it. If it would cost more than $100K, I pause, consult two colleagues, and sleep on it. The numbers are arbitrary; the principle is not. Not every decision deserves the same decision process.

Next up — Chapter 4: The Model Context Protocol (MCP). With the human’s side of the triad (engagement) and the codebase’s side (conventions) in place, Chapter 4 opens Part II of the book by turning to the agent’s side of the triad: the infrastructure that connects agents to real-world systems. MCP is the standard that made agentic development a serious discipline instead of a demo trick.