When accepting custom-developed business systems, the primary checkpoint is usually "does it work according to specifications?" You open screens, enter data, confirm that expected results return, and stamp the acceptance certificate. This method definitively verifies functionality.
What it cannot determine is whether that code will still be maintainable two years from now. Even for code delivering the identical screen and identical behavior, one codebase might take a single day to modify during the next enhancement, while another takes a full week just to decipher. And clients currently lack the means to see that difference.
This gap is widening rapidly today. With AI code generation, the sheer volume of written code has expanded. Having working code produced quickly is fundamentally a good thing, yet review speeds do not scale at the same pace. As a consequence, the proportion of unread code climbs.
What GitHub Code Quality attempts to measure
On July 20, 2026, GitHub Code Quality reached general availability (GA) for GitHub Enterprise Cloud and GitHub Team. GitHub announced that over 10,000 organizations had utilized it during the public preview phase.
What it does is essentially combine two major components:
- Deterministic analysis via CodeQL — Analyzes code at the syntax and control flow levels. The same code consistently yields identical results.
- AI-driven maintainability and reliability issue detection — Flags issues like "unreadability" and "fragility" that deterministic analysis struggles to catch.
Building on this, Copilot Autofix suggests remediation directly on pull requests. What was added in GA includes organization-level enablement, dashboards for maintainability and reliability scores alongside test coverage, and quality gates powered by rulesets. This last item—quality gates—is what holds real significance for clients. It makes it possible to block the merging of pull requests that fail to satisfy required standards.
Pricing is $10 per active committer per month on enabled repositories. In addition, AI-powered features (Copilot code review, AI-assisted detection, Copilot Autofix) incur usage-based billing, while deterministic CodeQL analysis consumes GitHub Actions runner minutes. Because fixed and variable costs are blended, calculating estimates purely by headcount will fall short.
What happens when you write "score of 8 or higher" into a contract
Here is the crux of the matter. If maintainability scores are output numerically, it is natural to think, "Why not make that an acceptance criterion?" Indeed, contracts written this way are increasing.
However, the moment you make a metric a contractual condition, effort will be expended simply to inflate that metric. And raising a maintainability score involves far more than just "rewriting code to be more maintainable."
- Adding configuration settings that exclude sections with frequent warnings from analysis
- Mechanically splitting long functions based on line counts rather than meaningful domain units
- Shifting coding style to avoid warnings (without actually improving readability)
None of these violate the contract, because they satisfy the formal condition. And because the client is only looking at whether the score exceeds the baseline, they cannot detect this manipulation.
This is not about custom development vendors acting in bad faith; it is the universal phenomenon that when a measurement metric becomes a target condition, that metric becomes the object of optimization. What occurred previously with test coverage is repeating with maintainability scores. Requiring 80% test coverage invariably leads to tests devoid of assertions—a road many development teams have walked before.
Base criteria on process rather than numbers
How, then, should acceptance criteria be written? What clients should specify is not an outcome metric, but that the detection and review mechanism is actively operating.
Specifically, it takes the following form:
- Analysis must be enabled, and a complete list of settings excluding files from analysis must be submitted. The key is requiring the exclusion list. Even if a score looks strong, it is meaningless if the scope was narrowed.
- Detected warnings must be categorized as resolved, intentionally accepted, or non-actionable, with documented rationale for any accepted items. Do not demand zero warnings. Having explanations attached to remaining warnings is far more trustworthy than a clean sheet of zero warnings.
- Quality gates must be configured, with criteria disclosed at the time of project handover. When the next company takes over, they can maintain the exact same standard.
Adopting this structure eliminates the incentive for development partners to game the numbers. Because being able to explain the rationale is the requirement, rewriting code artificially offers no advantage.
Separately, you must determine how seriously to take AI-generated findings. Unlike deterministic analysis, AI-assisted detections can vary even on identical code. If you make this subject to "fixing every single item every time," you will generate never-ending work. It is realistic to treat them on the premise of human judgment. Review operations themselves are covered in Two types of comments that actually work in code reviews, while review structures for AI-generated code are discussed in Claude Code security plugins and reviewing AI-generated code.
Do not misjudge the timing of adoption
From a practical standpoint, introducing this tool retroactively into a large existing codebase will trigger a massive flood of warnings on the initial run. Faced with a list of thousands of warnings, teams will almost certainly begin ignoring them. Once notifications are categorized as "things to ignore," future critical warnings will be skipped no matter how important they are.
A pragmatic rollout strategy is to target only newly authored diffs. Log findings from existing code for reference, while applying quality gates strictly to new changes. Existing sections can then be addressed progressively whenever modifications occur.
Decision frameworks for determining how much legacy code to refactor are discussed in Refactoring decisions and technical debt in the AI era. Furthermore, the gap between tests merely "passing" and tests being "meaningful" is addressed more directly in Measuring test quality of deliverables using mutation testing. Once coverage becomes visible on a dashboard, this discrepancy surfaces as a pressing issue.
What to do next
If you are currently commissioning a project, try asking your development team to "please share the list of exclusion settings" for work currently underway. That single request will reveal whether analysis is active and, if so, what has been left out of scope.
For upcoming development engagements, the stage where acceptance criteria are drafted represents the critical turning point. You may feel tempted to write numeric targets, but these three requirements—enabling analysis, documenting reasons for remaining warnings, and disclosing gate criteria at handover—are far more effective than numbers. Adding just one line to your contract now pays significant dividends later.
If you would like to consult on structuring development acceptance criteria or evaluating the handover readiness of existing systems, we assist through GleamHub's Development, AI, and Automation Consultation. Practical approaches depend on codebase size and team structure, so please consult with us individually. Reach out via Contact Us.
Sources
- GitHub Code Quality is now generally available — GitHub Changelog
- GitHub Code Quality generally available July 20, 2026 — GitHub Changelog
- GitHub Code Quality Targets Maintainability as AI-Generated Code Increases — InfoQ
- GitHub Code Quality Moves to General Availability, Bringing New Costs and Capabilities — DevOps.com
