Hands-On Testing of Cursor's Thermonuclear Code Review Skill: Can It Stop AI Code Degradation?

Introduction: AI Agents Are Quietly Degrading Your Codebase

As AI coding agents flood into everyday development workflows, a subtle yet thorny problem is emerging: the code agents produce tends to "just work," but it makes codebases increasingly bloated, chaotic, and unmaintainable over time. Automated code review is increasingly seen by senior engineers as a critical line of defense against this "code degradation."

AI coding agents refer to AI systems capable of autonomously understanding requirements, writing code, and performing debugging. Prominent examples include Cursor, GitHub Copilot Workspace, and Claude Code. Unlike traditional code completion tools, agents possess multi-step reasoning and autonomous decision-making capabilities, handling the complete workflow from requirement comprehension to code submission. However, driven by the objective function of "making code run," agents tend to take the shortest path — adding conditional branches instead of refactoring architecture, copy-pasting instead of abstracting for reuse, using loose types instead of precise constraints. This tendency has minimal impact in a single interaction, but after hundreds of iterations, it causes the codebase's entropy to continuously rise. The industry calls this phenomenon "code degradation" or "AI code rot."

This article is based on a hardcore hands-on test by a Bilibili content creator of the "Thermonuclear Code Quality Review" skill open-sourced by the Cursor team. The author maintains an open-source software factory project called Sentasol and has long been refining their own review skills, making this evaluation both a teardown of Cursor's official skill and a professional comparison of experiences.

The Core Design Philosophy of Cursor's Thermonuclear Review Skill

This skill is essentially just a SKILL.md file, yet it embodies a very clear review philosophy. Cursor is an AI-enhanced code editor built on VS Code, and its skill system allows users to define structured instruction sets through Markdown files that guide AI agents to execute tasks according to specific workflows and standards. SKILL.md is essentially a carefully designed system prompt, but it's more organized than a typical prompt — usually containing modules for role definition, execution steps, hard constraints, and output formats. This design philosophy stems from best practices in Prompt Engineering: decomposing complex tasks into checkable sub-steps and narrowing the AI's output space through explicit constraints. The Cursor team named this review skill "Thermonuclear," implying its review intensity far exceeds conventional lint tools, aiming for a "nuclear-grade" deep scan of code quality.

Its baseline requirement is: Perform a deep code quality audit on changes in the current branch, rethink how to structure the implementation to meaningfully improve code quality without changing behavior.

One notable detail is its emphasis on the reviewer's "ambition" — it repeatedly demands that the agent be bold, extremely thorough, and rigorous, searching throughout the review process for so-called "code judo" moves — clever refactors that can dramatically simplify implementations.

The "Code Judo" metaphor borrows from the core philosophy of the martial art: "maximum effect with minimum effort." In a software engineering context, it refers to refactoring techniques that achieve dramatic simplification through clever structural reorganization or abstraction extraction with minimal code changes. For example: replacing repetitive logic scattered across a dozen locations with a single higher-order function, eliminating deeply nested conditional branches with the Strategy pattern, or linearizing an O(n²) processing flow by introducing an intermediate data structure. The key characteristic of these refactors is extremely high "leverage" — small changes with large impact, often simultaneously improving readability, testability, and performance. Ordinary code reviews tend to focus on local style and convention issues, while code judo requires the reviewer to have a global architectural perspective — precisely the capability AI agents aren't good at by default but can be guided toward through carefully crafted prompts.

The author hit the nail on the head regarding the insight behind this design:

For review skills like these, agents tend not to be bold enough. If you give an agent a diff, it usually treats that diff as the working boundary.

The thermonuclear skill's prompt deliberately breaks through this boundary — it requires the agent to start from changes on the current branch but look for improvement opportunities across the entire codebase. This is precisely what sets it apart from ordinary code review tools.

Several "Non-Negotiable" Hard Standards

The skill sets a series of hard constraints, many of which align with the author's own practices:

• File line count red line: Don't let a PR push a file from under 1K lines to over 1K lines unless there's a compelling reason. The author explained the underlying mechanism — large files are extremely unfriendly to AI agents because they need to load the entire file into the context window just to locate useful content. The context window is a core architectural constraint of large language models, referring to the maximum number of tokens the model can "see" simultaneously during a single inference. Although modern models have expanded their windows to 128K or even 200K tokens, research shows that LLMs suffer from significant "Lost in the Middle" problems — when context is too long, the model's retrieval accuracy for information in the middle of the input drops dramatically. After splitting large files into semantically cohesive smaller files, filenames and directory structures themselves become "free" semantic indexes, allowing agents to quickly locate relevant modules by filename without loading all the content. The author's own experience threshold is splitting at 5K tokens, and 1,000 lines roughly corresponds to a similar standard.

• Against gratuitous nesting: If a change adds a strange if-statement at a random location, it should be treated as a design issue rather than a style issue, with a preference for pushing logic into dedicated abstractions (such as state strategy objects or independent modules).

• Preference for boring, maintainable code: Favor straightforward, plain but maintainable code over flashy implementations. The author noted this is almost directly borrowed from Claude Code's classic philosophy.

Type Boundaries and Code Reuse: Hitting AI-Generated Code's Pain Points

The skill sets strict requirements for TypeScript type quality: questioning unnecessary optional, unknown, any, and excessive type assertions. TypeScript's type system is the mainstream approach for implementing static type checking in the JavaScript ecosystem, with its core value being "Make Illegal States Unrepresentable" — using precise type definitions to eliminate runtime error possibilities at compile time. When an AI agent marks what should be a required property as optional, it's actually introducing unnecessary uncertainty into the type signature: every downstream location using that property must additionally handle the "doesn't exist" case, generating large amounts of defensive null-check code. Even more insidiously, this masks real data flow errors — if a property genuinely shouldn't be null in a specific path, the optional annotation prevents the compiler from catching omissions. Similarly, the any type completely bypasses type checking, unknown is safer but still loses concrete type information, and frequent type assertions amount to telling the compiler "I know better than you," undermining the type system's protective capabilities.

The author deeply resonated with this:

Every time an agent adds a prop to a React component, it sets it as optional — I don't know why… Even when it should be required, it makes it optional to maintain backward compatibility or reduce the blast radius of changes.

"Unnecessary optionality" is a quintessential chronic issue of AI-generated code — agents sacrifice type expressiveness for "safety."

The skill also emphasizes putting logic at the canonical layer, preferring to reuse existing utility functions in the codebase rather than one-off solutions that reinvent the wheel.

Additionally, it treats "unnecessary serial orchestration" as a design issue — if independent tasks are serialized for no reason, consider whether they can be parallelized. The author considers this fundamentally a performance issue but also cautions against going to the extreme of over-micro-optimization.

Highlights and Shortcomings: An Imperfect Prompt

The author gave a clearly mixed evaluation of this skill.

The favorite part was the core review question: "Is there a code judo move that could dramatically simplify this?" along with the requirement for the agent to explicitly state "whether this improves or worsens the local architecture." He emphasized:

You must explicitly define the criteria for good and bad so the agent can understand what "improving" or "worsening architecture" means.

This is precisely the key to enabling the agent to truly discuss code quality rather than mechanically checking it.

The main criticism was redundancy and loss of focus. The author repeatedly pointed out that the skill contains substantial duplicate content — repeatedly emphasizing "be ambitious," "split large files," "clarify type boundaries" — which could be significantly streamlined. His concern:

What worries me about these large review prompts is that the agent has to process a lot of messy instructions, and it's hard to know what to prioritize.

An even more notable structural gap: the entire skill focuses almost exclusively on source code itself, with no mention of tests whatsoever, nor any discussion of how to improve feedback loops for better subsequent runs. The author believes that the true purpose of an excellent codebase is being easy to modify, modular, and easy to navigate — and testing is an indispensable part of that.

Test Results: 3/4 Hit Rate, Manageable False Positives

The author used this skill to review the five most recently merged PRs into Sentasol's main branch, with quite impressive results:

• Discovered that an initialization service had bloated into a file exceeding 1,000 lines, mixing multiple responsibilities, and provided a reasonable splitting plan;
• Proposed an abstraction layer suggestion, using a generic registration function to eliminate about 20 lines of repetitive boilerplate;
• Identified custom tracking logic scattered across three layers using if-statements, suggesting the use of a discriminated union to push variants into the type itself. Discriminated unions are a powerful type modeling pattern in TypeScript. The core idea is organizing multiple type variants together through a common "discriminant property," allowing the compiler to automatically narrow types in branch statements. For example, defining a union type like {type: 'click', x: number, y: number} | {type: 'scroll', offset: number} — each variant contains only the fields it needs (no excess optionals), the compiler reports errors at all unhandled branches when adding new variants (exhaustive checking), and the code's self-documenting quality dramatically improves. In this scenario, tracking logic scattered across multiple layers of if-statements was suggested for refactoring with discriminated unions, essentially "lifting" runtime conditional branches to the type level and letting the type system guarantee that every variant is handled correctly;
• Caught silently swallowed errors (synchronous errors caught and returned without handling);
• Found byte-identical duplicate prompts (though the author disagreed with this finding, arguing that prompts should be independently modifiable).

The author agreed with most suggestions, with a hit rate roughly between two-thirds and three-quarters.

Regarding false positives, the author took a very pragmatic stance:

Making reviews very ambitious introduces more false positives, but those false positives are easy to simply reject. What's truly dangerous are the improvement opportunities you miss — the ones you never even see.

In other words, it's better to have an overly aggressive review that produces rejectable false positives than a conservative one that misses critical architectural improvement opportunities. This is a highly instructive trade-off judgment.

In its final conclusion, the skill even provided explicit approve/reject recommendations — noting that several PRs should not be merged in their current form because "the behavior of the three substantial PRs is all correct, but the codebase is much messier than it was a week ago."

Conclusion: Worth Trying, but Needs Streamlining and Strengthening

The author's final verdict: This skill is worth experimenting with, but it's not a perfect plug-and-play solution. If he were to improve it, he'd do three things:

1. Aggressively deduplicate, making the prompt more concise and focused to reduce the agent's instruction burden;
2. Strengthen the testing dimension, making the review address feedback loops rather than focusing solely on source code;
3. Emphasize "seams" in the codebase, enhancing review depth from an architectural extensibility perspective. The concept of "seams" was introduced by Michael Feathers in his classic book Working Effectively with Legacy Code, referring to places in code where you can change behavior without modifying the code itself — natural substitution points in a program. Common seam types include object seams (replacing implementations via dependency injection), preprocessing seams (switching behavior via build configuration), and link seams (replacing dependencies via module loading mechanisms). The presence of seams directly determines a codebase's testability and extensibility — if a piece of logic has no seams, you can't unit test it without running all its dependencies, nor can you replace any of its components without large-scale modifications. Emphasizing seams essentially requires the reviewer to evaluate architectural quality from the perspective of "how will this code be modified, extended, and tested in the future."

For teams whose codebases are being progressively rewritten by AI agents, the core message from this hands-on test is clear: Automated code review is indeed one of the most effective means of combating code degradation, and its success or failure depends on whether you dare to let the agent be "ambitious."