1st1

potentially. I'm toying with the idea of distributed lat ;)

- 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 really.

> Having a CI job that identifies places where the docs have drifted from the implementation seems pretty valuable.

Testing with lat isn't about ensuring consistency of code with public API documentation. It is about:

* ensuring you can quickly analyze what tests were added / changed by looking at the English description

* ensuring you spot when an agent randomly drops or alters an important functional/regression tests

The problem with coding agents is that they produce enormous diffs, and while reading tests code is very important in practice your focus and attention drifts and you can't do thorough analysis.

This isn't a new problem though, the same thing applies to classic code reviews -- rarely coding is a bottle neck, it's getting all reviews from humans to vet the change.

Lat shifts the focus from reading test code to understanding the semantics of the test. And because instead of reviewing 2000 lines of code you can focus on reviewing only 100 lines change in lat.md you'll be able to control your tests and implementation more tightly.

For projects where code quality isn't paramount I now just glance over the code to spot anti-pattern and models failing to DRY and resorting to duplicating large swaths of code.

can you tell me more about what you mean by generative tests for spec conformance?

Docs typically focus on the public api, lat focuses on both public and private impl detail

I don't think this is related in any way.

One anecdote: I added lat to quickjs codebase and asked questions like "how does quickjs gc circular object graphs" and was able to get an answer in 12 seconds vs 2 minutes without lat. But take this with a grain of salt, I need better benchmark harness. Benchmarks are hard to do in general, for LLMs it's its own hell. :)

++

> I suspect there's ways to shrink that context even more.

Yeah, I'm experimenting with some ideas on that, like adding `lat agent` command to act as a subagent to search through lat and summarize related knowledge without polluting the parent's agent context.

I think you can have your workflow with lat and it might make it even nicer. Would love feedback from you.

I think it's a great idea and I'm considering building this in lat too. Code embedding models can definitely speed up grepping further, but they still wouldn't help much when you have a business logic detail encoded across multiple complex files. With lat you'd have it documented in a paragraph of text + a few [[..]] links into your code.

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 check` flags any spec without a backlink, so you can review and maintain test coverage from the knowledge graph.

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