DEV Community: Manan Sharma

AI-Generated PR Review at Scale

Manan Sharma — Thu, 01 Oct 2026 03:08:53 +0000

High PR volume, but the manual reviewing speed doesn't improve

Before AI agents, a team merged maybe 5-10 PRs a day, and a senior engineer could hold "what does this touch" in their head. Now teams are seeing 3-5 times that volume. The bottleneck isn't reviewing code quality anymore — linters and type checkers handle that. The bottleneck is impact triage: which of these 40 PRs today actually touch something risky, and which are safe to fast-track? A human can't manually trace dependency graphs at that volume.

This is not a judgment problem (reviewing code), it is a computation problem — which is exactly what should be automated, not left to reviewer fatigue.

The traditional review methods - a human tracing "what does this change affect" on many PRs every day - won't work now. This is what failure mode blast radius analysis exists to remove.

How CXGRD helps

cxgrd implements auto-triage. It automatically calculates blast radius for changes done in every PR and flags them with tags like critical, high, medium and low. PRs with low risk move fast, whereas, the ones with critical or high risk are flagged for real human attention. What gets reviewed at scale is not the change, but the risk.

But this does not replace linting and type checking and actual code correctness still matter. CXGRD itself uses the compilers to verify the correctness of code.

Check out cxgrd, and let me know what you think.
Have you ever encountered a ton of PRs? I would love to know how you managed to review them.

Building a custom prompt generator for cxgrd

Manan Sharma — Wed, 23 Sep 2026 16:56:20 +0000

Hey everybody,

cxgrd currently uses AI models using API keys on free tier (yeah, I can't afford to pay for these models). And Groq doesn't support free models now. So, to avoid this problem once and for all, I decided to build a custom prompt generator for cxgrd.

So here is the plan: a pure logic based versatile engine which will

write a detailed description of the user's change.
include blast radius results: affected files, ranked by dependents or distance, with the risk level and the reason for it (e.g. "12 dependents, touches a shared util").
create constraints: conditional blocks driven by data. Examples: high risk adds "keep public exports unchanged", a schema or migration file adds "don't alter existing columns without a migration", and files with many dependents go into a "do not modify unless necessary" list, and some stop conditions like "if the change requires touching files outside the list above, stop and report."
performs verifications: which tests import the affected files, plus "run cxgrd check before finishing".

This way it's better at reliability, reproducibility, speed, and testability. It's not automatically better at interpreting intent like an AI model, because an AI model can turn a vague "make login less janky" into specific instructions, which a template can't. But this prompt's real value won't be the prose, it will be the facts which only cxgrd knows: the risk level, the affected files, what depends on what. A template can carry these metrics perfectly.

This is what I thought about this prompt engine. I would love to hear what your think about this, any form of feedback/suggestion is welcomed because I genuinely want cxgrd to grow.

Running git commands became tedious, so I built gatm

Manan Sharma — Mon, 14 Sep 2026 11:44:05 +0000

I actively make commits to cxgrd. But running the four git commands add, commit, push and branch again and again was time consuming and boring. So I built a small tool which I call gatm (Git Automation Tool by Manan).

Now I just need to run gatm in my terminal, and it runs add, commit and push by itself.

Install

npm install -g @geekgod382/gatm

I had to name it this way because npm said the name "gatm" is very similar to some other packages.

How it works

When you run gatm it will extract the untracked/modified files and run git add <the changed files>. After this, it deterministically generates a commit message (I just used git status --porcelain for this job) and run git commit -m "message". At last, it runs git push -u origin branch_name to push the commit.

If there are no modified files, it returns "nothing to commit". If push fails because of changes in remote origin, it returns "run git pull first". The extraction of untracked/modified files happens by keeping an eye on .gitignore file, to avoid node_modules or .env files from being committed.

Prerequisites

Git SHOULD BE installed and make sure git init was already ran in the project directory, and a remote origin was added.

Options

gatm supports these options:

-m "custom_commit_message" : use this option for adding a custom commit message. This will bypass the deterministic message generation.
-b "new_branch_name" : use this option for creating a new branch and commiting to it. When this option is used, gatm will run git checkout -b new_branch_name to create and switch to new branch, and then pushes to it.
-d : a dry run option. This will give you the details about changed files, commit message generated and branching and won't run any command. This option is just for your own satisfaction.

Although I build gatm for my personal use, but I decided to publish it to npm, if someone else struggles with running multiple commands, they can use it too.

GitHub : https://github.com/geekgod382/gatm

I would be very happy to hear your feedback about it.

I built Github actions workflow for cxgrd

Manan Sharma — Sat, 22 Aug 2026 17:53:24 +0000

I recently built and shipped GitHub Actions workflow for cxgrd. I built it to automate the scanning of project directory by the scan command and blast radius analysis by the check command, on every PR created.

What it does

When ever a PR is created,

The project dependencies and cxgrd are installed
The project is scanned with cxgrd scan
check command is used to run blast radius analysis and compiler checks
The results (risk level, affected files, changed types ) are posted as a comment to the PR.

The comment is updated on every subsequent run, instead of posting a new comment.

How I built this

The check command already had BlastRadiusAnalyzer being used for posting CI check results to DB and team dashboard. The only thing was to create a --json flag to extract the result in json format and post it as a comment.
The thing I found interesting was, I didn't have to use auth for posting the comment. While I was designing the flow, I came across something new: GITHUB_TOKEN, which Actions inject into every PR, and is scoped to the specific repo, with permissions to comment. So, I just needed to write a small JS script, something like this:

permissions:
  pull-requests: write

steps:
  - uses: actions/checkout@v4
  - run: cxgrd check --json > result.json
  - uses: actions/github-script@v7
    with:
      script: |
        const fs = require('fs');
        const result = JSON.parse(fs.readFileSync('result.json'));
        await github.rest.issues.createComment({
          owner: context.repo.owner,
          repo: context.repo.repo,
          issue_number: context.issue.number, // PR number, auto-available
          body: `## CXGRD Blast Radius\n\nRisk: ${result.risk}\n...`
        });

inside the .yml file.

Why I built this

I thought, the reason behind low adoption of cxgrd is that the users have to run CLI commands on their own. So I wrapped the core feature inside a CI workflow file.

Maybe this will help cxgrd grow.

Checkout the GitHub Action here.

I am open to any feedback which will help me and my tool grow.

How cxgrd differs from AI agent-based code review tools

Manan Sharma — Sat, 15 Aug 2026 09:33:23 +0000

In my previous post, I introduced the CLI tool CXGRD which I built to prevent agents from breaking architecture.

CXGRD computes blast radius using dependency graph traversal — a deterministic analysis of real import, call, and reference relationships in your codebase. This post explains what that means and how it differs from AI agent-based code review tools.

The core difference

AI agents (like an LLM-based code review tool) reads a diff and predicts what might be affected, based on pattern matching over the code it's shown. The output is a judgment — probabilistic, and it can miss relationships that aren't visible in the diff it was given, or hallucinate connections that don't exist.

CXGRD instead builds an explicit graph of your codebase's real dependencies — which files import which, which functions call which — and traces a change through that graph mechanically. A dependency edge either exists in the graph or it doesn't. There's no inference step where an edge could be missed or invented.

Why this matters in practice

	AI agent interpretation	CXGRD dependency graph
Basis	Model's reading of the diff	Actual import/call relationships
Consistency	Can vary between runs on the same input	Same input always produces the same result
Failure mode	Can miss or hallucinate a relationship	Can only miss relationships the graph itself doesn't model (e.g. dynamic imports)
Explainability	"The model flagged this as risky"	"File X imports function Y, which changed" — a traceable path

Where AI still adds value

CXGRD isn't anti-AI — Pro and Team tiers use an LLM (Groq) for prompt enrichment: turning a computed blast radius into a clear, readable prompt for feeding into an AI coding assistant's context window. The graph traversal that determines what is affected stays deterministic; the LLM's job is limited to explaining that result in natural language, not deciding it.

This is where CXGRD complements tools like Cursor or Claude Code rather than competing with them: those tools govern the actions an AI agent takes while writing code, while CXGRD governs the consequences of a change once it exists — checking blast radius before merge, regardless of whether the code was written by a human or an AI assistant.

See how CXGRD works here.

Why AI Coding Agents Fail on Large Repos: The Stateless Context Problem

Manan Sharma — Fri, 10 Jul 2026 11:52:24 +0000

Let's be honest - stateless AI tools are incredibly powerful, but they have terrible short term memory, and are context-limited. They look at your repo through a keyhole — whatever's visible in that one session is all they know.

You've probably seen your AI tool trying to fix one thing and break several others. This happens because they don't know what else in your codebase depends on that particular module it is editing.

Modern codebases are deeply interconnected, and as repos grow, it gets harder for AI agents to track every dependency, architectural layer, and downstream effect.

I ran into this constantly while building a PR reviewer tool. Every time I asked AI to fix one thing or add a feature, it would quietly break something else. I wondered if it was possible to provide a complete dependency map to the entire codebase which can tell AI something like, "Hey, you just changed what this method returns, but you forgot about these 3 modules importing it".

To fix this problem, I built a CLI which I call CXGRD . It maps your code, builds dependency graphs, calculates blast radius and provides enriched prompts for AI tools, while at the same time verifying the changes made by performing compiler-backed checks. It's free to try — npm install -g cxgrd and run cxgrd scan on any repo.

Would genuinely love feedback from anyone who's hit the same "fix one thing, break three" problem.

GitHub : https://github.com/cxgrd