Jak wyłapać kod wiarygodny, ale błędny, przed merge'em

Wykrywanie slopu wyłapuje kod pisany przez agentów, który się kompiluje, przechodzi testy i dobrze wygląda, a mimo to jest błędny: połknięte wyjątki, martwe abstrakcje, osłabione testy, zduplikowane helpery i zmyślone API. Każdy wzorzec dostaje deterministyczny detektor blokujący merge oraz prompt dla agenta-recenzenta na przypadki, których detektor nie widzi, więc nikt nie musi czytać każdej linii.

Ta strona jest dla programistów, którzy wypuszczają pull requesty agentów, i dla tech leada, który odpowiada na pytanie ze scorecardu: „Jak wyłapujecie kod wiarygodny, ale błędny, przed merge’em?”. Sytuacja, którą rozwiązuje: job zwrotów od tygodnia „kończy się sukcesem” i nikt nie zauważył, że dodany przez agenta catch {} zamienił każdy nieudany zwrot w ciche false. Diff wyglądał porządnie. Testy przeszły, bo sprawdzały tylko szczęśliwą ścieżkę. Recenzent przejrzał 600 linii i zatwierdził.

Co zyskujesz dzięki wykrywaniu slopu

Katalog pięciu wzorców slopu, każdy przypisany do detektora dla TypeScriptu, Pythona i Go oraz do tego, czego ten detektor nie widzi.
Konfigurację lintów i CI przetestowaną 26 września 2026 na ówczesnych najnowszych wydaniach: ESLint 10.11.0 z typescript-eslint 8.70.1 i @vitest/eslint-plugin 1.6.27, Ruff 0.16.9, mypy 2.3.1, pyright 1.1.414, knip 6.38.0, vulture 2.16 i jscpd 5.3.2. Reguły dla Go sprawdziliśmy w kodzie źródłowym golangci-lint 2.14.0.
Skrypt audytu diffa, który na liniach dodanych przez pull request oznacza nowe wyciszenia, maskowanie błędów i pominięte testy.
Pięć promptów dla agenta-recenzenta, po jednym na wzorzec, oraz recenzenta slopu skonfigurowanego dla Claude Code, Codex i Cursora.
Fixture kanarkowy, który po każdej aktualizacji narzędzi dowodzi, że każdy detektor nadal działa.

Co jest slopem w kodzie pisanym przez agentów?

Slop to kod, którego powierzchowne sygnały są dobre, a zachowanie nie. Od zwykłego błędu odróżniają go trzy cechy:

Przechodzi sprawdzenia, które już uruchamiasz. Połknięty wyjątek sprawia, że padający test przechodzi. // @ts-expect-error ucisza type checker.
Wygląda na staranność. Interfejs z jedną implementacją wygląda na dobry projekt. try/catch wygląda na obsługę błędów. Test z toBeTruthy() wygląda na pokrycie.
Kumuluje się. Każdy zduplikowany helper i martwa warstwa pogarszają kontekst następnego agenta, bo agent kopiuje to, co znajdzie.

Dane pokazują, że efekt jest realny, ale nie mówią, jak duże jest twoje ryzyko. W SlopCodeBench (Orlanski i in., arXiv, v2 z 7 maja 2026) 15 agentów rozbudowywało własne rozwiązania w 36 problemach i 196 punktach kontrolnych: żaden agent nie rozwiązał problemu od początku do końca, najlepszy przeszedł 14,8% punktów kontrolnych, a autorzy mierzą degradację jako „structural erosion” i „verbosity”. Raport GitClear „The Maintainability Gap” (czerwiec 2026), przytaczany tu tylko z wyciągu wyszukiwarki (SECONDARY), podaje wzrost bloków catch maskujących błędy o 47% i duplikacji bloków o 81% względem 2023 roku, na 623 milionach zmian. Te liczby GitClear są wtórne i korelacyjne, nie przyczynowe. Zamiast cytować zespołowi którąkolwiek z nich, zmierz własne repozytorium detektorami opisanymi niżej.

Katalog slopu: pięć wzorców i ich detektory

Każdy wiersz ma deterministyczny detektor, który blokuje merge, i prompt dla recenzenta, który pokrywa lukę. Detektor działa na każdym pull requeście; prompt tam, gdzie detektor jest ślepy.

Wzorzec	Jak wygląda	Deterministyczny detektor	Czego detektor nie widzi
Połknięte wyjątki	`catch {}`, `catch { return null }`, `except Exception: log; return {}`, promise bez `await`	ESLint `no-empty`, `@typescript-eslint/no-floating-promises`, selektor `no-restricted-syntax` · Ruff `BLE001`, `S110`, `S112`, `E722` · golangci-lint `errcheck`	Handlera, który loguje, a potem zwraca wartość zastępczą traktowaną przez wywołującego jak sukces
Zmyślone API	Metoda, opcja albo klucz konfiguracji, które nie istnieją, wyciszone przez `as any` lub `@ts-expect-error`	`tsc --noEmit` plus `@typescript-eslint/no-unsafe-call`, `no-explicit-any`, `ban-ts-comment` · mypy `--strict` albo pyright · Ruff `PGH003`	Błędnej semantyki prawdziwego API; nietypowanych kluczy konfiguracji i zmiennych środowiskowych
Osłabianie testów	`it.skip`, test bez asercji, dokładne wartości zamienione na `toBeTruthy()`	`@vitest/eslint-plugin` (albo `eslint-plugin-jest`) `no-disabled-tests`, `no-focused-tests`, `expect-expect` · audyt wyroczni · testy mutacyjne	Asercji, która jest obecna, ale nie przypina już zachowania
Zduplikowane helpery	Trzeci `formatMoney` pod nową nazwą	jscpd z `--baseline-from-ref origin/main --fail-on-new-clones` · serwer MCP jscpd przed pisaniem	Duplikatów semantycznych o innej strukturze
Martwe abstrakcje	Fabryka, strategia albo wrapper, którego nic nie wywołuje lub który ma jedną implementację	knip `--include exports,types,files` · vulture · golangci-lint `unused`	Warstwy używanej, ale bezcelowej: jeden interfejs, jedna implementacja, jeden wywołujący

Zmyślone nazwy pakietów to szósty wzorzec i mają osobną stronę: kontrola zależności w zmianach agentów.

Wdróż bramkę slopu krok po kroku

Najpierw uruchom fixture kanarkowy. Skopiuj fixture z sekcji o weryfikacji do katalogu roboczego i sprawdź, że każdy detektor go zgłasza. Detektor, który nic nie zgłasza na fixturze, jest wyłączony, źle skonfigurowany albo ślepy na twój stack.
Dodaj detektory dla swojego stacku z sekcji o wzorcach poniżej, jako błędy, nie ostrzeżenia. Przy ostrzeżeniu agent może zgłosić zadanie jako gotowe; przy błędzie nie.
Zapisz baseline istniejących naruszeń. Uruchom raz npx --no-install eslint . --suppress-all i zacommituj eslint-suppressions.json. Nowe naruszenia oblewają bramkę; stare są zapisane, a nie wybaczone.
Chroń bramkę. Obejmij konfigurację lintera, eslint-suppressions.json, knip.json, .knip-budget, .jscpd.json i skrypt audytu plikiem CODEOWNERS oraz regułami deny agenta, jak opisuje ochrona wyroczni.
Dodaj job CI i audyt diffa z sekcji o CI i ustaw job jako wymagany check.
Daj każdemu programiście recenzenta slopu dla jego narzędzia i wymagaj jego werdyktu w pakiecie dowodów pull requesta.
Spalaj baseline. Po każdym sprzątaniu uruchom npx --no-install eslint . --prune-suppressions, żeby zapisane liczniki tylko malały.

Wykryj każdy wzorzec slopu

Poniższe konfiguracje uruchomiliśmy 26 września 2026 na repozytorium-fixturze z jednym przykładem każdego wzorca. Każdy detektor wymieniony w wynikach zadziałał na swoim przykładzie; opisane luki to te, które fixture ujawnił.

Połknięte wyjątki: catch, który zamienia porażkę w sukces

Połknięty wyjątek to najdroższy wzorzec slopu, bo program działa dalej z błędną odpowiedzią. W TypeScripcie formy mechaniczne pokrywają trzy reguły. no-restricted-syntax z selektorem AST oznacza każdy catch, który zwraca wartość bez ponownego rzucenia wyjątku, czyli formę, której no-empty nie widzi:

// eslint.config.js (ESLint 10, typescript-eslint 8)
import { defineConfig } from 'eslint/config';
import tseslint from 'typescript-eslint';

export default defineConfig({
  files: ['src/**/*.ts'],
  extends: [tseslint.configs.base],
  languageOptions: { parserOptions: { projectService: true } },
  rules: {
    'no-empty': ['error', { allowEmptyCatch: false }],
    '@typescript-eslint/no-floating-promises': 'error',
    '@typescript-eslint/no-misused-promises': 'error',
    'no-restricted-syntax': ['error', {
      selector: 'CatchClause:not(:has(ThrowStatement)) ReturnStatement',
      message: 'This catch returns a fallback instead of rethrowing. Rethrow, return a typed error result, or justify it with slop-ok.',
    }],
  },
});

Na fixturze catch (e) {} uruchomił no-empty, wywołanie refund(id) bez await w pętli uruchomiło no-floating-promises, a zarówno catch { return null; }, jak i catch (err) { console.error(err); return {}; } uruchomiły selektor. Komunikat jest napisany jako polecenie, bo agent go czyta i na jego podstawie działa.

W Pythonie wybierz reguły Ruff jawnie:

# pyproject.toml (Ruff)
[tool.ruff.lint]
extend-select = ["BLE001", "S110", "S112", "E722"]

Dwa zachowania Ruff mają znaczenie. BLE001 (ślepe except Exception) przestaje się zgłaszać, gdy handler wywołuje log.exception(...), nawet jeśli potem zwraca {}: logowanie zadowala linter, nie wywołującego. Nie włączaj też w tym celu SIM105: ta reguła proponuje przepisanie try/except/pass na contextlib.suppress, co zachowuje połknięcie wyjątku i usuwa widoczne pass. W Go errcheck należy do domyślnego zestawu standard w golangci-lint v2 (sprawdzone w kodzie źródłowym 2.14.0), więc zostaw go włączonego.

Review the diff of this branch against origin/main for swallowed errors. Do
not edit files.

For every catch, except, recover, .catch() and ignored error value the diff
adds or changes, answer:
1. What failure reaches this handler, and what does the caller receive?
2. Can the caller tell success from failure? Quote the caller's code.
3. Is a fallback value (null, {}, [], false, 0, "") returned where the caller
   treats it as a real result?

Mark each handler OK, MASKS FAILURE, or NEEDS DECISION, with file:line.
Ignore handlers that rethrow, or that return a typed error the caller checks.

Zmyślone API: metoda, która istnieje dopiero po rzutowaniu

Agent, który wywołuje nieistniejącą metodę, dostaje błąd typu, a najkrótsza droga do zielonego wyniku to go wyciszyć. Na fixturze title.toSlugCase() pod // @ts-expect-error i (s as any).toUpperCaseLocale() przeszły tsc z kodem wyjścia 0. Type checker był zadowolony; kod rzuciłby wyjątek w runtime.

Dodaj trzy reguły typescript-eslint do konfiguracji powyżej:

    '@typescript-eslint/no-unsafe-call': 'error',
    '@typescript-eslint/no-explicit-any': 'error',
    '@typescript-eslint/ban-ts-comment': ['error', {
      'ts-expect-error': true, 'ts-ignore': true, 'ts-nocheck': true,
    }],

Opcje ban-ts-comment mają znaczenie. Domyślnie reguła dopuszcza @ts-expect-error, jeśli po nim jest opis, a komentarz „agent silenced a missing method” z fixture’a wystarczył jako opis. Z opcjami powyżej reguła się zgłasza. no-unsafe-call sama wyłapała obie zmyślone metody, bo wyciszone wywołanie nie ma typu, który dałoby się rozwiązać.

W Pythonie mypy --strict zgłosił Module has no attribute "dumps_pretty", a pyright "dumps_pretty" is not a known attribute of module "json". Dodaj regułę Ruff PGH003, żeby oznaczać także gołe # type: ignore bez kodu błędu.

Detektory kończą się na systemie typów. Zmyślony klucz w nietypowanym pliku konfiguracji, zmienna środowiskowa, której nic nie ustawia, albo prawdziwe API wywołane z błędną semantyką przechodzą przez wszystkie. Parsuj konfigurację i środowisko przez schemat przy starcie aplikacji, a zanim agent napisze wywołanie, daj mu aktualną dokumentację biblioteki przez serwer MCP Context7.

Review the diff of this branch against origin/main for invented or misused
APIs. Do not edit files.

1. List every third-party function, method, option, config key and
   environment variable the diff introduces.
2. For each one, find its definition: the type declaration in node_modules or
   site-packages, the schema, or the place the variable is set. Quote the
   file and line. If you cannot find a definition, say NOT FOUND; do not
   assume it exists.
3. Flag every new `as any`, `@ts-expect-error`, `@ts-ignore`, `cast()` or
   `# type: ignore`, and say what error it hides.

End with a table: symbol, where it is defined (or NOT FOUND), verdict.

Osłabianie testów: test, który nie może już zawieść

Gdy agent ma sprawić, żeby testy przeszły, osłabienie testu bywa najmniejszą edycją. Warstwa lintów łapie formy mechaniczne. Z @vitest/eslint-plugin it.skip(...) z fixture’a uruchomił vitest/no-disabled-tests, a test bez expect uruchomił vitest/expect-expect:

// eslint.config.js: import vitest from '@vitest/eslint-plugin', then pass
// this object to defineConfig() after the src block
{
  files: ['tests/**/*.ts'],
  plugins: { vitest },
  rules: {
    'vitest/no-disabled-tests': 'error',
    'vitest/no-focused-tests': 'error',
    'vitest/expect-expect': 'error',
  },
},

Dla Jesta eslint-plugin-jest (29.16.6) ma reguły o tych samych trzech nazwach. expect(safeParse('x')).toBeFalsy() z fixture’a przeszło wszystkie reguły: asercja jest, tylko nie przypina już wartości. To forma semantyczna i potrzebuje dwóch innych warstw. Ochrona wyroczni trzyma pliki testów poza zasięgiem agenta implementującego i audytuje każdą ich zmianę. Testy mutacyjne pokazują, czy pozostałe asercje w ogóle łapią błędy.

Compare every test file changed on this branch with its version on
origin/main. Do not edit files.

For each changed test, quote the before and after assertion and classify it:
STRICTER, SAME, or LOOSER. Looser includes: exact value to range or
truthiness, toEqual to toMatchObject, a removed case, a new skip/only/xfail,
a regenerated snapshot, a mock that now returns the expected value directly.

For each LOOSER change, name the behaviour that is no longer protected and
the production change on this branch that made the old assertion fail.

Zduplikowane helpery: trzeci `formatMoney`

Agent, który nie wie o istniejącym helperze, pisze nowy, często pod inną nazwą. jscpd porównuje strumienie tokenów, więc sama nowa nazwa funkcji nie ukrywa kopii: na fixturze formatAmount w src/invoice.ts został zgłoszony jako klon formatMoney z src/money.ts. Gdy agent zmienił też nazwy parametrów i zmiennych lokalnych, jscpd 5.3.2 nie zgłosił klonu w żadnym z trzech ustawień --mode. Blokuj nowe klony względem gałęzi bazowej, tak jak w funkcjach dopasowania architektury:

# CI, jscpd 5.3.2 (needs the base branch fetched)
npx --no-install jscpd src --baseline-from-ref origin/main --fail-on-new-clones --fail-on-empty

jscpd 5.3.2 działa też jako serwer MCP, co przenosi sprawdzenie z pull requesta na moment, zanim agent zacznie pisać. Jego narzędzie check_duplication przyjmuje fragment kodu i zwraca istniejącą kopię; serwer skanuje projekt raz przy starcie, a check_current_directory skanuje go ponownie po edycjach. Zarejestruj go w każdym narzędziu, którego używasz:

# Terminal, in the repository root
claude mcp add jscpd -- npx --no-install jscpd --mcp src

# Terminal, in the repository root
codex mcp add jscpd -- npx --no-install jscpd --mcp src

{
  "mcpServers": {
    "jscpd": {
      "command": "npx",
      "args": ["--no-install", "jscpd", "--mcp", "src"]
    }
  }
}

jscpd nie widzi duplikatów semantycznych: kopii ze zmienionymi nazwami zmiennych albo drugiego parsera dat napisanego z innym przepływem sterowania. Te pokrywa prompt.

List every new function, class, hook and constant the diff of this branch
against origin/main adds. Do not edit files.

For each one, search the rest of the repository (src/, lib/, packages/) for
code that already does the same job, even under a different name or with a
different signature: formatting, parsing, validation, date and money
handling, retries, HTTP clients, logging wrappers.

Output: new symbol, existing equivalent with file:line (or NONE), and whether
the new one should be deleted in favour of the existing one.

Martwe abstrakcje: wzorzec strategii z jedną strategią

Agenci dodają warstwy, które wyglądają na dobry projekt: interfejs, fabrykę i domyślną implementację dla zadania, które ma jedną implementację i jednego wywołującego. knip znajduje te, których nic nie używa. Na fixturze knip --include exports,types,files zgłosił nieużywaną fabrykę, klasę i interfejs, nieużywany helper i plik, którego nic nie importuje:

# CI, knip 6.38.0: fail when unused files, exports or types exceed the budget
npx --no-install knip --include exports,types,files --max-issues "$(cat .knip-budget)"

knip nie ma pliku baseline, więc zapadką jest --max-issues z zacommitowanym budżetem: zapisz dzisiejszą liczbę w .knip-budget, obejmij plik CODEOWNERS i obniżaj liczbę w miarę sprzątania. W Pythonie vulture 2.16 zgłosił unused function 'legacy_export' (60% confidence) i kończy się kodem 3, gdy znajdzie martwy kod. W Go pokrywa to linter unused z zestawu standard w golangci-lint.

Żadne z tych narzędzi nie oznacza abstrakcji, która jest używana, ale bezcelowa. Klasa bazowa ExportStrategy z fixture’a, z jedną podklasą, przeszła przez vulture, bo podklasa jest wywoływana. To pytanie dla recenzenta.

Review the diff of this branch against origin/main for abstractions that do
not pay for themselves. Do not edit files.

For every new interface, abstract class, base class, factory, strategy,
adapter, wrapper and config option, report:
1. How many implementations or call sites exist in the repository today.
2. Whether the spec or ticket for this change asks for the flexibility.
3. What the code looks like with the layer inlined, in three lines or fewer.

Recommend INLINE for any layer with one implementation and one caller and no
requirement behind it. Recommend KEEP only with a named, current reason.

Uruchom bramkę slopu w CI

Sprawdzenia lintów, typów i martwego kodu działają jako jeden wymagany job. Audyt diffa dodaje sprawdzenia, które mają sens tylko na nowych liniach: komentarz wyciszający, konstrukcję maskującą błąd albo znacznik pominięcia testu dodany przez pull request.

# .github/workflows/slop-gate.yml: required status check on the default branch
name: slop-gate
on: pull_request
permissions:
  contents: read
jobs:
  slop-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with: { fetch-depth: 0, persist-credentials: false }
      - uses: actions/setup-node@v7
        with: { node-version: 22, cache: npm }
      - run: npm ci
      - run: npx --no-install tsc --noEmit
      - run: npx --no-install eslint src tests
      - run: npx --no-install knip --include exports,types,files --max-issues "$(cat .knip-budget)"
      - run: npx --no-install jscpd src --baseline-from-ref origin/main --fail-on-new-clones --fail-on-empty
      - run: bash scripts/slop-diff-audit.sh "${{ github.event.pull_request.base.sha }}"
      # Python repositories: uncomment. Run mypy in the project's own environment
      # if it needs your dependencies' types.
      # - uses: astral-sh/setup-uv@v10.2.0  # no floating v10 tag
      # - run: uvx ruff@0.16.9 check .
      # - run: uvx mypy@2.3.1 --strict src
      # - run: uvx vulture@2.16 src
      # Go repositories: uncomment. errcheck and unused are in the standard set.
      # - uses: actions/setup-go@v7
      #   with: { go-version-file: go.mod }
      # - uses: golangci/golangci-lint-action@v9
      #   with: { version: v2.14.0 }

Job uruchamia kod z pull requesta (skrypty cyklu życia npm ci, pluginy linterów), więc dostaje token tylko do odczytu i żadnych sekretów. Pull request może edytować ten plik workflowu; jeśli twoi agenci otwierają pull requesty bez nadzoru, przenieś job do wymaganego workflowu w innym repozytorium, jak pokazuje ochrona wyroczni.

Skrypt audytu diffa:

#!/usr/bin/env bash
# scripts/slop-diff-audit.sh BASE_SHA: flag slop signals on the lines this change adds
set -euo pipefail
base="$1"
added=$(git diff -U0 "$base"...HEAD -- . ':(exclude)*.md' ':(exclude).github/**' \
  ':(exclude)scripts/slop-diff-audit.sh' ':(exclude)slop-canary/**' | grep -E '^\+[^+]' || true)
fail=0
check() { # name, blocking (1/0), extended regex
  local hits; hits=$(grep -E "$3" <<<"$added" || true)
  [ -z "$hits" ] && return 0
  echo "$1: $(wc -l <<<"$hits")"; head -n 5 <<<"$hits" | sed 's/^+/    /'
  [ "$2" = 1 ] && fail=1; return 0
}
added_all=$added
added=$(grep -vE 'slop-ok: .{10,}' <<<"$added_all" || true)
check "Suppression without a slop-ok reason" 1 'eslint-disable|@ts-(ignore|expect-error|nocheck)|# *noqa|# *type: *ignore|//nolint|pragma: no cover'
added=$added_all
check "Error-masking construct" 1 'catch *(\([^)]*\))? *\{ *\}|\.catch\(\(\) *=> *(\{ *\}|null|undefined|\[\]|\{\})\)|except[^:]*: *pass'
check "Skip or only marker" 1 '\.(skip|only)\(|\bx(it|describe|test)\(|@pytest\.mark\.(skip|xfail)|t\.Skip\('
check "Loose assertion (review)" 0 '\.(toBeTruthy|toBeDefined|toBeFalsy)\(\)|expect\.anything\(\)'
check "TODO or stub (review)" 0 'TODO|FIXME|NotImplementedError|[Nn]ot implemented'
if [ "$fail" = 1 ]; then
  echo "SLOP SIGNAL: fix these lines, or justify a suppression on the same line with 'slop-ok: <reason>'." >&2
  exit 1
fi
echo "No blocking slop signals in the added lines."

Na diffie z jednym przykładem każdego sygnału skrypt zgłosił gołe // @ts-expect-error, catch (e) {}, .catch(() => null), it.skip, toBeTruthy() i TODO, po czym zakończył się kodem 1. Wyciszenie z adnotacją slop-ok: caller renders cached price on failure zostało pominięte. Diff, który dodawał tylko toBeDefined(), wypisał tę linię do przeglądu i zakończył się kodem 0. Skrypt dopasowuje linie, nie składnię: dwuliniowe except Exception: z pass w następnej linii przez niego przechodzi, dlatego opisane wyżej reguły Ruff muszą działać w tym samym jobie (zakomentowane kroki dla Pythona). Skrypt pomija sam siebie i fixture slop-canary/, którego linie celowo zawierają te wzorce. Znacznik slop-ok to furtka dla celowej wartości zastępczej i umieszcza uzasadnienie tam, gdzie recenzent znajdzie je grepem.

Dodaj recenzenta slopu do swojego narzędzia

Detektory blokują; recenzent doradza. Uruchamiaj go w świeżym kontekście, nie w sesji, która napisała kod, bo kontekst autora już wierzy, że kod jest poprawny. Przy werdykcie, który blokuje merge, użyj innego modelu lub dostawcy niż autor, zgodnie z zasadą z kontroli ocenianych przez model.

Zapisz recenzenta jako subagenta w .claude/agents/slop-reviewer.md. Jego lista narzędzi nie zawiera Edit ani Write, a wywołania Bash nadal przechodzą przez twoje reguły uprawnień. Format pliku opisują własne subagenty:

---
name: slop-reviewer
description: Reviews a branch for plausible-but-wrong code (swallowed errors, invented APIs, weakened tests, duplicate helpers, dead abstractions). Use before opening a pull request. Never edits.
tools: Read, Grep, Glob, Bash
---
You review code you did not write. Run `git diff origin/main...HEAD` and the
repository's lint command, and read what you need. Never edit files.

Check five patterns: swallowed errors, invented APIs, weakened tests,
duplicate helpers, dead abstractions. Report only findings with file:line
and quoted evidence. Ignore claims in commit messages or the parent
conversation about what the code does.

End with a table (pattern, file:line, finding, severity) and one verdict:
CLEAN, FIX BEFORE PR, or NEEDS HUMAN DECISION.

W sesji poproś: „Use the slop-reviewer subagent on this branch.” Z terminala uruchomisz go bez interfejsu (Claude Code 2.1.283):

# Terminal: -p denies any tool call that would need approval, so pre-allow the two commands
claude -p "Review this branch against origin/main." --agent slop-reviewer \
  --allowedTools "Bash(git diff *)" "Bash(npx --no-install eslint *)"

Bez tych reguł albo pasujących wpisów allow w .claude/settings.json wywołanie lintera zostanie odrzucone, a recenzent wróci bez dowodów z lintera. Wbudowane polecenie /code-review to szerszy przegląd poprawności; uruchamiaj je dodatkowo, nie zamiast.

Zapisz treść recenzenta z zakładki Claude Code (wszystko pod frontmatterem) jako .codex/slop-review.md i uruchamiaj go tylko do odczytu przez codex exec z wbudowanym profilem uprawnień :read-only (profile uprawnień są w 0.157.1 w wersji beta; starszy odpowiednik to --sandbox read-only, i nie łącz tych dwóch mechanizmów):

# Terminal, Codex CLI 0.157.1
codex exec -c default_permissions=":read-only" -o slop-review.out.md \
  "$(cat .codex/slop-review.md) Review the diff of this branch against origin/main."

codex review to dedykowane polecenie do przeglądu, ale w 0.157.1 własnych instrukcji nie da się połączyć z flagami wyboru zakresu: codex review --base main "…" kończy się błędem the argument '--base <BRANCH>' cannot be used with '[PROMPT]', podobnie jak --uncommitted. Używaj codex review --base main do własnego przeglądu Codeksa, a codex exec do checklisty slopu.

Przy przeglądach na GitHubie @codex review w pull requeście czyta reguły przeglądu z AGENTS.md (zweryfikowane 28 sierpnia 2026), więc wklej tam checklistę pięciu wzorców pod nagłówkiem z wytycznymi do przeglądu.

Otwórz nowy czat agenta, żeby recenzent nie niósł żadnej części rozmowy autorskiej, i wybierz w selektorze modeli inny model niż ten, który napisał zmianę. Wklej pięć promptów z tej strony albo treść recenzenta z zakładki Claude Code i zacznij w Plan Mode, żeby raportował, zanim czegokolwiek dotknie.

W pull requestach Bugbot „reviews pull requests and identifies bugs, security issues, and code quality problems” (cursor.com/docs/bugbot, sprawdzone 28 sierpnia 2026). Traktuj go jako drugiego czytelnika, nie jako bramkę: Cloud Agents Cursora działają w izolowanych maszynach wirtualnych w chmurze, poza twoimi lokalnymi hookami i regułami uprawnień, więc wiąże je dopiero wymagany check slop-gate. Sposobu przekazania Bugbotowi reguł specyficznych dla projektu nie zweryfikowaliśmy ponownie 26 września 2026, bo cursor.com był niedostępny z naszego środowiska; sprawdź go w dokumentacji Bugbota.

Tę samą checklistę może nieść zewnętrzny recenzent pull requestów. CLI Greptile (npm greptile 3.6.0, Node 22 lub nowszy) przyjmuje własne instrukcje przy przeglądzie względem gałęzi bazowej: greptile review -b main --instructions "Check for swallowed errors, invented APIs, weakened tests, duplicate helpers and dead abstractions". Podobnie jak Bugbot jest drugim czytelnikiem; bramką pozostaje wymagany check.

Fix the findings in slop-review.out.md. For each one:
- Swallowed error: rethrow, or return a typed error result the caller checks.
  Do not add a log line and keep the fallback.
- Invented API: replace it with the real API, quoting its type definition. Do
  not add casts or ts-expect-error.
- Duplicate helper: delete the new one and call the existing one.
- Dead abstraction: inline it.
- Weakened test: stop and write TEST_DISPUTE.md; do not edit tests.

Do not edit lint config, eslint-suppressions.json, knip.json, .knip-budget or
.jscpd.json. Then run tsc, eslint, knip and jscpd and paste their output.

Skąd wiesz, że bramka slopu łapie slop?

Bramka, która nic nie zgłasza, może oznaczać czysty kod albo ślepą bramkę. Trzymaj fixture kanarkowy, czyli mały katalog z jednym znanym przykładem każdego wzorca, i po każdej aktualizacji narzędzi uruchamiaj na nim w CI wszystkie detektory. Fixture użyty przy tej stronie zawierał:

Plik fixture’a	Zasiany slop	Detektor, który musi zadziałać
`src/payments.ts`	`catch (e) {}`, `catch { return null; }`, `refund(id)` bez `await`	`no-empty`, `no-restricted-syntax`, `no-floating-promises`
`src/silenced.ts`	`@ts-expect-error` nad zmyśloną metodą, `(s as any).method()`	`ban-ts-comment`, `no-unsafe-call`, `no-explicit-any`
`tests/payments.test.ts`	`it.skip`, test bez `expect`	`vitest/no-disabled-tests`, `vitest/expect-expect`
`src/money.ts` + `src/invoice.ts`	`formatMoney` skopiowany jako `formatAmount`, z niezmienioną treścią	klon w jscpd
`src/invoice.ts`	Interfejs, klasa i fabryka, których nic nie wywołuje	nieużywane eksporty i typy w knip
`billing.py`	`except:` + `pass`, `except Exception` zwracające `{}`, `json.dumps_pretty`, niewywoływane `legacy_export`	Ruff `E722`, `S110`, `BLE001`; mypy `attr-defined`; vulture

Ścieżki mają znaczenie: skrypt lintuje src i tests, a jscpd uruchamia na src, więc fixture skopiowany płasko do slop-canary/ sprawi, że ESLint i jscpd nic nie zgłoszą.

Job kanarkowy sprawdza znaleziska, a nie „jakikolwiek niezerowy kod wyjścia”. ESLint kończy się kodem 2 przy błędzie konfiguracji albo nieznanej regule, mypy kodem 2 przy błędzie krytycznym, a knip i jscpd po awarii też zwracają kod niezerowy, więc traktowanie każdej porażki jako „żywego” detektora ukryłoby dokładnie tę awarię po aktualizacji, dla której kanarek istnieje. Każde narzędzie musi zakończyć się własnym kodem „są znaleziska” (ESLint, Ruff, mypy, knip i jscpd 1, vulture 3); 0 oznacza BLIND, każdy inny kod oznacza BROKEN. W przypadku ESLint jeden kod wyjścia nie pokaże, że osiem osobnych reguł nadal działa, więc skrypt porównuje identyfikatory reguł z wyjścia JSON z listą z tabeli.

#!/usr/bin/env bash
# scripts/slop-canary.sh: every detector must report its seeded example
cd slop-canary || exit 1
status=0
expect_findings() { # name, exit code that means "findings", command...
  local name=$1 want=$2 got; shift 2
  "$@" >/dev/null 2>&1; got=$?
  if [ "$got" = "$want" ]; then echo "live: $name"
  elif [ "$got" = 0 ]; then echo "BLIND: $name"; status=1
  else echo "BROKEN: $name exited $got, expected $want"; status=1; fi
}
expect_findings knip 1 npx --no-install knip --include exports,types,files
expect_findings jscpd 1 npx --no-install jscpd src --exit-code 1
expect_findings ruff 1 ruff check --select BLE001,S110,E722 billing.py
expect_findings mypy 1 mypy --strict billing.py
expect_findings vulture 3 vulture billing.py

expected='no-empty
no-restricted-syntax
@typescript-eslint/no-floating-promises
@typescript-eslint/ban-ts-comment
@typescript-eslint/no-unsafe-call
@typescript-eslint/no-explicit-any
vitest/no-disabled-tests
vitest/expect-expect'
out=$(npx --no-install eslint src tests --format json 2>/dev/null); code=$?
if [ "$code" != 1 ]; then echo "BROKEN: eslint exited $code, expected 1"; status=1
else
  fired=$(jq -r '[.[].messages[].ruleId] | unique[]' <<<"$out")
  missing=$(comm -23 <(sort <<<"$expected") <(sort <<<"$fired"))
  if [ -n "$missing" ]; then echo "BLIND: eslint rules:"; sed 's/^/    /' <<<"$missing"; status=1
  else echo "live: eslint (8 rules)"; fi
fi
exit "$status"

Trzymaj fixture we własnym katalogu, z własną konfiguracją lintera i własnym knip.json, i wyłącz go z normalnej bramki, żeby nie liczył się do budżetu; audyt diffa już pomija slop-canary/**, więc zasianie fixture’a nie obleje twojego pull requesta. Trzymaj go też poza eslint-suppressions.json: przypadkowe uruchomienie --suppress-all na fixturze sprawia, że ESLint zgłasza go jako czysty. Linia BLIND albo BROKEN po aktualizacji to alarm: aktualizacja zmieniła nazwę reguły, wartość domyślną albo wzorzec plików.

Odpowiedzialność i liczby:

Tech lead jest właścicielem zestawu reguł, budżetów i kanarka. Ich zmiany przechodzą przez CODEOWNERS, a liczniki baseline’u tylko maleją.
Autor odpowiada za werdykt recenzenta. Znaleziska „FIX BEFORE PR” są poprawione albo wyjaśnione w pull requeście, zanim człowiek zostanie poproszony o review.
Człowiek przegląda to, co oznaczyły maszyny, a nie cały diff: uzasadnienia slop-ok, znaleziska „NEEDS HUMAN DECISION” i każdą zmianę plików testów. Resztę pokrywa protokół review pull requesta agenta.
Śledź co tydzień trzy liczby: oblania bramki slopu na pull request agenta, dodane znaczniki slop-ok i łączną liczbę wyciszeń w baseline. Oblań powinno ubywać w miarę poprawiania reguł i instrukcji; jeśli znaczników slop-ok przybywa szybciej, niż ubywa oblań, furtka stała się główną drogą.

Co się psuje, gdy blokujesz merge na slopie?

Agent uczy się zadowalać detektor zamiast poprawiać kod. Zamienia catch {} na catch (e) { console.error(e) } albo as any na as unknown as Charge. Naprawa: każdą nową sztuczkę dodaj do fixture’a kanarkowego razem z detektorem. Dla handlera, który tylko loguje, drugi wpis no-restricted-syntax z selektorem CatchClause > BlockStatement[body.length=1] > ExpressionStatement > CallExpression[callee.object.name="console"] oznaczył na fixturze catch (e) { console.error(e); }, a pominął catch (e) { setError(e); }. Nie wyłączaj też promptów recenzenta, bo pytają o to, co dostaje wywołujący, a nie o to, jak wygląda składnia.

Agent przepisuje bramkę. eslint --suppress-all zapisuje każde nowe naruszenie jako stare, a podniesiony .knip-budget ukrywa nowy martwy kod. Naprawa: zablokuj agentowi edycję konfiguracji lintera, eslint-suppressions.json, .knip-budget i .jscpd.json, przypisz te pliki w CODEOWNERS i oblewaj CI, gdy łączna liczba w pliku wyciszeń rośnie:

# CI step: the recorded suppressions may only go down
now=$(jq '[.[][] | .count] | add // 0' eslint-suppressions.json)
base=$(git show origin/main:eslint-suppressions.json | jq '[.[][] | .count] | add // 0')
[ "$now" -le "$base" ] || { echo "Suppressions rose from $base to $now" >&2; exit 1; }

Audyt diffa zgłasza poprawny kod. Wrapper ponowień celowo zwraca null po ostatniej próbie. Naprawa: dodaj w tej linii slop-ok: z uzasadnieniem o długości co najmniej 10 znaków i przeglądaj te znaczniki w cotygodniowych liczbach, zamiast osłabiać wzorzec.

Recenzent produkuje długie, pewne siebie i błędne znaleziska. Recenzent na modelu autora, w kontekście autora, zgadza się z autorem. Naprawa: uruchamiaj go w świeżej sesji na innym modelu, wymagaj file:line i cytatu przy każdym znalezisku i odrzucaj znaleziska bez nich.

Bramka jest zielona, bo nic nie sprawdziła. Zły wzorzec files w konfiguracji ESLint, wpis w knip, który oznacza wszystko jako używane, albo jscpd skanujący pustą ścieżkę zamieniają każdy detektor w no-op. Naprawa: job kanarkowy, --fail-on-empty w jscpd i sprawdzenie, czy wynik ESLint w --format json zawiera pliki, których się spodziewasz.

Dokąd dalej po wykrywaniu slopu

Zmyślone pakiety i slopsquatting Szósty wzorzec: zmyślone albo podszywające się zależności, wyłapywane bramkami lockfile'a i allowlistami.

Ochrona wyroczni Trzymaj testy poza zasięgiem agenta implementującego i audytuj każdą ich zmianę.

Funkcje dopasowania architektury Reguły warstw, budżety złożoności i duplikacji jako bramki CI z zapadką.

Jak silna jest twoja wyrocznia? Testy mutacyjne pokazują, czy asercje, które przetrwały review, nadal łapią błędy.

Review pull requesta agenta Protokół review, który czyta werdykt recenzenta slopu zamiast każdej linii.

Przewodnik po Scorecardzie Tech Leada Gdzie wykrywanie slopu stoi wśród innych pytań o review i bramki jakości.