Over the last few years, Prompt Engineering has become one of the hottest topics in the LLM world.
People share prompts, prompt templates, and even prompt libraries. They definitely helped us get better results from LLMs.
But I have been thinking about something different.
What if prompts are not the thing we should invest in?
As foundation models become smarter, prompts become simpler. Many prompts we carefully wrote a year ago are no longer necessary. Better models understand us with much less effort.
What does not become obsolete that quickly is context.
Not conversation history.
Not agent memory.
I mean knowledge that people intentionally build, review, improve, and reuse.
I believe this is becoming one of the most valuable assets in the LLM era.
This is why I started thinking about Context Repositories.
Prompts are disposable. Context is an asset.
When I write a prompt today, there is a good chance I will rewrite it next month.
Sometimes, an even newer model makes the whole prompt unnecessary.
That doesn’t mean Prompt Engineering is useless.
It means prompts are tightly coupled to the capabilities of today’s models.
Context is different.
For example,
- coding conventions
- architecture decisions
- testing strategies
- domain knowledge
- API constraints
- security guidelines
These things do not disappear because GPT-6 or GPT-7 becomes smarter.
Actually, better models can make better use of them.
That’s why I started thinking that context should be treated as an asset rather than just an input.
We already have knowledge. We just don’t manage it for LLMs.
Most software teams already have a lot of knowledge.
It lives in Git repositories.
It lives in design documents.
It lives in Confluence.
It lives in ADRs.
It lives in people’s heads.
The problem is not the lack of knowledge.
The problem is that this knowledge is rarely organized in a way that LLMs can consume effectively.
Sometimes, important information is buried inside a huge document.
Sometimes, it exists only in a Slack conversation.
Sometimes, nobody knows which document is still correct.
The challenge is not generating more context.
The challenge is managing context.
Context should be reviewed like code
One thing I noticed while building software is that knowledge changes.
Requirements change.
Architectures evolve.
Best practices improve.
If context is important, it should evolve in the same way.
That means context should have:
- version control
- reviews
- ownership
- references
- dependencies
In other words, context should become part of software engineering.
Not just something copied into a prompt.
Context Repository
This is the idea I call a Context Repository.
A Context Repository is not a prompt library.
It is not a vector database.
It is not an agent memory.
Instead, it is a repository of reusable context assets maintained by humans.
These assets can then be used by many different LLMs, tools, and agents.
As models improve, these assets become even more useful instead of becoming obsolete.
That is a very different lifecycle from prompts.
This is bigger than one tool
The idea of a Context Repository is much more important than any implementation.
Today I’m exploring this idea through an open-source project called Renma.
Maybe in a few years there will be many implementations.
Maybe my implementation will not be the best one.
I’m completely fine with that.
What I really hope is that we start treating context as something worth engineering, reviewing, and improving over time.
Models will continue to evolve. Good context should evolve with them.
~ my tech diary ~ 