Я держу 4 Claude-инструмента в работе. HBR говорит, что у таких brain fry. Я был среди них

После моей статьи про Lexis (AI-репетитор на 4 LLM-провайдерах) у меня стали спрашивать: Как ты не выгорел?. Я отвечал так: 4 провайдера – это для пользователей, для разработки я использую Claude.

Месяц спустя я перечитал свой ответ и понял, что он наполовину правда. На разработку я тоже использую четыре инструмента: Claude Code (для кода), Claude Cowork (для документов и контента), Claude Design (попробовал для лендингов) и обычный chat.claude.ai для быстрых вопросов. Параллельно у меня лежит OpenAI API-ключ для тестов. Сейчас я думаю подключить пятый – Codex в связке с Claude за $40/месяц.

По счёту Harvard Business Review, опубликованному в марте 2026, оптимум – до трёх инструментов одновременно. Я давно за порогом и собираюсь дальше. Удобно объяснять это так: у меня другая архитектура. Но HBR-цифры – про меня тоже.

В исследовании на 1488 сотрудников 14% активных пользователей ИИ получили brain fry за последний месяц. Не выгорание (то хроническое). Острая ментальная усталость от oversight’а ИИ. У пострадавших +33% усталости от принятия решений, +39% серьёзных ошибок, в полтора раза выше намерение уволиться.

Эта статья – не как я разобрался. Это где меня ловило, что это стоило, и как я отделяю реальные защиты от плацебо, которые я себе рассказывал.

Что такое AI brain fry и откуда цифры

Чёткое определение

AI brain fry – острая ментальная усталость от чрезмерного oversight’а ИИ-агентов. Не burnout (тот хронический, копится месяцами). Brain fry – острый, появляется за пару дней интенсивной работы.

Симптомы:

• гудит в голове;

• ментальный туман;

• замедление принятия решений;

• мелкие и серьёзные ошибки в коде, который только что ревьюил.

Цифры исследования

База: 1488 американских сотрудников крупных компаний. Команда BCG (с участием UC Riverside research assistants).

Что нашли:

• 14% пользователей ИИ заявили brain fry за последний месяц.

• +33% усталости от принятия решений у пострадавших.

• +11% мелких ошибок, +39% серьёзных (тех, что влияют на ключевые решения).

• 34% vs 25% – намерение уволиться у пострадавших vs остальных.

По доменам:

• Маркетинг – 26%.

• HR – 19%.

• Юристы – 6%.

К доменной разнице вернусь дальше – она важнее, чем кажется на первый взгляд. Сначала про два сценария.

Главный парадокс: тип использования важнее количества

Самый важный вывод HBR, и тот, на котором я сам себя обманывал.

Сценарий A: ИИ заменяет toil (рутину)

• Burnout снижается на 15%.

• Растёт время на творчество.

• Эмоции к ИИ становятся позитивнее.

Сценарий B: ИИ дополняет работу с oversight’ом

• +14% ментальных усилий.

• +12% ментальной усталости.

• +19% информационной перегрузки.

Один и тот же ИИ – два разных эффекта, в зависимости от того, что он делает: убирает рутину или требует ревью.

Я в статье про Lexis уверенно говорил, что нахожусь в A. Я писал архитектуру вокруг ИИ, не ревьюил выводы ИИ. На бумаге безопасная зона.

На практике я месяц спустя сел и честно проследил, где это правда, а где я себя успокаивал.

Где меня ловило: три случая, которые я тогда не назвал brain fry, а зря

Случай 1: я готовил эту статью и провалил собственный чек-лист

Это самый ироничный кейс, и поэтому он первый.

Между черновиком и публикацией я ввёл собственный pre-publish чек-лист: проверить frontmatter, проверить TODO-маркеры, перепроверить факты через web-search (HBR-ссылку, утверждения про конкретные компании). Чек-лист прошёл. Я был доволен дисциплиной.

В финальном sanity-check, через сутки, я обнаружил в тексте служебный заголовок ## Hook (3-4 абзаца с личным лидом) на 27-й строке. Маркер из моего же чернового шаблона, оставленный от того момента, когда я ещё не написал лид. Пять часов мой собственный чек-лист его не ловил, потому что я проверял TODO-маркеры, а не названия секций.

Это в облегчённой форме то самое +39% major errors из HBR. Я был уверен, что прохожу проверку. Я её прошёл. Я пропустил очевидное.

Что это было по HBR-классификации: сценарий B под маской процессной дисциплины. Я не курировал генерацию ИИ – я курировал сам себя, и тоже плохо. Decision fatigue от количества пунктов в чек-листе притупляет внимание к тому, чего в чек-листе нет.

Симптом brain fry в моменте: уверенность в результате чек-листа, основанная не на полноте проверки, а на её ритуале.

Случай 2: я реализовал CEFR-уровни в Lexis и не замечал, что они не работают

В Lexis – моём pet-проекте AI-репетитора английского (github.com/VDV001/lexis) – есть уровни владения языком по шкале CEFR: A1, A2, B1, B2, C1, C2. Когда я их добавлял, я подумал: «Это просто. Поле в БД, switch-case, подстановка в промпт».

Реализация выглядела так:

user.level (varchar(5)) → levelContextMap[level] → строка в системный промпт
"Адаптируй текст для уровня B1 (intermediate)"

Тесты были. Тесты проходили: «Если уровень B1, в промпт попадает строка intermediate». Я закоммитил, выкатил, ушёл к следующей фиче.

Время спустя я прочитал на Хабре статью: CEFR не определит ни ИИ, ни учитель. Автор – глубоко изучивший тему челове. Он разбирает по методике, почему CEFR не определяется машиной в принципе. CEFR – это не свойство ученика, это профиль навыков (чтение / письмо / говорение / восприятие на слух) с разным уровнем по каждому. Сводить это к одному varchar(5) – не «упрощение», а подмена концепта.

Моя реализация формально работала. Она была той самой профанацией, которую критикует статья. Тесты её не ловили, потому что они проверяли pipeline (строка попала в промпт), а не root assumption (что одна буква может описать уровень владения языком).

Что это было по классификации: сценарий B в его самой коварной форме. Я ревьюил выводы (тесты зелёные, фича работает), но не ревьюил базовое допущение. Никакой ИИ мне это допущение не подсовывал – я его принял сам, потому что оно делало задачу решаемой. Мои инструменты помогли мне быстро реализовать неправильное решение.

Что это стоило: аудит, переписывание README с честным признанием ограничения, отдельное GitHub-issue для будущего пересмотра. Не катастрофа. Но какое то время я считал, что у моего AI-репетитора есть CEFR. Это не баг кода – это +39% major errors на уровне продуктового решения.

Как теперь: любая фича в Lexis, которая ссылается на доменный концепт (CEFR, IELTS, спецификации языка) – сначала ищется критическая статья эксперта в этой области, не статья популяризатора. Если эксперта не нашёл – помечаю «approximate» в README, не «implements CEFR».

Случай 3: я тестировал модели для своего рабочего проекта через OpenAI API и понял, что это и есть drift

В коммерческом проекте (продукт компании, в которой я работаю разработчиком) нужно было выбрать LLM для работы с тендерами: анализ ТЗ, генерация КП. Я завёл OpenAI API-ключ и начал тесты.

Workflow выглядел так:

Открываю одно ТЗ, прогоняю через Claude.
Открываю то же ТЗ, прогоняю через GPT.
Открываю чат, спрашиваю Y какая модель лучше для тендеров.
Чат говорит, что зависит от задачи. Открываю Claude, прошу
сравнить два вывода. Claude говорит оба разумны.
Открываю свою базу знаний и записываю итог: оба разумны.
Через 30 минут открываю следующее ТЗ. Прогоняю через Claude.
Открываю то же ТЗ, прогоняю через GPT.

К концу дня у меня было 15 страниц сравнений, ноль решений и стойкое ощущение, что я работал. На самом деле я переключался между моделями в надежде, что одна из них примет за меня решение.

NickAlister в недавней статье «Вайбкодинг – это гемблинг» (habr.com/ru/articles/1033130) описывает это точно: дофамин вырабатывается не в момент выигрыша, а в момент ожидания ответа модели. Поэтому каждый новый запрос даёт ощущение прогресса.

Что это было по классификации: граница между A и B, которую HBR не описывает явно. Я не ревьюил конкретный вывод (это было бы B). Я перебирал инструменты в надежде получить более удобный вывод. На бумаге – выбор инструмента (managerial activity). На практике – постоянное переключение контекста, которое и даёт информационную перегрузку (+19% по HBR).

Что это стоило: 6 часов работы, какое то количество $ на токенах, ноль зафиксированных решений. На следующее утро я открыл задачу заново, выбрал критерии (latency, стоимость per-tender, качество структуры ответа) и за час прогнал три модели по этим критериям. Решение появилось.

Урок: drift между моделями маскируется под исследование. Реальное исследование начинается, когда заранее зафиксированы критерии оценки. Без критериев это просто перебор вариантов с дофаминовой петлей.

Что я сейчас рассматриваю (и почему это иронично)

После всего, что я написал выше, я думаю добавить пятый инструмент.

В недавнем времени в Codex вышли изменения, после которых имеет смысл попробовать связку:

Claude   →   Codex делает
($20/мес Pro)            ($20/мес Plus)
              = $40/мес

Логика связки: Claude как оркестратор, который планирует декомпозицию и держит контекст архитектуры. Codex как исполнитель, который генерирует фактический код по плану. Два разных вендора, два разных набора сильных сторон, cross-model critique встроен.

Это прямая реализация oracle-pattern Митчелла Хашимото (создатель Ghostty), который недавно описал свой workflow на 16-сессионной разработке фичи: read-only sub-agent с усиленной моделью для планирования, основная модель для исполнения. Хашимото делал это в одном инструменте Amp. Я хочу сделать то же самое через двух разных вендоров.

Аргументы «за»

1. Снижение vendor lock-in. Если Anthropic или OpenAI выкатит плохой релиз, у меня есть запасной канал.

2. Cross-model critique работает на практике: Gemini за 30 секунд находит дыры, которые Claude пропустил при первичной генерации (есть отдельный кейс про paywall с loyalty-кредитами, где Claude спроектировал, Gemini поймал критическую ошибку).

3. Разделение труда снижает контекст в каждой сессии. Claude Code не пишет код – значит, не нужно держать всю кодовую базу в его контексте. Только архитектурные документы.

Аргументы «против» – которые ровно про эту статью

1. HBR говорит: оптимум – 3 инструмента. Я уже на 4 (Code/Cowork/Design/Chat). Codex – пятый. По цифрам исследования я двигаюсь в сторону +14% когнитивной нагрузки и +12% усталости. Не то, что это возможно, а с количественным прогнозом.

2. $40/мес – это формализация привычки. NickAlister прямо предупреждает: компании подсаживают на дешёвой первой дозе. $20/мес – дешёвая первая доза. $40/мес – признание, что я в этой петле, и решение пойти глубже, а не выйти.

3. Двойной oversight burden. Если я ревьюю и план Claude Code, и реализацию Codex – я ревьюю в два раза больше. Это сценарий B в квадрате. Если я не ревьюю реализацию – это автономный режим без надёжного стоп-критерия (см. свежий разбор production-фейлов Cursor / PocketOS).

4. Скрытая дофаминовая петля «попробую новый инструмент». Я узнал, что Codex обновили в мае. Я сразу почувствовал желание попробовать, не сформулировав, какую конкретно задачу это решает. Это тот же паттерн, что у меня был с моделями для рабочего проекта – переключение в надежде, что новый инструмент примет решение за меня.

Промежуточный вывод

Я не отказываюсь от идеи связки. Но я её отложил на месяц, и за этот месяц я должен:

• Зафиксировать конкретный критерий, при достижении которого подключение Codex окупится (например: «Claude Code три раза подряд не справился с конкретным типом задачи X»).

• Если критерий не достигнут – не подключать. Если достигнут – подключить только для этого типа задачи, не как универсальный второй инструмент.

Это работает не потому, что я стал умнее. Потому что я поставил искусственный барьер на «попробую, интересно же». HBR-цифры читать вслух перед моментом «закажу подписку» – удивительно эффективная вакцина.

Где статистика говорит больше, чем я был готов признать

В исследовании есть деталь, которую я долго не хотел применять к себе:

Пользователи, которые активно используют ИИ как часть рабочего процесса (а не эпизодически), показывают brain fry в 23% случаев, а не в 14%.

14% – это среднее по больнице. 23% – подгруппа таких, как я. Каждый четвёртый.

Когда я это прочитал в первый раз, моя реакция была: «у меня же архитектура, я не в этой подгруппе». Когда я это перечитал после случаев выше: «вероятно, я именно в этой подгруппе. Просто моя архитектура снижает риск, а не убирает его».

Чек-лист: семь пунктов, на каждом из которых я когда-то поскользнулся

Это не «как делать правильно». Это места, где я падаю.

1. Не больше 3 активных инструментов одновременно

Где я поскользнулся: Claude Code + Claude Cowork + Claude Design + chat.claude.ai, открытые в разных окнах. Я говорил себе «использую один за раз», но переключался между ними каждые 15 минут. Это и есть состояние из Случая 3 выше.

Как теперь: правило «один инструмент на сессию». Открыл Claude Code → закончил задачу → закрыл → потом следующий инструмент. И главное – не подключать пятый, не сформулировав, что именно он решает. Codex отложен на месяц именно по этой причине.

2. Различай «инструмент для toil» и «инструмент для oversight»

Где я поскользнулся: я был уверен, что Claude Code для меня – toil-инструмент. Он генерирует boilerplate, я просто принимаю. Реально – я каждый сгенерированный блок ревьюил построчно, переписывал половину, обсуждал с моделью что не так. Это full B-сценарий под маской A.

Как теперь: тест на честность раз в день. Открываю последние 5 моих коммитов и спрашиваю себя: я писал этот код, или я редактировал то, что написал ИИ? Если второе – я весь день был в B, даже если думал что в A.

3. Закрывай задачу за один заход

Где я поскользнулся: Рабочий проект, тестирование моделей. Открыл «на час сравнить три LLM на одном ТЗ», закрыл через 6 часов с 15 страницами сравнений и нулём решений. Каждые 30 минут «вот ещё одна модель проверить».

Как теперь: жёсткий timeout 90 минут на одну агентную сессию. После – перерыв 20 минут, потом либо коммит того, что готово, либо явное «откладываю до завтра» с записью, где я остановился. Это правило я нарушаю чаще, чем мне хотелось бы признать.

4. Откажись от метрик «больше токенов = лучше»

Где я поскользнулся: я начал измерять прогресс на пет-проекте в количестве успешных диалогов с агентом. «Сегодня 30 успешных prompt’ов» звучало как «продуктивный день». Это прямо то, что HBR называет анти-паттерном на корпоративном уровне, только я применял к себе сам.

Как теперь: метрика недели – сколько TODO из spec-документа закрыто, а не «сколько prompt’ов отправлено». Spec существует именно для того, чтобы было что закрывать, не сгенерированными строками меряться.

5. Проси помощи руководителя

В моём пет проекте Lexis руководителя нет (я единственный мейнтейнер). Но эта пятая позиция – самая сильная по HBR: поддержка снижает усталость на 15%.

Как теперь: в Lexis я пишу подробные ADR (architecture decision records) не для будущих контрибьюторов, а для себя через две недели. Это форма «руководителя» – моё прошлое я объясняет моему настоящему я, что произошло.

6. Защищай work-life balance

В компаниях, где балансу придают значение, brain fry на 28% ниже. Это самый сильный фактор защиты в исследовании.

Где я поскользнулся: работа в выходные «потому что у меня пет-проект и это удовольствие». Через полтора месяца стало не удовольствием, а необходимостью себя успокоить, что я двигаюсь.

Как теперь: календарь пет-проекта. Lexis – вторник вечер и суббота утром. Если в среду хочется «ещё чуть-чуть» – значит, я в дофаминовой петле, надо закрыть. Я нарушаю это правило, но реже, чем раньше.

7. Не строй карьеру вокруг oversight’а ИИ

Самое контр-интуитивное. В отрасли активно продают идею «вместо разработчика – куратор ИИ». HBR показывает цену кураторства: +14-19% когнитивной нагрузки и +9 п.п. к намерению уволиться.

Я не уверен, что эту цену сейчас все понимают. Я сам её недооценивал, пока не сам пожил несколько месяцев в режиме «куратор четырёх инструментов».

Куратор ИИ – не upgrade, а другая работа с другой нагрузкой. Если ты в эту сторону движешься (а отрасль активно толкает именно туда) – двигайся осознанно. Знай, что покупаешь.

Маркетинг 26%, юристы 6% – откуда такая разница

В исследовании есть деталь, мимо которой легко пройти:

• Маркетинг – 26% brain fry.

• HR – около 19%.

• Инженеры, финансы, IT – тоже выше среднего.

• Юристы – 6%.

Разрыв между маркетингом и юристами – в четыре раза. Это уже не шум, это сигнал.

Простая интерпретация (которая мне сначала тоже нравилась)

«В маркетинге и HR ИИ работает плохо. Природа задач не подходит – слишком субъективно, слишком много нюансов. Юристы спасены своей структурностью.»

Эта интерпретация лежит на поверхности, и я её сначала принял. Потом начал проверять и понял, что она слишком сильная.

Что в этой логике не сходится

Brain fry ≠ ухудшение работы. В исследовании измеряли состояние человека, а не время на задачу. Маркетолог может писать рекламные тексты в несколько раз быстрее с ИИ – и при этом получить brain fry от потока ревью. Скорость работы выросла, состояние ухудшилось. Это не одно и то же.

Юристы 6% – не потому, что ИИ им подходит лучше. У них меньше brain fry по другим причинам: 1) они в принципе меньше внедрили ИИ в реальный workflow (compliance-консерватизм); 2) когда внедрили – на бинарно-проверяемых задачах (поиск прецедентов, проверка дат); 3) меньше use-case’ов креативной генерации, где нужен субъективный ревью. То есть 6% – не комплимент инструменту, а свойство профессии.

Инженеры и финансисты тоже в высоких – но в простой интерпретации про них забывают. Если виноват домен – почему IT тоже плохо? Инженеры не пишут рекламу, а brain fry получают.

Альтернативная гипотеза – дизайн процесса, а не домен

Я думаю, реальный диагноз такой:

Маркетинг и HR чаще организованы под сценарий B (постоянный oversight выводов ИИ), чем под сценарий A (ИИ убирает рутину). Это не природа домена, а дизайн внедрения.

Аргументы:

1. Один и тот же маркетолог в разных процессах даст разный brain fry. Если Claude генерит первые драфты, а человек выбирает 1 из 5 и публикует – сценарий A, brain fry низкий. Если Claude выдаёт 50 вариантов, а человек ревьюит каждый – сценарий B, brain fry высокий. Домен один, выводы разные.

2. Корпоративные KPI давят в сценарий B. «Сколько постов сгенерировано» – сценарий B по дизайну. «Сколько кампаний вышло качественных» – сценарий A. Маркетинг чаще измеряют первым способом.

3. Раннее массовое внедрение. Маркетинг и HR были среди первых отделов, куда «приклеили» ИИ. Без редизайна процесса. Через 1-2 года эксплуатации без перестройки накопилась усталость.

Контр-кейсы из реальных историй

Если бы виноват был домен, в нём не должно быть успешных кейсов. Но они есть:

• Совкомбанк отчитался об ускорении рутинных процессов на 50% через ИИ-ассистента. Финансы – один из «high brain fry» доменов по HBR, но конкретный кейс показывает обратное.

• Avito ускорил code review через LLM. IT – тоже «high brain fry», и тоже есть положительный пример.

В каждом «проблемном» по HBR домене есть положительные кейсы. Это аргумент против гипотезы «домен виноват».

Что значит «правильный дизайн процесса»

Конкретно для маркетинга и HR:

• Делегируй, не ревьюй. ИИ закрывает первые черновики – человек выбирает финал, а не правит каждый вариант.

• Сократи количество вариантов. Не «сгенерируй 50 заголовков», а «сгенерируй 3 лучших по такому-то критерию».

• Метрики по результату. Не «сколько контента сгенерировано», а «сколько кампаний реально вышло в работу».

• Команды агентов – коллективные. Один маркетолог не должен курировать 5 ИИ-агентов в одиночку.

Краткий вывод этой части: статистика HBR верна, но интерпретация «домен виноват» – слишком сильная. Реальный виноват – дизайн внедрения. Если сейчас в твоей компании в маркетинге и HR brain fry зашкаливает – не убирай ИИ, а переделай процесс. Это исправимо.

Я не одинок: на Хабре за последнюю неделю появились две статьи на ту же тему

Пока я готовил эту статью, появились две публикации, к которым я прямо отсылаю:

• NickAlister, «Вайбкодинг – это гемблинг» (habr.com/ru/articles/1033130). Описывает дофаминовую петлю vibe coding: дофамин вырабатывается в момент ожидания ответа модели, а не в момент успеха. Поэтому ты веришь каждый раз, что вот сейчас агент сделает то, что ты просил 10 запросов назад. Прямое попадание в Случай 3 выше.

• Ansud, «Миллион клодобезьян: естественный отбор вайбкодинга» (habr.com/ru/articles/1033188). Считает математически: к 372-й итерации vibe coding проект разваливается под собственным весом. «Накопление макаронин в кастрюле перестаёт быть набором отдельных макаронин, становится лапшой».

Это не три случайные статьи. Это сигнал, что критика vibe coding-режима достигла критической массы. HBR-цифры из этой статьи – количественное подтверждение того, что NickAlister и Ansud описывают качественно.

Архитектурный ответ: встроить oversight в агента, а не в человека

Есть короткий путь, помимо «терпеть brain fry» или «убрать ИИ». Архитектурный.

В апреле 2026 на Хабре появилась статья TAU15 «Медленное мышление для быстрых машин» с реализацией рефлексирующего агента. Главная её мысль:

Решение не в том, чтобы сделать модель умнее. Решение в архитектуре, которая встраивает размышление и проверки в каждое звено цикла.

Семь столпов в двух словах: динамическая сборка контекста, виртуальная песочница для всех модификаций, обязательная фаза рефлексии после задачи, шлюз для критики с тремя уровнями риска (🟢 SAFE_READ авто, 🟡 MODIFY черновик, 🔴 DESTRUCTIVE подтверждение), многоуровневые предохранители в исполнительном слое, не в промпте.

Что это значит для brain fry:

HBR говорит «человек устаёт от oversight». TAU15 говорит «встроим oversight в архитектуру агента». Тогда человек проверяет не каждый шаг, а только финальные DESTRUCTIVE точки и итоговые черновики.

В сценарии B – не нужно, чтобы человек ревьюил каждый промежуточный вывод. Это работа архитектуры. Человек включается на gateway точках: «применить эти 12 правок?», «отправить email?», «удалить запись?».

Если в твоей команде brain fry вызван «архитектура слишком тонкая» – TAU15 стиль агент закрывает большую часть этой нагрузки. Оставшееся – это решения, которые должен принимать человек: что считать критичным, что считать готовым.

Это инженерное решение проблемы, описанной HBR как организационное. Не «нанять больше людей-ревьюеров», а «спроектировать процесс так, чтобы людей-ревьюеров нужно было меньше».

Заключение: я всё ещё учусь, но теперь знаю где нужно смотреть

Я не «нашёл способ не сходить с ума с 4 Claude-инструментами». Я признал, что brain fry меня цеплял регулярно, и описал, где именно.

Чек-лист из семи пунктов выше – не «как делать правильно». Это места, где я падаю. Я нарушаю свои собственные правила. Пункт 3 (закрывай задачу за один заход) я нарушил на тестах моделей. Пункт 1 (не больше 3 инструментов) я сейчас планирую нарушить, подключив Codex пятым.

Если ты сейчас ловишь brain fry на работе – проверь не «соблюдаешь ли ты правила». Проверь:

• Не врёшь ли себе про сценарий A, когда реально ты в B?

• Не списываешь ли усталость на «много задач», когда реально это +33% decision fatigue от oversight’а ИИ?

• Не давит ли руководитель «больше токенов», и если да – читал ли ты это исследование вслух перед ним?

• Защищает ли работодатель work-life balance – это самый сильный фактор защиты по цифрам.

Если хотя бы на один вопрос «да в плохую сторону» – это не ты сломан, это процесс сломан. Brain fry – не твоя слабость, а признак плохого дизайна работы вокруг ИИ.

Цифры HBR это подтверждают. И, что важнее, дают ясный язык для разговора с руководителем или командой: «Это не лень, это +33% decision fatigue. Давайте перестроим процесс».

А ещё – разрешение перестать притворяться, что у тебя всё под контролем.

Источники:

• Harvard Business Review, март 2026 – “When Using AI Leads to ‘Brain Fry’” – исследование BCG (с участием UC Riverside research assistants), 1488 респондентов. Авторы: Julie Bedard, Matthew Kropp, Megan Hsu, Olivia Karaman, Jason Hawes, Gabriella Kellerman.

• NickAlister, «Вайбкодинг – это гемблинг» – дофаминовая петля vibe coding (8 мая 2026, ~12K просмотров на момент написания этой статьи).

• Ansud, «Миллион клодобезьян: естественный отбор вайбкодинга» – математика деградации проектов (8 мая 2026, ~14K просмотров).

• Habr-пересказ HBR.

• Мой Lexis: github.com/VDV001/lexis (контекст для конкретных случаев в статье).