После моей статьи про 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. Я хочу сделать то же самое через двух разных вендоров.
Аргументы «за»
Снижение vendor lock-in. Если Anthropic или OpenAI выкатит плохой релиз, у меня есть запасной канал.
Cross-model critique работает на практике: Gemini за 30 секунд находит дыры, которые Claude пропустил при первичной генерации (есть отдельный кейс про paywall с loyalty-кредитами, где Claude спроектировал, Gemini поймал критическую ошибку).
Разделение труда снижает контекст в каждой сессии. Claude Code не пишет код - значит, не нужно держать всю кодовую базу в его контексте. Только архитектурные документы.
Аргументы «против» - которые ровно про эту статью
HBR говорит: оптимум - 3 инструмента. Я уже на 4 (Code/Cowork/Design/Chat). Codex - пятый. По цифрам исследования я двигаюсь в сторону +14% когнитивной нагрузки и +12% усталости. Не то, что это возможно, а с количественным прогнозом.
$40/мес - это формализация привычки. NickAlister прямо предупреждает: компании подсаживают на дешёвой первой дозе. $20/мес - дешёвая первая доза. $40/мес - признание, что я в этой петле, и решение пойти глубже, а не выйти.
Двойной oversight burden. Если я ревьюю и план Claude Code, и реализацию Codex - я ревьюю в два раза больше. Это сценарий B в квадрате. Если я не ревьюю реализацию - это автономный режим без надёжного стоп-критерия (см. свежий разбор production-фейлов Cursor / PocketOS).
Скрытая дофаминовая петля «попробую новый инструмент». Я узнал, что 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 (ИИ убирает рутину). Это не природа домена, а дизайн внедрения.
Аргументы:
Один и тот же маркетолог в разных процессах даст разный brain fry. Если Claude генерит первые драфты, а человек выбирает 1 из 5 и публикует - сценарий A, brain fry низкий. Если Claude выдаёт 50 вариантов, а человек ревьюит каждый - сценарий B, brain fry высокий. Домен один, выводы разные.
Корпоративные KPI давят в сценарий B. «Сколько постов сгенерировано» - сценарий B по дизайну. «Сколько кампаний вышло качественных» - сценарий A. Маркетинг чаще измеряют первым способом.
Раннее массовое внедрение. Маркетинг и 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 просмотров).
Мой Lexis: github.com/VDV001/lexis (контекст для конкретных случаев в статье).
