A few weeks ago, I wrote about the importance of trying failed AI experiments again.
The point was simple: if you asked an AI to do something several weeks or several months ago and it couldn't do it, that doesn't necessarily tell you anything about what it can do today. The models are changing too quickly. Something that failed before may now work perfectly well.
That's one half of the equation.
The other half may be even more important:
Something that worked well six months ago may no longer be the best way to work today.
We tend to think about progress in terms of new capabilities. The AI can write better code. It can reason through a larger problem. It can use tools more effectively. It can stay on task longer. It can understand a repository better.
But improved capabilities don't just make new things possible. They can also make some of our old working methods unnecessary and occasionally harmful.
That means we need to retest two different things:
- The things the AI couldn't do.
- The things we learned to do because the AI couldn't do them well.
Most people are beginning to understand the first one.
We're only starting to come to terms with the second.
The ground rules keep changing
Anthropic recently published an article called The New Rules of Context Engineering for Claude 5 Generation Models.
One of the more striking claims in the article is that Anthropic 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 worth stopping and thinking about.
For years, the common advice for getting better AI results has been to provide more structure:
- Give the AI detailed rules.
- Explain every important limitation.
- Show it examples of the output you want.
- Tell it which tools to use.
- Explain the steps it should follow.
- Repeat critical instructions so they won't be missed.
- Load all the background material before the work begins.
That advice didn't come from nowhere. It worked.
Older models needed more guidance. They were more likely to lose track of the objective, overlook an important instruction, use the wrong tool, or head down an obviously unproductive path. Detailed prompts and strong guardrails helped compensate for those weaknesses.
But a workaround can outlive the problem that created it.
A newer model may understand the objective without being told every step. It may use better judgment about which information matters. It may explore more effectively when it isn't being forced to imitate one old example.
The instructions that once kept the AI on the road may eventually become the traffic jam.
Best practices have expiration dates
Programmers aren't naturally trained to think this way.
Programming languages change. Frameworks change. Tools change. But much of the underlying craft changes relatively slowly.
Once you've learned how to break down a problem, design a reliable system, protect data, test failure paths, and build maintainable software, those skills remain useful for decades. An experienced programmer can move from one language to another because the syntax changes more quickly than the principles.
That creates a perfectly reasonable expectation:
Once I've learned the right way to do this, I can keep using it.
That expectation becomes dangerous when we're working with AI.
When you program with AI, one of the members of your development team can change substantially between one project and the next.
You may be the same programmer.
The language may be the same.
The repository may be the same.
The feature request may even be the same.
But the AI helping you do the work may now reason differently, follow instructions differently, use tools differently, and need a different kind of context.
The best way to work with the model you used six months ago may not be the best way to work with the model in front of you today.
Your experience still matters. But it can't become a fixed collection of procedures that you never question again.
Experience is becoming judgment
I often describe working with AI as having a junior programmer who knows the entire internet and can type 3,000 words a minute.
I still think that's a useful description.
The AI may know more syntax than you do. It may know APIs you've never used. It can produce routine code much faster than any human programmer. It can inspect a failure and often point directly to the mistake.
But it doesn't know your product the way you do.
It doesn't automatically know:
- Which behavior customers depend on.
- Which architecture decisions are deliberate.
- Which risks you're willing to accept.
- Which shortcuts would undermine the product.
- Which files are authoritative.
- Which old experiments have no standing.
- What "finished" really means in your environment.
That's where the programmer's experience becomes most valuable.
The value is moving away from controlling every keystroke and toward defining intent, boundaries, authority, risk, and proof.
The programmer's job isn't disappearing. It's moving upward.
Yesterday's best practice can become today's context debt
Every rule we add to an AI workflow has a history.
Perhaps the AI once modified files outside the requested area, so we added a rule telling it to make surgical changes only.
Perhaps it declared victory without testing the failure path, so we added a detailed verification checklist.
Perhaps it kept ignoring an architecture document, so we started requiring it to read every project document from beginning to end.
Perhaps it misunderstood a tool, so we supplied three examples showing exactly how to use it.
Those corrections may have been entirely justified.
But over time, they accumulate.
A project prompt that began with a few hundred words becomes several thousand. The startup instructions repeat rules already contained in repository documents. The same warning appears in the prompt, the project guide, the testing plan, and the delivery checklist.
Soon the AI is spending a significant part of its working context sorting through instructions about how it's supposed to work before it ever reaches the work itself.
That accumulated material is context debt.
Like technical debt, context debt isn't necessarily the result of bad decisions. It's often the residue of sensible decisions made under earlier conditions.
The question isn't whether the rule once helped.
The question is whether it still earns its place.
Context has more than one cost
People often think about context in terms of money.
How many tokens will this consume? How much will the call cost?
That matters, but it isn't the most important issue.
Every piece of context has at least three costs.
Capacity
It uses room that could have been available later for source code, test results, tool output, corrections, and deeper reasoning.
Attention
The AI has to decide whether the information is relevant and how it relates to everything else it has been given.
Conflict
The instruction may overlap with or contradict another instruction.
Imagine telling the AI:
- Work independently.
- Ask before making significant decisions.
- Don't create planning documents.
- Document important decisions.
- Keep changes narrowly scoped.
- Fix the underlying architectural problem.
A human can see how those rules might fit together, but the boundaries aren't automatic. The AI has to decide which instruction dominates in each situation.
More instructions don't always create more control.
Sometimes they just create more arbitration.
Don't replace one rigid rule with another
It would be easy to read the new guidance from Anthropic and come away with a new slogan:
Long prompts are bad.
That would be just as misguided as saying long prompts are always better.
Detailed context still matters when it communicates something the AI can't discover for itself.
A long instruction may be worthwhile when it explains:
- A product boundary that must not move.
- A dangerous historical failure.
- A platform limitation.
- A security requirement.
- A release policy.
- A customer-facing compatibility promise.
- A test that must pass before the work can be accepted.
The question isn't how long the prompt is.
The question is whether the information is relevant, authoritative, and useful at this stage of the work.
The same is true of examples.
Examples can show the AI what good output looks like. They can communicate taste, format, or an unusual domain convention better than a page of explanation.
But examples can also trap the AI into repeating one old approach instead of finding a better one.
Use examples to show what good looks like.
Be more cautious about using them to prescribe every step used to get there.
Sometimes the AI really does need to read everything
Progressive disclosure makes sense.
Instead of forcing the AI to preload every project document, we can give it a clear starting point and a good map of where specialized information lives.
But that doesn't mean targeted retrieval is always sufficient.
Consider a source file that has grown to 10,000 or 20,000 lines.
That file should probably never have become that large. It needs to be broken into meaningful modules.
But perhaps the product is nearing release, and reorganizing a large, fragile file would create more risk than it removes. The file exists, and the current task has to deal with it.
Searching for one function name and reading 200 lines around it may not be enough.
Important state could be established thousands of lines earlier. Cleanup logic could be somewhere else. Another code path might change the same data. An old workaround may look unnecessary until you discover the failure it prevents.
In that situation, telling the AI to read the complete file may be exactly right.
The lesson isn't to read everything.
The lesson isn't to read only what search retrieves.
The lesson is to make a technical judgment based on the risk and structure of the work.
Context needs architecture too
We understand that a giant source file is difficult to maintain.
The same thing is true of a giant project prompt.
A monolithic instruction file becomes difficult to:
- Navigate.
- Update.
- Reuse.
- Review.
- Keep internally consistent.
- Load selectively.
- Distinguish current rules from history.
The answer isn't to chop it into thirty random Markdown files.
The answer is context architecture.
A well-designed project context might include:
- A short starting document.
- A map explaining where different kinds of knowledge live.
- Stable architecture and product-boundary documents.
- Separate platform and coding rules.
- Specialized testing and delivery procedures.
- Historical material kept out of the normal working path.
- A current task document identifying what applies now.
The active prompt then becomes the front door.
It explains what we're doing today, which sources are authoritative, which supporting documents apply, and how we'll know the work is complete.
That's still prompt engineering.
It's simply happening at a higher level.
Retest your failures and your successes
A useful periodic audit doesn't need to be complicated.
Look at the way you currently work with AI and ask:
- Why did I add this instruction?
- Does the current model still need it?
- Is the same rule repeated elsewhere?
- Is this information needed for every task?
- Could a test enforce this more reliably than prose?
- Is this example showing quality, or forcing a method?
- Is this document current authority or merely history?
- Am I loading this because it matters now, or because it has always been in the prompt?
- Have I tested the workflow with the latest model?
- Have I compared the results without some of the older scaffolding?
Don't remove a rule merely because someone says the latest model is smarter.
Remove it when testing shows that the rule no longer prevents a real failure or when you've replaced it with something stronger.
A failing test is better than a paragraph saying "be careful."
A schema is better than three examples of valid output.
A tool that refuses an unsafe operation is better than repeatedly warning the AI not to perform it.
Rolling with the flow doesn't mean drifting
The phrase "roll with the flow" can sound passive.
That isn't what I mean.
Working well with AI requires more active judgment, not less.
You need stable principles:
- Protect the user's data.
- Preserve product intent.
- Understand before changing.
- Keep authority clear.
- Verify results.
- Test the failure path.
- Prefer evidence over confidence.
Those principles don't expire every six months.
The procedures used to uphold them might.
That's the difference between changing direction every time a new blog post appears and deliberately recalibrating your workflow when the evidence says the ground rules have changed.
The people who become good at working with AI won't be the ones who memorize one perfect prompting formula.
They'll be the ones who know how to recognize when the formula has stopped working.
Retry the things that failed, because the AI may have caught up with your idea.
Re-examine the things that succeeded, because the AI may have outgrown the workaround.
Then roll with the flow.
Related field note
For a personal look at how this is changing the way I manage PageSnip, PromptStacker, project documentation, and even the useful life of an AI conversation, read Watch the Tide.