Live data from Hacker News

AGENTS.md – Open format for guiding coding agents

agents.md

301–310 of 398 posts

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

#301

This should've been an .agents¹ with an index.md. For tiny, throwaway projects, a monolithic .md file is fine. A folder allows more complex projects to use "just enough hierarchy" to provide structure, with index.md as the entry point. Along with top-level universal guidance, it can include an organization guide (easily maintained with the help of LLMs). index.md ├── auth.md ├── performance.md ├── code_quality ├── da…

You can have multiple AGENTS.md files in your codebase and tooling will look at both the one in the current directory as well as in the root of the codebase. This way you can sort of do what you're suggesting but simultaneously keep the information closer to the code that it is describing.

Kind of, but for any given directory you can't separate out instructions for building from instructions for naming conventions, for example.

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

#302
post #294
post #290

This is a sad timeline. "AI is going to replace engineers.. but first please fill this human-readable markdown file to help it understand your code". What a bunch of morons, that's just called documentation. Instead of using AI where it can actually have positive impact on human lives like medicine, biology, et al. we're wasting huge amounts of resources and generating tons of pollution to teach it to program and ste…

> that's just called documentation. Ironically you sound very optimistic about AI capabilities here. This implies that an AI is just as capable as a human because all they need to contribute is what a human needs to contribute. Alternatively if you think AI is useless trash then clearly they need more than a human readme to do anything?

You're putting a whole lot of words in my mouth, I didn't say

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

#303
post #300
post #297

Earlier quoted context omitted.

The most effective argument I have for getting other developers to comment their code is "The agent will read it and it will give better suggestions". Truly perverse, but it works. I agree with you... but the reality is that there's a wide contingent of people that are not capable of understanding "people don't know the same things as me". So they need some other reason.

They understand it just fine; they are acting selfishly, because it does not benefit them. Helping the coding agent does.

They really might not understand it fully. That's very much in line with my understanding of how autism works.

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

#304

New Phoenix Framework projects have an AGENTS.md file in the root! It's really cool. https://x.com/alkadaemon/status/1955348410145358199

https://github.com/phoenixframework/phoenix/blob/main/instal... That’s insane . 3000 words of prose boilerplate about the language and framework . Sounds like you need, at the very least, some sort of import directive. I have no idea if “Read and follow the instructions in path/to/phoenixframework/AGENTS.md.” would work. And then the eclectic mixture of instructions with a variety of ways of trying to bully an intran…

Works great, why the _ugh_

Ultimately that's what matters.

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

#305

Earlier quoted context omitted.

Except not hidden. Why do people want to hide important files and directories? Particularly documentation? Tradition, I guess, but it's an antipattern that makes everything more opaque. Maybe robot_docs?

It's so it doesn't clash with any project that actually has a functional `agents/` directory

That's just an argument for having a more distinctive name.

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

#306
post #187

Earlier quoted context omitted.

Very strong "reverse centaur" vibes here, in the sense of humans becoming servants to machines, instead of vice versa. Not that I think making things more machine-readable is a waste of time, but you have to keep in mind the amount of human time sacrificed.

Well, it wouldn't even be the first time. We've completely redesigned society around cars - making the most human populated environments largely worse for humans along the way. Universal sidewalks (not really needed with slow moving traffic like horses and carts - though nice even back then), traffic lights, stop signs, street crossing, interchanges, etc.

As a cyclist, I’m with you 100%. Unfortunately we’re probably going to do it again with self-driving cars, with segregated lanes, special markers, etc.

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

#308

Earlier quoted context omitted.

Negative assertions can lead to unwanted weights in the context. I've found positive assertions to be more predictable.

Do you mind sharing a specific concrete example? I'm curious.

I can, I don't have a specific example I've used to give you in this moment. And trying to share an exact example would read like a double negative.

The general rule of thumb is only put what you want in context. If you put instructions of what not to do in context, those tokens can be misunderstood and create unintended/unwanted steering of the model.

A fair example would be testing for positive sentiment. Consider weight of tokens appended to context, phrase instructions or questions to be neutral or positive.

e.g. Some phrases and their impact:

- "Is the tone of the user message positive?" will be biased for a false positive.

- "Analyze the tone of the user message?" will be more neutral and less biased.

- "Is the tone of the message negative?" will be biased for false positives when evaluating for negative tone.

Post reply on HN