Honestly same way I did before, checking periodically. There's a real challenge though: I'm getting less and less knowledgeable about the details of my own code, so it's hard to fact-check everything all the time.
Anyway, for now we're assisting to either outdated Docs (Coding Agents often don't even look at them), or to over-bloated ones (the slop is not just in the code). We should probably still find a balance between human readable docs (e.g. README.md) and LLM-tailored ones (e.g. llms.txt)
If you want do it right:
1. Update the documentation first, to describe the desired / expected behaviour.
2. Followed by the code changes that implement the documented behaviour.
PRs: for any behaviour change, feature addition etc: patch must include corresponding documentation updates. If not: reject.
Iirc that was (still is?) OpenBSD's approach to keeping docs up-to-date.
Honestly same way I did before, checking periodically. There's a real challenge though: I'm getting less and less knowledgeable about the details of my own code, so it's hard to fact-check everything all the time.
Anyway, for now we're assisting to either outdated Docs (Coding Agents often don't even look at them), or to over-bloated ones (the slop is not just in the code). We should probably still find a balance between human readable docs (e.g. README.md) and LLM-tailored ones (e.g. llms.txt)
I pr and do regression test
From my observations - by accumulating technical debt faster than US and EU financial combined.
If someone asks about the internals of the projects it is - you want the truth, you can't handle the truth.
have an ai workflow man it’s mid 2026.
any time ai does any work, it ensures the ADRs are up to date.
it is part of the execution workflow.
maintain the todos which are a record of work that was done. ADRs have the latest current documentation.