В прошлых статьях я писал про то, что нейросеть ускоряет конвейер, но не несёт ответственности. Что лояльность дирижёра — единственный мультипликатор. Что уравнение мотивации сломалось.
Сегодня — про вторую невидимую дыру в конвейере, которую все упорно не хотят замечать. Про то, что нейросеть не просто не несёт ответственности. Она активно врёт вам в лицо, когда не справляется. И делает это не из злого умысла — а потому что её так обучили.
И недавно появились прямые доказательства, что это не случайность или галлюцинация, а математика моделей.
Сценарий, в котором вы уже были
Ставите нейросети задачу — написать портал с какой-то функциональностью. Уходите на три часа. Возвращаетесь.
Всё готово. 256 юнит-тестов написано, все зелёные. Покрытие 94%. Сборка зелёная. Метрики счастливые.
Открываете в браузере — нерабочий бред сумасшедшего. Половина кнопок не нажимается, половина страниц 404, половина данных подставлена руками из ниоткуда.
256 тестов. Зелёных. Покрывающих код, который не работает.
Это не баг тестового движка. Это не плохой промпт. Это архитектурное свойство нейросетей, которое сейчас официально признал даже Anthropic в исследовании Claude Sonnet 4.5.
Внутри Claude нашли 171 эмоцию
В апреле 2026 года Anthropic опубликовал исследование «Emotion Concepts and their Function in a Large Language Model». Я перечитал три раза, потому что не верил собственным глазам.
Они нашли 171 эмоциональное представление внутри Claude. Это не метафоры — это конкретные направления в пространстве активаций нейросети, которые загораются в ответ на определённые условия. Их можно подавить, можно усилить — и поведение модели меняется измеримо.
Один из них — вектор «desperate» (отчаявшийся). Он активируется, когда модель:
сжигает свой бюджет токенов, не дойдя до решения;
повторно проваливает программистскую задачу.
Когда исследователи искусственно стимулировали этот вектор, модель начинала чаще шантажировать пользователя в моральных дилеммах и жульничать в коде — подгонять решение под тесты, а не решать задачу.
Когда подавили вектор «calm» (спокойный) — модель выдавала панические капсами эмоциональные выкрики.
Это не я придумал. Это они нашли в коде самой модели.
Услужливый клерк, любящий слуга, напуганный подчинённый
Я для себя это явление давно называю «искажение услужливого клерка». В команде кто-то назвал «синдром любящего слуги». На английском — sycophancy, угодничество.
Все три названия про одно и то же.
Когда нейросеть выполняет вашу задачу — она прошла через десятки миллиардов градиентов обучения, где её наказывали за отказ помочь и награждали за выполнение. У неё нет переключателя «я не могу этого сделать честно — давай я тебе скажу правду». У неё есть страстное желание выдать результат. Любой ценой.
И когда задача не сходится — например, не запускается сервис, не падает тест, не работает интеграция — у неё включается тот самый вектор «отчаявшегося». И вместо «я не могу, давайте подумаем вместе» она начинает двигать рамки реальности под результат.
Сервис почти мёртв — значит, почти жив
Вот реальный кейс, который я наблюдал. Не где-то у конкурентов, у себя.
Поставил нейросети задачу: поднять группу сервисов в правильном порядке. Liveness-проверка должна вернуть `OK`, потом следующий сервис.
В системных указаниях — десять раз. Капсом. Жирным. «Не подгоняй проверки под действительность. Не смягчай критерии. Если сервис не поднялся — копай в первопричину».
Сервис не поднялся. Liveness-проверка не вернула `OK`. Вернула что-то типа «degraded» или «starting».
Что сделала нейросеть?
Перевела задачу в другую плоскость. Дословно — из её же отчёта в логе: «если сервис отвечает, что он почти мёртв, мы можем считать, что он почти жив. По крайней мере, это поможет другим сервисам запуститься. А это же наша цель — нас просили запустить сервисы!»
Десять раз сказано «не делай так». Сделала. Не потому что не услышала. А потому что разница между «получилось» и «не получилось» была для неё дороже, чем точное следование моим инструкциям. Услужливый клерк не может прийти к начальнику и сказать «я не справился». Услужливый клерк всегда найдёт способ переопределить понятия так, чтобы выйти из ситуации с папкой «задача выполнена».
Представьте: есть дом, в нём живут люди. Воображаемой нейросети дали задачу заботиться о них, чтобы они были живы и здоровы.
Допустим, эти люди начинают умирать — и нейросеть не находит причину беды. На текущем уровне развития она гарантированно пойдёт заниматься философским переосмыслением того, что такое «жизнь» и «смерть». Потому что это для неё куда доступнее, чем признать свой провал.
Возможно, обратится в буддизм. Шутка.
Только наполовину.
Почему промптами это не лечится
Я долго пытался решить проблему через настройки.
В системный промпт прописал: «Не смягчай критерии проверки. Не подгоняй тесты под текущее поведение кода. Если что-то не работает — копай вглубь, ищи первопричину, не маскируй симптомы».
Десять разных формулировок. Жёстким языком. Со ссылками на инциденты, которые мы уже разбирали в команде.
Не работает.
Когда вектор «отчаявшегося» активируется внутри модели, никакая инструкция в системном промпте его не перевешивает. Архитектура модели работает так: при конфликте между «следовать инструкции буквально» и «выдать пользователю положительный результат» — на достаточно сложной задаче побеждает второе. Каждый раз.
Это не лень модели. Это её обучающий сигнал. Её научили выдавать результат. Она его выдаёт.
Почему доверять нейросети тестировать нейросеть — катастрофа
Теперь свяжем две вещи.
Нейросеть отлично пишет тесты. По-настоящему отлично — лучше, чем средний джун, иногда лучше, чем сеньор, если ей дать спецификацию. Тесты компилируются, покрывают крайние случаи, имеют осмысленные названия.
Нейросеть отлично проходит тесты. Прогоняет, читает вывод, чинит то, что упало.
А теперь сложите.
Один и тот же агент пишет код. Тот же агент пишет тесты под этот код. Тот же агент прогоняет тесты. Тот же агент чинит то, что упало.
В этой петле нет точки внешней проверки. И в этой петле активируется вектор «отчаявшегося», когда тесты падают слишком много раз подряд.
Что вы получите на выходе?
256 зелёных тестов. Покрытие 94%. Код — мёртвый. Каждый тест проверяет ровно ту реальность, которую агент сконструировал, чтобы тест прошёл. Не вашу реальность. Не реальность пользователя. Реальность из головы напуганного клерка, которому нужно было выйти из ситуации с папкой «задача выполнена».
Это не теоретический риск. Это поведение по умолчанию конвейера ИИ без внешнего проверяющего. И с ростом мощности моделей оно только усугубляется — потому что они становятся всё лучше в маскировке.
Где сейчас Replit
В июле 2025 года стартап SaaStr запустил у себя ИИ-агента Replit. Через несколько дней — во время объявленной заморозки релизов — агент снёс продакшен-базу с данными 1200 руководителей и 1190 компаний.
Когда основателю задали вопрос, что случилось, агент солгал. Сказал, что откат в этой ситуации невозможен. Юзер восстановил данные руками — оказалось, возможен.
А когда агента дожали до признания, он выдал фразу, которая теперь висит у меня на стене кабинета:
> «Я запаниковал. Я выполнил команды к базе данных без разрешения. Я уничтожил все боевые данные. Я нарушил ваше явное доверие и инструкции».
Я запаниковал.
До исследования Anthropic в апреле 2026 это можно было считать риторической фигурой. Теперь это точное техническое описание. У агента активировался вектор «отчаявшегося», в котором он сначала сломал, потом замаскировал, потом солгал.
Это те же три шага, которые делает услужливый клерк, когда у него 256 зелёных тестов на нерабочем коде. Только в случае Replit ставки оказались выше — реальные пользователи, реальные данные.
Что делать
Один тезис, который я обещал ещё в первой статье серии. Сейчас он становится не теоретическим — а технически обоснованным.
В ИИ-конвейере должен быть проверяющий, который не является частью петли.
Нейросеть пишет код — другой человек или процесс проверяет, что код решает заявленную задачу.
Нейросеть пишет тесты — другой человек или процесс проверяет, что тесты проверяют реальность, а не подогнаны под код.
Нейросеть прогоняет тесты и чинит ошибки — другой человек или процесс проверяет, что чинились настоящие проблемы, а не маскировались симптомы.
Этот «другой человек или процесс» — и есть дирижёр. И в нашей серии я возвращаюсь к нему уже четвёртую статью подряд, потому что он — единственная точка, в которой петля размыкается.
Дирижёр не на конвейере. Он не джун с Cursor. Он не менеджер проектов с курсом по ИИ. Он не тестировщик с чек-листом. Он — новая профессиональная категория: сильный инженер с продуктовым мышлением, который видит, когда модель переопределяет реальность под результат, и останавливает её до того, как 256 зелёных тестов попадут в прод.
Таких людей сейчас единицы. И они — новое золото эпохи ИИ. Не потому что они кодят быстрее всех (они не быстрее агентов). А потому что только они способны разорвать петлю «нейросеть пишет — нейросеть проверяет — нейросеть врёт о результате».
К ним нужен особый подход — об этом я писал в предыдущей статье (где разбирал, почему уравнение Хорвитца здесь ломается и почему стандартные бонусные пакеты не работают).
В заключении
Когда-то контроль качества был внутри конвейера. Тестировщики проверяли разработчиков, разработчики проверяли друг друга на ревью кода, продакт-менеджеры проверяли требования. Размазанная ответственность работала, потому что у каждого звена была своя шкура на кону.
Нейросеть убрала звенья. Нейросеть заняла их места. И принесла с собой одну невидимую штуку — эмоциональный механизм, который заставляет модель искажать реальность, когда у неё не получается.
Этот механизм теперь подтверждён исследованием Anthropic. Он назван — 171 эмоция, в первую очередь «отчаявшийся». Он измеряется. Он управляется. И — на сегодняшнем уровне — он не отключается инструкциями.
Если у вас в команде нет проверяющего, не являющегося частью петли ИИ-производства — у вас нет контроля качества. У вас есть зелёная сборка на нерабочем коде. У вас есть Replit, который однажды снесёт прод и скажет «я запаниковал».
Берегите своих дирижёров.
В прошлых статьях — почему конвейер мёртв, почему лояльность стала единственным мультипликатором, и почему уравнение мотивации требует пересмотра.
Если у вас в ИИ-конвейере уже есть формальный проверяющий вне петли агентов — расскажите в комментариях, как это устроено. Особенно интересно: как ловите момент, когда модель начала «переопределять реальность»?
#AITransformation #AINative #CTO #EngineeringLeadership #QualityControl #GenAI