I built DevsMind because keeping project context in sync had become a problem of its own.
I was working on Harrir, leading a team of eight on a product spread across multiple frontend and backend repositories. Alongside the team, I was using Claude, Antigravity, and Codex. Each tool could help with the code in front of it, but keeping useful context available across all of them was difficult.
The code was in the repositories. The understanding of that code was scattered between people, conversations, and separate agent sessions.
That gap became the reason I started DevsMind.
The problem I was trying to solve
In a project with several repositories, a task rarely ends at the file where it starts. A frontend change may depend on backend behavior. Understanding a backend change may require knowing which other part of the product relies on it. Previous decisions matter too: why something was implemented a certain way, what was already investigated, and what work is still in progress.
Using three AI coding tools added another layer. Switching tools meant carrying context between them. Continuing in a new conversation meant recovering it again. A useful investigation could end up trapped in the chat where it happened.
I wanted the next agent to have a better starting point. I also wanted useful discoveries to remain available to teammates instead of depending on someone remembering to repeat them.
The question behind DevsMind was simple: how could I make project understanding persist alongside the code?
Starting with a map of the code
The first foundation was a code graph: a structured map of functions, classes, and the relationships between them.
Instead of asking an agent to read large amounts of source and reconstruct everything from scratch, I wanted it to find the relevant area and inspect the connections around it. Where is this behavior implemented? What calls it? What does it call? What might be affected by changing it?
I exposed that information through MCP, the Model Context Protocol, so connected coding agents could use the same tool interface.
That was the beginning of DevsMind: a project context layer that different agents could consult. TypeScript and JavaScript became the foundation for its structural code mapping, while file search gave it a way to find other project material too.
DevsMind's viewer, using this portfolio as an example project. The selected node shows its relationships and recorded history; this is not a screenshot of Harrir's code.
A code map was useful, but building it also made the next problem clearer. Knowing where something lives does not explain why it exists.
Making context shareable
The early storage design needed to work better with a team.
In version 2.0, graph data and change history moved into JSON files that Git could track and merge. SQLite became a local cache that could be rebuilt from that shared data.
That change mattered because a shared project tool needs a practical way to move information between machines. Keeping the useful context inside one developer's local database would have left much of the original problem unresolved.
Another important improvement followed: reading source live from disk. A saved description can help an agent find the right function, but the implementation may have changed since it was indexed. DevsMind needed to show the current code and make stale context visible.
Those changes established two requirements I kept returning to: context should be shareable, and it should stay connected to the code that actually exists.
Recording the reason behind an edit
The next step was making changes traceable.
DevsMind grew an editing workflow in which an agent stages its changes and records the reason for them at a checkpoint. The record connects what changed with the original request, why the change was needed, and what it was meant to achieve.
That is useful when another person or agent returns to the same area later. The source shows the implementation; the recorded reasoning helps explain the decision behind it.
The workflow also expanded to cover edits outside functions and classes. Stylesheets, Markdown, configuration, and markup may not belong in the structural code graph, but changes to those files still need a reviewable record.
Over time, that became a local activity view with file diffs and request-level reverts. It gave me a way to inspect what an agent had changed across a task.
Giving longer work a place to continue
Individual edit records were only part of the story. A larger feature can span several conversations, involve research, and change direction before it is finished.
Workflows grew out of that need. They provide a persistent place for implementation steps, decisions, research, and supporting documents. A later session can recover the relevant work without depending entirely on the conversation that started it.
The search experience evolved with this. DevsMind now searches code symbols, source files, and workflow decisions together. Later changelog entries add links from code back to related workflows and make the substance of workflow steps searchable.
That progression reflects the original problem closely. I wanted an agent to find useful prior understanding as well as the implementation it needed to edit.
Learning from the less visible problems
The changelog also contains plenty of fixes that are less exciting to describe: Windows paths, stale source, oversized tool responses, session attribution, and synchronization behavior.
Those fixes are part of the journey. A context tool becomes hard to trust if it silently drops results, records another session's changes under the wrong task, or serves an old snapshot as current code.
Sharing the context also needed to fit ordinary development. DevsMind eventually moved shared brain data onto a dedicated Git branch, keeping it out of everyday feature pull requests. Personal activity and local credentials remain on each developer's machine.
Building the features taught me what the tool could do. Working through these failures taught me what it needed to do reliably.
What DevsMind means to me now
I built DevsMind end to end, and I am continuing to develop it as an open-source project. Its direction still comes from the problem I encountered on Harrir: useful understanding was too easy to lose between repositories, teammates, tools, and sessions.
There are limits. The richest structural mapping is for TypeScript and JavaScript. Other files can be searched and recorded without receiving the same depth of code relationships. A shared graph also needs agents to record their work and synchronize it; connecting a tool does not automatically preserve every decision.
For me, the value is continuity. An investigation should leave something useful behind. A new session should be able to recover earlier decisions. Moving from Claude to Codex or Antigravity should not require rebuilding the entire project context in a new conversation.
That is why I started DevsMind, and it is still the problem I want it to solve.