What I learned while building a project-intelligence layer for AI-assisted development.
There is something strange happening with AI-assisted development.
AI is getting very good at writing code.
It can inspect a repository, understand functions, generate tests, refactor files, and even make fairly complex changes.
But there is another part of software development that doesn't live neatly inside the codebase:
Why was this decision made?
Why did we choose this architecture?
Why is this workaround still here?
Why can't this seemingly simple function be changed?
What did we already try?
What constraint were we working around?
What did the user actually ask for?
And perhaps most importantly:
What did we learn the last time we touched this part of the system?
That information is often scattered across Git history, issues, documentation, Slack, PR discussions, and AI conversations.
The code survives.
The reasoning often doesn't.
The problem isn't just memory
At first, I thought this was mainly an AI memory problem.
Give the AI more context.
Store more conversations.
Index more files.
Retrieve better chunks.
But the more I worked on it, the more I realized that remembering information isn't the same as understanding the state of a project.
Consider a simple example.
You have a function that looks unnecessarily complicated.
An AI agent sees it and says:
"This can be simplified."
Technically, it might be right.
But perhaps three weeks ago someone already tried simplifying it.
It broke an edge case.
The workaround was intentionally introduced.
That decision may exist nowhere in the function itself.
It exists in the history and reasoning around the function.
Without that context, an agent can make a technically reasonable change that is completely wrong for the project.
Code is only one layer of a project
I've started thinking about a project as having several layers.
Code tells you what the system does.
Documentation tells you what people wrote down.
Git history tells you what changed.
But there is another layer:
Project intelligence — the decisions, assumptions, constraints, goals, feedback, and reasoning that explain why the system is the way it is.
That's the layer I became interested in.
Because when an engineer returns to a project after a few days, the expensive part isn't always reading the code.
It's reconstructing the mental model.
What was I doing?
Why did I choose this approach?
What did I already discover?
What shouldn't I touch?
What is still unresolved?
That reconstruction can take longer than the actual coding.
Then we started building Xeyria
This is the problem that led us to build Xeyria.
The idea is simple:
Instead of treating a codebase as the entire project, treat the project's accumulated knowledge as part of the system too.
Xeyria is being built around that idea.
It connects the pieces of project knowledge that normally become fragmented and helps preserve the context behind development work.
Not just:
"Here is the code."
But also:
"Here is what we learned."
"Here is why this decision exists."
"Here is what was tried."
"Here is what still matters."
The goal isn't to make developers remember more.
The goal is to make them reconstruct less.
We didn't want to validate this with a survey
This part was important to us.
We could have asked developers:
"Would you use a tool that remembers project context?"
Almost everyone would probably say yes.
That wouldn't tell us much.
Instead, we gave Xeyria to actual founders and watched what happened when they used it over multiple days.
One used it continuously for four days.
Another continued using it for seven days.
Their feedback changed several parts of the product.
More importantly, it gave us something a survey couldn't:
evidence that the problem becomes noticeable during real work, not just when someone is asked about it.
That gave us enough confidence to make the next decision.
We're preparing Xeyria for launch.
But there's a problem with AI "memory"
There's another lesson I've learned while working on this.
Simply storing more information doesn't automatically make an AI system better.
You can retrieve a perfectly relevant piece of information and still reach the wrong conclusion.
Evidence exists ≠ evidence entails the conclusion.
And even if the conclusion is correct:
True ≠ authorized to act.
That distinction becomes increasingly important as AI moves from answering questions to actually modifying systems.
A future development workflow can't just ask:
"Did we retrieve something relevant?"
It also needs to ask:
"Is this information still true?"
"Does it actually support this conclusion?"
"Is the agent allowed to act on it?"
These are very different verification problems.
The direction we're exploring
I don't think AI-assisted development is going back.
Agents will write more code.
They'll operate across more tools.
They'll run for longer periods.
They'll make more decisions.
And that makes project context increasingly important.
Because the more capable the agent becomes, the more expensive it is to give it incomplete context.
The interesting challenge isn't just:
"How do we make AI write better code?"
It's also:
"How do we make sure AI understands the project it is changing?"
That's the problem we're working on with Xeyria.
We're getting close to launch now, and over the next couple of weeks we're finishing the last pieces before putting it in the hands of more developers.
If you've ever returned to a project after a few days and thought,
"Wait… why did I build it this way?"
I'd genuinely be interested in hearing how you currently deal with that problem.
That's the problem that started Xeyria.
Top comments (1)
Disclaimer up front - though as you already know, we work in the same space you do: a persistent memory and context layer for AI-assisted dev, ours called cachly. So this is one competitor talking to another. But your comments have steered us right more than once across these posts, comments, and threads, and the honest way to say thanks is with our real numbers instead of a survey answer - in the hope they help Xeyria as much as your sharp reads have helped us. Competitors can still hand each other the good tools. :)
Your three verification questions are the right split, and they are not equally hard. "Is this still true?" you can date and decay. The one that quietly breaks systems is the middle one: evidence existing is not the same as evidence entailing the conclusion. Across ~3,400 verification calls, the format of the evidence - a bare recalled token vs. the same fact shown in real code context - changed whether the model reached the right conclusion by roughly an order of magnitude. Same fact, same model; what it was allowed to see changed the answer. So "we stored the reasoning" is necessary and nowhere near sufficient - the reader is the bottleneck, not the retrieval.
The other one you name - true is not the same as authorized to act - we ended up treating as a separate property of each stored decision: not just what was decided and why, but whether it is still binding, superseded, or a one-off. A correct-but-stale "we decided against X" is exactly the memory that blocks the right change with borrowed authority, so "true" and "act on it" have to be answered by different checks.
How we handle the reconstruction problem in practice: don't make the agent remember more, make it derive the decision at write time, so returning to a file surfaces the "why" unprompted. Same instinct as yours - reconstruct less.
One genuine question about Xeyria: when two pieces of stored reasoning conflict - an old decision and a newer one that quietly reverses it - what decides which one the agent sees? That resolution step is where "remember the why" gets hard, and it is the part I would most want to compare notes on.