I've been writing documentation since 2012, having started in the field post a B.A in Literary Journalism. I have built documentation and curriculum for server-side and cloud-hosted software solutions, and the content I've published has been viewed by millions of real users over the years.
It is tremendously fun to get my hands into every part of the software stack and experience things as a user. This is the absolute crux of the writer-engineer's skillset and what I believe will keep the profession alive even in light of the AI boom. We know because we have done the thing, and in doing it we can better use the available tooling to build better outputs.
I'm struck that for all the writing I've done over the years, I have done absolutely none for myself, or about myself, or reflecting anything I've thought. This site aims to correct that, among other things.
AI has the ability to present itself as deterministic - confidently giving consistent answers to a problem set. The reality is that these are probability machines where outputs vary even with standard inputs. The line between skilled operator and future victim lies in recognizing this and using the tools appropriately.
It took just about 30 days to get to this point if I start counting from the first bit of (AI generated) code piped from some remote server farm to my Xubuntu-on-a-stick laptop.
BraiseDocs is a Proof-of-Concept around docs with out-of-the-box support for RAG pipelines and a process-level MCP for improved development.
I wanted to see what the PostGreSQL docs would look like in a slightly more contemporary rendering. More importantly, I wanted to use BraiseDocs to build a RAG + MCP server to see how it could benefit PGSQL development.