Documentation was difficult to keep in sync with code because the tools didn't operate at a natural language level. Things like refactoring names, or terminology, or concept changes (foo is now fooGroup that contains bar) were tedious.
The granularity at which documentation parity is kept makes a big difference.
For example, brekaign things down into explicit assertion blocks in the code, and a link to the documentaiton that covers that assertion. So block-to-block tracking works well. Tracking completely separate documentation to independent codebase... idk I haven't tried it but my guess it that the context windows are too small for that.
But minor things like making sure there are unique error codes, that the codes somewhat make sense, etc. are all helpful. If nothing else, the model being stupid and acting as a rubber duck for pair-programming is useful for knowing what to document given a different perspective.
Comments
Documentation was difficult to keep in sync with code because the tools didn't operate at a natural language level. Things like refactoring names, or terminology, or concept changes (foo is now fooGroup that contains bar) were tedious.
The granularity at which documentation parity is kept makes a big difference.
For example, brekaign things down into explicit assertion blocks in the code, and a link to the documentaiton that covers that assertion. So block-to-block tracking works well. Tracking completely separate documentation to independent codebase... idk I haven't tried it but my guess it that the context windows are too small for that.
But minor things like making sure there are unique error codes, that the codes somewhat make sense, etc. are all helpful. If nothing else, the model being stupid and acting as a rubber duck for pair-programming is useful for knowing what to document given a different perspective.