61–70 of 70 posts
Creator of lat.md here. There are two videos with me talking about lat in more detail [1] and less detail [2]. But I'm also working on a blog post exploring lat and its potential, stay tuned. AMA :) [1] https://x.com/mitsuhiko/status/2037649308086902989?s=20 [2] https://www.youtube.com/watch?v=gIOtYnI-8_c
At that point why not have an obsidian vault in your repo and get the Agent to write to it?
Because lat gives agents more tools and enforces the workflow. Unlike obsidian, lat allows markdown files link into functions/structs/classes/etc too. This saves agents time on grepping but also allows you to build better workflows with tests. Test cases can be described as sections in `lat.md/` and marked with `require-code-mention: true`. Each spec then must be referenced by a `// @lat:` comment in test code. `lat…
lat seems like it could be useful to cross-reference company-wide projects.
Creator of lat.md here. There are two videos with me talking about lat in more detail [1] and less detail [2]. But I'm also working on a blog post exploring lat and its potential, stay tuned. AMA :) [1] https://x.com/mitsuhiko/status/2037649308086902989?s=20 [2] https://www.youtube.com/watch?v=gIOtYnI-8_c
What does lat.md do better than a docs/ or specs/ directory you manage yourself?
- gives agent tools to search and traverse the graph, better than they can with grep
- ability to have semantic links into your code and back
etc, see the README
Earlier quoted context omitted.
Because lat gives agents more tools and enforces the workflow. Unlike obsidian, lat allows markdown files link into functions/structs/classes/etc too. This saves agents time on grepping but also allows you to build better workflows with tests. Test cases can be described as sections in `lat.md/` and marked with `require-code-mention: true`. Each spec then must be referenced by a `// @lat:` comment in test code. `lat…
This is interesting. I've been using a system-wide Obsidian vault that all my agents use for stuff that's platform-specific instead of project specific (think common Android/Samsung-related or ANR fixes). So far, it hasn't been mind-blowing but it's only been a month so its knowledge from there is also limited. lat seems like it could be useful to cross-reference company-wide projects.
Can this tool solve these problems with models:
- insisting on using sed and shell redirection instead of File Edit Tools?
- trying to use npx to run commands instead of npm run that's right there in package.json
- forgetting to produce the docs that was asked for in AGENTS.md
- checking and using latest package versions instead of deciding somehow that years old versions are good enough
To my mind these are context problems, where somehow model chooses other information it has over what's in the repository, and what tools it has on call.
The other side of Lat.md, checking diffs models make among other changes, that's hard for me to grasp. I'd need to see it in action. Perhaps a coding session as a stream?
I found having smaller structured markdowns in each folder explaining the space and classes within keeps Claude and Codex grounded even in a 10M+ LOC codebase of c/c++
I'm working on making lat hierarchical, e.g. - lat.md # high-level description of the project - frontend/lat.md # frontend-related knowledge - backend/lat.md # details about your backend
Keep going, prompt engineering is fascinating.
Earlier quoted context omitted.
> Test specs with enforcement — test cases can be described as sections in lat.md/ and marked with require-code-mention: true. Each spec then must be referenced by a // @lat: comment in test code. lat check flags any spec without a backlink, so you can review and maintain test coverage from the knowledge graph. if you mean this paragraph - imo that's still too hand-wavy compared to enforcement through generative test…
can you tell me more about what you mean by generative tests for spec conformance?
normative specs allow generation of such tests deterministically - no need to spend tokens, no risk of hallucinations, much higher level of confidence that generated code is correct and much more accurate feedback from the test system into the LLM loop.
Earlier quoted context omitted.
What does lat.md do better than a docs/ or specs/ directory you manage yourself?
- makes agent manage it for you in a controlled way - gives agent tools to search and traverse the graph, better than they can with grep - ability to have semantic links into your code and back etc, see the README
Not trying to poopoo your project or be dismissive, just curious whether I'm missing something.
Earlier quoted context omitted.
I don't think this is related in any way.
> Having a CI job that identifies places where the docs have drifted from the implementation seems pretty valuable. https://docs.python.org/3/library/doctest.html > To check that a module’s docstrings are up-to-date by verifying that all interactive examples still work as documented. To perform regression testing by verifying that interactive examples from a test file or a test object work as expected. To write tutor…
"why not just put markdown files in each folder?" I had those files. I also had the answer.
I had lots of `.md` files, custom skills for consistency checks, a test-audit skill for coverage gaps, a code-truth skill that worked backwards from code to documentation. All untethered from the actual code. Nothing connected a design decision in `auth-flow.md` to the function implementing it. Nothing told me when a renamed method made the docs fiction.
So I became the binding. Personally running consistency checks. Running reconciliation. Constantly worrying about drift. It didn't scale — it scaled me.
lat.md replaced that work with three things: docs link into source code and source code comments link back to docs — the connection is explicit, not hopeful. `lat check` enforces referential integrity automatically — the tool worries about consistency so I don't have to. And the knowledge compounds — every session the agent consults the graph and can update it. I've taken to ending conversations with "review this and update [x]" where "x" is some document that I'm working on in the thread. lat.md gets updated for free.
I haven't run rigorous tests. It isn't perfect. There's no planning engine but I get by fine with various *plan.md file. But I'm rolling it out across all my repos because it replaced manual work I was already doing, more reliably than I was doing it.
Not "why do I need a tool for documentation?" but "why was I personally doing the job of a linter?"