AI-SLOP Detector has changed substantially since v3.8.1, but the most important improvements are not simply more checks.
The detector became better at distinguishing structural risk from legitimate code, better at explaining what it found, better at showing what it did not analyze, and harder for either a human or an agent to over-interpret.
That is the main story of v3.8.9.
The release does not replace the structural score. It puts more evidence around it.
A project result can now tell you not only that its weighted deficit status is clean, but also whether independent findings remain, how much of the source tree was actually analyzed, which supported files were excluded, which source types were unsupported, and whether the optional ML scorer actually participated in the run.
That makes a clean result more useful because its boundary is visible.
Release boundary: This article separates the tagged v3.8.9 release, published August 22, 2026, from follow-up work on
main. Anything explicitly marked Unreleased is not presented as part of v3.8.9.
What we actually improved since v3.8.1
When I wrote about v3.8.1, AI-SLOP Detector had started moving beyond detection into operational review.
Cleanup candidates gained confidence, action classes and evidence. Dependency manifests became part of unused-dependency analysis. Architecture review could opt into layered rules without mixing those rules into the scoring model.
The releases that followed concentrated less on adding surface area and more on making those capabilities dependable.
Adaptive initialization became preview-first, separating repository-specific suggestions from the decision to apply them.
The Node package became a typed transport over the Python analyzer rather than a second implementation, reducing the risk of separate interfaces drifting into separate scoring systems.
Human reports gained plain-language metric interpretation and deterministic Next Steps. Machine-readable output gained richer guidance for JSON, MCP and agent consumers.
Cleanup semantics also became stricter. A high-deficit file is no longer sufficient evidence to label something dead code. Duplicate analysis distinguishes exact duplicates from near-identical clone clusters. Manifest analysis became more careful about standard-library imports, development dependencies, monorepo package roots and dependency/import aliases.
The editor integration was tightened too. Refresh now performs a real workspace re-scan rather than merely repainting cached state. Removed or renamed files no longer linger in the sidebar, findings open the exact path rather than matching only a basename, and Quick Fix configuration writes avoid duplicate entries.
These are not dramatic new metrics.
They are the kinds of changes that make an existing detector more dependable in everyday use.
False-positive control became an engineering feature
Using the detector across more repository shapes exposed an important problem: strictness cannot simply mean flagging more things.
v3.8.7 tightened several boundaries where legitimate code could resemble the structural patterns the detector was designed to catch.
Runtime dependency accounting was corrected around TYPE_CHECKING. Vocabulary tables stopped creating artificial jargon inflation. React and TSX structures stopped looking like callback hell merely because they contained nested braces and object literals.
Monorepo package discovery improved. Dependency/import aliases such as grpcio -> grpc and pyyaml -> yaml became recognizable. Similar property accessors stopped being grouped into clone clusters simply because their implementation shape was intentionally repetitive.
Clone grouping itself became more conservative. Instead of allowing a loose chain of pairwise similarities to form a large group, the detector now requires a stronger mutual-similarity relationship and constrains size differences.
During that false-positive reduction pass, the detector's own repository moved from eight deficit files to three, while its weighted deficit score moved from 9.3892 to 6.4186.
Those numbers are useful regression evidence for the known repository.
They are not an external accuracy benchmark.
The more important outcome is that the discovered cases became explicit regression boundaries future versions are expected to preserve.
v3.8.9 makes the scan boundary visible
The largest conceptual improvement in v3.8.9 is that a project result now carries evidence about its own scope.
Previously, an aggregate result could dominate the interpretation:
overall_status = clean
That value is still useful. It tells you that the weighted structural deficit for the analyzed result falls below the applicable project threshold.
But it answers only one question.
v3.8.9 makes several other questions first-class.
The project JSON now exposes finding_summary, scan_coverage, and ml_scoring alongside overall_status.
An illustrative result looks like this:
{
"overall_status": "clean",
"finding_summary": {
"total": 3,
"affected_files": 2,
"severity": {
"critical": 0,
"high": 1,
"medium": 2,
"low": 0
},
"score_semantics": "independent_of_weighted_deficit_status"
},
"scan_coverage": {
"analyzed": {
"total": 84,
"python": 72,
"javascript": 9,
"go": 3
},
"excluded": {
"total": 18
},
"unsupported": {
"total": 4
}
},
"ml_scoring": {
"status": "disabled"
}
}
The numbers above are illustrative. The field structure reflects the current project-result contract.
The four fields answer different questions.
-
overall_statusdescribes the measured weighted deficit. -
finding_summaryshows independent pattern findings that may still deserve review. -
scan_coveragedescribes the analysis universe: what was analyzed, what was intentionally excluded, and what source types were recognized but unsupported. -
ml_scoringtells a downstream consumer whether the optional ML capability was available, disabled or unavailable.
This gives clean a more precise meaning:
clean within the measured structural scoring boundary.
It does not silently mean zero findings, universal language coverage, successful execution of every optional capability, or semantic correctness.
That distinction is now represented in the output contract rather than left to interpretation.
-include-tests now has a narrower meaning
Scope visibility also required tightening the behavior around test inclusion.
slop-detector scan . --include-tests
does not mean “ignore every exclusion and scan everything.”
It removes the detector's built-in test-file exclusions.
User-configured ignores remain active. Dependency directories and build artifacts remain excluded.
That makes the option more predictable: expand the normal test boundary without discarding explicit repository policy or artifact exclusions.
Capability absence is now evidence
The optional ML scorer exposed a similar problem.
The deterministic scanner should continue to work even when the ML layer cannot. ML is a secondary signal, not a prerequisite for the core score.
But a missing secondary capability should not disappear silently.
v3.8.9 therefore carries ML availability into the result.
A run with no configured model can report:
ml_scoring.status = disabled
A model or dependency that exists but cannot be loaded can report:
ml_scoring.status = unavailable
with a reason attached.
That distinction matters particularly for machine consumers. An agent reading JSON no longer needs to infer whether the optional scorer actually executed simply because the main scan completed.
The deterministic path survives.
The missing capability remains visible.
Discovery is checked before acceleration is trusted
AI-SLOP Detector can optionally use a Rust helper for faster project discovery.
That optimization created another trust boundary.
If the accelerated walker and the Python discovery path disagree about which files exist, every downstream score is operating on a different input universe.
The current implementation therefore compares accelerated discovery against root-relative Python discovery. If they disagree, the detector uses the Python fallback rather than silently trusting the faster path.
This is a small architectural detail with a large consequence:
correct scoring over the wrong file set is still the wrong result.
Discovery itself belongs in the evidence chain.
Strictness without pretending certainty
AI-SLOP Detector is intentionally strict about structures that often accompany generated-code debt: placeholder implementations, suspicious repetition, disconnected dependencies, fake-complete functions and other forms of plausible-looking incompleteness.
Maximum sensitivity, however, is not the objective.
A detector that marks every repetitive structure or unusual dependency relationship as suspicious quickly becomes noise.
The current policy is therefore to treat false positives as reproducible engineering problems. Legitimate structures can become regression fixtures or strictness cases. Explicit suppressions remain visible rather than rewriting history, and cleanup confidence is treated as prioritization evidence rather than automatic permission to delete or rewrite code.
The opposite boundary matters as well.
Static structure cannot establish semantic correctness.
Code may look structurally healthy and still implement the wrong behavior. Some plausible-looking failures will remain outside the detector's observable signal space.
That is why AI-SLOP Detector is intended to complement runtime tests, conventional linters and human review rather than replace them.
Release verification scope
At the v3.8.9 release boundary:
-
Command:
python -m pytest -q -
Result:
472 passed - Scope: the repository's Python regression suite at the release commit
- This verifies: contract preservation and known regression coverage
- This does not verify: precision/recall across independent repositories, complete language coverage, or external governance validity
A separate target-repository assessment also provided regression context: the target test suite remained green during the assessment.
That evidence is useful operationally because it helps show that the assessment did not leave the reviewed target in an obvious regression state.
It is not treated as evidence of AI-SLOP Detector's precision or recall.
Passing regression tests establish something real. They should not be made to establish something they were never designed to measure.
Reproduce the v3.8.9 result contract
Reproducibility starts by pinning the release.
pip install "ai-slop-detector==3.8.9"
slop-detector scan . --json --output slop.json
Using ==3.8.9 matters here. A command such as >=3.8.9 could install a later release and would no longer reproduce the v3.8.9 execution boundary described in this article.
For a useful first inspection, look at these fields:
overall_status
finding_summary
scan_coverage
ml_scoring
They answer four different questions:
- How did the analyzed project score?
- What independent findings remain?
- What did the detector actually analyze?
- Which optional ML capability was present during the run?
That is a more useful inspection surface than a single aggregate quality number.
What v3.8.9 improves — and what it does not claim
v3.8.9 materially improves scope accounting, finding visibility, false-positive boundaries, discovery reliability and machine-readable evidence.
Those improvements are useful now.
They make the detector easier to integrate into CI and agent workflows, easier to inspect when a result looks surprising, and less likely to encourage a reviewer to treat one summary label as the complete story.
The project still does not claim that its structural score has been independently validated across external repositories.
That is a separate research question.
The current validation boundary leaves several questions open: whether geometric aggregation performs better than simpler baselines on independent repositories, whether AST-distribution signals distinguish the intended phenomenon rather than repository-specific confounds, and whether structural coherence contributes useful signal beyond simpler measurements.
Those open questions do not erase the current engineering value.
They define the difference between a deterministic structural-risk instrument that can already produce inspectable evidence and a detector whose general statistical validity has been independently established.
AI-SLOP Detector is currently the former.
What would change our mind?
A stronger external-validation claim would require evidence of a different kind.
The detector configuration and thresholds should be frozen before evaluation. Repository selection should be independent of the project. Ground-truth review should be blinded from detector output where practical. Precision and recall should be measured directly, and the detector should be compared with simpler baselines under the same conditions.
Thresholds should also be evaluated rather than treated as correct simply because they are deterministic.
If that evidence eventually supports a stronger claim, the claim can change with it.
Until then, the current boundary is intentional.
One development change remains outside v3.8.9
At publication time, main also contains an Unreleased architectural refactor that separates the Python analysis core into focused scoring, topology and project-aggregation modules while preserving the existing CLI and result contracts.
core.py remains a compatibility facade, with responsibilities moving into:
core_scoring.py
core_topology.py
core_project.py
That work addresses maintainability of the implementation, but it is not being retroactively presented as part of v3.8.9.
Release state and development state are separate.
What changed most
The v3.8.1 article argued that when code generation becomes cheap, structural trust becomes expensive.
The releases since then made that argument more concrete.
AI-SLOP Detector now has stronger cleanup semantics, tighter false-positive control, more reliable editor state, richer machine-readable output, explicit scan coverage, explicit ML capability state and a verified fallback when accelerated discovery disagrees with the canonical path.
The result is not simply a detector with more features.
It is a detector that tells you more about why its result should be read the way it is.
AI-SLOP Detector v3.8.9 does not try to turn a structural score into a universal verdict. It makes that score more useful by showing the evidence around it: what was found, what was analyzed, what was excluded, and which capabilities actually participated in the run.
That makes the detector easier to inspect, easier to integrate into automated workflows, and harder to over-interpret.
External validation remains a separate step.
The product can still provide useful structural evidence before that step is complete — as long as the boundary stays visible.
AI-SLOP Detector: v3.8.9
Stable release: August 22, 2026
Repository: flamehaven01/AI-SLOP-Detector
v3.8.9 release/tag: v3.8.9
Release changelog: CHANGELOG.md at v3.8.9
Validation boundary: docs/VALIDATION.md
