Talking Lat.md With Yury Selivanov
TL;DR
Yury Selivanov’s pitch is “review the decisions, not the code.” — His tool, Lat.md, stores a project’s evolving knowledge base in Markdown next to the code so humans can review high-level business logic and design choices instead of staring at 10,000 lines of React or Python.
Lat.md turns specs into a navigable graph, not a dead document. — It uses Obsidian-style wiki links, source-code links, and bidirectional references so agents can search for concepts like “release procedure,” jump to the right section, and expand only the relevant functions or methods.
The system is opinionated because drift is the whole problem. —
lat initwires agents like Pythagora/Pi and Claude into a workflow,lat checkvalidates Markdown and code links, and Yury says the stop hooks run checks “religiously” so stale specs fail locally and in CI.The retrieval story is local, structured, and more precise than plain RAG over code. — Lat builds a local vector index in a libSQL database, parses source with Tree-sitter for languages like TypeScript, Rust, Python, and C, and can link directly to a function instead of dumping whole files into context.
One of the most interesting tricks is spec-driven test enforcement. — In files marked
requireCodeMention: true, every leaf test spec must be referenced back from real test code, which lets an agent scaffold tests from Markdown and makeslat checkfail if the implementation is missing.Armin’s big question is scale, and Yury’s answer is “probably hierarchy.” — Armin worries that large systems eventually require pulling in too much spec context anyway, while Yury argues that English still compresses better than code and suggests nested Lat directories for monorepos, with local knowledge augmented by broader top-level context.
The Breakdown
The pitch: code review is broken, so compress the knowledge
Yury opens with a very specific pain: he wants to review code he and agents write, but reading dense low-level code at scale just doesn’t work. His answer is “compression” — capture the project’s key decisions, business logic, and rationale in Markdown, checked into the repo, so people review the high-level choices the agent made instead of every implementation detail.
What Lat.md actually is: Markdown plus links into reality
The core format is simple: regular Markdown with Obsidian-style wiki links, plus links into source files and even specific symbols. A section can describe something like a login flow in plain English and point at the exact implementation, and code can link back to the relevant Markdown section, creating a two-way map between knowledge and implementation.
The workflow matters as much as the format
Yury keeps stressing that “just having Markdown” isn’t enough; agents need a process. lat init scaffolds the latmd/ directory, creates agents.md or claude.md, installs hooks and plugins for tools like Pi and Claude, and injects itself into the agent’s start/stop flow so updating the knowledge base is part of finishing the task.
Search, section expansion, and less codebase spelunking
The retrieval loop is the clever bit: lat search runs against a local embedding index, then lat section expands the relevant section along with outgoing references and backlinks from other docs or code. In the live demo, the agent starts by searching for things like let init command plugin generation, then expands only the relevant sections instead of crawling files blindly — Armin notices it often reads just one actual file because the Lat output was enough.
Under the hood: local vectors, Tree-sitter, and ripgrep
Yury explains that the cache lives locally in the latmd/ directory, with hashes to track changed Markdown and a libSQL vector database that can be rebuilt on demand. For source references, Lat parses code with Tree-sitter — he mentions TypeScript, Rust, Python, and C — and uses ripgrep for speed, so links resolve to exact functions and methods at read time instead of relying on stale cached coordinates.
The test-spec trick is where it gets really practical
A standout moment is the requireCodeMention: true frontmatter option: if a Markdown test spec is marked this way, every leaf section must be referenced by real test code. Yury shows how this lets the agent add or update test specs first and then scaffold the implementation, while lat check catches missing backreferences — his preferred workflow is to review the English diff rather than read pages of generated test code.
Armin pushes on the hard part: drift and scale
Armin’s skepticism is precise: specs can drift, and on big systems the amount of context you need might explode anyway. Yury’s answer is that drift is exactly what the hooks and CI checks are designed to prevent, and that even if the scaling problem remains, it’s still better than forcing an agent to “grab grab grab” through millions of lines of code with no compressed intermediate representation.
The bigger vision: hierarchical knowledge graphs and code as a view
By the end, Yury is clearly thinking beyond a single repo-level folder. He imagines hierarchical latmd directories in monorepos, where a local search in backend/ prefers nearby knowledge but can pull in broader top-level business context, and even hints at a future where the knowledge graph is primary and code is more like one implementation view — maybe even rewritten from Rust to TypeScript from the spec, with source only used for edge cases.