Turning AI Code Reviews Into Continuous Improvement: How GitHub CLI Became My Secret Weapon

Beneath the shifting layers of the code we write and keep, A quiet voice reviews the parts we overlook or bury deep. It scans the paths we rush past, where hidden problems hide, And feeds them back with clarity — an architect at our side.

With steady hands and tireless eyes, it marks what might be flawed, Not truth, but sparks of insight from a mind that’s never awed. Each finding forms a question, each question forms a way To shape the code we craft tomorrow better than today.

And when the tools we lean on fail or fade into the night, We build our own foundations, simple scripts that make things right. A loop of constant learning grows from prompts we teach with care — Continuous improvement lives in every issue filed there.

This article explores how I combined AI-driven code reviews with the stability of the GitHub CLI to build a continuous-improvement engine for my codebase. By automating the capture of AI findings as GitHub Issues — while still applying human architectural judgment — I’ve created a workflow that surfaces hidden problems, tracks technical debt in real time, and improves not just the code itself but the way I improve it. It’s a practical example of how AI can augment software development when paired with reliable tools and a well-crafted prompt.

Over the last few months, I’ve been experimenting with ways to integrate AI more deeply into my software development workflow — not just as a coding assistant, but as a system that helps me continuously improve the quality of my codebase. What I stumbled into has turned out to be surprisingly powerful: a loop where AI identifies findings, GitHub automates the tracking, and I retain full architectural judgment.

And the strange hero of this whole system turned out to be something simple and old-school: the GitHub CLI.

This is the story of how a failed MCP endpoint pushed me into building a better, more stable, and far more useful continuous-improvement pipeline.

The Problem: AI Can Review Code, But Insights Get Lost

I have a custom architectural review prompt that evaluates my code against the things I care about most as a software architect — SOLID principles, coupling, cohesion, testability, clarity, and structural design. It does a remarkably thorough job. In fact, because it’s not emotionally invested in the code, it often catches things I overlook simply because I’m too close to the problem domain.

The output is always a set of findings:

• Each with a description
• Each with a priority
• Each with an estimated amount of time to fix

Some findings are spot-on. Some are noise. Some are valid but not worth addressing right away.

But the real issue wasn’t the AI’s accuracy — it was that good insights evaporated unless I manually recorded them.

And manually transcribing findings into GitHub Issues isn’t scalable. It’s tedious, it’s error-prone, and most importantly, it means insights die on the vine.

Enter GitHub MCP… and Then Exit GitHub MCP

For a short time, GitHub’s MCP integration solved that problem. I could simply say:

“Create issues for these findings.”

It worked brilliantly — until one Friday night when the MCP endpoint went down. Suddenly, the AI couldn’t create issues anymore. At the same time, I didn’t want to rely on third-party VS Code extensions that promised similar capabilities.

But I noticed something interesting during the failure: The AI tried to fall back to the GitHub CLI. What there is a CLI?

So I installed gh, explored it, and immediately realized:

“I don’t need MCP at all. I can build my own orchestration layer using simple scripts.”

That turned out to be the best decision I’ve made in this entire experiment.

How GitHub CLI Became the Backbone of My Process

The GitHub CLI exposes everything:

• Creating issues
• Closing issues
• Listing
• Searching
• Adding labels
• Organizing work

Unlike the MCP, it’s stable, local, version-controlled, and not subject to someone else’s deployment schedule.

I wrapped the CLI with a PowerShell script and gave the AI a single instruction:

“When you generate findings, call this script. Add new findings as issues, but don’t duplicate existing ones.”

Now I have a pipeline that looks like this:

AI Review → Findings → PowerShell Script → GitHub CLI → Issues → 
Human Review → 
Improved Code → Repeat

This is more than automation. It’s architectural acceleration.

What an AI Finding Looks Like (Simple Example)

To make this concrete, here’s an example of the structured output my prompt generates:

{
  "title": "OrderService violates SRP",
  "description": "OrderService currently handles ordering, payment processing,
                  and notifications. This concentrates too many 
                  responsibilities into one module.",
  "priority": "High",
  "effort_hours": 2.0,
  "file": "src/Services/OrderService.cs",
  "labels": ["architecture", "solid", "refactor"]
}

The script then converts this into a GitHub Issue — unless a similar issue already exists (the power of LLMs).

This forces consistency and gives me a backlog I can trust.

AI Findings Are Not “Right” — They’re Signals

One thing I’ve learned through this process is that AI findings are not truth.

They’re possibilities.

I still need to review each one because architecture is nuance. For example, complexity metrics like cyclomatic complexity can be misleading. Splitting a function into three helpers may reduce the reported complexity of one function but not reduce the overall complexity of the system. Sometimes that split is still a win because it dramatically improves testability.

AI doesn’t know the context that I do.

But the benefit is that it never gets tired. It never gets attached to the code. It never forgets to look at something —

— provided you take the time to refine your prompt.

This is an important caveat.

AI can overlook things if the prompt is vague or inconsistent. But once you polish your review prompt — once you tune it so the model outputs exactly the findings you want — it becomes remarkably consistent and dependable.

The reliability of the whole system rests on that prompt:

• Clear criteria
• Stable formatting
• Consistent expectations
• Structured output

Once that foundation is set, the AI becomes a tireless reviewer who applies the same standards every time.

From Findings to Metrics: Tracking Technical Debt at Code Review Time

Because each accepted issue includes an estimated effort, I can now compute something incredibly valuable:

Technical Debt Ratio (the total hours of effort represented by accepted findings)

Instead of technical debt being a vague feeling, I get a measurable number:

• How many hours of fixes are outstanding
• Which categories (architecture, readability, testing, duplication) are most expensive
• Whether the debt is trending up or down as I refactor

This transforms technical debt from guesswork into data.

And all of this happens organically as part of normal development — not during a quarterly “cleanup sprint.”

This Is Continuous Improvement Done Right

What I love about this system is that it reinforces the essence of continuous improvement:

• I’m not just improving my code.
• I’m improving how I improve my code.

I can now:

• Run architectural reviews continuously
• Capture findings automatically
• Curate them efficiently
• Track progress over time
• Keep my backlog clean and relevant
• Build project-specific internal tools that make the AI smarter and more effective

And none of it depends on fragile integrations.

The underlying operations are rock solid because they’re built on stable primitives — gh commands and simple automation scripts orchestrated by a prompt to AI.

Where This Leads Next

This workflow gives me a foundation to expand into additional areas:

• Continuous dependency health (“software vaccination”)
• Automated architecture drift detection
• Auto-labeling and categorization
• Backlog pruning as code evolves
• AI-driven prioritization based on impact
• Cross-project architectural baselines

These tools will live inside the projects utilities directory. AI agents can use them. I can use them manually. And they help me build better software faster.

The future of software engineering isn’t AI replacing developers — it’s developers who build systems like this that amplify their insight, accelerate their workflow, and keep their codebases healthier than ever.

https://github.com/mgrandau/copilot-confirm/blob/main/utilities/create_issues.py