DEV Community: Nevin-Bali100

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

Nevin-Bali100 — Sun, 14 Jun 2026 16:35:01 +0000

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:

GitHub Webhooks — DevDocAI listens for PR merges and auto-triggers the pipeline
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

Building DevDocAI - An AI That Writes Your Docs Automatically | Part 2: LangGraph Core, Agents & RAG

Nevin-Bali100 — Sun, 07 Jun 2026 13:36:28 +0000

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?

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_parser

…

View on GitHub

Building in public. Part 3 dropping soon.

Tags: python ai langgraph langchain rag fastapi opensource

Building DevDocAI - An AI That Writes Your Docs | Part 1: Foundation

Nevin-Bali100 — Fri, 05 Jun 2026 08:57:25 +0000

Series: Building DevDocAI — A Production Multi-Agent LangGraph System
Part 1 of 6 — Foundation: Backend, Auth, DB, GitHub OAuth, MCP Server

The Problem

Every engineering team has the same dirty secret: the docs are lying.

Not intentionally. Code moves fast, documentation doesn't. A new dev joins → spends 2 weeks reading outdated wikis → still has to disturb 3 senior engineers just to understand one service.

I got tired of it. So I'm building DevDocAI.

What is DevDocAI?

DevDocAI is a production-grade multi-agent LangGraph system that:

Connects to your GitHub repo
Reads your codebase at the AST level (not just text — actual code structure)
Auto-generates structured documentation per module/function
Updates docs automatically every time a PR gets merged
Has an onboarding chatbot — new devs can ask "what does this function do?" and get real answers from live code

The key word is agent — not just a RAG chatbot. This system understands your code.

The Full Agent Pipeline (What I'm Building)

START
  ↓
codebase_parser      ← AST-level parsing of GitHub repo
  ↓
doc_generator        ← LLM generates structured docs per module/function
  ↓
brave_researcher     ← enriches with external context (libraries, best practices)
  ↓
HITL checkpoint      ← YOU review generated docs before publish
  ↓
doc_publisher        ← saves to DB + updates vector store
  ↓
pr_watcher           ← GitHub webhook re-triggers on every PR merge
  ↓
END

Parallel → onboarding_chatbot ← RAG over vector store for new devs

The HITL (Human-in-the-Loop) part is what makes this real. The LangGraph pipeline literally pauses, waits for a dev to approve via the frontend, then resumes. Not just vibes — actual workflow.

Tech Stack

Layer	Tech	Why
Agent Framework	LangGraph	Multi-agent, HITL, checkpointing
Backend	FastAPI + Python	Async, fast, clean
Frontend	Next.js + Tailwind	(coming Phase 6)
LLM	Groq llama-3.3-70b	Blazing fast inference
Embeddings	Cohere	Best-in-class embeddings
Vector DB	Qdrant	Production-grade, pure Python client
Web Search	Brave Search API	Dev-focused, privacy-first
Observability	LangSmith	Agent traces, debugging
Tool Protocol	MCP	Modern tool standard
Auth	JWT + GitHub OAuth	Secure, industry standard
Cache	Redis (Upstash)	(coming Phase 5)
Storage	AWS S3	Doc storage
DB	PostgreSQL	Neon (prod), Docker (dev)
Deployment	ECR + ECS Fargate	(coming Phase 7)
CI/CD	GitHub Actions	(coming Phase 7)

Architecture — The Pattern I Follow

Every layer has one job. No exceptions.

Route      → HTTP only (request/response)
    ↓
Service    → Business logic
    ↓
Repository → DB queries only
    ↓
Database

This is what separates a demo from something real. When 5 engineers touch the same codebase, this pattern saves you.

Folder Structure

backend/
├── auth/
│   ├── jwt.py              ← token create/verify
│   ├── github_oauth.py     ← GitHub OAuth flow
│   └── routes.py           ← HTTP layer only
├── db/
│   ├── database.py         ← async PostgreSQL
│   └── models.py           ← SQLAlchemy models
├── repositories/
│   └── user_repository.py  ← all DB queries here
├── schemas/
│   └── auth_schemas.py     ← Pydantic request/response
├── services/
│   └── auth_service.py     ← business logic
├── utils/
│   ├── helper_auth.py      ← bcrypt helpers
│   └── encryption.py       ← Fernet token encryption
├── mcp/
│   └── github_server.py    ← GitHub tools for agents
├── agents/                 ← Phase 4
├── graph/                  ← Phase 3
├── webhooks/               ← Phase 5
└── main.py

Database Design

4 tables, all connected:

User
  └── Repository
          ├── Document       ← generated docs (PENDING → APPROVED → PUBLISHED)
          └── PipelineRun    ← LangGraph execution tracking

A few production decisions I made:

UUIDs over integer IDs — no sequential ID enumeration attacks.

Fernet encryption for GitHub tokens — never store access tokens in plaintext. Ever.

# utils/encryption.py
from cryptography.fernet import Fernet

_fernet = Fernet(settings.ENCRYPTION_KEY.encode())

def encrypt(value: str) -> str:
    return _fernet.encrypt(value.encode()).decode()

def decrypt(value: str) -> str:
    return _fernet.decrypt(value.encode()).decode()

Indexes on Document table — repo_id, file_path, status are all indexed because these will be queried constantly at scale.

DocStatus enum for proper state machine:

PENDING → APPROVED → PUBLISHED
PENDING → REJECTED

GitHub OAuth Flow

Frontend → GET /auth/github  →  GitHub redirect URL
              ↓
    User authorizes on GitHub
              ↓
GitHub → POST /auth/github/callback?code=xxx
              ↓
    Code → access_token exchange
              ↓
    Token encrypted → stored in DB
              ↓
    JWT returned → Frontend

Clean separation — routes.py only handles HTTP, auth_service.py has all the logic, user_repository.py handles all DB queries.

MCP Server — GitHub Tools for Agents

Built 6 tools that LangGraph agents will use:

GITHUB_TOOLS = [
    get_repo_contents,      # list files/folders
    get_file_content,       # read a file's source code
    list_branches,          # all branches
    get_pr_details,         # PR changed files (for pr_watcher)
    get_repo_info,          # repo metadata
    list_python_files,      # recursively find all .py files
]

These are @tool decorated LangChain tools — agents can call them directly in the pipeline.

Dev vs Prod Database Setup

One thing I'm proud of: proper environment parity from day one.

# database.py
connect_args = {"ssl": "require"} if settings.DATABASE_SSL else {}

engine = create_async_engine(
    settings.DATABASE_URL,
    connect_args=connect_args,
    ...
)

Dev  → Docker postgres:16 locally  → DATABASE_SSL=False
Prod → Neon PostgreSQL             → DATABASE_SSL=True

Same code, different config. No hacks.

What It Looks Like Running

After uvicorn main:app --reload, the DB initializes automatically:

✅ CREATE TYPE repostatus AS ENUM (...)
✅ CREATE TYPE docstatus AS ENUM (...)
✅ CREATE TABLE users (...)
✅ CREATE TABLE repositories (...)
✅ CREATE TABLE documents (...)      ← with indexes
✅ CREATE TABLE pipeline_runs (...)
✅ Database initialized. Tables created.
✅ Application startup complete.

And Swagger UI at /docs shows all endpoints live:

Key Learnings from Phase 1 + 2

1. Foundation takes time — and that's fine.
Two phases before writing a single agent. Every senior engineer says the same thing: boring infrastructure is what separates a demo from a product.

2. Pydantic v2 — use model_config, not class Config.

# Wrong (Pydantic v1 style)
class Config:
    from_attributes = True

# Correct (Pydantic v2)
model_config = ConfigDict(from_attributes=True)

3. Never store tokens in plaintext.
Fernet encryption, always. Takes 10 minutes to set up, protects your users forever.

4. Repository layer is not optional.
The moment you have DB queries in your service layer, you've lost. Create a repositories/ folder early, thank yourself later.

What's Next — Part 2

Phase 3 is LangGraph Core:

graph/state.py — the State schema that flows through all agents
graph/pipeline.py — connecting all agents into one graph
graph/hitl.py — the pause/resume HITL checkpoint logic

This is where it gets exciting. The graph will actually start running.

Follow the series to catch Part 2 when it drops! 🚀

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 🤖📄

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      ← AST-level

…

View on GitHub

Building in public. Part 2 dropping soon.

Tags: python ai langchain productivity beginners

I Turned My npm Package Into a Full DevOps Security Toolkit (v2.0.0)

Nevin-Bali100 — Fri, 22 May 2026 19:06:33 +0000

A few weeks ago I published dep-inspector-cli — a dependency analyzer for Node.js projects. It went from 107 → 240 weekly downloads in a day, which honestly surprised me.
But the more I used it in real projects, the more I kept thinking: dependency scanning is just one piece. What about secrets, Docker misconfigs, broken CI pipelines?
So I rebuilt it. v2.0.0 is out now — and it's a completely different tool.

What changed
v1 did one thing: dependency + vulnerability analysis.
v2 does six:

The features in detail
🔐 scan:secrets — what it catches
This one I'm most proud of. It scans your entire codebase for:

AWS Access Keys & Secret Keys
OpenAI, Groq, GitHub tokens
Hardcoded JWT secrets
MongoDB / PostgreSQL connection strings with credentials
Stripe & Razorpay live keys (not test keys)
Generic password= / secret= assignments in source files
.env files not listed in .gitignore

The last one is important — it doesn't scan .env content (that's expected to have secrets), but it checks whether .env is gitignored. A surprising number of projects miss this.

dep-inspector scan:secrets

🔐 Secrets Scanner

✅ .env is gitignored
[HIGH] JWT Secret hardcoded
  File : src/middleware/auth.ts:12
  Code : const JWT_SECRET = "my-super-secret-key-123"

🐳 scan:docker — Dockerfile analysis

dep-inspector scan:docker

🐳 Docker Analysis

[HIGH]   No non-root USER defined — container runs as root
[MEDIUM] No HEALTHCHECK instruction
[MEDIUM] Using ':latest' tag — not reproducible, pin a specific version
[LOW]    npm install without --omit=dev — devDependencies included in image

Checks for:

Container running as root
Missing HEALTHCHECK
:latest tag (non-reproducible builds)
Secrets in ENV/ARG
Missing .dockerignore
Single-stage builds

⚙️ scan:ci — GitHub Actions linting
This one catches things that are easy to miss in CI configs:

dep-inspector scan:ci

⚙️  CI/CD Pipeline Analysis

[HIGH]   deploy.yml: Deprecated '::set-output' — replace with $GITHUB_OUTPUT
[HIGH]   pr.yml: pull_request_target + actions/checkout is a privilege escalation risk
[MEDIUM] build.yml: Actions using @main — pin to a specific version
[LOW]    build.yml: No caching configured — builds will be slow
The pull_request_target + actions/checkout combination is a real security issue that's bitten several open source projects. Good to catch it early.

🔌 scan:ports — port monitor

dep-inspector scan:ports

🔌 Port & Process Monitor

[WARN] :27017 — Port 27017 is publicly exposed — restrict to localhost
[WARN] :6379  — Port 6379 is publicly exposed — restrict to localhost
[OK]   :3000
[OK]   :443

Flags database ports (MongoDB, Redis, PostgreSQL, MySQL) that are exposed on 0.0.0.0 instead of localhost. Works on both Linux and Windows.

📋 scan:logs — logger health

dep-inspector scan:logs

📋 Logger Health Check

✅ winston detected
⚠️  winston-daily-rotate-file not found — logs may grow unbounded
⚠️  LOG_LEVEL not set in .env — logger may default to verbose in production

Zero AI dependency by default
v1 had a problem: if you didn't have GROQ_API_KEY, the tool felt incomplete. Several people mentioned this in feedback.
v2 fixes it properly. Every scan is pure static analysis — regex, file parsing, CLI wrappers. No API calls, no keys, works offline, works in CI.
The --ai flag is additive:

# Works for everyone
dep-inspector scan:secrets

# Optional enhanced output if you have a Groq key
dep-inspector scan:secrets --ai

I also dropped LangChain entirely and moved to the official groq-sdk. Fewer dependencies, no transitive vulnerabilities, faster installs.

CI/CD integration

yaml# .github/workflows/security.yml
name: Security Scan
on: [push, pull_request]

jobs:
  dep-inspector:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install -g dep-inspector-cli
      - run: dep-inspector scan:secrets --json > secrets.json
      - run: dep-inspector scan:ci
      - uses: actions/upload-artifact@v4
        with:
          name: security-reports
          path: "*.json"

Fail build on HIGH severity findings:

bashdep-inspector scan:secrets --json | node -e "
  let d = '';
  process.stdin.on('data', c => d += c);
  process.stdin.on('end', () => {
    const { findings } = JSON.parse(d);
    const high = findings.filter(f => f.severity === 'HIGH').length;
    if (high > 0) { process.exit(1); }
  });
"

What's next

1. .git history scanning (catch secrets that were deleted but still in history)
2. scan:docker — docker-compose multi-service analysis
3. --report flag — HTML report with charts
4. Custom rules via .depinspectorrc

Try it:

npm install -g dep-inspector-cli
cd your-project
dep-inspector scan:all

📦 npm: npmjs.com/package/dep-inspector-cli
🐙 GitHub: github.com/Nevin100/Dep-inspector-cli
If it's useful, a ⭐ on GitHub helps a lot. Issues and PRs are open

I Built & Published My First npm Package: dep-inspector-cli

Nevin-Bali100 — Mon, 20 Apr 2026 16:28:12 +0000

And it went from 107 → 240 weekly downloads in a day.!!!!

I've been building full-stack apps for a while now — Next.js, TypeScript, PostgreSQL, MongoDB, and much more. But I'd never shipped something to the npm registry before. *dep-inspector-cli * changed that.
Here's the honest story of what it does, why I built it, and what's coming next.

The Problem:

Every Node.js project eventually runs into this moment:
npm audit

You get a wall of text. Severity levels, CVE IDs, a list of packages - but zero context about which of your actual dependencies pulled the vulnerable one in, or what you should realistically do about it.
I wanted something that actually connected the dots.

The Solution:

What dep-inspector-cli Does

npm install -g dep-inspector-cli
dep-inspector

Run it from your project root and you get:
🌳 Visual Dependency Tree — shows your full dep graph with outdated versions flagged inline, not as a separate report.
🛡️ Vulnerability Scan — wraps npm audit but surfaces results with severity, version delta, and a breaking-change warning if the fix is a major bump.
🔗 Dependency Chains — this is the part I care most about. It traces exactly which package in your tree pulled in the vulnerable dep. No more guessing.
📦 Package Context — homepage, author, repo link for flagged packages. Because knowing what a package is matters when you're deciding whether to update or swap it out.
🤖 AI Insights (optional) — add --ai and it uses Groq (llama-3.3-70b) to give you a plain-English breakdown: what the vuln is, what it affects in your specific project, and a recommended fix.
📄 JSON Output — --json flag for CI/CD pipelines. Fail the build if vulnerabilities are found, upload reports as artifacts, the works.

Example Output:

⚠️  Vulnerability Analysis

📦 axios
  Severity   : HIGH
  Version    : 0.21.1 → 1.7.2
  ⚠️  Breaking change possible!
  Repo       : https://github.com/axios/axios
  🔗 Chain: root → axios

💡 Fix Suggestions
  → axios: npm install axios@latest

CI/CD Integration

- name: Check dependencies
  run: dep-inspector --json > dep-report.json

- name: Upload report
  uses: actions/upload-artifact@v3
  with:
    name: dependency-report
    path: dep-report.json

Tech Stack

I used following tech stack to develop the initial version of this npm package:

TypeScript (fully typed)
Commander.js for CLI parsing
Chalk + Ora for terminal UX
LangChain + Groq for the --ai flag
Semver for version comparison

What's Coming Next (v1.2+):

The current version handles vulnerability scanning well, but I want dep-inspector to be genuinely useful for production-grade projects too. Here's what I'm actively working on:

🏥 Dependency Health Scoring - an overall health score for your project's dependency tree. Factors: vulnerability count, how outdated your deps are, and whether maintainers are active. One number that tells you roughly how much debt you're carrying.
📊 Production Package Support - first-class analysis for packages like winston, pino, morgan (logging), helmet, cors, express-rate-limit (security middleware), dotenv, zod (config/validation). Currently, these show up in the tree, but there's no opinionated analysis. Coming soon: known best-practice checks and upgrade guidance specific to each ecosystem.
🔍 License Audit - flag packages with restrictive licenses (GPL, AGPL) that might be a problem in commercial projects.
📈 Trend Tracking — run dep-inspector over time and see if your health score is improving or regressing. Useful for teams that do regular dependency maintenance sprints.

Try It and can raise an issue and some suggestions in the comments:

npm install -g dep-inspector-cli
cd your-project
dep-inspector

📦 npm: npmjs.com/package/dep-inspector-cli
🐙 GitHub: https://github.com/Nevin100/Dep-inspector-cli

If it's useful, a ⭐ on GitHub goes a long way. And if you run into issues or have feature requests — PRs are open.

Revision and completing Nextronix.ai

Nevin-Bali100 — Tue, 06 May 2025 17:54:21 +0000

Just did revision of nextjs while completing the nextronix.ai Project.

Day 4 of coding and learning!!!

Nextronix.ai on the verge of complete!!

Nevin-Bali100 — Mon, 05 May 2025 16:23:06 +0000

Nextronix Diet: Forks Over Fail

Nevin-Bali100 — Sat, 03 May 2025 18:10:32 +0000

Welcome to Nextronix.ai — my AI-powered fitness diet planner, built as part of my journey to master full-stack development and AI integration! Powered by Gemini API, Vapi Voice Assistant, and crafted using Next.js, TypeScript, Convex DB, and Clerk, this project listens to your voice, gathers key details, and creates a free, personalized diet plan just for you.

🔹 AI Voice Assistant Calls (via Vapi)
🔹 Info gathering through natural conversation
🔹 Personalized fitness diet plan
🔹 Real-time database with Convex
🔹 Auth handled by Clerk
🔹 Built for learning, sharing, and consistency

Learning from the tutorial on Youtube: Codesistency

This is Day 2 (missed Day 1 😅), but I’m showing up consistently from here on!

Insightful Article Post

Nevin-Bali100 — Tue, 13 Aug 2024 18:17:39 +0000

I read this post on the dev.daily about the good and bad commit changes on the git which I found quite insightful.
It was able to draw some important conclusions regarding the approach of doing proper commits but also I would like to add my perspective that for some scenarios,one can stash their current changes and can move to higher branch.

post link : https://dev.to/sheraz4194/good-commit-vs-bad-commit-best-practices-for-git-1plc
credits: Sheraz Manzoor

My-Portfolio

Nevin-Bali100 — Mon, 12 Aug 2024 16:44:02 +0000

As a Full Stack Developer, I have created a dynamic portfolio using React JS and Framer-motion. It showcases my skills and projects, highlighting my expertise in building efficient and user-friendly web applications. Let's connect and explore new opportunities!