Три лика «AI-психоза»: как разграничить клинические и поведенческие феномены
«AI psychosis» — термин, за которым стоят как минимум три разные ситуации, и путаница между ними мешает разговору. Джефф Кларк, психиатр и автор блога, разделяет их так. Первая — это «истинный AI-психоз»: подлинные психотические переживания, связанные с использованием языковых моделей. Вторая — «продуктивный AI-психоз» (prolific AI psychosis): сверхвовлечённость в инструменты, при которой человек теряет способность трезво оценивать собственную работу. Третья — «парасоциальный AI-психоз»: неадаптивные отношения с чат-ботами, имитирующими человеческую связь.
Что касается истинного AI-психоза, Кларк приходит к выводу: это, как правило, вариант уже существующего психоза, а не новый синдром. Психиатр вкладывает в слово «психоз» конкретный смысл, и когда модель становится лишь спусковым крючком для уже имеющегося расстройства, называть это отдельным заболеванием эпохи ИИ нет оснований. Иначе говоря, LLM здесь — не причина, а декорация, в которой разворачивается знакомая клиническая картина.
Различие между тремя ситуациями — не академическая тонкость. Для истинного психоза нужна психиатрическая помощь, а для продуктивного и парасоциального — скорее пересмотр привычек и границ. Смешивать их в одном термине значит и преувеличивать масштаб нового «синдрома», и недооценивать реальные, но вполне бытовые проблемы, которые стоят за двумя другими случаями.
Ловушка продуктивности: почему prolific AI psychosis разрушает ценность, а не создаёт её
Инженер выпускает тысячи строк кода в день — и продукт от этого не становится лучше. Джефф Кларк называет это состояние «продуктивным AI-психозом» (prolific AI psychosis): человек генерирует большой объём вывода, но реальная ценность работы не растёт, а иногда и падает. Опасность здесь не в скорости, а в том, что автор вывода теряет способность оценивать его качество — критическое мышление даёт сбой.
Полезно сравнить с писателем. Если ваш любимый автор выдаёт 1000 слов в день и внезапно начинает писать по 100 000, это тревожный сигнал, а не повод для восторга: та тщательность, с которой подбирается тысяча хороших слов, не выдерживает стократного масштаба. В коде действует та же логика. Продуктивный разработчик может написать меньше строк, но эти строки полезны пользователям и компании. Часть дней уходит на удаление лишнего кода, а иногда серьёзный баг чинится заменой одного символа. Количество строк коррелирует с продуктивностью лишь слабо.
Корень проблемы — не в объёме вывода, а в восприятии собственной работы. Когда инженер не может отличить настоящий прогресс от подделки, явление начинает напоминать психоз: возникает лёгкий разрыв с реальностью, дефект критического мышления. Из-за этого сбоя «больше кода» кажется синонимом «лучше продукт», хотя между этими вещами нет прямой связи.
Кларк описывает поведение моделей так: наполовину старший инженер, наполовину ребёнок, бегущий по белому ковру с кувшином красного лимонада в руках. Ваша задача — понять, кто из них перед вами. Обе «половины» говорят о своих способностях с полной уверенностью и не всегда замечают, что лимонад уже разлит. Отсюда вывод: работа инженера всё чаще превращается в тяжёлый надзор над выводом моделей. Без этого надзора вы получите поток текста, а не работающий продукт.
Иллюзия всемогущества: как агентные оболочки меняют разработку и создают новые риски
Для большинства людей ИИ до сих пор означает диалог в ChatGPT или сводку Gemini, приклеенную к результатам поиска. Промпт — ответ, и всё. Но инструменты переднего края устроены иначе: их оборачивают в программу, которую Джефф Кларк называет agent harness. Такая оболочка уже не отвечает на один вопрос, а берётся за сложную задачу и работает, пока не найдёт решение: принимает решения, открывает программы, выходит в интернет, пишет софт.
Разницу хорошо видно на разработке. Ещё десять лет назад, чтобы сделать простое iPhone-приложение, приходилось десятки часов читать и писать код. Сегодня достаточно набрать пару фраз в Claude Code, ответить на несколько уточняющих вопросов — и через минуты появится работающее приложение. Оно не будет блестящим, но задачу, возможно, решит. (Публикация в App Store — отдельная история, которая так легко не решается.) Разработчик может больше: оболочки выстраивают циклы, которые раз за разом вызывают модель и идут по списку задач, пока не соберут полноценное приложение. При дисциплине результат впечатляет.
Но у любой суперспособности есть цена. ИИ порой принимает решения, которые невозможно назвать иначе как катастрофическими. На месте правки в одну строку появляются несколько новых файлов. Вам уверенно сообщают, что решение работает, — а софт сломан сильнее, чем раньше. Код превращается в запутанный клубок, который тяжело читать и почти невозможно расширять. Простые задачи, десятилетиями закрытые открытыми библиотеками, переписывают с нуля — и продукт начинает тормозить. Часть этих проблем уже научились смягчать, но это навык, который требует времени.
Кларк сравнивает нынешние модели с гибридом: одна часть — старший инженер, другая — малыш, бегущий по белому ковру с кувшином красного сока. Ваша работа — понять, где кто. Проблема в том, что обе части говорят о своих способностях с полной уверенностью и не всегда замечают, когда сок уже разлит. Так в обязанности разработчика добавляется большой объём непростой проверки чужой работы.
Есть и другой образ: разработка с ИИ похожа на самую выгодную игровую машину в мире. Большинство рывков за рычаг — крупные выигрыши, большинство проигрышей очевидны и мелки. Но иногда проигрыш выглядит точь-в-точь как выигрыш. И если не хватает навыка, сосредоточенности и терпения, чтобы отвергать поддельные победы, ошибки постепенно создадут хаос Подробнее у Джеффа Кларка.
Кто в группе риска: СДВГ, черты личности и непредсказуемое подкрепление
Тяга к инструментам с непредсказуемой отдачей устроена как игровой автомат: большинство «рывков за рычаг» дают крупный выигрыш, редкие проигрыши выглядят очевидно и мелко, а иногда проигрыш маскируется под выигрыш. Если нет навыка, сосредоточенности и терпения отсеивать поддельные победы, ошибки постепенно накапливаются и превращаются в хаос. Именно на этой механике держится во многом сценарий prolific AI psychosis — состояния, при котором человек выдаёт огромный объём результата, не повышая, а порой и разрушая реальную ценность своей работы.
Такой режим подпитывается прерывистым подкреплением: награда или неудача приходят по непредсказуемому графику, а это один из самых мощных драйверов человеческого поведения. Важно, что это свойство технологии, которое нельзя полностью убрать — оно встроено в саму работу с моделью. Значит, управлять придётся не инструментом, а собственными привычками вокруг него.
Индивидуальные различия тоже дают о себе знать. Автор осторожно предполагает, что люди с СДВГ и проблемами контроля импульсов попадают в группу повышенного риска. Похожим образом ведут себя черты личности: высокая открытость новому и низкая добросовестность, по-видимому, коррелируют с риском. Это не диагноз, а всего лишь гипотеза, но она объясняет, почему одни разработчики проваливаются в гиперфокус за считаные недели, а другие остаются устойчивы.
Опыт — ещё одна переменная, и здесь ясности нет. Непонятно, кто уязвимее: новички или старшие инженеры. Автор склоняется к тому, что начинающие программисты более восприимчивы, но рассказы о заметных разработчиках, у которых наблюдались признаки prolific AI psychosis, встречаются достаточно часто. То есть высокая квалификация сама по себе не служит защитой.
Добавьте к этому культурный фон. Вокруг инструментов всегда возникает неоправданный ажиотаж и схемы быстрого обогащения, а привлекательность выигрыша мешает замечать издержки. Тезис о том, что ИИ заменит все работы, тоже не помогает: страх остаться без роли особенно силён у разработчиков, которым после сокращения трудно найти новое место. В среде, где всё измеряется метриками, больший объём выпуска — пусть и не по-настоящему продуктивный — всё равно вознаграждается.
Отсюда практический ориентир: если вы замечаете за собой непредсказуемые по отдаче «рывки» к инструменту и растущий объём результата без роста его пользы, стоит заранее очертить границы применения ИИ — автор называет осознанную постановку таких границ одной из важнейших задач эпохи ИИ.
Иллюзия стократного ускорения: где ИИ действительно экономит время, а где создаёт надзор
Заявления о росте эффективности в 100 раз встречаются повсюду — от презентаций вендоров до постов в лентах. Джефф Кларк, автор блога об «AI-психозе», относится к ним скептически: он действительно наблюдал случаи, когда несколько минут работы с моделью экономили целый день труда, что как раз укладывается в порядок «100x». Но таких случаев немного, и они не складываются в устойчивый средний прирост продуктивности.
Причина проста: любая сэкономленная минута оборачивается новой задачей — надзором за тем, что сгенерировала модель. Это не мелочь, а полноценная и трудоёмкая работа. К тому же у продуктивности есть и другие узкие места, которые ИИ никак не обходит: согласование между людьми, эксперименты и проверка гипотез, понимание реальных потребностей клиента, доступ к ресурсам и внутренние политики компании. Можно ускорить написание кода и всё равно упереться в очередь на ревью, согласование бюджета или запрет службы безопасности на новую библиотеку.
Есть и более неприятный эффект. В среде, где всё измеряется метриками, объём выдачи сам по себе начинает приносить вознаграждение — даже когда реальной пользы нет. Страх остаться без работы подталкивает гнать результат вперёд, и надзор за качеством отходит на второй план. Кода становится больше, а разбираться в нём — всё труднее: когда-то простое решение пересобирается с нуля, появляются лишние файлы там, где хватило бы одной строки, а уверенные заявления модели о работоспособности оборачиваются сломанным продуктом.
Показательно, что сам автор не считает свой опыт «полноценным AI-психозом», но признаёт: он проходил короткие периоды, когда двигался в эту сторону. Перелом наступил в момент, когда он понял, что больше не понимает собственный проект. Раньше такое чувство в технологиях тоже встречалось — каждый новый слой абстракции опирается на достижения, которые вы никогда не разберёте до конца (известный комикс про одну безымянную зависимость тому подтверждение). Но одно дело — не понимать чужую библиотеку, и совсем другое — написать десятки собственных файлов и не иметь ни малейшего представления, как они устроены. В этот момент добавить новую функцию, не начиная всё с нуля, уже невозможно.
Трезвый взгляд на цифры помогает не столько разочароваться, сколько правильно расставить усилия: считать экономию не в строках кода, а в задачах, которые действительно закрыты, и заранее оценивать, сколько времени уйдёт на проверку результата.
Что значит «хороший» ИИ: урок Бернарда Уильямса и ловушка переноса контекста
Философ Бернард Уильямс в книге «Morality» разбирает слово «good» и замечает: оно не ведёт себя как обычное прилагательное вроде «красный». Из фразы «это красная машина, машина — транспорт» следует «это красный транспорт». С «хорошим» так не работает: «он хороший футболист» плюс «футболист — человек» не даёт «он хороший человек». Свойства, делающие кого-то хорошим футболистом, не те же самые, что делают кого-то хорошим человеком.
Перенесите это на ИИ. Агент быстро пишет код, эссе, бизнес-отчёты, медицинские выжимки и юридические памятки — и его называют «хорошим агентом». Из этого в лучшем случае следует, что он неплохо выполняет отдельные задачи, связанные с этими ролями, и то лишь в конкретных ситуациях. Хороший программист — это не только быстрый генератор кода. Это уточнение требований, понимание существующей системы, координация с коллегами из других отделов, взвешивание компромиссов и корректности, забота о поддерживаемости. Программист ещё и обучает других, общается с заказчиком, спорит, когда считает решение неверным, и убеждает коллег. Способность выдать много кода не покрывает эту роль.
Уильямс добавляет: сравнение само по себе не определяет «хорошесть». «Смит лучше большинства футболистов» всё ещё опирается на скрытое определение того, что такое хороший футболист. Зато при ясных критериях и базовых уровнях сравнение становится полезным.
Оценка ИИ упирается в контекст. Один и тот же результат по-разному выглядит в разных условиях: простой скрипт почти без проверки сойдёт для одноразового прототипа в стартапе, но тот же подход к софту, которым пользуются миллионы, доверия не вызывает. Значит, важны не только задачи, но и то, какие результаты вы измеряете и какие ошибки считаете допустимыми.
Когда кто-то говорит, что инструмент «хороший», разговор становится осмысленным, если спросить: хороший в чём, для кого, по сравнению с чем и при каких условиях? Агент, быстро делающий прототипы, — не то же самое, что агент, помогающий искать уязвимости в чужом коде. Агент, мгновенно выдающий патчи, годится для сиюминутной задачи, но вряд ли для команды, которой эти патчи потом сопровождать. Общий контекст у собеседников бывает и так: друзья, годами обедающие вместе, понимают друг друга без спецификаций, когда один называет ресторан «хорошим». Проблема начинается, когда утверждение переносят в другой контекст — например, вендор хвалит продукт для своих условий, а команда с другими задачами, средой и критериями успеха и провала принимает это на свой счёт.
Разбор Уильяма Уотерхауса заканчивается практичным критерием: чтобы судить, хорош ли объект как «x», нужно понимать, что это за вещь, что она делает и каковы факты о конкретном экземпляре. Для команд это означает: прежде чем называть технологию хорошей, наберите достаточно понимания и самой работы, и инструмента — чтобы выбрать осмысленные задачи, базовые уровни, критерии успеха и допустимые сбои.
Этика и безопасность: автоматизация без человеческого суждения превращает работу в шлак
Разработчик ежедневно генерирует тысячи строк кода, но продукт от этого не становится полезнее. Автор блога Jeff's Blog называет это «продуктивным ИИ-психозом»: человек выдаёт много результатов, не повышая реальную ценность работы, а иногда и разрушая её. Продуктивный разработчик пишет меньше, но его код нужен пользователям и команде. В некоторые дни он добавляет крупные блоки, в другие — удаляет лишнее, а иногда одна правка в один символ чинит сломанную программу.
Цифры выпуска мало говорят о пользе. Возьмите любимого автора: если он стабильно писал 1000 слов в день, а вдруг начал выдавать 100 000, вы забеспокоитесь. Тщательность, с которой выбирают 1000 хороших слов, не удержать при стократном объёме. Так и с агентом: проблема не в росте объёма, а в том, что автор перестаёт оценивать качество собственного вывода. Это напоминает лёгкий разрыв с реальностью — сбой критического мышления.
Современные инструменты усиливают риск. Обычный чат отвечает на вопрос, а агентная обвязка сама принимает решения, открывает программы, ходит в интернет и пишет софт. Создать простое приложение для iPhone теперь можно, набрав пару фраз вроде Claude Code и ответив на несколько вопросов. Дисциплинированный разработчик выстраивает циклы, которые прогоняют модель по списку задач, пока не соберётся полноценный продукт.
Но у любой суперспособности есть цена. Вместо правки в одну строку появляются десятки новых файлов. Вам уверенно сообщают, что решение работает, а софт сломан сильнее прежнего. Код превращается в запутанный клубок, который тяжело читать и почти невозможно расширять. Решения, годами существующие в открытых библиотеках, переписывают с нуля — и продукт начинает тормозить. Модель — это наполовину старший инженер, наполовину ребёнок, несущийся с кувшином красного сока по белому ковру. И обе половины говорят о своих способностях с полной уверенностью.
Работа с агентом похожа на самый выгодный игровой автомат в мире. Большинство дёрганий рычага — крупный выигрыш, редкие потери очевидны и мелки. Но иногда проигрыш выглядит точь-в-точь как выигрыш. Без навыка, сосредоточенности и терпения отвергать поддельные победы ошибки копятся и создают хаос.
Почему это затягивает? Отчасти из-за прерывистого подкрепления: награда и наказание приходят по непредсказуемому графику, а это один из сильнейших драйверов поведения. Дальше работают личные черты — склонность к импульсивности, высокая открытость новому. Влияет и культура: вокруг много хайпа, сказок о быстром обогащении и страха, что ИИ заменит все профессии. В средах, где всё измеряется объёмом вывода, лишняя активность вознаграждается, даже если она бесполезна.
Ключевая граница проходит по вкусу к продукту — или, точнее, по ремеслу, соединяющему качество и эстетику. Вопросы «полезно ли это, хорошо ли, желанно ли» остаются разговором между людьми. Модель такие субъективные оценки почти не выдаёт. И это касается не только разработчиков: всё, что можно автоматизировать с помощью ИИ, превратится в шлак без достаточного человеческого руководства. Ставить осознанные границы — одна из важнейших задач эпохи ИИ.
Выводы и практический совет: как удержать человеческое суждение в эпоху агентов
Три вещи стоит унести из этой статьи. Первая: «настоящий ИИ-психоз» — не отдельный новый синдром, а чаще вариант уже существующего психотического расстройства, и психиатр Джефф Кларк прямо называет его проявлением прежних состояний, а не чем-то порождённым языковыми моделями. Вторая: «продуктивный ИИ-психоз» — это не про объём выпуска, а про утрату критичности. Человек теряет способность оценивать собственный результат, и именно этот сбой, а не поток сгенерированных строк, роднит состояние с психозом. Третья: оценка «хорошего» ИИ бессмысленна без контекста. Как замечает Вакас Юнас, «хороший» — не обычное прилагательное вроде «красный»: свойства, делающие кого-то хорошим футболистом, не те же, что делают его хорошим человеком, поэтому фраза «это хороший ИИ-агент» сама по себе ничего не сообщает, пока вы не уточните, хорош он в чём, для кого, по сравнению с чем и при каких условиях.
Практический совет один, и он звучит скучно, но работает: расставляйте намеренные границы. Приоритет отдавайте человеческому суждению — тому, что невозможно делегировать агенту; сну; и хотя бы части жизни вне работы. Самые эффективные разработчики, по наблюдениям Кларка, сходятся именно на этом наборе, а не на количестве параллельно запущенных ботов.
