A fellow programmer in an AI forum recently posted a link to a new Anthropic article about working with its latest generation of Claude models.

The title was The New Rules of Context Engineering for Claude 5 Generation Models, so naturally it caught my attention.

I spend a lot of time thinking about context.

I've spent roughly two years programming with AI for 10 to 12 hours a day, seven days a week. PageSnip alone has been through well over 1,700 development iterations. I've worked with different models, different tools, long conversations, short conversations, fresh repository handoffs, detailed startup prompts, and more corrective rules than I could probably count.

I've developed some fairly strong opinions about what works.

Then Anthropic came along and said, in effect, that some of what worked before may now be getting in the way.

That got my attention too.

The part that bothered me in a good way

Anthropic said it had removed more than 80 percent of the Claude Code system prompt for its newer models without seeing a measurable loss in coding performance.

That's a pretty remarkable statement.

For a long time, the direction of travel seemed obvious. If the AI missed something, add another instruction. If it misunderstood the job, provide a better example. If it wandered outside the requested scope, add another guardrail.

Over time, a good AI development prompt became a carefully engineered stack:

• Here's the product.
• Here's the architecture.
• Here are the rules.
• Here's the repository layout.
• Here's what you must always do.
• Here's what you must never do.
• Here are examples.
• Here are the mistakes made by previous models.
• Here's the current assignment.
• Here's the exact way I expect you to report the results.

I still believe a carefully curated prompt is far better than starting a development session with:

Well, I want to do something with this part of the program today.

But I'm starting to question whether all that carefully curated material still belongs in one giant block.

That's not quite the same thing.

I've been carrying the entire workshop to every job

My normal project startup instructions have become fairly demanding.

I provide the repository. I tell the AI that it's the sole source of truth. I direct it to the starting document. I require it to read the project documentation in order. I tell it not to rely on memory from previous conversations.

Then I often ask it to inspect the source and show me enough evidence that I know it actually read it.

There are good reasons for every part of that.

I've seen agents make assumptions based on old conversations. I've seen them work from obsolete architecture. I've seen them ignore documentation, invent capabilities, modify the wrong area, or declare a repair complete without proving that the defect was fixed.

Those aren't imaginary risks.

But PageSnip is also a very large project now.

The documentation has grown. The architecture has grown. The changelog has grown. The source has grown. Some of the larger implementation files contain tens of thousands of lines.

When I tell the AI to read everything before it starts, I'm using a significant portion of the useful context before we've done any work at all.

Then the AI has to inspect the code, make changes, run tests, diagnose failures, explain the results, and prepare the next build.

Context may be large, but it still isn't free.

The useful life of a thread has become shorter

I've changed the way I manage development conversations.

At one time, I might have allowed a thread to continue through ten iterations before considering a fresh start.

I don't do that much anymore.

If the work has been straightforward, I may break into a new thread after four or five iterations. If we've gone deeply into architecture, diagnostics, or a difficult regression, I may start a new one after only one or two.

I've also gotten in the habit of asking the AI:

How are we doing on this thread?

What I really mean is:

• How much useful context remains?
• Is the conversation still helping?
• Is old exploration beginning to compete with the current work?
• Do we have enough room to start something substantial?
• Would a clean handoff give us a better result?

That's become part of my normal workflow.

Most programmers don't think about an AI conversation that way yet. They treat it as though it were an unlimited room where every discussion, source listing, failed attempt, test result, and correction can remain on the table forever.

It can't.

At some point, the accumulated history stops being useful context and starts becoming clutter.

"Read the whole file" can still be the right instruction

This new thinking doesn't mean I'm suddenly going to let the AI search for one keyword, read twenty lines, and start modifying PageSnip.

That would be foolish.

Some of the PageSnip source files are far larger than they should be. They need to be broken down, and I'll deal with that after release when the risk is lower.

But they exist as they are today.

If I know that a behavior is spread throughout a 10,000-line file, the AI may need to read that entire file. A keyword search could find the function where the visible action begins while missing state management, cleanup, recovery, persistence, and related behavior elsewhere.

Targeted retrieval can create false confidence.

It can make the AI believe it has understood the system when all it has understood is the piece that matched the search phrase.

So there's a boundary here.

The file should never have become that large.

But since it did, and since reorganizing it during release stabilization could break the product, reading it fully may be the safest choice.

The answer isn't always "load less."

The answer is to load what the risk of the task actually requires.

The changelog is telling me something too

PageSnip has a long changelog.

That has been valuable. We can look back and understand when a feature was introduced, what a build attempted, which runtime tests passed, and which approaches failed.

But after more than 1,500 iterations, a single changelog is no longer the most useful way to present all that information to an AI.

The history probably needs structure.

There should be a map that separates:

• Current architecture.
• Accepted product behavior.
• Superseded experiments.
• Important historical failures.
• Release checkpoints.
• Current unresolved work.
• Specialist procedures that only apply to certain tasks.

The AI shouldn't have to read every historical event to understand the current product.

But it does need a reliable way to find the part of history that explains why an odd-looking rule or workaround still exists.

That's a very different problem from simply deciding whether prompts should be long or short.

It's a problem of context architecture.

Experience doesn't give me an exemption

I've been a programmer for roughly 40 years.

I know how software works. I know how projects go wrong. I know what it takes to design, test, and release a real product.

I also have far more hands-on AI programming experience than most developers. I haven't just experimented with it on weekends. I've worked with it intensively, day after day, across large, real applications.

It would be easy for me to say:

I've got this figured out.

But that would be exactly the wrong lesson.

My experience tells me what has worked.

It doesn't guarantee that the same method is still optimal for the model I'm using today.

Anthropic's announcement is a good example. OpenAI's newer models and guidance have been moving in a similar direction. The models can often infer more of the intended job, exercise better judgment, and work more effectively without having every intermediate step prescribed.

That doesn't mean I should throw away all my rules tomorrow.

It means I need to know why each rule exists, whether the current model still needs it, and whether there's now a better way to enforce the underlying principle.

The experience is valuable.

The certainty is dangerous.

Watch the tide

That's why I keep coming back to the tide as a metaphor.

The water comes in and the water goes out.

It exposes things that were hidden. It covers routes that were previously usable. It changes where you can safely stand, even though the coastline itself hasn't moved.

The principles of good software development haven't disappeared.

Protect the data. Understand the system. Preserve the architecture. Test the result. Don't confuse confidence with proof.

Those are still the coastline.

But the best path across it keeps changing.

A failed experiment from three weeks ago may be worth trying again.

A successful prompt from six months ago may be worth taking apart.

A rule that once prevented a real failure may now be consuming context and narrowing the model's judgment.

A giant startup prompt may need to become a small mission directive backed by a structured context package.

The people working successfully with AI won't be the ones who found one perfect method and held onto it.

They'll be the ones who keep watching the tide.

Related guide

For a broader look at how to re-evaluate old AI failures, established best practices, prompt structure, and accumulated context debt, read Roll with the Flow.