DEV Community: Nevin-Bali100

Building DevDocAI — A Production Multi-Agent LangGraph System | Part 6 — The Full Loop Works. Now: Deployment...

Nevin-Bali100 — Fri, 11 Sep 2026 06:22:31 +0000

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

Part 6 — The Full Loop Works. Now: Deployment.

The Milestone

Something clicked this week that hasn't clicked before in this project.

I connected a real GitHub repo through the dashboard, watched the pipeline parse it, generate docs with an LLM, enrich them with external context, pause for my review, got the "Docs approved" screen after clicking approve, and then asked the onboarding chatbot a question about that exact repo — and got a real, grounded answer back.

Not a demo. Not a curl command against an endpoint. A real browser, a real GitHub account, five agents, two databases, and a vector store, all talking to each other correctly.

That's the milestone. Here's everything that had to get fixed to get there — because it wasn't one clean run.

The Debugging Gauntlet

I'm not going to pretend this was smooth. Getting from "the pipeline runs once" to "the pipeline runs reliably, every time, from a cold start" surfaced a string of production-grade bugs, each one small but each one a real lesson.

1. The checkpointer connection kept dying

The first version of the LangGraph PostgreSQL checkpointer opened a single raw connection and held onto it. Neon — being serverless — closes idle connections after a while. The second time I ran the pipeline, everything blew up with the connection is closed.

The fix was switching to a proper connection pool:

_pool = AsyncConnectionPool(
    conninfo=psycopg_url,
    max_size=10,
    kwargs={"autocommit": True},
    open=False,
)
await _pool.open()
_checkpointer = AsyncPostgresSaver(_pool)

A pool self-heals. A single connection doesn't. That's the whole lesson, but it cost a few hours to land on.

2. `aupdate_state`, not `update_state`

The HITL resume endpoint calls doc_graph.update_state(...) to inject the human's decision back into a paused graph. Except with an async checkpointer, that call has to be awaited and it has to be the async variant:

# silently broken
doc_graph.update_state(config, {...}, as_node="human_review")

# correct
await doc_graph.aupdate_state(config, {...}, as_node="human_review")

The sync version doesn't error loudly with an async backend — it just doesn't behave. Easy to miss, annoying to trace.

3. Cohere → HuggingFace, mid-project

Embeddings were originally wired to Cohere. When the API key turned out to be invalid and I didn't want another external dependency with rate limits, I swapped to local sentence-transformers embeddings — completely free, runs on-device, no network call:

embeddings = HuggingFaceEmbeddings(
    model_name="sentence-transformers/all-MiniLM-L6-v2"
)

The catch: Cohere's model outputs 1024-dimension vectors, MiniLM outputs 384. Qdrant collections are locked to a vector size at creation time. Every "vector dimension error: expected 1024, got 384" was the collection remembering the old model. The collection had to be deleted and recreated once the embedding model changed — not something obvious until you hit it.

4. Qdrant Cloud wants an explicit index

Filtering search results by repo_id worked fine on paper, then Qdrant Cloud rejected it:

Index required but not found for "repo_id" of type: [keyword]

Local Qdrant setups can be more lenient; the managed cloud version requires you to explicitly create a payload index before you can filter on a field:

await client.create_payload_index(
    collection_name=settings.QDRANT_COLLECTION_NAME,
    field_name="repo_id",
    field_schema=PayloadSchemaType.KEYWORD,
)

Now baked into the same startup routine that creates the collection, so it never has to be a manual step again.

5. Brave Search killed its free tier mid-build

Genuinely — while building this, Brave Search API dropped its card-free 2,000 queries/month plan in favor of a credit-card-required $5-monthly-credit model. Rather than add a billing dependency to a side project, I swapped the research agent over to Tavily, which still has a genuinely free, card-free tier and is built specifically for agent/RAG use cases. Same node, same interface, different provider underneath — this is exactly why the agent is isolated behind one function boundary in the graph.

Why None of This Broke the Architecture

Every one of these was a plumbing fix — a connection strategy, an await keyword, a vector dimension, an index, a provider swap. Not one of them touched the graph structure, the agent responsibilities, or the API contracts the frontend depends on.

That's not an accident. It's the payoff of:

One node per responsibility — swapping Brave for Tavily meant editing one file, not touching the graph definition
A repository layer — the DB never leaked SQL into the pipeline logic
A single embeddings module — changing providers meant editing one file, vectorstore/embeddings.py, and nothing that calls it

The infrastructure decisions from Part 1 kept paying rent, four months later.

Also Fixed This Round

RAG counting questions — the chatbot was confidently answering "how many modules are in this repo?" using only its top-4 retrieved chunks, not the whole repo. Fixed with a stricter system prompt that forces the model to say "here's what I can confirm from what I retrieved" instead of presenting a partial view as a total, plus raising top_k from 4 to 15 for broader coverage.
Markdown rendering in chat — responses were coming back with literal **bold** and table pipes instead of rendered formatting. Added react-markdown + remark-gfm to the chat bubble.
A polished HITL review UI — proper loading/error/empty/done states, a full-screen pipeline loader with staged progress instead of a blank screen during the multi-minute run, hover states and skeleton loaders across the dashboard.

Where Things Stand

Piece	Status
Backend (13 endpoints)	✅ Complete
Multi-agent pipeline, end-to-end	✅ Confirmed working live
GitHub OAuth	✅ Working
Dashboard, review, chat — wired to real data	✅ Complete
RAG chatbot honesty/accuracy	✅ Improved
Phase 7 — Docker, ECR, ECS Fargate, CI/CD	🔨 Starting now

This is genuinely the last major checkpoint before deployment. Everything from here is Dockerfiles, a docker-compose setup for local full-stack testing, GitHub Actions for build-and-push, and getting this running on AWS instead of my laptop.

What's Next — Part 7

Phase 7. Containerizing the backend and frontend, pushing images to ECR, standing up ECS Fargate services, and wiring a CI/CD pipeline so a merge to main ships to production without me touching a terminal.

This is also where the "dev environment held together with local Docker and Neon" setup meets real infrastructure decisions — VPCs, security groups, environment secrets, the works.

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 — from "it ran once" to "it's about to run in production."

Tags: python langgraph fastapi qdrant rag docker aws opensource

Building DevDocAI — A Production Multi-Agent LangGraph System | Part 5 - Backend Closed Out, GitHub OAuth Working End-to-End

Nevin-Bali100 — Sat, 29 Aug 2026 14:52:50 +0000

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

Part 5 — Backend Closed Out, GitHub OAuth Working End-to-End

Quick Update

Short post this time — but a meaningful checkpoint.

Since Part 4, two things happened:

The backend is now fully complete — all 13 endpoints, tested and working.
GitHub OAuth is wired frontend → backend → GitHub → back again, and I watched it work end-to-end for the first time.

That second one felt bigger than it sounds. Let me walk through both.

Backend — The Final Two Endpoints

Part 4 left two gaps: no way to browse a user's actual GitHub repos, and no way to trigger the pipeline outside of a PR merge webhook. Both are closed now.

GET /github/repos
Pulls the user's repos directly from GitHub — not from our DB. New MCP tool, list_user_repos, wraps PyGithub's user.get_repos() and returns the fields the frontend actually needs: name, default branch, visibility, language.

POST /repos/{repo_id}/run
The manual trigger. Connect a repo → hit this → the full LangGraph pipeline starts immediately instead of waiting for a PR to merge. Same run_pipeline() the webhook uses, just a different entry point and trigger="manual" instead of "pr_merge".

Full endpoint list now:

POST  /auth/register
POST  /auth/login
GET   /auth/github
POST  /auth/github/callback
GET   /auth/me
POST  /webhooks/github
GET   /repos
GET   /github/repos
POST  /repos/connect
POST  /repos/{repo_id}/run
GET   /pipeline/{thread_id}/state
POST  /pipeline/review
POST  /chat/ask

Backend's done. Every agent, every checkpoint, every route the frontend needs — all there.

GitHub OAuth — Where It Actually Broke

This is the part worth writing down, because the bug was sneaky.

The flow is: frontend asks the backend for a GitHub authorize URL, backend builds it using GITHUB_REDIRECT_URI from .env, GitHub redirects back to that exact URI with a code, frontend catches it and exchanges it for a session.

I updated GITHUB_REDIRECT_URI in .env from the backend's own callback route to the frontend's:

# before
GITHUB_REDIRECT_URI=http://localhost:8000/auth/github/callback

# after
GITHUB_REDIRECT_URI=http://localhost:3000/auth/callback

Updated the GitHub OAuth App's redirect URI to match. Tested without restarting the server. GitHub threw:

Be careful! The redirect_uri is not associated with this application.

The URL in the browser still showed localhost:8000. .env was correct. GitHub App settings were correct. So why was the old value still being used?

@lru_cache() on get_settings(). The settings object gets built once and cached for the life of the process — editing .env while the server is still running (even with --reload, which only watches code files, not env vars) does nothing. A full stop and restart was needed to actually rebuild the cached Settings instance.

Small gotcha, easy fix, but worth remembering: env var changes need a hard restart, not a hot reload.

Seeing It Work

After the restart, the full loop:

/login → "Continue with GitHub"
      → GitHub authorize screen
      → redirects to localhost:3000/auth/callback?code=xxx
      → frontend exchanges code with backend
      → JWT stored
      → /dashboard

And it just worked. Landed on the dashboard, GitHub username in the top corner, no errors in either console.

There's something different about a full auth loop working versus a single endpoint returning 200 in Swagger. This is the first time a real browser, a real GitHub account, and the actual frontend all talked to each other correctly. It's the first "this feels like a product" moment in the project.

Where Things Stand

Piece	Status
Backend (13 endpoints)	Complete
GitHub OAuth, frontend to backend	Working, tested live
Frontend pages (landing, auth, dashboard, review, chat)	Built
Dashboard / review / chat wired to real data	Next
Phase 7 — Docker, ECR, ECS, CI/CD	Untouched

The dashboard is currently rendering against sample repos. Next step is swapping that for GET /repos and GET /github/repos, and making "Connect repository" actually call POST /repos/connect followed by POST /repos/{id}/run.

That's Part 6.

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 — one working loop at a time.

Tags: python nextjs oauth fastapi langgraph webdev opensource

Building DevDocAI — A Production Multi-Agent LangGraph System | Part 4 — Coming Back, Closing Out the Backend, and Laying Down the Frontend

Nevin-Bali100 — Thu, 27 Aug 2026 13:29:56 +0000

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

Part 4 — Coming Back, Closing Out the Backend, and Laying Down the Frontend

Where I Disappeared To

It's been about a month since Part 3.

No sugarcoating it — health took a hit, and along with a few other things piling up, DevDocAI sat untouched for weeks. Not proud of the silence, but I'd rather be honest about it than pretend the "building in public" streak was unbroken.

Here's the thing though — the project didn't die. It waited.

And this week I sat back down, opened the repo, and picked up exactly where I left off. No rewrite, no "let me restart with a cleaner approach" spiral. Just continuing.

If you're building something and life knocks you off pace — the comeback matters more than the streak. This post is that comeback.

Recap — Where Things Stood

By the end of Part 3, DevDocAI had:

✅ Full multi-agent LangGraph pipeline (parser → generator → researcher → HITL → publisher)

✅ GitHub OAuth + encrypted token storage

✅ GitHub PR webhook auto-triggering the pipeline

✅ Redis caching layer

✅ Qdrant + Cohere RAG for the onboarding chatbot

The backend was functionally complete for the pipeline itself. But the surface area a frontend would actually need to talk to — repos, pipeline state, chat — wasn't there yet.

That's what this phase closes out.

Part 1 — Finishing the Backend

The Neon Detour

Small but real lesson here: I'd been running Postgres locally in Docker, forgot the password mid-project (it happens), and instead of fighting a container password reset for the fourth time, I just switched dev to Neon.

# before — local docker, constant password drama
DATABASE_URL=postgresql+asyncpg://postgres:???@localhost:5432/devdocai

# after — one connection string, zero local state to babysit
DATABASE_URL=postgresql+asyncpg://neondb_owner:***@ep-xxxx.neon.tech/neondb?ssl=require

Two gotchas worth flagging for anyone hitting the same wall:

Neon gives you postgresql:// — you have to manually add +asyncpg for SQLAlchemy's async engine
Neon's copied connection string uses sslmode=require&channel_binding=require, but asyncpg only understands ssl=require. Drop the rest or the connection just silently fails.

Once that was sorted, all four tables (users, repositories, documents, pipeline_runs) created cleanly against Neon and stayed that way.

Three Endpoints That Were Missing

The pipeline could run end-to-end via webhook, but nothing existed to let a frontend see into it. So I added:

GET /repos + POST /repos/connect
Lets a user list their connected repos and register a new one against their account. Standard repository-pattern CRUD — route stays thin, RepoService holds the logic, RepoRepository owns the queries.

GET /pipeline/{thread_id}/state
This one's the interesting one. It doesn't touch a custom table — it reads straight from the LangGraph PostgreSQL checkpointer:

snapshot = await doc_graph.aget_state(config)
values = snapshot.values

Whatever state the graph paused at — mid-parse, mid-generation, sitting at human_review — this endpoint reflects it live. No separate "sync the graph state to a table" step needed. The checkpointer already is the source of truth.

POST /pipeline/review
The HITL resume endpoint. A dev approves or rejects on the frontend, this calls resume_pipeline(), and the paused graph continues exactly where it left off — either to doc_publisher or back to doc_generator with their notes as feedback.

POST /chat/ask
Runs the onboarding chatbot graph as a one-shot call. Each question gets its own thread_id — no need to persist a running conversation for a simple Q&A endpoint like this.

Backend endpoint count now:

POST  /auth/register
POST  /auth/login
GET   /auth/github
POST  /auth/github/callback
GET   /auth/me
POST  /webhooks/github
GET   /repos
POST  /repos/connect
GET   /pipeline/{thread_id}/state
POST  /pipeline/review
POST  /chat/ask

Part 2 — Laying Down the Frontend

This is genuinely new ground for the series — first time anything visual exists.

The Stack

Next.js 15, TypeScript, Tailwind, App Router, src/ directory. Nothing exotic — I wanted the frontend boring and the backend interesting, not the other way around.

The Design Direction

Instead of defaulting to "dark theme, blue accent, done," I tied the visual language to the actual product: an ink background (#0b0e14), and three accent colors mapped directly to what the pipeline stages mean —

Teal — parsing / published states
Violet — generation / enrichment (the LLM-heavy steps)
Amber — the human checkpoint

Typography: Space Grotesk for headings, Inter for body, JetBrains Mono for anything code- or pipeline-related.

The signature piece on the landing page is a small animated component — PipelineStrip — that cycles through the five actual agent names (codebase_parser → doc_generator → brave_researcher → human_review → doc_publisher) with the dot lighting up amber right at human_review. It's not a generic hero animation; it's literally the product's own pipeline, visualized.

Pages Built

frontend/src/
├── app/
│   ├── page.tsx          ← landing, with the pipeline strip
│   ├── login/page.tsx    ← email/password + GitHub OAuth
│   ├── signup/page.tsx   ← same, register flow
│   ├── dashboard/page.tsx← connected repos, status dots
│   ├── review/page.tsx   ← HITL approve/reject panel
│   └── chat/page.tsx     ← onboarding chatbot UI
├── components/
│   ├── Navbar.tsx
│   └── PipelineStrip.tsx
└── lib/
    └── api.ts            ← typed fetch wrapper for the FastAPI backend

Login and signup are fully wired — they hit /auth/register, /auth/login, /auth/github for real and store the JWT. Dashboard, review, and chat are built against the real API client too, but since repo-connect and pipeline flows need an actual end-to-end run to populate them, they're currently rendering against sample data with clearly marked TODOs pointing at the exact endpoint each one needs.

A Tailwind v4 Gotcha

Quick note because it cost some time: newer create-next-app scaffolds ship Tailwind v4 by default, which no longer uses @tailwind base/components/utilities. It's:

@import "tailwindcss";

If your custom colors suddenly stop applying and everything renders as unstyled HTML, check your Tailwind major version before anything else.

What's Actually Left

Being straight about the gap, not just declaring victory:

Backend — two small pieces

GET /github/repos — right now /repos only lists repos already connected in our DB. There's no endpoint yet to browse the user's actual GitHub repos to connect one for the first time.
A manual pipeline trigger (POST /repos/{id}/run) — right now the pipeline only starts from a PR-merge webhook. For a "connect repo → see docs immediately" first-run experience, a manual trigger is needed.

Frontend — the integration pass

Wiring dashboard/review/chat off sample data and onto the real endpoints above
Handling the GitHub OAuth redirect callback page
Loading and empty states for a pipeline that's actually running

Phase 7 — untouched
Docker, ECR, ECS Fargate, GitHub Actions CI/CD. Still ahead.

What I'm Taking From the Break

Momentum matters, but it's not the whole story. The month off didn't erase the project — the code was exactly as I left it, the architecture still made sense coming back to it cold, and picking it back up took an afternoon, not a rebuild.

That's the actual payoff of the layered architecture and the checkpointed graph state I set up back in Part 1 and Part 3: things I built for "production correctness" turned out to also be what made a month-long gap survivable. Clean boundaries don't just help other engineers — they help future-you.

If you're mid-break on something right now: the code will still make sense when you get back. Go take care of what you need to.

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 — with real gaps, and real comebacks.

Tags: python nextjs ai langgraph fastapi typescript opensource webdev

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

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

DEV Community: Nevin-Bali100

Building DevDocAI — A Production Multi-Agent LangGraph System | Part 6 — The Full Loop Works. Now: Deployment...

The Milestone

The Debugging Gauntlet

1. The checkpointer connection kept dying

2. aupdate_state, not update_state

3. Cohere → HuggingFace, mid-project

4. Qdrant Cloud wants an explicit index

5. Brave Search killed its free tier mid-build

Why None of This Broke the Architecture

Also Fixed This Round

Where Things Stand

What's Next — Part 7

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

🚨 The Problem:

✨ What It Does

🤖 Agent Pipeline

Building DevDocAI — A Production Multi-Agent LangGraph System | Part 5 - Backend Closed Out, GitHub OAuth Working End-to-End

Quick Update

Backend — The Final Two Endpoints

GitHub OAuth — Where It Actually Broke

Seeing It Work

Where Things Stand

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

🚨 The Problem:

✨ What It Does

🤖 Agent Pipeline

Building DevDocAI — A Production Multi-Agent LangGraph System | Part 4 — Coming Back, Closing Out the Backend, and Laying Down the Frontend

Where I Disappeared To

Recap — Where Things Stood

Part 1 — Finishing the Backend

The Neon Detour

Three Endpoints That Were Missing

Part 2 — Laying Down the Frontend

The Stack

The Design Direction

Pages Built

A Tailwind v4 Gotcha

What's Actually Left

What I'm Taking From the Break

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

🚨 The Problem:

✨ What It Does

🤖 Agent Pipeline

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

Real Talk First

Recap

What Phase 5 Adds

GitHub Webhooks — How It Works

The Webhook Handler

Redis Caching — Why It Matters

What the Full System Looks Like Now

The Endpoints Now

Building During Exams — What I Learned

Key Technical Learnings from Phase 5

What's Next — Part 4

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

🚨 The Problem:

✨ What It Does

🤖 Agent Pipeline

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

Recap

What We Built in This Phase

Phase 3 — LangGraph Core

Phase 4 — Agents & RAG

The Updated Workflow

Phase 3 — LangGraph Core

State Management

2. `aupdate_state`, not `update_state`