Docs directories are doomed (yagmin.com)

I would describe myself as pretty AI-positive in software engineering, and even in technical writing, but something about seeing diagrams that are clearly generated by Nano Banana Pro immediately makes me stop reading. Weird!

No. If you cannot keep docs in sync, let the agent keep it in sync. Better keep the docs in the repo, not in a wiki or elsewhere

Another day, another person telling us how we should change what we have been doing for decades, just to make sure the machine can drop 1,000's of lines of debt that we'll never review, or worse yet, a machine will review it.

I guess the hope is that the middle managers will finally be able to get rid of the annoying techies, this time, as has been the promise for decades.

Maybe these LLMs are the silver bullet to finally free us so we can dance, paint, write poetry, and fuck instead of working.

Not that I consider writing code to be work, since it's always been the easy bit for me, but yeah, just as the machines have taken music, art, poetry, etc, why not let them take everything we enjoy.

PS - You'll prise copilot in vsc from my cold dead fingers :-)

Well, maybe I want my docs folder to be useful for humans checking my code and don't care about LLMs at all..

The blog reads like an advertisement for some product that doesn't exist (yet?). It seems rough to store, access and accurately update this context-code mapping

The constant changing of tense in this article makes it very hard to read.

Im from the opinion that not only for AI agents but detailed development docs (ADRs, Specs …) should live alongside each package.

High level and user docs in /docs

I feel like the article either doesn't really contain any information, or is describing the concept of "code comments" after being translated through 35 languages.

Here's an easier solution that actually works, gives any agent FREE long term memory (platform agnostic and zero infrastructure!), always accurate context that is self-maintained by the LLM.

Use the idiomatic comments for your language.

Here is a snippet of our prompt for C# (and similar one for TS):

    - Use idiomatic C# code comments when writing public methods and properties
    - `<summary>` concise description of the method or property
    - `<remarks>` the "why"; provide domain or business context, chain of thought, and reasoning; mention related methods, types, and files
    - `<param>` document any known constraints on inputs, special handling, etc.
    - `<return>` note the expected return value
    - `<example>` provide a brief example of correct usage
    - Use inline comments sparingly where it adds clarity to complex code
    - Update comments as you modify the code; ensure they are consistent with the intent of the code

What happens: when the LLM stumbles upon this code in the future, it reads the comments and basically "re-hydrates" some past state into context. The `<remarks>` one is doing heavy lifting here because it is asked to provide its train of thought and mention related artifacts (future LLM knows where else to look).

You already know the agents are going to read your code again when it gathers context so just leave the instructions and comments inline.

The LLM is very good at keeping these up-to-date on refactors (we are still doing human code reviews) and a bonus is that it makes it very easy to review the code to see why the LLM generated some function or property because the reasoning is right there for the human as well.

Common AI blog posts that seem generated:

1. State problem created by AI

2. Provide simple solution

3. State it cannot work and AI won’t help

4. Describe another way to solve for AI with more work

This feels like at least the third blog I’ve read that follow this pattern and have the hallmarks of generated text.

People are playing LLM slot machine for engagement blogs.

I can’t tell if “table of context” is a clever new phrase or a typo.