Live data from Hacker News

AGENTS.md – Open format for guiding coding agents

agents.md

41–50 of 398 posts

Re: AGENTS.md – Open format for guiding coding agents

#41
post #24

Earlier quoted context omitted.

> We're in a transition phase today where agents need special guidance to understand a codebase that go beyond what humans need. Before long, I don't think they will. This isn't guaranteed. Just like we will never have fully self-driving cars, we likely won't have fully human quality coders. Right now AI coders are going to be another tool in the tool bucket.

Have you taken a Waymo?

Waymo uses a bespoke 3D data representation of the SF roads, does it not? The self-driving car equivalent of an AGENTS.md file.

Re: AGENTS.md – Open format for guiding coding agents

#42
The agents instructions file needs to be hierarchical; It's a pain managing multiple agents.md files with a lot of duplication between them for different projects, even in a mono-repo. we probably need a tool for this.

In any case, I increasingly question the use of an agents file. What's the point, then the agent forget about them every few prompt, and need to be constantly reminded to go through the file again and again?

Another thought: are folks committing their AGENTS.md? If so, do you feel comfortable with the world knowing that a project was built with the help of AI? If not, how do you durably persist the file?

Re: AGENTS.md – Open format for guiding coding agents

#43
post #24

We're in a transition phase today where agents need special guidance to understand a codebase that go beyond what humans need. Before long, I don't think they will. I think we should focus on our own project documentation being comprehensive (e.g. the contents of this AGENTS.md are appropriate to live somewhere in our documentation), but we should always write for humans. The LLM's whole shtick is that it can read an…

> We're in a transition phase today where agents need special guidance to understand a codebase that go beyond what humans need. Before long, I don't think they will. This isn't guaranteed. Just like we will never have fully self-driving cars, we likely won't have fully human quality coders. Right now AI coders are going to be another tool in the tool bucket.

I don't think the bar here is a human level coder, I think the bar is an LLM which reads and follows the README.md.

If we're otherwise assuming it reads and follows an AGENTS.md file, then following the README.md should be within reach.

I think our task is to ensure that our README.md is suitable for any developer to onboard into the codebase. We can then measure our LLMs (and perhaps our own documentation) by if that guidance is followed.

Re: AGENTS.md – Open format for guiding coding agents

#44

We're in a transition phase today where agents need special guidance to understand a codebase that go beyond what humans need. Before long, I don't think they will. I think we should focus on our own project documentation being comprehensive (e.g. the contents of this AGENTS.md are appropriate to live somewhere in our documentation), but we should always write for humans. The LLM's whole shtick is that it can read an…

One of the most common usages I see from colleagues is to get agents to write the comments so you can go full circle. :)

Re: AGENTS.md – Open format for guiding coding agents

#45
post #19

Earlier quoted context omitted.

It's not just understanding the codebase, it's also stylistic things, like "use this assert library to write tests", or "never write comments", or "use structured logging". It's just as useful --- more so even --- on fresh projects without much code.

... most of which would also be valuable information to communicate when onboarding new devs.

If there were already a universal convention on where to put that stuff, then probably the agents would have just looked there. But there's not, so it was necessary to invent one.

Re: AGENTS.md – Open format for guiding coding agents

#46
post #19

Earlier quoted context omitted.

It's not just understanding the codebase, it's also stylistic things, like "use this assert library to write tests", or "never write comments", or "use structured logging". It's just as useful --- more so even --- on fresh projects without much code.

... most of which would also be valuable information to communicate when onboarding new devs.

Yeah I agree. I think the best place for all this lives in CONTRIBUTING.md which is already a standard-ish thing. I've started adding it even to my private projects that only I work on - when I have to come back in 3 or 4 months, I always appreciate it.

Re: AGENTS.md – Open format for guiding coding agents

#47

I'm still not convinced that separating README.md and AGENTS.md is a good idea.

It is. README is for humans, AGENTS / etc is for LLMs. Document how to use and install your tool in the readme. Document how to compile, test, architecture decisions, coding standards, repository structure etc in the agents doc.

Why would these things not be relevant for humans?

Re: AGENTS.md – Open format for guiding coding agents

#48

Earlier quoted context omitted.

You're going to include specific coding style rules in your README? Or other really agent-specific things like guidance about spawning sub-agents? They are separate for a good reason. My CLAUDE.md and README.md look very different.

Why would you publish agent specific things to your codebase? That's personal preference and doesn't have anything to do with the project.

README often contains only basic context for the project and instructions for basic tasks like running it and building it from source. If additional information for developers, like coding conventions, is short enough compared to the rest of the README then it sometimes gets added there too, but if there's a lot of it then it's frequently kept elsewhere to prevent README from getting overwhelming for end users and random people just checking out the project.

Re: AGENTS.md – Open format for guiding coding agents

#50
I am developing a coding agent that currently manages and indexes over 5,000 repositories. The agent's state is stored locally in a hidden `.agent` directory, which contains a configuration folder for different agent roles and their specific instructions. Then we've a "agents" folder with multiple files, each file has

Agent only reads the file if its role is defined there.

Inside project directory, we've a dot folder where coding agents state is stored.

Our process kicks off with an `/init` command, which triggers a deep analysis of an entire repository. Instead of just indexing the raw code, the agent generates a high-level summary of its architecture and logic. These summaries appear in the editor as toggleable "ghost comments." They're a metadata layer, not part of the source code, so they are never committed in actual code. A sophisticated mapping system precisely links each summary annotation to the relevant lines of code.

This architecture is the solution to a problem we faced early on: running Retrieval-Augmented Generation (RAG) directly on source code never gave us the results we needed.

Our current system uses a hybrid search model. We use the AST for fast, literal lexical searches, while RAG is reserved for performing semantic searches on our high-level summaries. This makes all the difference. If you ask, "How does authentication work in this app?", a purely lexical search might only find functions containing the word `login` and functions/classes appearing in its call hierarchy. Our semantic search, however, queries the narrative-like summaries. It understands the entire authentication flow like it's reading a story, piecing together the plot points from different files to give you a complete picture.

It works like magic.

Post reply on HN