Series: Building DevDocAI — A Production Multi-Agent LangGraph System
Part 2 — LangGraph Core, Human-in-the-Loop Workflows, Agents & RAG
Recap
In Part 1, I built the foundation of DevDocAI:
- FastAPI backend
- PostgreSQL database
- JWT authentication
- GitHub OAuth
- MCP server for GitHub tools
- Clean layered architecture
At that point, the infrastructure was ready, but the actual AI system didn't exist yet.
This phase changes that.
In this article, I'm covering Phase 3 and Phase 4, where DevDocAI finally becomes a real multi-agent system powered by LangGraph.
What We Built in This Phase
The goal was simple:
Take a GitHub repository and turn it into living documentation through an orchestrated AI workflow.
To make that happen, I built:
Phase 3 — LangGraph Core
- State Management
- Workflow Pipeline
- Human-in-the-Loop (HITL)
- PostgreSQL Checkpointing
- Conditional Routing
Phase 4 — Agents & RAG
- AST-based Code Parser Agent
- Documentation Generator Agent
- Brave Researcher Agent
- Documentation Publisher Agent
- Qdrant Vector Store
- Embeddings Pipeline
- Onboarding Chatbot
This is where DevDocAI went from "backend project" to "actual AI product."
The Updated Workflow
The complete pipeline now looks like this:
START
↓
codebase_parser
↓
doc_generator
↓
brave_researcher
↓
HITL checkpoint
↓
doc_publisher
↓
END
Parallel
onboarding_chatbot
↓
Vector Store
↓
Generated Docs
Every node performs a specific task and passes information to the next node through a shared graph state.
Phase 3 — LangGraph Core
Before building agents, I needed a reliable workflow engine.
This is where LangGraph came in.
Unlike a simple chain, LangGraph allows:
- Stateful execution
- Checkpointing
- Human approval workflows
- Conditional routing
- Resume after interruption
Exactly what a production documentation system needs.
State Management
The first thing I built was a central state object.
Every agent in the graph reads from and writes to the same state.
class DevDocState(TypedDict):
user_id: str
repo_full_name: str
repo_raw_content: str
parsed_structure: dict
generated_docs: str
current_step: str
review_status: str
dev_notes: str
final_docs: str
Think of this as the memory of the entire workflow.
Instead of passing dozens of variables between agents, everything flows through a single structured state.
This makes debugging significantly easier.
Building the Pipeline
Once the state was defined, I created the graph itself.
START
↓
code_parser_node
↓
doc_generator_node
↓
hitl_review_node
↓
doc_publisher_node
↓
END
Each node performs one responsibility.
Code Parser Node
Reads the repository and analyzes the code structure.
Documentation Generator Node
Creates documentation using the parsed output.
HITL Node
Pauses execution and waits for a human decision.
Publisher Node
Publishes approved documentation.
This separation keeps the graph modular and easy to extend.
Human-in-the-Loop (HITL)
This was one of the most interesting parts of the project.
I didn't want an AI that automatically pushes documentation to production.
Developers need control.
So the graph pauses before publishing.
Generated Docs
↓
Review
↓
Approved ?
/ \
Yes No
↓ ↓
Publish Stop
The workflow literally waits for a developer's decision.
This is not a prompt-based approval.
This is actual workflow orchestration.
The graph execution stops and resumes later based on user input.
PostgreSQL Checkpointing
A paused workflow is useless if the state disappears.
That's why I implemented checkpoint persistence.
The complete graph state is stored in PostgreSQL.
checkpoint -> database
resume -> restore state
continue execution
Benefits:
- Workflow survives server restarts
- Long-running executions become possible
- Human approval can happen hours later
- Full auditability
This was one of the biggest advantages of choosing LangGraph.
Conditional Routing
After review, the graph makes a decision.
def should_publish(state):
if state["review_status"] == "approved":
return "publish"
return "reject"
The graph dynamically routes execution.
Review
↓
Approved?
↓
┌───────┬────────┐
│ Yes │ No │
↓ ↓
Publish Reject
Simple idea.
Very powerful in production workflows.
Phase 4 — Building the Agents
Once the graph was ready, it was time to build the intelligence layer.
I created four specialized agents.
Each one solves a specific problem.
Agent 1 — Codebase Parser
This agent is responsible for understanding the repository.
Instead of treating source code as plain text, it analyzes the code using Python's AST.
What it extracts
- Functions
- Classes
- Imports
- Modules
- Dependencies
- Documentation patterns
Example:
def process_payment(amount):
pass
The parser understands:
- Function name
- Parameters
- Relationships
- Dependencies
Not just raw text.
Actual code structure.
This becomes the foundation for documentation generation.
Agent 2 — Documentation Generator
After parsing, the next challenge is turning code into useful documentation.
This agent takes structured information and generates docs.
Capabilities include:
- Markdown generation
- HTML generation
- Function explanations
- Usage examples
- API documentation
- Multiple documentation styles
Input:
Parsed AST Structure
Output:
Developer-Friendly Documentation
This is the core value proposition of DevDocAI.
Agent 3 — Brave Researcher
Documentation generated purely from code is often incomplete.
Libraries, frameworks and external tools also need context.
To solve this, I built the Brave Researcher.
It uses the Brave Search API to gather additional information.
Examples:
- Library explanations
- Framework documentation
- Best practices
- External references
This creates richer documentation than code analysis alone.
Agent 4 — Documentation Publisher
Generating docs isn't enough.
They need to be distributed.
The publisher agent handles that responsibility.
Supported targets include:
- GitHub Wiki
- README generation
- File storage
- Versioned documentation
The rest of the system doesn't care where docs go.
The publisher abstracts that away.
Adding RAG with Qdrant
The next challenge was onboarding.
Imagine a new engineer joins a project.
Instead of reading hundreds of files, they should be able to ask:
What does the authentication flow look like?
or
Which service handles payment processing?
To make that possible, I added Retrieval-Augmented Generation (RAG).
Vector Store Architecture
Generated documentation is embedded and stored in Qdrant.
Generated Docs
↓
Embeddings
↓
Qdrant
↓
Semantic Search
Instead of keyword matching, the system performs semantic retrieval.
This allows developers to ask natural language questions.
Embeddings Pipeline
Every document is converted into vectors.
Document
↓
Embedding Model
↓
Vector
↓
Qdrant
These vectors capture meaning rather than exact words.
That makes retrieval dramatically better.
The Onboarding Chatbot
The final piece of Phase 4 was the onboarding assistant.
This chatbot sits on top of the vector store.
Workflow:
Developer Question
↓
Vector Search
↓
Relevant Docs
↓
LLM
↓
Answer
Now a developer can ask questions about the codebase without manually searching through files.
The answers come from generated documentation and repository knowledge.
Not generic internet responses.
Why I Chose Specialized Agents
One giant prompt could technically do everything.
But that's not how production systems scale.
Instead:
Parser Agent
↓
Research Agent
↓
Generator Agent
↓
Publisher Agent
Each agent has:
- One responsibility
- Clear inputs
- Clear outputs
- Independent testing
This makes the system easier to maintain and improve.
What the Project Structure Looks Like Now
backend/
├── agents/
│ ├── brave_researcher.py
│ ├── codebase_parser.py
│ ├── doc_generator.py
│ ├── doc_publisher.py
│ └── onboarding_chatbot.py
│
├── graph/
│ ├── state.py
│ ├── pipeline.py
│ └── hitl.py
│
└── vectorstore/
├── embeddings.py
└── qdrant_client.py
The architecture is starting to resemble a real production AI platform.
Key Learnings from Phase 3 & 4
1. Agents Need Structure
Most AI projects fail because every responsibility gets stuffed into one prompt.
Breaking responsibilities into specialized agents makes the system dramatically more reliable.
2. Human Approval Matters
Fully autonomous documentation publishing sounds cool until it publishes something wrong.
HITL workflows provide the safety net production systems need.
3. RAG Is Only As Good As Your Documents
A chatbot is useless if the underlying knowledge base is poor.
Investing in quality documentation generation improves everything downstream.
4. State Management Becomes Critical
Once workflows span multiple agents, checkpoints and persistence become mandatory.
Without state management, debugging becomes a nightmare.
What's Next — Part 3
The core AI system is now complete.
Next, I'll focus on Phase 5:
- GitHub Webhooks
- Automatic PR Detection
- Incremental Documentation Updates
- Redis Caching
- Event-Driven Pipeline Execution
This is where DevDocAI becomes truly autonomous.
Every merged PR will automatically trigger documentation updates.
No manual intervention required.
GitHub
Nevin100
/
DevdocxAI
DevDocxAI is a production-grade multi-agent AI system that automatically generates, maintains, and updates engineering documentation by deeply understanding you…DevDocAI is a production-grade multi-agent AI system that automatically generates, maintains, and updates doc. by understanding deeply.
DevDocxAI 🤖📄
DevDocxAi is a production-grade multi-agent LangGraph system that automatically generates and updates engineering documentation from your GitHub codebase.
🚨 The Problem
Every engineering team has the same dirty secret — the docs are lying.
Not intentionally. Code moves fast, documentation doesn't.
- New dev joins → 2 weeks reading outdated wikis
- Senior engineers constantly interrupted with "what does this do?"
- PR gets merged → docs never updated
- Generic RAG chatbots don't understand code structure
DevDocAI fixes this.
✨ What It Does
- 🔍 Connects to your GitHub repo via OAuth
- 🌳 Parses your codebase at the AST level — understands functions, classes, modules
- 📝 Auto-generates structured documentation per module and function
- 🔄 Updates docs on every PR merge via GitHub webhooks
- 👀 Human-in-the-Loop review — you approve before anything goes live
- 💬 Onboarding chatbot — new devs ask questions, get answers from live code
🤖 Agent Pipeline
START
↓
codebase_parserBuilding in public. Part 3 dropping soon.
Tags: python ai langgraph langchain rag fastapi opensource
Top comments (0)