- 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

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

https://github.com/1st1/lat.md?tab=readme-ov-file#the-idea

I'm very early into this and need to build proper harness, but I can see sometimes lat allowing for up to 2x faster coding sessions. But the main benefit to me isn't speed, it's the fact that I can now review diffs faster and stay more engaged with the agent.

[1] https://x.com/mitsuhiko/status/2037649308086902989?s=20

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

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.

  - lat.md           # high-level description of the project
  - frontend/lat.md  # frontend-related knowledge
  - backend/lat.md   # details about your backend

https://github.com/1st1/lat.md/commit/da819ddc9bf8f1a44f67f0...

The agent will update the graph.

If you have thousands of nodes in md it means you have a highly non-trivial large code base and this is where lat will start saving you time - agents will navigate code much faster and you'll be reviewing semantic changes in lat in every diff, potentially suggesting the agents to alter the code or add more context to lat.

You still have to be engaged in maintaining your codebase, just at a higher level.