11 октября 2026
Я разработал и внедрил эту политику в компании со 150+ инженерами. В работе начал появляться слоп: сгенерированный код, задачи, документы и ревью, которые выглядели готовыми, но требовали от коллег дополнительного разбора и проверки. При обсуждении возникали аргументы вроде «это AI ошибся, а не я» или «вот же все написано». Нужно было договориться, что считать выполненной работой, кто отвечает за результат и как давать обратную связь.
Политика уже используется при разборе конкретных случаев. Пока без жестких санкций: многие споры снимаются ссылкой на общие правила или разговором в личке.
Принцип ответственного использования AI
AI помогает в работе, но не заменяет собственное мышление, экспертизу и ответственность. За опубликованный результат всегда отвечает автор. Мы ожидаем не только эффективного использования AI-инструментов, но и помощи коллегам, когда замечаем, что эти инструменты используются некорректно.
Workslop - это рабочий материал, созданный полностью или преимущественно с помощью AI. Он выглядит как готовый результат, но ему не хватает понимания задачи, контекста, проверки и осмысленных решений, поэтому пользы для дальнейшей работы от него мало.
Примеры:
- Код, который автор не понимает, не проверил и не сможет поддерживать.
- Постановка или описание задачи с выдуманными требованиями и решением, предложенным без учета нашего контекста.
- Передача ответа LLM без осмысления и критического анализа под видом выполненной задачи.
- Множество непроверенных комментариев к коду под видом полноценного code review.
- Документ или другой рабочий материал без проверки фактов.
- LLM-speak: корректный по смыслу, но неоправданно длинный, шаблонный и переусложненный текст.
- Обоснование решения авторитетом модели: «AI / агент / Claude / Codex сказал / выдал / считает».
Ключевая особенность workslop - асимметрия затрат: создать материал при помощи AI дешево, а понять, проверить, исправить или отклонить его дорого. Локальная экономия автора превращается в распределенные издержки коллег и организации.
Модель ответственности: влияние × реакция
Мы не пытаемся определить, «виноват» ли человек в использовании AI, и не оцениваем его по одному неудачному результату. Сначала смотрим на влияние кейса, затем на реакцию автора. Наша цель - исправить работу и помочь человеку. Персональная ответственность усиливается только тогда, когда ожидания уже понятны, но проблема сознательно или систематически воспроизводится.
Влияние на работу (I)
I0. Нет проблемы
Результат полезен и не требует коммуникации с автором.
Пример: автономный агент проводит первичный анализ бага, собирает контекст и создает PR. Рутинная работа выполнена, а принимающий понимает, что результат получен агентом, проверяет его и отвечает за итог.
I1. Локальная доработка
Результат валиден, но требует коммуникации с автором, чтобы разобраться.
Пример: тикет подготовлен правильно, но LLM при переводе исказила формулировку одного из требований. Общий смысл сохранился, однако появилась неоднозначность, из-за которой получателю пришлось уточнить детали у автора.
I2. Перекладывание ответственности
Проверка, фильтрация или осмысление переложены на коллег.
Пример: автор передает замечания ревьюера в LLM и возвращает сгенерированные исправления, не разобравшись в изменениях. MR ходит по кругу, а ревьюер фактически ведет задачу и проверяет очередные попытки вместо автора.
I3. Существенное влияние
Workslop повлиял на решение, внешнего получателя, несколько команд или повторяемый процесс.
Пример: LLM добавила в спецификацию выдуманное или искаженное требование, противоречащее исходной задаче. Его не проверили, реализовали и выпустили в production.
Реакция автора (R)
R0. Заметил, обозначил и устранил проблему до передачи результата
Ожидаемое поведение.
Пример: инженер получил автоматический триаж бага от своего агента, проверил его перед передачей другой команде, обнаружил ошибки и исправил их. Дальше ушел уже проверенный триаж, за корректность которого отвечает инженер.
R1. Принял замечание и доработал
Считаем единичную ошибку частью нормального рабочего процесса.
Пример: агент выдавал большой объем комментариев, в котором возможные полезные замечания тонули в шуме. Автор MR отказался это разбирать и сказал прямо, что перед ним слоп-ревью. Ревьюер замечание принял, поправил агента так, чтобы тот выделял только существенное, и с тех пор проверяет выдачу сам перед публикацией.
R2. Признает проблему, но не может исправить ее без помощи
Причиной может быть недостаток навыка, контекста или ясных критериев. Помогаем, обучаем и проверяем условия работы. Автор отвечает за освоение подхода, руководитель за понятные ожидания и необходимую поддержку.
Пример: инженер осваивает новый профиль и упирается в предел, за которым работы автора уже нет. Задача не по основному профилю, ревью приходит от профильного инженера. Замечания автор исправляет целиком с помощью агента, потому что их суть уже не понимает. С этого момента MR фактически доводит ревьюер: он формулирует проблему, он же диктует решение, автор передает это модели. Формально работа идет, фактически автор из нее вышел.
Правильное действие: признать проблему и запросить выделенного ментора, который не только смотрит код, но и разбирает суть замечаний и учит. Обучение должно быть явным для обеих сторон. Ревьюер обязан понимать, в какой он роли: либо он обучает, либо честно требует результат. Когда тип задач освоен, автор возвращается на общее ревью без сопровождения.
R3. Повторяет тот же паттерн после понятного фидбека и предоставленной поддержки
Подключаем руководителя, фиксируем ожидания в Performance Improvement Plan. От автора ожидается устойчивое изменение способа работы.
Пример: автор готовит PR или рабочий документ. После ревью он несколько раз полностью перегенерирует документ вместо точечных исправлений: старые проблемы исчезают, но появляются новые, и проверку приходится начинать заново. Автору объяснили риск, показали правильный подход и повторили договоренность через руководителя, однако следующие версии приходят в том же виде. Повторяется конкретный способ работы, а не отдельная ошибка.
R4. Сознательно обходит требования, имитирует проверку, скрывает отсутствие понимания или размывает ответственность
Рассматриваем кейс как нарушение требований к качеству, добросовестности и ответственности. Применяем формальную ответственность.
Пример: автор приложил к изменению сгенерированный отчет об успешной проверке, хотя фактического прогона не было. Либо выдал результаты исследования агента за проверенные выводы, хотя агент лишь собрал сырой материал, а источники и утверждения никто не валидировал. В обоих случаях результат представлен как проверенный, хотя проверка была сымитирована генерацией.
Матрица принятия решений
Строки - влияние (I), колонки - реакция (R). Действие берем на пересечении.
Высокое влияние само по себе не означает вины, а небольшое влияние не оправдывает сознательное игнорирование требований. Сначала исправляем результат и процесс, затем учитываем реакцию автора и повторяемость паттерна.
| Влияние / реакция | R1: исправил | R2: нужна поддержка | R3: повторяет | R4: игнорирует или скрывает |
|---|---|---|---|---|
| I1: локальная доработка | Не требуется | Помочь исправить | Применяем Performance Improvement Plan | Формальная ответственность и разбор системных причин |
| I2: перекладывание ответственности | Не требуется | Вернуть результат | Применяем Performance Improvement Plan | Формальная ответственность и разбор системных причин |
| I3: существенное влияние | Разобрать системные причины | Зафиксировать ожидания с руководителем, разобрать системные причины | Применяем Performance Improvement Plan, разобрать системные причины | Формальная ответственность и разбор системных причин |
Кто применяет шкалу и куда давать фидбек
Триаж делает тот, кто столкнулся с workslop: ревьюер, исполнитель тикета, читатель документа. Отдельной роли, дежурного или комитета для этого нет.
Промолчать и доделать за автора - самый дорогой сценарий: издержки остаются скрытыми, автор не получает сигнала, паттерн повторяется.
Эскалация:
- Первый раз - в личке с автором. Цель договориться, а не зафиксировать нарушение. Обычно этим и заканчивается (R1).
- Повторно - там, где замечено: тред MR, комментарий к тикету, канал команды. Не публичный разбор человека, а рабочий контекст, где проблему видят все участники цепочки.
- Паттерн повторяется после понятного фидбека и поддержки (R3) - к прямому руководителю автора.
R4 (имитация проверки, сокрытие отсутствия понимания) идет к руководителю сразу.
Калибровочные примеры влияния
Примеры помогают одинаково применять уровни I0-I3 и служат ориентирами, а не исчерпывающим перечнем. Если вы столкнулись с новым типом влияния, добавьте свой пример. Если существующий пример кажется отнесенным к неверному уровню, предложите изменение с пояснением контекста и фактических последствий кейса.
По возможности обезличивайте примеры и убирайте сведения, несущественные для понимания влияния. Но если пример сохраняет ценность только в исходном виде, например как ссылка на PR, postmortem или документ, то лучше привести его, чем отказаться от полезного кейса. Мы рассматриваем такой пример как рабочий артефакт для обучения и улучшения процесса, а не как оценку или публичное обсуждение конкретных людей.
I3. Существенное влияние
Сгенерированный black box как часть production-системы. Один из компонентов пользовательского репортинга сгенерирован с помощью LLM, понимания и экспертизы по нему в команде нет. Компонент начал течь по памяти, и изменения вносятся наугад. В одном из исправлений попытались принудительно вернуть освобожденную память операционной системе, но это не помогло. Проблему закрыли на уровне инфраструктуры.
I2. Перенос работы
Генерация задачи: готовое решение вместо постановки задачи. В тикете нет ясной проблемы и ограничений, только сгенерированная инструкция по реализации, не сверенная с нашим контекстом. Исполнитель вынужден сначала разобрать предложенное решение, а затем выяснить, что вообще требовалось. Простая проверка: если убрать раздел с решением и задача станет непонятной, постановки не было. При этом вариант решения допустим, если он явно обозначен как гипотеза и не заменяет описание задачи.
Описание PR как лога работы. Вместо краткой выжимки автор передает хронику изменений без приоритетов. Ревьюер вынужден сам выяснять, что изменилось, где границы и риски, фактически выполняя работу автора. Проверка: если по описанию нельзя понять изменение в поведении системы и основные риски, оно не выполняет свою функцию. Длинное описание допустимо, если начинается с выжимки, а детали вынесены отдельно.
Полное делегирование code review агенту. Проблема возникает, когда человеческое ревью заменяется агентским там, где нужно оценить само решение: соответствие задаче и продуктовому контексту, архитектурные границы, доступы, изоляцию данных, необратимые операции и последствия выбранного подхода. Агент может подтвердить соблюдение формальных правил, но не то, что решение в целом правильное.
Не является проблемой: использовать агента для проверки стиля, конвенций и других машинно проверяемых требований, а также автомержа изменений без логики при условии, что корректность подтверждается линтером, тестом или другим детерминированным инструментом.
I1. Локальная доработка
Полезный отчет по релизу, но с невычищенными кусками сырого вывода модели в тексте. Например: «Вердикт: продукт долетел и вызвал искренний восторг бизнеса, но процесс закрыл эпик как Released при сломанном в production способе оплаты и оставил хвост работы после релиза».
I0. Нет проблемы
Без контрпримеров шкала превращается в способ отклонять неудобное, а слово «workslop» становится универсальным аргументом в споре.
- Код или любой другой артефакт, полностью написанный агентом. Претензия сводится к стилистике и самому факту генерации, при этом стилистика не ухудшает восприятие результата.
- Черновик, переданный как черновик. Материал отдан с явной пометкой, что это сырье для обсуждения, а не результат. Получатель знает, во что вкладывается, и сам решает, читать или нет.