Building DevDocAI — A Production Multi-Agent LangGraph System | Part 3 - GitHub Webhooks, Redis Caching

Series: Building DevDocAI — A Production Multi-Agent LangGraph System

Part 3 — GitHub Webhooks, Redis Caching & Making DevDocAI Truly Autonomous

---

Real Talk First

Between Part 2 and this post, I had university exams.

Not just one. A full exam week.

And honestly? I almost paused the project.

But then I thought — if I can't build while life is happening, what's the point?

So I kept going. Exams in the morning, code at night.

This post is the result of that.

---

Recap

By the end of Part 2, DevDocAI had:

✅ A fully working LangGraph multi-agent pipeline

✅ AST-level codebase parsing

✅ LLM-powered documentation generation

✅ Brave Search enrichment

✅ Human-in-the-Loop review

✅ Qdrant vector store + RAG chatbot

But there was one major problem.

It was still manual.

Someone had to trigger the pipeline every time.

That's not autonomous documentation. That's just a fancy script.

Phase 5 fixes that.

---

What Phase 5 Adds

Two things:

1. GitHub Webhooks — DevDocAI listens for PR merges and auto-triggers the pipeline
2. Redis Caching — pipeline status, docs, and repo data cached for speed

After this phase, the flow becomes:

Developer merges a PR
        ↓
GitHub sends webhook to DevDocAI
        ↓
DevDocAI finds the repo in DB
        ↓
Verifies the webhook signature
        ↓
Creates a PipelineRun record
        ↓
Triggers the full agent pipeline
        ↓
Docs auto-update

Zero manual intervention.

---

GitHub Webhooks — How It Works

A GitHub webhook is simple.

When something happens in a repo (PR merged, push, etc.), GitHub sends a POST request to a URL you configure.

DevDocAI listens at /webhooks/github.

But there's a security problem.

Anyone can send a fake POST request to that URL.

GitHub solves this with HMAC-SHA256 signatures.

Every webhook request has an X-Hub-Signature-256 header.

It's a hash of the payload signed with a shared secret.

We verify it before doing anything:

def verify_github_signature(payload: bytes, signature: str, secret: str) -> bool:
    expected = "sha256=" + hmac.new(
        secret.encode(),
        payload,
        hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(expected, signature)

If the signature doesn't match, request is rejected.

Simple. Secure.

---

The Webhook Handler

The full webhook flow in code:

@router.post("/github")
async def github_webhook(request: Request, ...):

    # Only care about merged PRs
    if action != "closed" or not merged:
        return {"status": "ignored"}

    # Find repo in our DB
    repo = await db.get_repo_by_github_id(github_repo_id)

    # Verify signature
    verify_github_signature(payload_bytes, signature, secret)

    # Create PipelineRun record
    pipeline_run = PipelineRun(trigger="pr_merge", pr_number=pr_number)

    # Cache pipeline status in Redis
    await cache_set(pipeline_status_key(thread_id), {"status": "running"})

    # Trigger the pipeline
    await run_pipeline(initial_state, doc_graph)

Clean, sequential, easy to follow.

Each step has one job.

---

Redis Caching — Why It Matters

Every time someone opens the dashboard, should we query PostgreSQL for everything?

No.

That's where Redis comes in.

Three main cache keys:

repo_docs_key(repo_id)          # "repo:{id}:docs"
pipeline_status_key(thread_id)  # "pipeline:{thread_id}:status"
user_repos_key(user_id)         # "user:{id}:repos"

When a PR triggers the pipeline, old docs cache is invalidated immediately:

await cache_delete(repo_docs_key(str(repo.id)))

When someone checks pipeline status, it comes from Redis — not a DB query.

Fast. Cheap. Simple.

---

What the Full System Looks Like Now

backend/
├── auth/
│   ├── jwt.py
│   ├── github_oauth.py
│   └── routes.py
├── db/
│   ├── database.py
│   └── models.py
├── repositories/
│   └── user_repository.py
├── schemas/
│   └── auth_schemas.py
├── services/
│   └── auth_service.py
├── utils/
│   ├── helper_auth.py
│   └── encryption.py
├── mcp/
│   └── github_server.py
├── agents/
│   ├── codebase_parser.py
│   ├── doc_generator.py
│   ├── brave_researcher.py
│   ├── doc_publisher.py
│   └── onboarding_chatbot.py
├── graph/
│   ├── state.py
│   ├── pipeline.py
│   └── hitl.py
├── vectorstore/
│   ├── embeddings.py
│   └── qdrant_store.py
├── webhooks/
│   └── github_pr.py       ← new
├── cache/
│   └── redis_client.py    ← new
└── main.py

Backend is complete.

---

The Endpoints Now

GET   /health
POST  /auth/register
POST  /auth/login
GET   /auth/github
POST  /auth/github/callback
GET   /auth/me
POST  /webhooks/github      ← new

---

Building During Exams — What I Learned

Honestly, shipping Phase 5 while having exams taught me more than just code.

A few things I noticed:

Constraints force focus.

When you only have 2 hours, you don't waste time on perfect folder naming or over-engineering. You build what matters.

Momentum is everything.

Missing one day makes it easier to miss two. Shipping something small every day — even just one file — keeps the project alive.

University teaches you to work under pressure. Building teaches you to create under pressure.

Both matter. They're not enemies.

I'm not saying skip studying. I'm saying you don't have to choose between learning and building.

Do both. It's harder. It's worth it.

---

Key Technical Learnings from Phase 5

1. Always verify webhook signatures.

Without HMAC verification, anyone can trigger your pipeline. Never skip this.

2. Invalidate cache on state change.

When docs update, old cache must go. Stale cache is worse than no cache.

3. Background tasks need proper state.

When the webhook triggers a pipeline, it runs async. Make sure state is fully initialized before kicking it off.

4. psycopg[binary] is required for LangGraph PostgreSQL checkpointer on Windows.

Spent more time than I'd like to admit on this one.

---

What's Next — Part 4

Phase 6 is the Next.js frontend.

Three pages:

• Dashboard — connected repos, pipeline status, doc overview
• Review Panel — HITL approval UI (approve/reject generated docs)
• Chat — onboarding chatbot interface

This is where DevDocAI becomes something you can actually show someone without saying "trust me, it works."

Exams are still going. Building is still happening.

Part 4 dropping soon. 🚀

---

---

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_parser

…

View on GitHub

---

Building in public — through exams, late nights, and all.

Tags: python ai langgraph fastapi redis webhooks opensource webdev