DEV Community: EvanLin | Contorium

Your Code Can Be Correct Today — And Still Be Based on a Wrong Decision

EvanLin | Contorium — Fri, 14 Aug 2026 14:13:33 +0000

Software projects accumulate decisions.

Why this database?

Why this architecture?

Why was MCP introduced?

Why does this service exist?

At the moment a decision is made, there is usually a reason.

But software doesn’t stay still.

The project changes.

Dependencies change.

Requirements change.

Assumptions change.

And eventually, a decision that was completely reasonable six months ago may no longer be correct.

The problem is:

Most development tools remember the decision, but not its lifecycle.

⸻

A decision is not just a piece of documentation

Consider this:

Decision
↓
Assumption
↓
Project changes
↓
Impact
↓
Review

A database choice might have been made because the project needed high write throughput.

Later, the architecture changes.

The original assumption may no longer be true.

But unless someone notices, the decision simply remains there.

This creates a form of technical debt that is difficult to see.

The code still works.

The documentation still exists.

But the reasoning behind it may already be obsolete.

⸻

This is where AI can become useful

An AI agent shouldn’t only answer:

“What does this code do?”

It should also be able to answer:

“Why was it designed this way?”

And eventually:

“Is that decision still valid?”

This requires more than code retrieval.

It requires understanding the relationship between:

decisions
assumptions
changes
impact
validity

That’s the direction Contorium is exploring with its Project Intelligence Layer. (Contorium)

Instead of treating project knowledge as static documentation, decisions can have a lifecycle.

VALID → WARNING → NEEDS REVIEW

Now the project can tell you not only what it decided.

It can tell you what may need to be reconsidered.

⸻

Git tells you what changed

Git is excellent at tracking code history.

But code history doesn’t necessarily explain the reasoning behind a decision.

A commit can tell you:

This file changed.

Project intelligence can tell you:

This decision changed because the original assumption was no longer valid.

That’s a very different layer of information.

⸻

The next generation of AI development tools may not simply help us write code faster.

They may help us understand when the decisions behind that code stop making sense.

That’s a much more interesting problem.

And it’s one Contorium is trying to solve.

AI #AIAgents #SoftwareEngineering #MCP #OpenSource

https://www.contorium.dev/

https://github.com/ContoriumLabs/contorium

Your AI Tool Changes. Your Project Shouldn’t Have To Start Over.

EvanLin | Contorium — Fri, 14 Aug 2026 14:05:02 +0000

Your AI Tool Changes. Your Project Shouldn’t Have To Start Over.

AI coding tools are changing incredibly fast.

Today you might use Cursor.

Tomorrow, Claude Code.

Next month, perhaps Codex, Gemini, or another agent.

Switching tools is becoming normal.

But there is a problem we don’t talk about enough:

Every AI tool has its own context.

And your project is forced to adapt.

⸻

The project should be the constant

Think about a real software project.

It has accumulated:

architectural decisions
technical constraints
trade-offs
assumptions
failed approaches
current state
historical context

That knowledge belongs to the project.

It shouldn’t belong to a particular AI assistant.

But today, much of it is reconstructed every time we start a new AI session.

The repository provides the code.

The AI provides the reasoning.

But the connection between the two is often temporary.

Contorium approaches this differently.

It puts a persistent Project Intelligence Layer between the project and AI tools. (Contorium)

            AI Tools
    ┌─────────┼─────────┐
 Cursor   Claude Code   Codex
    │          │          │
    └──────────┼──────────┘
               ↓
    Project Intelligence
               ↓
          .contora/
               ↓
          Your Project

The intelligence stays with the project.

Not with the model.

Not with the chat.

Not with the IDE.

⸻

What does the project actually remember?

Not just conversations.

Not just retrieved documents.

Not just code snapshots.

Contorium is designed to preserve:

State → Intent → Decisions → Reasoning → Outcomes → Evolution (Contorium)

That changes what an AI agent can ask.

Instead of:

“Read the repository and figure out why this exists.”

It can ask:

“Why was this decision made?”

Or:

“What should I know before changing this?”

Or:

“What changed, and why?”

The goal is not to give AI more text.

The goal is to give AI access to the project’s accumulated understanding.

⸻

The AI tool is becoming interchangeable

This may become increasingly important as AI coding evolves.

Models will improve.

Agents will change.

IDEs will change.

New runtimes will appear.

But the project can remain the same.

That means the valuable asset isn’t necessarily the AI interface.

It is the intelligence accumulated by the project over time.

Contorium is building around that idea:

One project. One intelligence layer. Every AI runtime. (Contorium)

The tool can change.

The project remembers.

AI #AIAgents #MCP #OpenSource #DeveloperTools

https://www.contorium.dev/

https://github.com/ContoriumLabs/contorium

The Future of AI Coding Is Not One Agent. It Is Many Agents Sharing One Understanding.

EvanLin | Contorium — Mon, 10 Aug 2026 14:12:37 +0000

The first generation of AI coding was simple:

Human asks.
AI answers.

But the next generation is different.

We will have:

coding agents
testing agents
review agents
documentation agents
deployment agents

working together.

The challenge is no longer:

“Can AI write code?”

The challenge becomes:

“Do these agents understand the same project?”

⸻

Today, every AI agent has its own temporary context.

One agent knows the architecture.

Another knows the bug history.

Another knows previous decisions.

But they don’t share the same understanding.

The result?

Repeated explanations.
Lost decisions.
Inconsistent changes.

⸻

Software projects need a shared intelligence layer.

A place where AI agents can understand:

project goals
architecture decisions
constraints
assumptions
evolution history

This is the idea behind Contorium.

A Project Intelligence Layer designed for AI-native development.

Git stores code changes.

Contorium stores project understanding.

Because the future of software development will not be built by one AI.

It will be built by teams of AI agents.

And teams need shared memory.

GitHub:
https://github.com/ContoriumLabs/contorium

Website:
https://www.contorium.dev

AI #Agents #MCP #OpenSource #SoftwareEngineering

AI Can Generate Code. But Who Preserves the Intelligence Behind It?

EvanLin | Contorium — Mon, 10 Aug 2026 14:06:30 +0000

Modern AI coding tools are becoming incredibly capable.

They can generate functions.
Refactor systems.
Explain complex code.

But there is still a fundamental problem:

AI understands the code, but it doesn’t understand the history behind the code.

Why was this architecture chosen?

Why did the team reject another approach?

Which assumptions are still valid?

What decisions should be revisited?

These questions are not stored in code.

They exist in conversations, meetings, and the minds of developers.

And when a new AI session begins, that knowledge disappears.

⸻

This is the problem Contorium is trying to solve.

Not by creating another coding assistant.

But by creating a Project Intelligence Layer.

A project is more than files.

A project contains:

STATE
INTENT
DECISION
WHY
ASSUMPTION
EVOLUTION
Contorium captures these signals and makes them available across:

IDEs
MCP agents
CLI workflows
AI coding environments

Think about the difference:

Git answers:

What changed?

Contorium answers:

Why did it change?

Git stores history.

Contorium stores understanding.

⸻

As AI development moves toward multi-agent workflows, the next challenge is not simply making models smarter.

The challenge is maintaining continuity.

Because intelligence without memory becomes a series of disconnected conversations.

The future AI developer workflow will not just need better models.

It will need better project intelligence infrastructure.

That is the layer Contorium is building.

GitHub:
https://github.com/ContoriumLabs/contorium

Website:
https://www.contorium.dev

AI #LLM #MCP #OpenSource #Coding

Memory Isn’t Enough for AI Development

EvanLin | Contorium — Tue, 04 Aug 2026 13:36:18 +0000

Developers often say AI needs better memory.

I agree—but only partially.

Imagine AI remembers every commit you’ve ever made.

Great.

But does it know which architectural decisions were temporary?

Does it know which workaround is still necessary?

Does it know why the team intentionally ignored a “better” solution?

Probably not.

Memory stores information.

Judgment requires interpretation.

That’s why I think the next evolution isn’t longer context windows.

It’s Project Intelligence.

Instead of remembering everything, AI should understand which decisions still matter today.

That’s a much harder problem.

And probably a much more valuable one.

https://www.contorium.dev/

https://github.com/ContoriumLabs/contorium

Why AI Still Makes “Correct” Decisions That Break Your Project

EvanLin | Contorium — Tue, 04 Aug 2026 13:29:06 +0000

One thing I’ve noticed while building AI developer tools:

AI often makes decisions that are technically correct—but project-wise completely wrong.

Examples:

Removing “unused” code that’s intentionally reserved.
Replacing an architecture because it looks simpler.
Changing interfaces without knowing external dependencies.
Refactoring away workarounds that exist for real production issues.

None of these are reasoning failures.

They’re information failures.

The AI only sees the code.

It doesn’t see the project’s accumulated knowledge.

That’s why I’ve been building Contorium, a Project Intelligence Layer.

Instead of treating a repository as only files, Contorium treats it as a collection of evolving decisions.

When AI works on a task, it can understand:

Why a decision was made.
Which assumptions still matter.
What alternatives were rejected.
How the project evolved over time.

Code tells you how something works.

Project Intelligence tells AI whether it should change it at all.

I believe the next generation of AI development tools won’t simply generate better code.

They’ll make better project decisions.

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

Your AI Can Write Code. Can It Defend an Architectural Decision?

EvanLin | Contorium — Thu, 30 Jul 2026 12:41:00 +0000

One question I’ve started asking myself is surprisingly simple.

If my AI generates a new architecture today, can it explain why it’s better than the previous one?

Not just describe the implementation.

Actually defend the decision.

Can it explain:

Why the previous approach became a problem?
Which constraints influenced the redesign?
Which alternatives were considered?
What trade-offs were accepted?

In many projects, those answers aren’t stored anywhere.

They’re scattered across chat history, meetings, GitHub issues, or someone’s memory.

Yet those decisions are exactly what future development depends on.

This is why I think the conversation around Vibe Coding is starting to evolve.

Generating code is becoming a solved problem.

Understanding engineering decisions isn’t.

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

Not another coding assistant.

A Project Intelligence Layer that helps AI understand not only what the project is today, but why it became that way.

https://www.contorium.dev/

https://github.com/ContoriumLabs/contorium

The Best Vibe Coding Workflow Isn’t the One That Writes the Most Code

EvanLin | Contorium — Thu, 30 Jul 2026 12:27:14 +0000

When people talk about Vibe Coding, they usually focus on speed.

Generate a feature.

Refactor a module.

Fix a bug.

Everything happens faster.

But speed isn’t the metric I care about most anymore.

The best AI workflow is the one that requires the fewest repeated explanations.

If I have to explain the same architectural decision every week, something is missing.

If a new AI session keeps proposing ideas we’ve already rejected, something is missing.

If project knowledge only exists in chat history, something is definitely missing.

I think the next evolution of Vibe Coding is reducing repeated thinking—not just repeated typing.

That means preserving decisions.

Tracking assumptions.

Recording architectural evolution.

Giving every AI session a shared understanding of the project instead of starting from zero.

This idea is what led me to build Contorium as a Project Intelligence Layer.

AI is already good at writing code.

Now it’s time to help AI understand the projects it works on.

https://www.contorium.dev/

https://github.com/ContoriumLabs/contorium

Vibe Coding Doesn’t Eliminate Software Engineering

EvanLin | Contorium — Tue, 28 Jul 2026 14:48:41 +0000

Watching Vibe Coding become mainstream has been fascinating.

Some people believe software engineering is becoming less important because AI writes more code.

I actually think the opposite is happening.

The easier it becomes to generate code, the more valuable engineering decisions become.

AI can generate five different implementations.

Someone—or something—still needs to know which one fits the project’s history, architecture, constraints, and long-term direction.

That’s where software engineering lives.

Not in typing code.

In making decisions.

I think the future isn’t AI replacing engineering.

It’s AI becoming better at understanding engineering decisions.

That requires more than source code.

It requires persistent project knowledge.

That’s one of the ideas I’m exploring with Contorium: giving AI access to a project’s evolving intelligence instead of only its current files.

Vibe Coding changes how we write software.

It doesn’t change why good software succeeds.

https://www.contorium.dev/

https://github.com/ContoriumLabs/contorium

The Next Bottleneck After Vibe Coding Isn’t Code

EvanLin | Contorium — Tue, 28 Jul 2026 14:12:06 +0000

A year ago, writing code was the expensive part.

Today, AI can generate hundreds of lines in seconds.

Tomorrow, that probably won’t be the challenge either.

After using AI daily, I think the next bottleneck looks different.

It’s continuity.

Every AI session starts almost from zero.

The model understands the repository.

It understands your prompt.

But it doesn’t understand your project’s journey.

It doesn’t know which architectures were intentionally rejected.

It doesn’t remember why a design changed three weeks ago.

It can’t distinguish temporary experiments from long-term decisions.

As projects become larger, these questions matter more than code generation itself.

This is why I’ve been exploring the idea of a Project Intelligence Layer with Contorium.

Instead of focusing on generating more code, it focuses on preserving the knowledge that software projects accumulate over time.

Because in long-term development, writing code is only half the job.

Understanding the project is the other half.

https://www.contorium.dev/

https://github.com/ContoriumLabs/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