Compylar

Compylar gives AI agents persistent memory of your codebase, enabling them to understand, build, and evolve software instead of starting from scratch every session

Comment

Inspiration

Every AI coding assistant today has the same weakness: it forgets.

Developers repeatedly explain architecture, conventions, business logic, and project structure every time they start a new conversation. As repositories grow, context windows become expensive, noisy, and unreliable.

I asked a simple question:

What if AI coding agents could keep long-term, evidence-backed memory of a software project instead of rediscovering it every session?

That became Compylar.

What it does

Compylar is persistent repository memory for AI coding agents.

It analyzes a local codebase, builds a durable Repository Brain, tracks when that knowledge becomes stale, and gives agents compact task-specific context before they read files or make changes.

Instead of asking an LLM to ingest an entire repository repeatedly, Compylar stores structured facts such as:

  • project structure
  • routes
  • symbols
  • dependencies
    • references
  • configuration
  • learned architecture facts
  • source-cited memory from prior agent work

When an agent receives a task, it can ask Compylar for the relevant memory first, read only the files that are truly necessary, and then update the Brain after meaningful discoveries or code changes.

The result is faster onboarding, less repeated exploration, lower context usage, and more consistent agent behavior across sessions.

How I built it

Compylar is a local TypeScript CLI with a deterministic indexing pipeline.

It parses repositories into a Repository Brain, stores that Brain locally, and exposes commands for bootstrap, context retrieval, memory lookup, freshness checks, refresh, and agent setup.

The key design is that Compylar works with coding agents rather than replacing them. The CLI handles deterministic repository facts and persistence. The agent performs deeper understanding when needed, then records source-cited learnings back into Compylar so future sessions do not repeat the same work.

The current workflow is:

  1. Install Compylar.
  2. Run setup-agent for Codex, Claude Code, or OpenCode.
  3. Bootstrap the repository Brain.
  4. Run the bundled codebase-index workflow for first-time semantic understanding.
  5. Use context, memory, overview, systems, and status during normal agent work.
  6. Refresh and update memory after validated changes.

No OpenAI API key is required for the core workflow. Optional AI enrichment can be added, but deterministic facts remain authoritative.

Challenges I ran into

The hardest part was not code generation. It was designing memory that stays useful over time.

Naive memory becomes noisy quickly. Static indexes answer “what exists,” but agents need help with “how this system works,” “what changed,” and “what should not be forgotten.”

We had to balance:

  • retrieval quality
  • indexing speed
  • freshness detection
  • source citations
  • context size
  • agent usability
  • avoiding unnecessary AI cost

Another challenge was agent onboarding. A skill file alone is not enough because agents may not load it proactively. Compylar now installs both the detailed skill and a short always-on project instruction so agents know to use repository memory before broad source reads.

Accomplishments that I am proud of

Compylar shifts the workflow from bigger prompts to better memory.

It can install into a project, create a local Brain, detect stale knowledge, retrieve targeted task context, and preserve source-backed discoveries across sessions.

I’m especially proud that the core works locally without requiring an API key. That matters because the product is about reducing repeated AI cost, not adding more hidden AI cost.

Compylar is also designed around evidence. Durable facts need citations. If memory is stale, Compylar says so. If the agent needs to read source, it should be a targeted read, not another broad rediscovery pass.

What I learned

I learned that AI coding quality depends heavily on when the agent starts writing.

If the agent writes before it understands the repository, even strong models make bad assumptions. But if the agent starts from persistent, structured memory, its work becomes more deliberate and cheaper to guide.

I also learned that repository memory has to be maintained overtime just the infrastructure. It needs freshness checks, citations, invalidation, and explicit unknowns.

What's next for Compylar

The next steps are:

  • broader language and framework support
  • stronger semantic retrieval
  • better reference and impact analysis
  • richer test and configuration awareness
  • IDE integrations
  • background indexing
  • team-shared memory
  • knowledge graph visualization
  • developer feedback loops for improving memory quality
  • possible MCP integration later, if the CLI-and-skill workflow proves a real need

The long-term vision is for coding agents to stop treating every repository like a first-time encounter. Compylar is the memory layer that helps agents understand, maintain, and evolve software over time.

Built With

Share this project:

Updates