Inspiration
Software teams don't just lose knowledge because documentation is missing—they lose the reasoning behind the code. A new developer may be able to read what a function does, but often doesn't know why it was designed that way, what incidents led to it, or which decisions they should be careful about.
I wanted to build an AI assistant that remembers this engineering context over time. This led to DevTrace AI — an engineering memory layer for software teams. Its goal is simple: help developers understand a codebase as if they had been part of the team from day one.
What it does
DevTrace allows users to work with codebases and ask questions about their code, architecture, technical decisions, incidents, and engineering knowledge.
Instead of simply retrieving documents, DevTrace uses persistent memory to provide contextual answers in simple, developer-friendly language. Users can also save important decisions and notes so that this knowledge remains available for future conversations.
The core idea is:
Code + Engineering Knowledge + Decisions + Incidents → Persistent Memory → Contextual AI Answers
How we built it
I built DevTrace around CockroachDB's distributed capabilities and vector indexing to store and retrieve engineering memories efficiently.
The system combines:
CockroachDB for persistent engineering memory and structured data Vector search for retrieving relevant memories based on the user's question LLMs for understanding and synthesizing the retrieved context Code context/RAG to connect stored knowledge with relevant source code User and project isolation so knowledge remains associated with the appropriate codebase and user A web-based interface for chatting with the engineering memory and managing saved knowledge
When a developer asks a question, DevTrace retrieves the most relevant engineering context and combines it with available code context before generating the answer.
Challenges we ran into
The hard part was making memory the system of record, not a prompt add-on. We had to design types (ADR, incident, onboarding, impact) and a retrieve-then-answer loop so Chat cites CockroachDB rows instead of inventing lore. Getting that loop production-shaped meant matching Titan’s 1024-d embeddings to a C-SPANN VECTOR index, then wiring Bedrock so a missing Claude use-case form didn’t kill the demo — we switched the generator to Nova Pro and kept Titan for embeds.
Product-wise, scoping was messy: ShopFlow had to stay shared while imported repos stayed private, without leaking memories across projects. Hosting exposed a different class of bugs — US serverless talking to Mumbai CockroachDB made every click feel broken, and Git import failed because Vercel can’t write where a laptop can. Teaching the agent when to trust memory vs code context took more iteration than the UI.
Accomplishments that we're proud of
I shipped a working engineering-memory agent, not a chatbot demo. Memories (ADRs, incidents, impact links) live as VECTOR(1024) rows in CockroachDB with a C-SPANN index. The agent embeds with Bedrock Titan, cosine-searches that index, and Nova Pro answers with citations. ShopFlow is a shared production-shaped codebase; anyone can log into the live app, ask “why can’t cart.ts call Stripe?”, and see the ADR. I also added login, project scope, Remember (write a memory), and Impact (blast radius).
What we learned
Engineering knowledge dies in Slack and old ADRs unless something owns it. An agent is useful only if that knowledge is typed, stored, and searchable — not pasted into a prompt. Putting vectors in CockroachDB next to impact links meant one system of record: the same row you retrieve in Chat is the one Impact uses for blast radius.
I learned Bedrock is two jobs, not one: Titan for embeddings, Nova Pro for answers, and model access can block you mid-hackathon. Product-wise, “one shared demo + private imports” needs real auth and project scope or memories leak. Infra is part of the agent too — region, cold starts, and a read-only filesystem change what “import a repo” even means. Most of all: show citations. If the engineer can’t see which memory was used, they won’t trust the answer.
What's next for DevTrace AI
I want DevTrace to become automatically aware of how a codebase evolves. The next step is Git- and incident-aware memory, automatically ingesting PRs and incident write-ups so decisions, fixes, and outage lessons are captured in CockroachDB.
I also plan to add stronger team workspaces, with shared organizational memory alongside private project memory, plus support for multiple repositories and cross-service memory. The Impact view will eventually analyze entire change sets rather than individual files.
Longer term, I plan to make Git imports durable, run DevTrace on AWS alongside CockroachDB, and optionally use CockroachDB Agent Skills for operations.
The vision remains the same: persistent engineering memory, not another coding assistant.
Built With
- amazon-bedrock
- amazon-nova
- amazon-titan
- ccloud
- cockroach-db
- distributed-vector-indexing
- mcp
- next.js
- node.js
- rag
- react
- typescript
- vercel
Log in or sign up for Devpost to join the conversation.