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.

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

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

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

Fixed

Good idea. :)

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

My concern is scale though. Once you have thousands of nodes the Markdown files themselves become a mess to navigate

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.

The problem is that for any non-trivial question agents have to grep A LOT to understand the high-level logic expressed in code. In big projects grepping can take minutes some times. Lat short-circuits grepping significantly with `lat search` that agents happily use.

I'm working on a blog post about lat, stay tuned. Yes, it does work and I continue improving it.

The graph can be human-maintained, but the preferred flow is to let agents update it.

Adding a command to bootstrap lat for an existing code base is a good idea, I'll work on it.

Other than that the goal of lat is to make the agent use it and update it and it has tools to enforce that.

This is what lat is doing. `lat init` would install hooks to double check that Claude/Codex/OpenCode update lat.md when they finish the work.

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

FWIW polymorphic schema and queries are trivial in Gel https://docs.geldata.com/reference/edgeql/select#polymorphic...

geldata.com

Gel (ex EdgeDB) | SREs / Infrastructure Engineers | Full-time | Remote | https://www.geldata.com/

Gel is an open-source data platform built on top of Postgres. It’s designed to give developers a better end-to-end user experience than traditional SQL databases. We provide a more expressive schema modeling & query language (EdgeQL), and "batteries included" features such as built-in schema migrations and a graphical schema browser, data explorer, and access control/auth.

We offer a hosted cloud service for Gel, with the goal of doing developer-friendly cloud hosting "the right way" - we want users to use our hosted service because it's great, not because they're locked-in by restrictive licensing or cloud-only features.

We are looking for experienced SREs / infrastructure / devops engineers to help scale out our cloud. Unlike many infrastructure roles, this is not supporting a separate product team - for us, our infrastructure is our product. We are looking for people who care about not just building reliable infrastructure but also exposing that infrastructure to end-users as a seamless product.

Our tech stack is Hashicorp tools (Terraform, Consul, Nomad, Vault); Postgres; Golang with some Python & Rust; and AWS (with eventual expansion to other cloud platforms). It's a requirement that you have strong experience with Golang.

We are a remote-first company, headquartered in San Francisco, with most of the team working in US/Canada timezones and a few people in Europe. Unfortunately we are unable to provide any visa/immigration sponsorship at this time.

To apply, send your resume to jobs at geldata dot com and mention you saw this post on Hacker News.

---

P.S. I (co-founder) personally review all CVs from HN. I'm sorry I can't reply personally to everybody, but we do look and read through everything you send to us. And yes, we did hire a couple of wonderful people through HN and it was a great experience, I'm grateful.

Godot is a game engine. https://godotengine.org

Yeah, I knew that, and precisely because of that I assumed it's a typo :)

We have a native Python client. We can take a look if it works from Godot. Do you know if this is a popular use case?

Sorry, divan, for causing pain. This wasn't an easy decision. FWIW we're still strict about backwards compat and all you stuff should continue working.

Yeah, we probably can. We'll research!

++