51–60 of 70 posts
i've had a related question recently but it didn't get much traction https://news.ycombinator.com/item?id=47543324 what's the point of markdown? there's nothing useful you can do with it other than handing it over to llm and getting some probabilistic response
Earlier quoted context omitted.
One of the things that I've been chewing on lately is the sync problem. Having a CI job that identifies places where the docs have drifted from the implementation seems pretty valuable.
Python community figured this out in 2001: https://docs.python.org/3/library/doctest.html
managing agents.md is important, especially at scale. however I wonder how much of a measurable difference something like this makes? in theory, it's cool, but can you show me that it's actually performing better as compared to a large agents.md, nested agents.md, skills? more general point being that we need to be methodical about the way we manage agent context. if lat.md shows a 10% broad improvement in agent perf…
I'm working on a blog post and on benchmarks. Here [1] Armin suggested I take something like quickjs, built lat base for it, and compare side by side how, say, claude code works with lat vs. without. 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 faste…
i've had a related question recently but it didn't get much traction https://news.ycombinator.com/item?id=47543324 what's the point of markdown? there's nothing useful you can do with it other than handing it over to llm and getting some probabilistic response
Read this section, I've just updated it to be more clear, hopefully will answer your question: https://github.com/1st1/lat.md?tab=readme-ov-file#the-idea
if you mean this paragraph - imo that's still too hand-wavy compared to enforcement through generative tests for spec conformance.
So the graph is human-maintained, and agents consume it and `lat check` is supposed to catch broken links and code-spec drift. How do you manage this in a multi-agent setup? Is it still a manual merge+fix conflicts situation? That's where I keep seeing the biggest issues with multi-agent setups
The graph can be human-maintained, but the preferred flow is to let agents update it.
Earlier quoted context omitted.
Python community figured this out in 2001: https://docs.python.org/3/library/doctest.html
I don't think this is related in any way.
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 tutorial documentation for a package, liberally illustrated with input-output examples. Depending on whether the examples or the expository text are emphasized, this has the flavor of “literate testing” or “executable documentation”.
Seems pretty related to me.
Earlier quoted context omitted.
The graph can be human-maintained, but the preferred flow is to let agents update it.
Curious if you've seen a difference between agents finding things through the graph structure vs just vector search over a docs directory. The section constraints and check validation seem like the real quality wins here, wondering how much the wiki link topology adds on top of that.
Earlier quoted context omitted.
Read this section, I've just updated it to be more clear, hopefully will answer your question: https://github.com/1st1/lat.md?tab=readme-ov-file#the-idea
> 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…
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…
> 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.
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++