IME developers have low tolerance for interrupting flow to track down the docu that is aimed at them, so keep it near and obvious.
If you split code up into multiple packages, moving the docs closer to the code might make sense. The docs for package foo could be in packages/foo/docs.
Before implementation, context is always cleared to ensure that the model is working only from known context (skills, AGENT.md, etc).
A major benefit of this is that agents can look up prior prompt instructions as needed or when mentioned in the current prompt it's working on.
I recently described my workflow here https://jaisenmathai.com/articles/sojourn-for-ios-was-45-one...
1. he's describing a manual version of Spec-Kit / OpenSpec / BMAD?
2. Thinks Markdown is... somehow different from normal text or other markup languages?
3. Doesn't seem to understand that LLMs are not deterministic?
this not perfect but he is describing a real trend, so listen with open mind.
One example is SpiderMonkey, which uses these beautiful, long expository comments explaining not only what, but why design choices have been made. https://searchfox.org/firefox-main/source/js/public/RootingA...
If the goal is "locality", you can't get much closer than as a comment.
As far as markdown becoming "source code for agents" under the agentic paradigm, per-directory `AGENTS.md` seems more consistent, at least visually. If agent managed markdown is going to be high-churn, I'd rather it be confined to a single file. Constraints, especially for agents, are good.
The interesting part of any program source is what it took to make that program. I view AI-generated code in the same category that I see a binary.
[1] https://blog.tombert.com/Posts/Technical/2026/04-April/Stop-...
Be sure to add a "/src/md/bikeshed.md" file to the directory, to specify the color of your project's bike shed. This is an important contribution you're making as a human. Fable is chipping in 600k lines of code too of course, but the color you picked is just great.
ktpsns•15h ago
We did put non-code into /src for a very long time: It was heredocs, multiline docs, etc. Actually my preference is to put texts close to code and only fallback to /docs/something.md at a conceptual level. Which is probably what the author proposes, given that he sees markdown as primary interface to code.
Rendello•31m ago
I actually miss what I had when I was playing around in TempleOS. All text in the OS is rich (you can toggle between the markup and the standard WYSIWYG view), so comments could have formatting, colours, images (bitmap or vector, great for diagrams), hell, even (aggressively spinning) 3D models.
The thing I used most was the collapsible sections, think <details> and <summary> in HTML. Although I appreciate plain text and would hate WYSIWYG rich text in my serious source code (not to mention binary data appended to the end of the source file for images and models), I can't help but pine for those features. Being able to just draw a real diagram and being able to edit it later in seconds as opposed to making some horrid ASCII art was awesome.