371–380 of 398 posts
Earlier quoted context omitted.
Another reason to use a src/ directory for the actual source code.
These files also generally work in a nested fashion, like .gitignore and the like. So you want something that can be injected into the namespace of any directory in your project with relatively low likelihood of conflicts.
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…
Earlier quoted context omitted.
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.
``` // AGENTS.md
If implementing a new service, first read @./SERVICE_SETUP.md
If writing tests, first read @./TESTING_SETUP.md
```
Or whatever else might make sense for your project.
This looks like a normal README.md to me. Why do we need a separate file?
E.g. "Before each commit, do X and Y to validate the changes."
Not having support for importing files makes this dead on arrival. It means you can’t have a local file with local environment details. There’s an issue open about this in the repo already. I mean if you’re going to copy the CLAUDE.md concept, don’t leave out one of the most useful parts.
``` If adding tests, read @./TESTING_INSTRUCTIONS.md
```
Earlier quoted context omitted.
This. Projects need to stop inventing their own root level files and directories. Stop polluting the root dir. I'm not a fan of the name "well-known", but at least it's a convention [1]. I think it'd be great if we took something like XDG [2] and made it common for repositories, build scripts, package managers, tooling configs, etc. [1] https://www.rfc-editor.org/rfc/rfc8615 [2] https://wiki.archlinux.org/title/XDG_B…
I've been in IT for a long time and configured Apache, Nginx, even IIS a bit back in the day, but I actually didn't know about well-known. I guess I was one of the lucky 10000 :-) https://xkcd.com/1053/
Earlier quoted context omitted.
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.
A pessimistic look at self driving cars: https://www.youtube.com/watch?v=040ejWnFkj0&t=3148s If we end up where the video presents, humans don't deserve technology of any kind.
Not to be too harsh, but this sentiment -- that the successes of the ruling class are theirs to boast, but their failures are all humanity's shame -- is so pervasive and so effective at shielding rightful blame from said ruling class that I just cannot help but push back when I see it/
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.
several ironies here: 1) an AI agent is less likely to notice than even a junior is when the docs are out of date from the code 2) AI boosters are always talking about using language models to understand code, but apparently they need the code explained inline? are we AGI yet? 3) I frequently hear how great AI is at writing comments! But it needs comments to better understand the code? So I guess to enable agentic co…