Two weeks ago I shipped the first version of git11.
The first post on this platform was about repo monitoring
and bug flagging. git11 has evolved significantly since then.
This is what it is now and what building it taught me.
What git11 does today.
git11 is an AI workspace for GitHub engineering teams.
Connect your organization and get:
Auto-generated documentation for any repository. The AI
reads your actual codebase and produces structured docs
without any manual input. No writing. No templates.
Just connect and it works.
Natural language codebase Q&A. Ask your codebase anything
in plain English and get accurate answers from the actual
source code. "How does auth work?" "Where is the payment
logic?" "What does this service do?" Answered from the
real code, not guessed.
Organization access control. Owner, Admin, Member roles
with granular repository permissions. Every action logged
in real-time audit logs.
API key management. SHA-256 hashed, shown once at creation,
revocable instantly.
Repository templates. Define your standard structure once.
Every new project inherits it automatically.
PDF export with branding. Email notifications for every
org action.
What I got wrong first.
I optimized for speed. The first version generated docs
in under 30 seconds. Nobody cared.
What engineers actually care about is accuracy. A
documentation tool that confidently generates wrong
function names and invented file paths is worse than
no tool at all. It creates false confidence.
So I built validation layers. AI output is now checked
against the actual repository structure before being
shown. Uncertain sections are flagged explicitly.
Slower. More trustworthy. That tradeoff was correct.
What I got right.
Read-only GitHub App permissions by default. No write
access. No code stored permanently. No admin permissions.
This was a design decision made before writing the first
line of code. Every conversation with a potential user
eventually reaches the permissions question. Having a
clear honest answer removes the biggest objection
immediately.
Engineers are protective of their codebases. Respecting
that is not a constraint. It is the correct way to build
a tool that accesses someone else's work.
The insight that changed how I think about this.
Teams do not have a documentation problem. They have a
knowledge transfer problem.
Documentation is one symptom. The real issue is that
institutional knowledge lives in people and walks out
when they leave. New engineers spend weeks asking
questions that should have written answers. CTOs cannot
get a clean explanation of how their own product works
without digging through code.
git11 is not a documentation editor. It is a knowledge
transfer system.
Where it stands.
Solo founder. No funding. Built with tools available to
anyone. Free to try at git11.xyz.
If you are building something similar or have dealt with
documentation debt on a real team, I want to hear what
you tried and why it did not work.
-Om Yaduvanshi
git11.xyz
Top comments (0)