So to help validate my idea, i want to discuss it here at Taro.
The problem is that keeping documentation up to date is very difficult. As a produce evolves and changes, the documentation usually lags behind and becomes obsolete.
From my experience with Test Driven Development I learned that automated tests act as living documentation. If I needed to understand how code on a new code base worked, I look at the tests.
What if we could generate docs based off the tests?
You know the docs are up to date because the tests are passing. You know if tests are removed, that documentation is removed. Making docs generate based off tests ensures that functionality is accessible to non-engineers. And acts as validation for feature requests. This also provides a clear, continuously updated reference for feature development and prevents regressions.
E2E testing. I'm currently looking in to using Playwright, and it should theoretically be doable.
We write the tests in a Gherkin style BDD framework. Given, When, Then. We'll develop best practices for generating rich, narrative documentation from these structured tests over time.
The core concept leverages Playwright's step function to create blocks of actions that describe documentation.
Given: sets up the test scenario
When: some kind of input or action we're testing against
Then: our assertion on what we expect
Many tests distill down to this pattern.
While the test executes we can take screenshots to give visual examples.
After the playwright tests run we output markdown which can be consumed by Docusaurus or some other documentation library.
The How section outlines an open source library. But where the true magic sauce lies is in offering a SaaS that makes it easy for non-technical people to help contribute to and improve the docs.
So the service will host the docs. We can allow non-technical users to make edits and then generate PRs to the repo using Github's APIs which ensures that the code is the source of truth. To allow more collaborations we can allow for comment style discussions on the doc, similar to Google Docs. Integrations with tickets like Jira or Github Issues to track the original requirements.
Feedback would be much appreciated. Is this something that would solve a pain point your organization has? Any suggestions?
The main problem with documentation is writing and especially maintaining it, so I definitely like the idea. My main concern is around the feasibility. A lot of these AI tools sound great in theory but when you get into the implementation, it turns out that getting it to a sufficient degree of quality is extremely rough. We learned that the hard way with TaroGPT. People 100% love chat bots, but we simply couldn't get the quality of TaroGPT to where it needed to be, and that's why the feature never got any real traction and we had to eventually kill it.
In your scenario, I'm very worried that your tool is going to end up generating a bunch of AI slop where it says a lot of stuff, but it's ultimately still hard to understand. I do have an idea to decrease the chances of that and that's to bring in data from more sources besides automated tests (which many smaller companies and codebases don't even have). This includes:
There's a ton of artifacts you can collate together to piece together a doc for every part of the codebase; it'll just be hard to match them all outside of the blames in particular.
Best of luck!
I do not believe that AI will be able to generate reliable docs. They just hallucinate too much for it to be reliable.
I actually have a prototype working for it now, you can see here. This is still very much a WIP. I'm still wrestling with how I want to generate the Docusaurus metadata, so odds are things will be breaking in the very near future.
But assuming the the tests are correct, the documentation that is generated will be correct as well. It will rely on developers implementing good tests. This is about creating more robust best practices not about getting free documentation unless you've already written the tests in the first place.
I am a firm believer in TDD, even though I know most places do not practice it, I do think a tool like this makes the value prop to write more tests, gets you not just more reliable software, less bugs, and it also gives you documentation for non-technical stakeholders. This would theoretically be great for companies that do need strict and auditable compliance in regulated industries like finance, health care, etc.
I almost forgot - Here's a great thread about documentation and building a good culture around it: "Best Practices for Retrofitting Documentation in a Growing Codebase"