6 ms·
Ask HN: How do you keep documentation up to date with AI generated code?
I've seen numbers like 75% of code at Google is AI generated, huge %s of code overall is AI generated, open source projects overwhelmed with "slop" PR requests.
It's pretty undeniable that AI code is here to stay - so on your teams / companies how are you managing staying up on PR reviews, and documentation?
- segmondy 2mo agoThe same entity that generates the code generates the documentation. If you have 75% of your code generated by AI, then 75% should be documented by AI.
- cyanydeez 2mo agowith local AI, I can set a for loop that runs nightly on any files updated the prior day and point it to a <file>.md right next to it and just have it revise it. You canimagine any number of loops like this. Obviously if you're using cloud solutions who both generate garbage faster and cost money per garbage, this doesn't work.
- trio8453 2mo agoThe documentation lives alongside the code and is changed at the same time.
- slipwalker 2mo agoreplace documentation for an agent/chatbot accessing a RAG with the collection of requirements/design docs plus the code repository. I have been doing a POC at my day job and it works surprisingly well even with SLMs ( Gemma3 4B, i smy current favourite )
- PaiDxng 2mo agoThe 75% number matters less than the review loop: every AI-heavy PR still needs a human owner, reproducible tests, and docs explaining the behavior change.
- ghosts_ 2mo agoHave you tried any AI review tools? I've been using / trialing a few and find they do an OK job but still seem hell bent on __finding__ and issue no matter what
- aldotirado 2mo ago[flagged]
- alphacrack 2mo ago[flagged]
- deleted 2mo ago[deleted]
- alphacrack 2mo ago[flagged]
- Hussain04 2mo ago[dead]
- ReptileMan 2mo agoFrom 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.
- RetroTechie 2mo agoIf 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.
- moomoo11 2mo agohave 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.
- jsabess24 2mo agoI pr and do regression test
- rstagi 2mo agoHonestly 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)
- ghosts_ 2mo agoWould you consider introducing any tooling around that? I've been building an automation setup for keeping dev docs up to date (and eventually user-facing knowledgebase docs) but would love to chat with other developers to make sure I'm doing the right thing or meeting the right needs. For me the focus was introducing easily readable / digestible docs, including mermaid diagrams where they are useful, linking to other parts of the code / docs, etc. and then a layer on top is a basic "Q&A" feature (you could do the same in any AI tool realistically) but something that surfaces docs or generates them on demand based on where the knowledge gaps are.