Building AutoDoc: How an AI Documentation Engine Became My Graduation Project — and a Real Deliverable for Mobelite

The Problem I Set Out to Solve

Anyone who has worked in a fast-moving engineering team knows the gap: code ships faster than documentation ever can. Onboarding new developers means reading raw source files, asking around in Slack, or worse, guessing. I wanted to build something that could close that gap automatically — a system that understands a codebase the way a senior engineer does, and writes the documentation a senior engineer would have written, if they'd had the time. That idea became AutoDoc.

What AutoDoc Actually Does

At its core, AutoDoc ingests a codebase, parses it structurally, and generates accurate, context-aware documentation using a retrieval-augmented generation (RAG) pipeline running on local LLM inference. The architecture breaks down into a few key layers:

• Parsing layer: AST (Abstract Syntax Tree) extraction to understand code structure, not just text — functions, classes, dependencies, and call relationships.
• Retrieval layer: Vector embeddings stored in Weaviate, so the system can pull in the right context when generating documentation for any given file or module.
• Generation layer: CLoud LLM inference producing documentation grounded in the actual code, not generic boilerplate.
• Security layer: Semgrep for static analysis and ClamAV for malware scanning, because any system that ingests arbitrary source code needs to treat that input as untrusted by default.

On the product side, the backend runs on Node.js/Express, the frontend on Next.js 16, with a dark "Terminal Intelligence" design system that fits the engineering audience it's built for.

From Backlog to Build

Before writing a line of backend code, I mapped the full product surface: 10 epics, a complete backlog, and a 9-sprint delivery plan, supported by class diagrams, sequence diagrams, and activity diagrams in PlantUML. That groundwork mattered more than I expected — when I hit real engineering problems later (pipeline duplication, Mongoose CastErrors, async/await ordering bugs, middleware sequencing issues), having a clear architectural map made debugging a matter of locating the failure, not re-deriving the system from scratch. This is the part of the job I think gets underrated in junior engineering roles: the discipline to plan a system before you build it pays compounding interest the moment something breaks in production — or in this case, the moment a demo has to work in front of an audience.

Taking It to Mobelite

AutoDoc wasn't just an academic exercise. I presented it internally at Mobelite, where I was interning as a DevOps Engineer, and the response went well enough that an engineering manager requested access to review the private repository directly — a strong signal in any internship, and one that speaks to the system being more than a proof of concept. That's the distinction I'd want a hiring manager to take away from this: AutoDoc isn't a toy project built to check a box on a CV. It's a full-stack, security-conscious, AI-integrated platform that was scrutinized by working engineers at a real company and held up.

What This Project Says About How I Work

I came into DevOps and SRE from a software engineering background, and AutoDoc sits exactly at that intersection — it's a product I built, but I built it the way an SRE thinks: with security baked in from day one, with infrastructure decisions (vector databases, local inference, ingestion pipelines) made deliberately rather than bolted on, and with the operational question always in the back of my mind — what happens when this breaks, and how do I know before the user does. For anyone evaluating this as a hire: this project is a fair representation of how I approach unfamiliar problems. I plan before I build, I instrument for failure, and I don't consider something done until it's been tested against real scrutiny — whether that's a competition panel or an engineering manager reading my code.