Up until then, I found it very hard to communicate to LLMs that I specifically do not want to handle X case because maybe it has never happened on production so far and I’d rather move on to other higher priority tasks.
I could agree with this in one session but the next will forget, and the automated code review LLM will flag my PR …
I know this may be VERY obvious to some but only recently I realised that you can use Doctests to document the cases that your code won’t handle.
I can fully relate to this one.
The project I’m working on right now includes complete documentation, plus the thought and backlog workflows in the repo. Being heavily AI-assisted, I found this a good way to make sure that the LLM has access to thoughts/backlogs as well as the “design” and “thoughts” which are not directly code but still shape the way the product behaves and should develop.
I have to admit that, in this sense, I no longer differentiate between code and documentation - both help the LLM understand the lay of the land. E.g. I have several doc gates as well - the simplest one being public function documentation being at 100%. Another “simple” thing I try to enforce is pushing the LLM to document why something is implemented the way it is, rather than how.
I have to admit that, in this sense, I no longer differentiate between code and documentation
Another “simple” thing I try to enforce is pushing the LLM to document why something is implemented the way it is, rather than how.
Yes exactly, couldn’t agree more!
© Copyright Elixir Forum | Terms | Privacy & Cookies
