sergio
Ever improving LLM models, still have to copy and paste documentation from hexdocs. Can we do better?
This thread is just to chat about ways we can improve the Hexdocs ↔ LLM integrations to make it best in class.
I experienced this yesterday:
I was trying to improve my image background removal code that used @kip’s wonderful Image library. My version was using erode and had jagged edges, so using Google’s new Gemini 2.5 I was able to slowly ask it about:
- What problem I had initially.
- Here are some functions the Image library has.
- What do you want to see docs for?
- Repeat #2.
After a few back and forths it gave me a great solution that worked better that my original function.
It got me thinking: is there a way to better give these ever-improving AI models the docs and be more helpful to us Elixir developers? In the case of Image, I’m not really an image manipulation guy. My company does not specialize in image manipulation. I just need to remove a chroma key background as reliably as I can as fast as I can. I would have benefitted from a chunky document that listed all the module’s functions, instead of having to copy and paste it.
Is there a more native integration like having mix docs generate a ai text version of the docs that all one beefy chunk we can place into an LLMs context?
How do you guys work with hexdocs and AI? I’m curious if there’s a much better way I’m not aware of. Thanks!
Most Liked
v0idpwn
I have written a hexdocs MCP server: GitHub - v0idpwn/hexdocs-mcp: Unofficial, experimental MCP server for HexDocs · GitHub
I’m not sure yet of how well it behaves in real world scenarios, but you may want to give it a try.
nulltree
Roughly three better solutions:
- You can create an MCP server akin to GitHub - 9elements/hex-mcp: MCP Server for Hex Package Versions · GitHub
- Use this to convert hex documentation to .txt: GitHub - mjrusso/hex2txt: hex.pm package → llms.txt · GitHub, cf. also https://hex2txt.fly.dev/
- Wait until this lands natively (for newly generated docs at least): https://github.com/elixir-lang/ex_doc/pull/1976
A combination might even yield better results ![]()
D4no0
Honestly I always have the problem of finding the correct documentation, especially when it comes to bigger things such a phoenix.
I don’t think that specialized prompts for a bloated LLM is the way to go, as there is no information where the data was scraped from, this is especially a problem since a library usually has multiple versions, including major versions that change or introduce new things.
I think that fine-tuning a model such as BERT with elixir documentation might be something with a lot of potential, especially since we can make it aware of different versions of libraries. I was investigating this some time ago, but my poor desktop that was built on budget is not the best fit for training models, so iterations are way too slow for experimentation.
Popular in Discussions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









