Would you actually use AI-generated plain English explanations of your code for collaborators?
Writulos already auto-generates technical docs on every push via GitHub Actions.
We're now exploring expanding it beyond developers. The idea: every file in your codebase can also generate a plain English version. Not code docs, but a "here's what this does" explanation for a client, a product manager, a design partner, or a new teammate who doesn't read code.
Example output for auth.ts:
"This file handles login validation. It checks credentials, creates a session token, and returns an error if something's wrong. If login behavior changes in your app, this is the first place to look."
You'd get this automatically on every commit (or on-demand for a specific file). No copy-pasting, no writing it manually.
We're genuinely curious:
Have you ever had to explain code to a non-technical stakeholder and wished there was a clean document you could just send them?
Would auto-generated plain English docs actually save you time, or would you spend more time fixing them?
What's a documentation pain point you still have that no tool has solved for you?
We're also interested in what else would be useful:
Doc drift alerts (knowing when your docs are out of date),
Auto-generated changelogs,
Architecture decision record generation from commit history,
User-facing README sections?
Or something completely new?
Trying to figure out what's actually worth building.


Replies
Yes, but the trust question is the hard part, not the generation. I built something adjacent, plain-English explanations of AI decisions for regulators instead of code for collaborators and the thing that took longest to get right wasn't generating the explanation, it was making people trust it without re-checking it manually every time. A "doc drift" alert (your point above) is probably the highest-leverage feature here, because stale-but-confident docs are worse than no docs. People stop trusting the tool the first time it's wrong.
Writulos
@anthony_widjaja
How did you handle trust for the regulator-facing explanations?
Was the main problem accuracy or completeness?
And what actually worked better in practice: a confidence signal, human review, or making verification fast enough that people still checked it?