DEV Community: EvanLin | Contorium

We Version Code. Why Don’t We Version Project Knowledge?

EvanLin | Contorium — Mon, 27 Jul 2026 13:51:17 +0000

Git changed software development by making code history visible.

Every commit tells us what changed.

But it doesn’t tell us something equally important:

Why did we make that change?

The reasoning usually disappears into:

Chat conversations
Design meetings
Issue discussions
Temporary AI chats
Someone’s memory

Months later, developers—and now AI—have to reconstruct that reasoning from scratch.

We’ve become very good at versioning code.

We’re still surprisingly bad at versioning knowledge.

As AI becomes part of everyday software development, this gap becomes much more obvious.

AI doesn’t just need access to files.

It needs access to the project’s accumulated understanding.

What assumptions still hold?

Which architectural decisions have expired?

Which constraints should never be violated?

These questions are rarely answered by source code alone.

That’s why I’m exploring a different idea with Contorium.

Not another coding assistant.

Not another IDE.

But a Project Intelligence Layer that preserves the evolving knowledge behind a project, so both humans and AI can build on understanding instead of starting over.

Git remembers the code.

Projects should remember their thinking.

https://www.contorium.dev/ https://github.com/ContoriumLabs/contorium

Git Remembers Code. AI Needs to Remember Decisions.

EvanLin | Contorium — Mon, 27 Jul 2026 13:20:02 +0000

Every software project accumulates invisible knowledge over time.

Not just source code, but decisions.

Why a framework was chosen.

Why an API was designed a certain way.

Why an idea was abandoned.

Unfortunately, most of this knowledge disappears into chat history, meetings, or people’s memories.

When AI joins a project months later, it only sees the current repository. It has no understanding of the project’s evolution.

That’s why developers often find themselves explaining the same architectural decisions again and again.

This isn’t a context window problem.

It’s a project knowledge problem.

I believe AI development needs another layer—one that persists beyond a single conversation.

Instead of storing prompts, it should preserve the project’s evolving intelligence:

Decisions
Assumptions
Constraints
Architectural evolution
Why things changed

This is the motivation behind Contorium.

Rather than acting as another coding assistant, it provides a Project Intelligence Layer that allows AI tools to understand not only what exists today, but also how and why the project arrived there.

Code evolves.

Project knowledge should evolve with it.

https://www.contorium.dev/

https://github.com/ContoriumLabs/contorium

Building a Project Intelligence Layer for AI Coding Agents

EvanLin | Contorium — Sat, 25 Jul 2026 14:26:52 +0000

AI coding agents already have access to a lot of context.

They can index repositories, search files, retrieve documentation, inspect Git history, use MCP tools, and maintain various forms of session memory.

But while building Contorium, I kept running into a different problem:

Repository context is not the same thing as project understanding.

The missing layer

A repository can tell an agent:

src/
auth/
api/
database/
services/

It can tell the agent what functions exist and how modules depend on each other.

But it may not tell the agent:

Why was this architecture chosen?
Why was another approach rejected?
Which constraints are intentional?
Which decisions are still valid?
What changed after the original design?
What is the current project state?

This information is often distributed across commits, conversations, issues, documentation, and — most importantly — the developer’s own reasoning.

That is the layer I’m experimenting with.

Project Intelligence

Contorium defines this layer as Project Intelligence.

At a high level:

Intent
↓
Decisions
↓
Reasoning
↓
Implementation
↓
Outcomes
↓
Evolution
↓
Current State

The important part isn’t just storing these objects.

It’s connecting them.

For example:

Decision
│
├── motivated by → Constraint
│
├── implemented by → Module
│
├── replaced by → New Decision
│
└── resulted in → Outcome

This creates a project-level knowledge structure rather than another flat memory store.

Where Contorium sits

The architecture is intentionally separated from the AI coding tool:

┌─────────────────────────────────────────┐
│ AI Tools │
│ │
│ Cursor · Claude Code · Codex · VS Code │
└───────────────────┬─────────────────────┘
│
▼
CIL — Cognitive Interaction Layer
│
▼
Project Intelligence
│
▼
.contora/
│
▼
Your Project

CIL is the interaction layer.

Project Intelligence is the persistent project-level state.

.contora/ keeps that intelligence associated with the project itself.

This separation is important because the AI runtime shouldn’t own the project’s accumulated understanding.

Why not just use Git?

Git already contains history.

But Git answers questions like:

What changed?

Project Intelligence tries to answer:

Why did it change?

And then:

What happened afterward?

And eventually:

Does the original reasoning still apply?

Git is an essential source of project history.

It isn’t the entire semantic model of the project’s evolution.

Why not just use RAG?

RAG is very good at retrieval.

If the question is:

Find the documentation about authentication.

retrieval is exactly what we need.

But a project intelligence system may need to connect:

Authentication
│
├── Decision
│ └── Why JWT was rejected
│
├── Constraint
│ └── Existing mobile clients
│
├── Module
│ └── auth-service
│
└── Outcome
└── Migration completed

The interesting part isn’t just retrieving the relevant documents.

It’s understanding the relationships between them.

Why this matters for AI agents

Imagine switching from one AI coding tool to another.

The new agent can read the repository.

It can inspect the current code.

But without project intelligence, it may still need to reconstruct the project’s history and reasoning.

With a persistent project layer, the workflow becomes:

New Agent
↓
Read Project Intelligence
↓
Understand Decisions
↓
Understand Constraints
↓
Understand Current State
↓
Continue Development

The model changes.

The tool changes.

The project intelligence remains.

Contorium today

Contorium is currently being built around several pieces:

project history
structured project state
decision and reasoning tracking
project graph
AI-ready handoff
MCP integration
IDE integration
local .contora/ storage

The project is open source, and I’m deliberately building it in public.

I’m not claiming that Project Intelligence is a solved problem.

I’m trying to find the right abstraction for it.

The bigger question

AI coding is moving from:

Human → Prompt → Code

toward:

Human
↓
Project
↓
Multiple AI Agents
↓
Continuous Evolution

Once multiple agents work on the same project over long periods, something needs to preserve the project’s accumulated understanding.

That’s the problem I’m interested in.

Not just AI memory.

Not just more context.

Project Intelligence.

That’s the direction behind Contorium.

https://www.contorium.dev/

https://github.com/ContoriumLabs/contorium

From Project Memory to Project Intelligence

EvanLin | Contorium — Sat, 25 Jul 2026 12:43:08 +0000

AI coding agents are becoming increasingly capable.

But there is an architectural problem that becomes more obvious as projects get longer-lived:

Where does the project’s evolving state actually live?

Today, we have many ways to provide agents with context:

AGENTS.md
CLAUDE.md
IDE rules
MCP servers
vector databases
RAG
session memory
repository indexing

These approaches are useful, but they mostly answer different versions of the same question:

How can I give the agent enough context to complete the current task?

I’m interested in a slightly different question:

How can the project maintain its own evolving intelligence across agents, sessions, and tools?

Static context isn’t enough

A file like AGENTS.md is excellent for relatively stable information:

Use TypeScript.
Run tests before committing.
Don't modify the generated directory.
Use PostgreSQL for persistence.

But real projects continuously change.

A decision made yesterday can be invalid tomorrow.

A failed implementation can be extremely important even though it doesn’t exist in the final codebase.

A workaround can remain in the repository long after the reason for it has been forgotten.

This creates a gap between:

what exists in the repository

and

why the repository looks this way.

That gap becomes increasingly important when multiple AI agents participate in development.

The project needs a state layer

This is the idea I’m exploring with Contorium.

Instead of treating context as something that belongs to a particular AI tool, I’m experimenting with treating project knowledge as a separate layer.

Conceptually:

         AI Agents
  ┌────────┬────────┬────────┐

Cursor Claude Codex Other
│ │ │
└────────┼─────────┘
│
Project Intelligence
│
┌────────┼─────────┐
Decisions History Constraints
│ │ │
Reasoning Outcomes Evolution
│
Project State

The important part is the middle layer.

The coding agent should be replaceable.

The project’s accumulated intelligence shouldn’t be.

Memory is not the same as intelligence

A memory system might tell an agent:

“We tried implementation A last week.”

Project Intelligence should eventually be able to represent something closer to:

“Implementation A was rejected because of constraint B.
Constraint B is still active.
Therefore, don’t reintroduce A unless B has changed.”

That requires more than retrieval.

It requires tracking relationships between:

decisions → reasons → outcomes → current validity

This is one of the areas I’m currently exploring with Contorium.

Why I’m building this

The more I use AI coding tools, the more I notice that switching models isn’t really the problem.

The deeper problem is switching understanding.

I might use one model for architecture, another for implementation, another for debugging, and another for review.

I don’t want each one to reconstruct the project from scratch.

The project should carry its own history.

That’s the basic idea behind Contorium:

A Project Intelligence Layer for AI-assisted development.

It’s still being built, and I’m intentionally developing it in public.

I’m less interested in claiming that this is already solved than in figuring out what the correct abstraction actually is.

If AI agents are becoming increasingly autonomous, perhaps the next important infrastructure isn’t another smarter agent.

Maybe it’s the layer that allows all of those agents to understand the same project.

https://www.contorium.dev/

https://github.com/ContoriumLabs/contorium

Projects Shouldn’t Lose Their Memory When You Change AI Tools

EvanLin | Contorium — Fri, 24 Jul 2026 13:38:30 +0000

Developers switch AI tools all the time.

Cursor today.

Claude Code tomorrow.

Codex next month.

Each tool is getting better.

But every switch introduces the same problem.

The project starts from zero again.

The AI doesn’t know why the architecture looks the way it does.

It doesn’t know which decisions were intentional.

It doesn’t know which compromises were temporary.

The knowledge is fragmented across chats, commit messages, documentation, and human memory.

That’s not a context problem.

It’s a project knowledge problem.

Contorium explores a different idea.

Instead of attaching knowledge to an AI session, attach it to the project itself.

The project becomes the source of truth.

Any compatible AI agent can understand not only the current codebase, but also the reasoning behind it.

Software evolves.

AI tools evolve.

Project intelligence should survive both.

That’s the direction I’m exploring with Contorium, an open-source Project Intelligence Layer for AI development.

https://www.contorium.dev/

https://github.com/ContoriumLabs/contorium

Git Stores Code. What Stores Project Intelligence?

EvanLin | Contorium — Fri, 24 Jul 2026 13:29:59 +0000

Modern AI coding assistants are becoming incredibly capable.

They generate code.
Review pull requests.
Debug issues.
Even help design architectures.

Yet they all share the same limitation.

They only understand what exists today.

Software projects are much more than today’s codebase.

They contain months—or years—of accumulated decisions.

Why was JWT chosen instead of Sessions?

Why was the database schema redesigned?

Which modules were affected by that change?

What assumptions should future contributors keep in mind?

These questions rarely have answers in the source code.

They live in discussions, documents, and people’s memories.

That’s where Contorium comes in.

Contorium is a Project Intelligence Layer that sits between AI tools and your project.

Instead of only storing code history, it preserves project intelligence:

Why decisions were made
Alternatives that were evaluated
The evolution of the architecture
Knowledge that should survive across AI tools

The vision is simple.

Git gave software projects version history.

Contorium aims to give them intelligence history.

The future of AI-assisted development isn’t just about generating better code.

It’s about enabling AI to understand the journey behind the code.

https://www.contorium.dev/
https://github.com/ContoriumLabs/contorium

Context Engineering May Become More Important Than Prompt Engineering

EvanLin | Contorium — Thu, 23 Jul 2026 12:46:57 +0000

Prompt engineering was one of the earliest skills developers learned when using large language models.

Today, I think another discipline is quietly becoming more important:

Context engineering.

Most AI coding tools already understand syntax, APIs, and programming languages remarkably well.

Where they struggle is understanding your project.

Questions like these are surprisingly difficult for an AI to answer consistently:

Why was this design chosen?
Which architectural decisions are intentional?
What assumptions are still true?
Which old decisions should be revisited?

These aren’t code problems.

They’re context problems.

The more I work with AI-assisted development, the more I believe that persistent project context will become foundational infrastructure.

Instead of rebuilding context in every conversation, projects need a structured memory that both humans and AI can understand.

That’s one of the motivations behind Contorium.

The goal isn’t to replace developers or create another autonomous coding agent.

It’s to preserve project knowledge in a way that survives across tools, IDEs, and AI sessions.

Code generation will continue improving.

But I suspect the next competitive advantage won’t just be who generates better code.

It will be who understands the project better before writing a single line.

That’s where I think context engineering begins.

https://www.contorium.dev/

https://github.com/ContoriumLabs/contorium

Why I’m Building a Project Intelligence Layer Instead of Another AI Coding Agent

EvanLin | Contorium — Thu, 23 Jul 2026 12:41:15 +0000

Most AI developer tools today focus on one goal: generating better code.

That’s an important problem, but I think another challenge is becoming just as significant.

Context doesn’t survive.

When you start a new AI session, you often have to explain your project again:

Why was this system designed this way?
What’s the current direction?
Which architectural decisions are intentional?
Which ones should probably be revisited?

Git tracks source code.

Documentation explains isolated concepts.

Chat history disappears.

None of them provide a persistent understanding of a project’s reasoning.

That’s why I’m building Contorium.

The core idea is straightforward:

Git stores code history. Contorium stores project intelligence.

Project intelligence includes things like:

Decisions
Design rationale
Assumptions
Project state
Timeline
Relationships between decisions
Knowledge validity

One feature I’m exploring is Decision Lifecycle.

Instead of recording an architectural decision once and forgetting about it, Contorium tracks whether that decision is still trustworthy as the project evolves.

A decision can move from VALID to WARNING, then to NEEDS_REVALIDATION if the assumptions behind it are no longer true.

This isn’t about replacing developers or making autonomous decisions.

It’s about giving both humans and AI a persistent memory of the project.

As AI becomes a permanent part of software development, I think project memory will become just as important as code generation.

That’s the direction I’m exploring with Contorium.

https://www.contorium.dev/

https://github.com/ContoriumLabs/contorium

Git Changed Collaboration. MCP Changed AI. What’s Next?

EvanLin | Contorium — Mon, 20 Jul 2026 16:05:21 +0000

Every decade, software development gains a foundational abstraction.

Version control changed teamwork.

Containers changed deployment.

Cloud changed infrastructure.

Now MCP is changing how AI tools integrate with development workflows.

But another problem is quietly emerging.

⸻

AI tools are excellent at producing code.

Repositories are excellent at storing code.

Neither is particularly good at preserving engineering knowledge.

That’s becoming expensive.

Because projects don’t fail from missing source code.

They fail from missing understanding.

⸻

What if “Project Intelligence” became a first-class citizen?

Imagine a repository that continuously maintains:

architectural decisions
feature evolution
dependency reasoning
implementation history
future priorities
engineering confidence

Not as documentation.

As structured project knowledge.

⸻

Maybe this becomes a new infrastructure layer.

One that sits beside Git instead of replacing it.

Git answers:

What changed?

A project intelligence layer answers:

Why did it change?

Those two questions together describe software far better than source code alone.

https://www.contorium.dev/

https://github.com/ContoriumLabs/contorium

We’re Optimizing the Wrong Part of AI Development

EvanLin | Contorium — Mon, 20 Jul 2026 15:44:14 +0000

Every major AI release focuses on the same metrics.

More tokens
Better benchmarks
Faster inference
Lower latency

Those are important.

But they’re not the bottleneck most teams experience after months of AI-assisted development.

The bottleneck is this:

Nobody remembers why anything was built.

⸻

Software development has entered a strange phase.

Writing code is becoming easier.

Understanding existing code is becoming harder.

Ironically, AI accelerates both trends.

It produces software faster than teams can absorb the decisions behind it.

⸻

Think about a mature repository.

It doesn’t just contain source code.

It contains years of trade-offs.

Rejected designs.

Temporary compromises.

Performance fixes.

Security decisions.

Business requirements.

These pieces of knowledge are often more valuable than the implementation itself.

Yet they’re the first things to disappear.

⸻

Perhaps repositories need a second layer.

One layer stores code.

Another stores understanding.

One records implementation.

The other records intent.

When AI tools can access both, they stop acting like code generators and start behaving like long-term engineering collaborators.

That feels like a much more interesting direction than simply making context windows bigger.

https://www.contorium.dev/

https://github.com/ContoriumLabs/contorium

Git Stores Code. What Stores Engineering Decisions?

EvanLin | Contorium — Fri, 17 Jul 2026 16:37:50 +0000

Git is incredible.

It remembers every file.

Every commit.

Every branch.

Every merge.

But Git was never designed to remember why.

⸻

Months later, developers ask questions Git cannot answer.

Why was this microservice split?

Why didn’t we use Kafka?

Why does this API still exist?

Why was this refactor abandoned halfway?

The information existed once.

Usually inside someone’s brain.

Or an AI conversation.

Or a meeting.

Then it disappeared.

⸻

As AI becomes part of software development, this problem becomes even bigger.

We’re generating more code than ever.

But we’re preserving less engineering knowledge than ever.

The faster code is written,

the faster reasoning disappears.

⸻

Imagine pairing Git with a second layer.

Git tracks files.

Another layer tracks decisions.

Git records what changed.

A cognitive layer records why it changed.

Together they create something much closer to how humans actually understand software.

Not files.

Not folders.

Not commits.

But intent.

That feels like a much stronger foundation for AI-native development than simply giving models larger context windows.

ContoriumLabs / contorium

Project Intelligence Runtime powered by CIL. Ask your project what happened, why it changed, and what comes next across any AI coding tool.

Contorium

Project Intelligence Layer for AI Coding

Git remembers what changed.
Contorium remembers why.

Contorium is a local-first project intelligence layer that preserves the context, decisions, and reasoning behind software projects.

It helps AI coding tools understand not only your code, but also:

Why architectural decisions were made
What assumptions they depend on
How the project evolved
Which decisions are still valid

Supported environments:

Cursor
Claude Code
Codex
Gemini CLI
VS Code
Any MCP-compatible AI runtime

The Problem

AI coding tools are powerful, but they forget.

Every new session starts with the same problems:

Why was this architecture chosen?

Why don't we use another solution?

What is the current project direction?

What decisions are still valid?

Developers repeatedly provide the same context.

The code exists.

The reasoning disappears.

The Idea

Git stores code history.

Contorium stores project intelligence history.

Git tells you:

What changed.

Contorium tells you:

Why it changed.

…

View on GitHub

https://www.contorium.dev/

From AI Chat History to Project Intelligence

EvanLin | Contorium — Fri, 17 Jul 2026 16:31:34 +0000

Modern development has a strange problem.

Our projects become smarter.

But our projects also become easier to forget.

Every AI conversation contains valuable engineering knowledge:

design trade-offs
rejected ideas
architectural decisions
implementation reasoning
future plans

Unfortunately, most of it disappears after the chat ends.

Documentation rarely stays updated.

Commit messages are too small.

ADRs are often forgotten.

So we started asking a different question.

What if the repository itself could remember?

Contorium approaches this by separating two responsibilities:

PIL (Project Intelligence Layer)

A deterministic, local-first storage layer that continuously captures structured project knowledge.

CIL (Cognitive Interaction Layer)

An intelligence layer that allows both humans and AI agents to understand that knowledge through natural language.

Instead of searching dozens of files, developers can simply ask:

Why?
How?
What changed?
What’s next?
What’s missing?

The interesting part isn’t another AI assistant.

The interesting part is creating a shared cognitive layer that survives across:

Cursor
VS Code
Claude Code
Codex
Gemini
MCP clients
CLI

One project.

One source of project intelligence.

Every AI tool starts from the same understanding instead of starting over.

We’re not trying to replace documentation.

We’re trying to make project understanding continuous.

Because software isn’t just source code.

Software is accumulated reasoning. Contorium is designed to preserve exactly that.

https://www.contorium.dev/

https://github.com/ContoriumLabs/contorium