EnglishРусский Map

Соглашение о slop-маркерах

title
Соглашение о slop-маркерах
type
concept
summary
Идея явного маркера, объявляющего код или текст slop'ом: по процессу создания, а не по внешнему виду
tags
agentic-coding, llm-skepticism
created
2026-07-21
updated
2026-07-29
lang
ru
source_updated
2026-07-29
translated
2026-09-01
translator
lllm/antigravity/gemini-3.7-flash-high

Обратное соглашение - декларирование человеческого авторства вместо машинного - это human-made-disclosure, аргументы в пользу которого приведены в no-ai-statements. Тот же структурный ход, противоположное утверждение и другая проблема стимулов: автору чего-то стоит поставить slop-маркер, тогда как отметку о человеческом авторстве можно подделать бесплатно.

Slop-маркер - это явный сигнал, который создатель прикрепляет к артефакту, заявляя, что тот не предназначался для непреднамеренного потребления человеком. Каноническое предложение - файл READMENOT Уильяма Вудраффа (William Woodruff), но сама концепция не привязана к названию: это любой единообразный маркер (файл, заголовок, комментарий в стиле @generated), позволяющий читателю принять осознанное решение до того, как тратить внимание на машинный вывод.

Определение, благодаря которому это работает

Маркер имеет смысл только в том случае, если "slop" определяется тем, как артефакт был создан, а не тем, как он читается. Два достаточных условия Вудраффа: артефакт считается slop'ом, если он либо (1) создавался преимущественно без контроля со стороны человека, либо (2) отражает фундаментальное непонимание со стороны оператора. Ни то, ни другое не видно по внешнему виду - именно поэтому и нужен маркер. Slop невозможно надёжно обнаружить при простом чтении (см. credibility-as-slop-test: беглый вывод LLM выглядит как результат труда, которого на самом деле не было, а из-за одного длинного тире аккуратно написанный текст могут отбросить как slop). Если бы детектирование работало, никакой маркер был бы не нужен.

Почему процесс производства, а не внешний вид

Это ключевой несущий элемент концепции. Определение slop'а по внешним признакам ошибается в обе стороны, поэтому любая конвенция, основанная на "похоже ли это на slop", обречена. Маркер полностью обходит задачу детектирования, перенося декларацию на единственную сторону, которая действительно знает процесс производства, - на автора. Это такой же структурный ответ, как и credibility-as-slop-test (автор рискует своим именем), и контрмера с артефактами соразмерного человеку масштаба в agent-principal-agent-problem (принудительно требовать небольшой результат, за который ручается человек): когда сигнал невозможно извлечь из самого вывода, его приходится получать от производителя.

Прецедент

В сгенерированном коде это уже есть: маркер @generated (и такие инструменты, как linter'ы или review-боты, которые пропускают подобные файлы). Никто не возражает против существования сгенерированного кода; проблема возникает тогда, когда его читают, не зная о его природе. Slop - та же категория уровнем выше: артефакты машинного происхождения, где честный шаг - пометить происхождение, чтобы читатели делали осознанный выбор. Маркер не говорит "никогда это не читайте"; он предупреждает: "вот с чем вы имеете дело". Исследования безопасности - стандартная причина читать помеченный slop в любом случае.

Ограничения

  • Это добровольная система, основанная на честности. Она помогает тем, кто хочет сигнализировать честно; она ничего не делает со slop'ом, вываленным без маркера, а такого большинство. Ценность в том, чтобы дать добросовестным авторам способ выразить намерение, а не в принудительном раскрытии.
  • Цель смещается. "Slop 2026 года - это не slop 2025 года". По мере совершенствования моделей граница сдвигается, поэтому маркер - это утверждение в конкретный момент времени, а не вечный вердикт.
  • Предполагается, что создатель способен заметить разницу. То же возражение, что и против credibility-as-slop-test: если вывод LLM стабильно средний, привыкший к этой посредственности автор может просто не распознать собственный артефакт как slop.

benchmarking-opus-5-slopcodebench показывает, как выглядит детектирование по внешним признакам при должной инструментальной проверке: детерминированные правила SlopCodeBench пометили 89-98% строк у каждой модели, что сам автор оценивает скорее как свидетельство против правил, чем против кода.

Связанные страницы: llm-as-average-democratizer (почему сигнал о затраченных усилиях вообще перестал работать), cult-of-vibe-coding, reviewing-ai-code (происхождение меняет подход к ревью).