← Back to context

Comment by kaurimu

14 hours ago

I settled on lat.md [1] at the beginning of this year and never looked back.

Its design offers a compellingly simple surface for weaving natural-language intent into the codebase itself, without overcomplicating things:

---

Key Ideas

* Plain markdown: readable by humans, parseable by agents

* Wiki links connect concepts into a navigable graph

* // @lat: and # @lat: comments tie source code to specs

* lat check ensures nothing drifts out of sync

* lat search for semantic vector search across all sections

---

For me it strikes the right balance between structure and flexibility. It gives agents enough context-efficient grounding to reduce functional and architectural drift [2], while remaining malleable enough to evolve with new requirements.

Admittedly I haven't run any evals, and I'm sure there are even better systems out there... but if I still had the problem I was trying to solve when I found it, I wouldn't be talking about it right now.

Of course it's likely that my problem has only migrated to a higher order of complexity, but surfacing it again through building increasingly complex things is an interesting enough challenge in itself.

[1] https://github.com/vercel-labs/lat.md

[2] 100% auto-eliminating drift is an unrealistic goal -- that's where you come in.

Hi, your comment motivated me to try it out on my project. I'm looking for some advice.

I had a 2000 line specification, but no code yet. Based on lat.md, I have split the specification into 25 different files in the lat.md folder (not sure if that's too many).

My next task is to create a staged implementation plan, but I'm not sure how lat.md can help me (or is it even designed to?). Should the implementation plan stages also be separate markdown files in the lat.md folder? Or a sub folder? (Does it matter).

My understanding is that lat will help create a knowledge graph between the specification files the implementation files, and the code.