Asking GitHub Copilot in Visual Studio 2026 for a plain "do a code review" gives you polite, inflated feedback that misses the biggest problems — especially architecture. The fix is to feed Copilot your own conventions, a solution-structure template, and a weighted scorecard as a markdown file. With that scaffolding, Copilot delivered a brutally honest review of a 2013 codebase (roughly 15/100: no architecture, static classes everywhere, no tests) and recommended a full rewrite rather than patching. The catch: AI is non-deterministic, so the same scorecard can produce meaningfully different results run to run.
The simplest option is to just tell Copilot to do a code review, and it will usually surface some useful insights — the author used exactly this approach in an earlier video in the series, where he also asked Copilot to explain a codebase he hadn't touched in over ten years. But an unguided review has two structural weaknesses. First, AI tends to miss critical issues, especially architectural ones. Second, Copilot has no idea about your team's conventions or specialized standards, and by default it tries to stay extremely positive and avoid being harsh.
That politeness is deliberate. The author contrasts it with human reviews, which can get political — some people take feedback personally or read a review as an office agenda or even constructive dismissal. AI sidesteps that drama, but the trade-off is an inflated, neutral report that is often too optimistic.
The demo target is an application the author wrote back in 2013. It's functional but riddled with fundamental flaws. The initial simple Copilot review isn't comprehensive enough: it fails to flag the missing architecture — the most important problem — while other obvious issues also go under-weighted. Most of the classes are static, many do nothing but pass control straight through to a data access layer (acting as little more than proxies), the data access and domain logic are mixed into the same project, and there are no proper tests.
To get a rigorous review grounded in real-world engineering standards, the author supplies Copilot with his own conventions and a scorecard he built a few years ago. The scorecard assigns different weights to different areas of development — pure coding (syntax, readability, structure) might cap at 15%, while testing might carry around 20%. For this particular project, security isn't a major factor and is excluded from the final score. Combined with a separate template describing how a solution should be organized, this becomes a custom code-review guideline, and for every review in the video Copilot is given the scorecard as a markdown file.
Run against the scorecard, the old solution is a clear fail — roughly 15 out of 100. Architecture is non-existent, code quality is extremely low, and there are no tests. Copilot's recommendation is not to attempt a fix, because the technical debt is too severe; instead, rewrite the application on a modern architecture and treat the old codebase purely as a reference. The author highlights the "honest assessment" section as the standout: rather than the usual positive spin, the review is straightforward and calls the codebase technically bankrupt. He contrasts this with the old open-ended review, which had described the same app as "a well structured simulation system" with clear domain modeling and separation of concerns.
After a rewrite that still took a couple of days with Copilot doing most of the coding, the new solution has a decent, familiar project layout. It's a simple lottery simulation that picks numbers from historical results and reports net profit and loss (the odds, of course, point to a loss). Running the same scorecard against the new code exposed a key wrinkle: this time Copilot returned a plain grade of "C" instead of a score out of 100. Because AI isn't deterministic — it reasons rather than executing hard-coded logic — the author had to re-prompt to get output in the correct format, which then produced a detailed review. Some weight assignments came out unrealistic (error handling weighted above data access in what is mostly a CRUD app), but the review showed a massive improvement, with refactoring recommendations and an estimated effort of about three and a half weeks.
The closing lesson is that a genuinely detailed AI code review requires clear guidelines, a structured template, and a weighted scorecard reflecting what matters for each section. Even then, strict instructions won't guarantee consistency: because the model is designed to think, running the same review multiple times with the same scorecard can produce responses that vary significantly. Copilot works as a useful independent reviewer, but it needs your standards baked in and its output treated as reasoned opinion, not deterministic scoring.
"and AI is usually going to miss some critical issues especially when it comes to architecture."
"Normally AI is programmed to put a positive spin on everything. But here the review is brutally helpful, straightforward. The code base is just technically bankrupt."
"But even with strict instructions, AI may still deviate every now and then because it's designed to think."
"If you were to give it the same prompt multiple times, it's not going to necessarily give the exactly the same result."
| Approx. Time | Topic |
|---|---|
| 0:00 | Intro — code review with Copilot in Visual Studio 2026 |
| 0:40 | The simple "just do a code review" prompt and its limits |
| 1:30 | Why unguided AI reviews stay too positive |
| 2:30 | Human reviews, politics, and AI's neutrality |
| 3:20 | Looking at the flawed 2013 original application |
| 4:30 | Building a weighted scorecard and convention template |
| 6:00 | The brutally honest scorecard review (~15/100) |
| 7:20 | Comparing against the old optimistic open-ended review |
| 8:00 | Reviewing the rewrite and the "C" grade |
| 9:00 | Non-determinism and final takeaways |