We've been using AI in development for a while.
At first, the use cases were straightforward: generating code, writing tests, reviewing changes and helping us navigate unfamiliar parts of a codebase.
Then we started giving agents larger pieces of work — debugging production issues, refactoring existing systems, working across APIs and making changes that touched multiple parts of a project.
That's when we started running into a different problem.
AI could write the code. It just didn't always know enough about the project to write the right code.
A real software project is more than what currently exists in src/.
It has architectural decisions made months or years ago, contracts that must remain compatible, responsibilities divided between services, conventions that aren't obvious from reading a few files, and plenty of decisions that only make sense if you know why they were made.
A developer who has worked on the system for a year carries much of that context naturally.
A coding agent entering the repository does not.
And we found ourselves repeatedly explaining the same things:
- this service owns this responsibility;
- don't break this contract;
- keep this backwards compatible;
- use the existing implementation instead of creating another one;
- these tests describe the behaviour we need to preserve.
Then we'd start another session and explain much of it again.
That was the starting point for CS AI Core.
Put project knowledge next to the code
The basic idea is simple: the knowledge required to work safely on a project should live with the project.
Architecture, component boundaries, engineering rules, important decisions, tasks and acceptance criteria should be versioned alongside the code they describe.
A project might look roughly like this:
project/
├── ai/
├── ai-core/
├── src/
├── tests/
└── ...The application remains the application.
CS AI Core doesn't replace its architecture or introduce another runtime layer. It provides the context needed to understand and change that application correctly.
When an agent starts working on a repository, we want it to be able to answer a few basic questions before changing anything:
What is this system? How is it structured? Which component owns what? What can I change? What must remain compatible? How will we prove the work is finished?
Because that knowledge is versioned with the repository, it can evolve together with the software.
Change an architectural decision, update the context. Change a contract, update the relevant rules. Check out an older version of the project, and the context for that version is there as well.
Better tasks, not bigger prompts
We also learned that giving an agent more context doesn't fix a poorly defined task.
“Implement conversation recovery” sounds reasonable until you actually try to delegate it.
Which component owns recovery? What state is authoritative? What happens after reconnect? What existing behaviour must remain compatible? Which scenarios prove that the implementation works?
A useful engineering task needs an objective, scope, constraints, acceptance criteria and a clear definition of done.
That turned out to be useful beyond AI.
If we can't explain what a task should change, what it must not change and how we'll verify the result, then the task probably isn't defined well enough for a developer either.
Architecture still belongs to us
One of the more important lessons was that AI is often very good at finding a solution.
That doesn't mean it will put that solution in the right place.
In one of our systems, for example, responsibilities might be divided like this:
Gateway → identity and ordering
SDK → transport and lifecycle
App → presentationAn agent without that context can produce completely valid code in the wrong layer.
It compiles. Tests may even pass.
Six months later, the same state or business rule exists in three different places and somebody has to untangle it.
CS AI Core is partly about preventing that class of problem: not by asking the model to make architectural decisions for us, but by making our existing decisions explicit enough that an agent can work within them.
“Done” needs evidence
There is another problem with increasingly autonomous coding agents: finishing an edit is not the same thing as finishing a task.
We want completion to be something we can verify.
Tests pass. Existing contracts remain valid. Acceptance scenarios are covered. Required documentation is updated. The implementation stays inside the architectural boundaries defined for the project.
This becomes more important as agents take on larger pieces of work.
Reviewing every generated line becomes less useful if the surrounding engineering process can't tell us whether the resulting system still behaves correctly.
So we're putting more emphasis on evidence of completion, rather than simply accepting that an agent says it's done.
Why we're building it
CS AI Core didn't start because we wanted to build another AI framework.
It started because we kept seeing the same problems in our own projects: repeating context, rediscovering architectural decisions, poorly defined tasks and implementations that looked fine in isolation but didn't fit the system around them.
We started capturing that knowledge in a common structure.
Over time, that structure became CS AI Core.
It's still evolving, and we're changing it as we use it across real projects. We don't expect the first version to solve everything.
The goal is much more practical:
give coding agents enough knowledge about a project — its architecture, constraints and definition of done — to make useful changes without rediscovering the system every time.
That's what we're building.
And as the individual pieces become useful enough in our own projects, we'll write about those too.