Реальный AI: от теории к практике

AI-first, которого нет

Недавно я столкнулся с занятным парадоксом. От разработчика ждут скорости, гибкости, точности, вайбкодинга и владения свежими инструментами. Приносят требования. Предлагаешь отсортировать их по RICE, а не по MoSCoW. И — ступор.

«У нас нет данных, это не продукт с рынком».

Но постойте. Продукт есть. Он продается, используется клиентами. Да, это десктоп-версия, не SaaS, но данные с десктопа переносимы. В интернете есть оценки по аналогам — конкуренты, их метрики, отзывы, рыночные бенчмарки. Казалось бы: зайди в DeepSeek, проведи быстрый анализ, получи RICE хотя бы предварительный. Модель может проверить наличие фактов, подсветить, где оценка завышена, а где данных просто нет. Это не идеальная приоритизация, но это движение. Вместо ступора — черновик, который можно оспорить и уточнить.

Нет. «Это недостоверно». Когда мы продаем клиенту ИИ, которая сортирует заявки или планирует продажи через модель, — достоверно. Когда применяем тот же подход к своему бэклогу — нет. Нужно живое общение. Требуют максимум, но отказываются сделать минимум. Забавно.

Это не частный случай. Исследование 2026 года, охватившее 287 продуктовых профессионалов, показало: только 7,3% респондентов часто используют ИИ и ML для приоритизации бэклога, хотя 63,4% открыты к этому. RICE требует реальных данных о reach и impact, MoSCoW — честного признания, что «must have» не равно «все хочется». Без данных любой фреймворк превращается в ритуал. Поэтому и возникает ступор: цифр нет, а без них приоритизация — политика, а не управление.

Более того, старые фреймворки в 2026 году сломались. Один из бенчмарков показал: только 6,4% фич дают 80% кликов. 94% всего, что команды шипят, игнорируется. Проблема не в RICE как методе — проблема в его входах. Vibe coding сжал цикл разработки с кварталов до дней, и та же ошибка приоритизации теперь повторяется в десять раз быстрее. AI-проекты проваливаются в 80,3% случаев, 95% GenAI-пилотов не доходят до продакшена. Не потому что модели плохи, а потому что команды строят не то.

Дальше — знакомая история. «Нам обещали за день. Авторизацию делали быстро». Окей, делали. Потому что был готовый дизайн, требования обсуждены. Но я ни разу не видел, чтобы что-то быстро сделали в продуктовой команде, где больше одного человека и больше одного мнения. По данным BairesDev, 42% разработчиков говорят, что ИИ пишет как минимум половину их кода (год назад — 12%). ИИ экономит им 13 часов в неделю на кодинге. Но 67% стали больше времени тратить на ревью ИИ-кода, а 52% — на отладку проблем, которые ИИ привнес. «Ни один из этих сэкономленных часов не вернулся», — говорит CEO BairesDev Даррен Шимкус. В командах, где нужно согласовывать мнения, скорость упирается не в код, а в координацию.

Компании называют себя AI-first, но ИИ у них не first. Люди продолжают встречаться, заметки со встреч не ведутся, цифры не фиксируются, правила не описываются. Потом возникает вопрос: «Почему так долго?» Действительно, непонятно. По данным Atlassian, 89% руководителей говорят, что ИИ ускорил работу, но только 6% уверены, что могут указать на конкретную окупаемость инвестиций в ИИ на уровне всей организации. NBER: около 70% компаний заявляют о внедрении ИИ, но почти 90% не фиксируют измеримого влияния на продуктивность или занятость. Sinch: 62% компаний уже используют ИИ-агентов в производстве, 88% ожидают этого к концу 2026 года. Techreviewer.co: 89% компаний используют ИИ для написания кода, 97% сообщают о росте продуктивности, но 90% сталкиваются как минимум с одним негативным последствием — 52,8% жалуются на галлюцинации, 44,1% — на рост нагрузки на код-ревью, 33,1% — на уязвимости в сгенерированном коде. Доля компаний, сообщающих о росте продуктивности более чем на 50%, выросла с 7,5% в 2024 году до 30,7% в 2026-м. Но рабочий документ Duke University и Федеральных резервных банков Ричмонда и Атланты, основанный на опросе почти 750 руководителей, показал: заявленный рост продуктивности от ИИ в 2025 году — 1,8%, а расчеты на основе реальной выручки и занятости дают куда более скромные цифры. «Это еще не бьет по верхней строке в полную силу, — говорит соавтор исследования Джон Грэм. — Здесь определенно есть задержка».

Andus Labs в сентябре 2026 года опубликовала Ground Truth Index — рейтинг 25 главных барьеров, мешающих корпоративному ИИ приносить отдачу. Почти половина из них связана с решениями руководства, а не с технологиями. На первом месте — «Empty Chairs»: компании дают ИИ право принимать решения, но не назначают ответственного, который может эти решения проверить или отменить. На втором — «Learning While Drowning»: сотрудников заставляют учить ИИ, не освобождая для этого время. «Модели работают. Ломается все вокруг них», — говорит CEO Andus Labs Крис Перри.

Исследование Insead и Harvard, охватившее 515 быстрорастущих стартапов, добавляет: AI-native компании примерно на 25% меньше по размеру, но эффективнее. Разница не в количестве инструментов, а в культуре: данные, метрики и обратная связь встроены в саму работу.

Проблема не в ИИ, а в том, как его используют. ИИ ускоряет создание артефактов старой проектной модели — бизнес-кейсов, роадмапов, PRD, кода. Сильные продуктовые команды применяют его иначе: для ускорения discovery, проверки гипотез и поиска решений, которые действительно работают. Разница между AI-first на словах и AI-first на деле — это разница между «мы купили инструменты» и «мы изменили способ принятия решений». Первое можно сделать за день. Второе требует времени, данных и готовности признать: старые фреймворки без новых данных остаются старыми фреймворками.

«Разработчик умирает» — это мы слышим отовсюду. ИИ пришёл, софт-скиллы теперь в цене, а код пишут все, кто умеет формулировать промпты. Но давайте заглянем в реальность.

Вы приходите на собеседование в стартап или регистрируетесь на хакатон. Команда — человек пять, максимум. Никаких продакт-менеджеров, никаких аналитиков, дизайнер — и тот редкость. Один продуктовый аналитик на всех, и всё. Вроде бы ИИ позволил ускорить разработку, и лишние роли стали не нужны. Но спрос на разработчиков не падает — он растёт. Как так?

Я решил разобраться на живом примере. Берём сервис для доменной логики, написанный не разработчиком, а «промпт-инженером» с помощью нейросети. Открываю код: цикл за циклом ходит в базу, секреты торчат в открытую, пакеты — как помойка 2018 года, Docker-контейнеры собраны на коленке, стек неоптимален, а архитектурные паттерны нарушены так лихо, что Gang of Four в гробу перевернулись. И всё это, представьте, работает. Функционально — да. Но бизнес задаёт вопросы: «Почему так долго?», «Когда поправите?», «Сможем ли мы подменить API без переписывания половины?». А в ответ — тишина. Потому что автор кода не знает, что такое индексы, кэши или хотя бы Connection Pool.

И тут самое интересное. Цифры за август–сентябрь 2026 года рисуют совершенно другую картину, чем панические заголовки. Исследование FoundRole, охватившее почти 83 тысячи вакансий, показывает: зарплаты разработчиков на 68% выше медианных по рынку — 155 тысяч против 93 тысяч долларов. При этом 37% вакансий — это fullstack, а доля удалёнки держится на уровне 24%. Более того, по контрактной статистике за год профессия «Software Developer» подскочила на 73 позиции в рейтинге востребованности, а «AI Engineer» — сразу на 119. Но есть нюанс: «Junior Developer» рухнул на 32 позиции, а его медианная зарплата упала на пятую часть за год. Младшие специалисты вымываются.

Почему? Ответ даёт исследование Microsoft, проведённое в июле–августе. Код, сгенерированный ИИ, содержит в 1,4 раза больше критических ошибок и в 1,7 раза больше серьёзных дефектов, чем написанный человеком. А уязвимости находят в 45% таких проектов. Согласно опросу Habr (317 респондентов), ИИ остаётся личным помощником, но сквозное внедрение в крупных компаниях встречается на 35% реже, чем в небольших — потому что в масштабе каждая такая ошибка превращается в пожар.

Так что же на самом деле происходит? ИИ не убил профессию. Он убил иллюзию, что можно обойтись без архитектурного мышления. Он ускорил написание кода, но не его поддержку, не его безопасность и не его эволюцию. Бизнес платит не за строки — он платит за уверенность, что система не ляжет в пятницу вечером, а API можно заменить за час, а не за месяц. И когда в ответ на вопросы — тишина, становится понятно: настоящий разработчик не тот, кто умеет генерировать, а тот, кто понимает, почему сгенерированное — плохо, и как это переделать.

Профессия не умирает. Она просто перестаёт быть массовой — и становится дорогой, зрелой и незаменимой. Именно такой, какой всегда должна была быть.

Десять лет не участвовал в ML-соревнованиях, а тут решил попробовать AI-First подход: код генерит DeepSeek, гипотезы и выводы мои. Задача от Ozon: предсказать GMV 250 тысяч клиентов на 30 дней вперёд. Данные - разрежённая матрица: почти 46% пользователей с нулевым оборотом, а один процент китов даёт непропорциональный вклад в ошибку. Оценивали по RMSLE, где значение 1.6 означает реальную ошибку в пять-шесть раз. Для прогноза это норма.
Первые дни ушли на классику. DeepSeek бодро накидал пайплайн на LightGBM. Baseline из 22 фич дал 1.6976 на публичном лидерборде. Дальше я гонял его по кругу: walk-forward, новые фичи, тюнинг. Результат полз вниз: 1.6723, потом 1.660, потом 1.6518. Казалось, ещё чуть-чуть и войдём в топ-20. Но упёрлись.
Нейросеть послушно генерировала варианты, но её мышление сузилось до банального подбора гиперпараметров. «Давай ещё раз прогоним learning_rate», - твердила она, когда я предлагал попробовать BTYD-модели или внешние макро-данные из отчётности Ozon. Я потратил день на расчёт коэффициента роста GMV из квартального отчёта, добавил его множителем, но LB не улучшился. Мы явно застряли в локальном минимуме, и DeepSeek не видел выхода.
Тогда я вспомнил, что поведение покупателей - это временные ряды. Почему мы игнорируем последовательности? Предложил попробовать рекуррентные сети. Нейросеть скептически заметила, что для табличных данных это избыточно, но код написала за минуты. GRU с шириной 4096 дал 1.6702 на LB - лучше многих бустингов. Затем я скрестил эмбеддинги из GRU с табличными фичами. Гибрид с весом нейросетевой части 0.3 выбил 1.650366 на public. Это был топ-50. DeepSeek удивился: «Не ожидал, что так сработает». Человеческая интуиция вывела модель из ступора, до которого ИИ не додумался.
Дальше я попробовал экзотику: Transformer оказался медленным и худшим (1.716), Mamba взорвалась на моих 8 гигабайтах видеопамяти, RWKV умерла, а xLSTM показал 1.6736 - клон GRU без выигрыша в разнообразии. Железо не позволяло развернуться, арендовать облако не хотелось. DeepSeek предлагал «потерпеть и тюнить дальше», но я решил остановиться на гибриде.
Финал обнажил главный урок. Public score 1.650366 (ранг 70) обернулся private 1.6655 (ранг 59). Разрыв +0.0152 - всё, что я подгонял под публичный лидерборд, не перенеслось на скрытую выборку. Табличный вариант с калибровкой оказался бы надёжнее. Это классическая ловушка соревнований, о которой все забывают.
В сухом остатке: LLM - отличный исполнитель, но слабый архитектор. Он быстро пишет шаблонный код, но застревает в привычных схемах. Человек медленнее кодит, зато способен увидеть неожиданный поворот и вытащить модель из локального минимума. AI-First работает, если первый - это человек. А ваш ИИ тоже упирается в потолок, или вам везёт больше?

Недавно я увидел конкурс от сетки, где авторов попросили рассказать о своих профессиональных привычках, и решил поделиться своей. Я разработчик, поэтому мои главные навыки строятся вокруг программирования. У меня всё просто — я программирую каждый день. Выбираю задачу, какой-то кейс или оптимизацию, и просто делаю. Либо пишу посты. В программировании мне важен не столько результат, сколько процесс, поэтому задачу каждый раз подбираю интересную. Сейчас, например, делаю модель прогноза цен на следующий период — заодно пересматриваю современные техники, которые можно запустить на обычном ноутбуке с видеокартой и процессором.
Эта привычка не просто про дисциплину. Исследования показывают: разработчики, которые перекладывают мышление на ИИ, хуже справляются с диагностикой ошибок и пониманием базовых концепций. В одном из экспериментов пользователи ИИ показали на 17% более низкие результаты в тестах на понимание кода по сравнению с теми, кто писал вручную. Это называют когнитивной разгрузкой — полное делегирование мыслительных процессов машине. Моя ежедневная практика без ИИ — прямая противоположность такому сценарию.
Если не программирую и не пишу посты, читаю книги. У меня есть полка с непрочитанными, сейчас читаю «Книгу дракона» — учебник по компиляторам. Кто-то спросит: зачем, если есть ИИ, вайб-кодинг и прочее? Всё просто — чтобы точно понимать, как и что работает, иметь стройную ментальную модель, а ещё это профилактика когнитивных искажений и возрастных изменений. Наука на моей стороне: чем больше люди полагаются на генеративные инструменты, тем меньше у них развито критическое мышление. Microsoft Research обнаружила, что высокая уверенность в ИИ коррелирует со снижением критического мышления, тогда как уверенность в собственных силах — с его ростом. Чтение фундаментальных трудов — это тренировка той самой уверенности в себе.
Есть исследования, которые показывают: продолжительные занятия укрепляют интеллект и позволяют дольше оставаться в тонусе. Годы, потраченные на учёбу, повышают интеллект примерно на 1–5 пунктов в год. Я придерживаюсь философии, где важно полагаться на себя, вкладывать в себя и развиваться. Именно ежедневными занятиями я смог раскачать технические и математические навыки. Делая по одной олимпиадной задаче каждый день, за год вошёл в топ-1 на Codewars.
Это не просто хобби. Использование ИИ ускоряет написание кода, но замедляет развитие глубоких навыков — особенно отладки и концептуального понимания. Выигрыш в пару минут может стоить потери глубокого понимания. Решая задачи вручную, я тренирую те самые навыки, которые атрофируются при полном делегировании. Кроме того, привычка писать посты — это форма рефлексии и публичного обсуждения, которая сохраняет глубину мышления. Исследования фиксируют: разработчики с ИИ задают меньше вопросов и хуже усваивают материал, чем при работе в паре с человеком. Мои тексты — это способ оставаться в диалоге с собой и аудиторией.
Получается, мои привычки — не просто рутина, а осознанная система защиты от негативных паттернов влияния ИИ. Когнитивная разгрузка, атрофия критического мышления, деградация навыков отладки, vibe coding и потеря экспертизы — всё это реальные риски, подтверждённые исследованиями. Ежедневная ручная практика, чтение фундаментальной литературы и рефлексия через тексты позволяют им противостоять. ИИ — это инструмент, а не замена мышления. Те, кто сохраняет привычку думать самостоятельно, останутся востребованными даже в эпоху самого продвинутого ИИ. Как показывают данные, способ использования ИИ важнее самого факта его использования.
#вформе

Как я перестал бояться и полюбил архитектурную энтропию: рецепт упреждающей инженерии
Осознав масштаб проблемы, я перешёл от реактивной уборки к тому, что называю упреждающей инженерией. Вместо бесконечных ручных чисток в репозитории поселились три скрипта статического аудита. analyze_openapi_entities.py строит матрицу связей сущностей, показывая, какие из них реально используются, а какие — мёртвый груз. find_frontend_orphans.py выискивает компоненты и хуки, не импортируемые нигде, кроме самих себя. analyze_backend_data_flows.py классифицирует каждый эндпоинт по типу доступа к базе и подсвечивает дублирующиеся маршруты. Все отчёты генерируются автоматически и блокируют PR, если артефакты устарели.
Параллельно мы зафиксировали принцип единого источника истины. OpenAPI-спецификация теперь генерируется напрямую из FastAPI-кода, а не пишется вручную. Утилита Orval на её основе создаёт типизированные хуки для фронтенда — так мы избавились от ручного fetch. DBML-диаграмма базы синхронизируется с SQLAlchemy-моделями. Матрицы сущностей и потоков данных не правятся руками — только генерируются. Это исключило расхождение документации и реальности.
Жёсткие конвенции добили оставшиеся лазейки. Скрипт check-no-raw-fetch.sh отклоняет PR, если видит прямой fetch. Для оптимистичных обновлений в UI заведён канонический шаблон с обязательными onMutate, onError и onSettled — никаких падений с 500-й ошибкой. Каждая миграция API завершается командой make generate-api && npx tsc --noEmit. На бэкенде включены mypy strict и Pydantic v2, на фронте вычищены все неявные any (16 файлов, +232/-89 строк) и активирован строгий режим TypeScript. Предметно-ориентированное проектирование и денормализация позволили выделить настоящие агрегаты и радикально сократить число сущностей, убрав дублирующие таблицы и связи.
Результаты не заставили себя ждать. За двое суток (3–5 августа 2026) число таблиц сократилось с 23 до 10 (–57%), 27 миграций объединились в одну, а строки миграционного кода упали на 92%: с 3000 до 227. Из API ушли дублирующие маршруты, ещё 70 устаревших эндпоинтов запланированы к удалению. С фронта исчезли 56 файлов-призраков, все вызовы API теперь идут через сгенерированные хуки. Ноль неявных any, оптимистичные обновления работают надёжно, а аудит стал детерминированным — вместо «кажется, надо почистить» мы получили точные метрики.
Разумеется, сама энтропия никуда не делась: стохастичность LLM не отменить. Однако теперь она видна заранее, а не всплывает внезапно в продакшене. Главный урок, который я вынес: инструменты должны генерировать истину, а люди — задавать правила. Да, на это потребовалось 2274 строки инфраструктурного кода, но теперь каждый PR проверяется автоматически, и разработка с агентами стала предсказуемой. Если вы тоже тонете в агентном хаосе, начните с малого: одна кодогенерируемая схема, один скрипт аудита, один чек-лист. Энтропия отступает ровно в тот момент, когда у неё забирают право быть незаметной.

Почему ваш AI-агент плодит хаос, а не код (и при чём тут фаза луны)
Когда я в очередной раз запустил оркестр агентов, чтобы быстро собрать клиентское приложение, главная боль заключалась не в том, что модель не умеет программировать. С этим LLM справляются давно. Настоящая проблема — архитектурный дрейф, который незаметно разъедает проект изнутри.
Машина воспринимает каждый диалог как изолированный фрагмент смысла. Ответ зависит от последовательности токенов, фазы луны, цвета клавиатуры и знака зодиака. Даже при низкой температуре одна и та же просьба может быть понята по-разному. Пока вы работаете в одном файле — мир прост. Но когда проект разрастается до пяти докеров в кластере, сотни роутингов, пятисот компонентов и трёх десятков таблиц, модель начинает теряться в хитросплетениях. Вам приходится следить за этим разнородным массивом: достаточно использовать синоним в промпте, и агент дорисует лишнюю страницу, модалку или целый дублирующий сервис — просто из желания угодить, даже если настроены линтинг, тесты и документация.
Именно это случилось в моём проекте. Я доверился LLM — и вместо 12 эндпоинтов получил сотню, вместо нескольких сущностей развелось 23, а на фронте нашлось 56 неиспользуемых компонентов. API-маршруты /me, /users/me, /api/v1/me вели к одному и тому же ресурсу; после миграции events → activities фронтенд догонял бэк четырьмя заплатками подряд. База данных обросла 27 миграционными файлами почти на 3000 строк, а таблицы вроде user_contents и event_attendees существовали только сами для себя. Дрейф проявлялся во всём: дублировались схемы, устаревала документация, а ручные fetch() обходили сгенерированный API-слой.
Я быстро понял, что это не единичный случай. По данным ряда исследований 2024–2026 годов, зависимость кода от формулировок оказывается критической. При семантически эквивалентных промптах структурно различный код генерируется в значительном проценте случаев. Если в запросе мелькают синонимы или несогласованные термины (скажем, «юзер», «клиент», «аккаунт» для одной сущности), вероятность разрастания системы кратно увеличивается.
Отдельный пласт — влияние «неинженерных» промптов. Когда в индустрию приходят люди без технического бэкграунда, пишут с ошибками или смешивают языки, модель начинает перестраховываться, что ведет к избыточности кода. Даже добавление вежливых оборотов, как показывают наблюдения, может увеличивать число создаваемых файлов — модель бессознательно воспроизводит паттерны развёрнутых ответов из обучающих данных.
Глобальная статистика (по данным сервисов мониторинга AI-кода) подтверждает масштаб: в проектах до 10 файлов дрейф составляет около 6%, на 50–100 файлах — уже 19%, а при >500 файлов 28–35% кодовой базы — это «дрейфовый шум». Причём 60% шума порождено всего 15% самых неоднозначных промптов. Разрыв между опытными разработчиками и новичками (14% против 29%) почти исчезает, если в проекте применяются строгие шаблоны запросов и автоматическая генерация из единой спецификации.
Вывод очевиден: дрейф — не персональная неаккуратность, а фундаментальное свойство стохастических моделей, помноженное на хаос человеческих формулировок. Единственный способ жить с этим — перестать надеяться на идеальные промпты и встроить автоматический контроль прямо в процесс разработки. О том, как я это сделал и что из этого вышло, — во второй части.

Привет, коллеги! В прошлом году защитил диплом и выложил исходники — github.com/maxbogus/fltrVd. В прошлом посте я писал о проекте, но без деталей. Сегодня — разбор по косточкам: как устроен конвейер, на чём написано, с какими граблями столкнулся и что из этого вышло.

В открытых каналах (RTSP, веб-камеры, YouTube) можно спрятать данные прямо в пикселях. Классика — LSB (младшие биты) или маскировка под высокочастотный шум. Глаз не отличит артефакт сжатия от внедрённого файла. Моя задача — научить алгоритм находить эти «закладки» и помечать подозрительные кадры, не путая их с обычным шумом или сменой сцены.

Система fltrVd — это не один скрипт, а целый пайплайн из пяти этапов:
1. Захват
2. Предобработка
3. Извлечение признаков
4. Классификация
5. Постобработка

Я сравниваю гистограммы соседних кадров четырьмя методами из OpenCV. Но одного критерия недостаточно — резкая смена сцены тоже меняет гистограмму. Поэтому все метрики идут в общий пул признаков.
LSB-проверка

Для синего канала извлекается младший бит. Считается доля единиц, бинарная энтропия и отклонение от 0.5. При случайном заполнении контейнера распределение стремится к равномерному. Есть упрощённый chi-square-тест на парах соседних значений — порог пока эвристический (15.0), дальше буду калибровать на реальных данных.
Нейросеть — не SVM, не RandomForest, а CNN на PyTorch

Да, я попробовал и классические ML-алгоритмы, но они проигрывали по точности. В итоге остановился на двух моделях:
1. TinyVGG — лёгкая CNN для быстрых экспериментов.
2. SteganalysisNet — первый слой с фиксированными SRM-фильтрами (30 штук), дальше обучаемые свёртки, BatchNorm и Global Average Pooling. Именно SRM помогает вытащить слабый стегосигнал, который обычно «тонет» в шуме.

Датасет и обучение
Сгенерировал синтетический набор:
1. 2500 изображений на класс для обучения, 725 — для теста.
2. Шумы: гауссовское, экспоненциальное, гамма-, равномерное, рэлеевское.
3. Встраивание LSB с заполнением 25%, 50%, 75%.

Обучение: 30 эпох, batch_size=32, Adam (lr=0.001), CrossEntropyLoss. Без аугментации точность на тесте ~0.614, с аугментацией на некоторых эпохах доходила до 0.839. Для синтетики — неплохо, но до промышленного применения ещё далеко.
Временные аномалии

Последовательность размеров кадров после PNG-кодирования разбивается на окна по 10 кадров. Автоэнкодер сжимает окно до двух латентных значений и пытается восстановить. Ошибка восстановления, превышающая mean + 2*std, помечается как аномалия. Так я ловлю не только одиночные «закладки», но и их влияние на поток.
Что в коде и как всё организовано

Какие были сложности (и как я их победил)
1. Не перепутать шум с контейнером — главная боль. Чистый шум, сжатие, смена сцены — всё даёт выбросы. Решение: комбинировать гистограммы, LSB-статистику, размер кадра, CNN и временную модель. Ни один признак не доминирует.
2. Скорость обработки — на первых версиях всё тормозило. Перешёл на пакетную обработку: собираю батч кадров и прогоняю через модель один раз. Добавил mixed precision, cosine scheduler, gradient clipping, early stopping — ускорило обучение и инференс.
3. Эвристические пороги — для LSB и автоэнкодера они пока ручные. В планах — подбирать их по ROC/PR-кривым на валидации, но это уже за рамками диплома.

Что получилось и куда двигаться дальше

Система обнаруживает LSB-контейнеры, которые визуально неотличимы от шума. График временного ряда чётко показывает, где заканчивается «чистый» шум и начинается подозрительная активность. Мне удалось убедиться, что совместное использование статистических критериев и нейросетей действительно работает.

Диплом дал мне бесценный опыт: я вплотную столкнулся с CV, ML, стеганографией и понял, что это не магия, а математика, которая видит то, что скрыто от глаза. Код местами сыроват — прошу прощения у будущих форкеров, но для первого погружения в тему он вполне рабочий.

Буду рад звёздочкам, вопросам в Issues и конструктивной критике. Заходите, обсуждаем!

Ссылка на проект: github.com/maxbogus/fltrVd

В 40 лет с синим дипломом бакалавра Бауманки.

В прошлом году я получил синий диплом бакалавра МГТУ им. Баумана, кафедра ИУ7. Защита была непростой, с эксцессами — совсем не как защита юриста.

Многие спрашивают: зачем в 40 лет идти в бакалавриат? Ты же директор, столько времени просрал. Честно говоря, меня задолбал синдром самозванца. Ты всегда немного сомневаешься в себе и постоянно думаешь: «А что было бы, если бы у меня был диплом?». Даже проходя очередной курс от Udacity, продолжаешь сомневаться в себе и своей базе. И вот что скажу: даже несмотря на 14 лет продакшена за плечами, опыт настройки сетей, знание устройства модемов наизусть и решение олимпиадных задач — в Бауманке было больно. Особенно с учетом совмещения с работой и рождением сына.

Сдать всё на отлично и вовремя — почти невозможно. В одиночку — невозможно. Всё изучить — невозможно. Бауманка учит выплывать вопреки.

Я нарушил один из принципов обучения — обучение в группе. Пошёл по хардкору, чтобы проверить себя, и поэтому делал всё сам. Списал за всё время 1–2 раза, и то без толку. Остальное решал сам, почти не спрашивая. Хотел понять, на что способен. Понял — на многое.

Апофеозом стал диплом. Тогда я вообще не знал, что хочу делать, и попросил Кирилла Леонидовича выбрать тему за меня. Он предложил. Я не знал, как это решать, но взялся. Более того — он мне даже не помогал. Просил — сбегал. И я ему за это благодарен. Писал без нейросетей, по старинке.

Год спустя решил прогнать этот проект через Minimax с оркестром агентов: подсобрать, стереть пыль, доработать замечания комиссии. Получилось, мне кажется, неплохо. Надеюсь, кому-то пригодится.

Что зацепило: коммерческая разработка часто сводится к перекладыванию сущностей. Задачи слишком простые и неинтересные — их можно делать по дороге в зоопарк. Я, кстати, пару раз так и делал: надиктовывал решение на скорости 100 км/ч ночью в лесу по дороге в Тверь на диктофон. И от этого, если честно, грустно.

А в дипломе было что-то настоящее. Китайская модель помогла рефакторить код и указала на слабые места — на уровне профессоров. Очень горжусь китайскими разработчиками, которые создали такой инструмент.

Именно этот гибрид — инженерная закалка Бауманки и умение оркестрировать AI-агентов — позволяет мне сейчас вытаскивать проекты, где обычное «перекладывание сущностей» не работает. Если ваш AI-продукт уперся в потолок и требует настоящей глубокой проработки — вы знаете, к кому идти.

Вывод простой: иногда делаешь вещь не для работы, а для себя. И именно такие вещи вызывают настоящее чувство удовлетворения.

Знакомо? Когда годы продакшена не спасают от мысли «а вдруг я недостаточно хорош»? Как вы справляетесь со своим синдромом самозванца — закапываетесь в хардкор или находите другие способы?

#бакалавриат #бауманка #ИУ7 #диплом #AI #агентнаяразработка

Реальный AI: от теории к практике pinned «🚀 Меня зовут Максим Богуславский. Я проектирую AI-системы, которые приносят деньги, а не хайп. 19 лет в IT: от монтажника и самоучки до CTO и основателя AI-компании. За спиной — MBA, юриспруденция, инженерный бэкграунд и десятки живых проектов в FinTech,…»

🚀 Меня зовут Максим Богуславский. Я проектирую AI-системы, которые приносят деньги, а не хайп.

19 лет в IT: от монтажника и самоучки до CTO и основателя AI-компании. За спиной — MBA, юриспруденция, инженерный бэкграунд и десятки живых проектов в FinTech, EdTech, Logistics и Mobility.

Что я умею такого, чего не умеет обычный разработчик или консультант:
1. Вижу картину целиком: от безопасности и бюджета до архитектуры и переговоров с заказчиком.
2. Строю агентные системы по принципу «скелет + мозг» — предсказуемый детерминированный каркас и управляемый LLM-слой.
3. Считаю деньги: мои клиенты сокращают расходы на API-токены и инфраструктуру на 20–60% без потери качества.
4. Работаю по модели fractional CTO: включаюсь в кризисные проекты и довожу до результата без раздувания штата.

Почему я один:
Я проповедую принцип «есть свою собачью еду». Все мои советы по оптимизации сначала проверены на себе. В моей компании нет раздутого ФОТ, офиса и «менеджеров по вайбу» — только я, мои AI-агенты и точечно привлекаемые спецы под задачу. Это даёт вам скорость и честную цену.

Здесь я пишу о:
1. архитектуре агентных систем (MCP, оркестрация, промпт-инжиниринг),
2. реальной экономике AI (цифры, кейсы, грабли),
3. управлении проектами без «базар-вокзала».

Если у вас:
• проект буксует, а AI-подрядчик не вывозит,
• счета за API пугают, а результат не радует,
• нужно спроектировать агентную систему с нуля или вытащить из кризиса текущую - напишите мне в личные сообщения. Разберём вашу ситуацию.

19 года в IT: как опыт, который не помещается в резюме, стал моим главным активом

С 2007 года я работаю в индустрии. За это время сменил несколько доменов - EdTech, FinTech, Mobility, AI, GameDev, Logistics - и накопил набор компетенций, который сложно описать одной строчкой. Продажи, юриспруденция, кибербезопасность, MBA, инженерная и продуктовая практика - навыки, которые вызывают разумное сомнение у HR при первой встрече вместе с некоторым сомнением в моей целеустремленности.

Последние 7 лет мне постоянно приходится кромсать свой опыт, так как большинство вакансий требуют либо «AI-разработчика», либо «продакта в FinTech», либо «методолога EdTech». А что делать, если в понедельник ты проектируешь агентную CRM, во вторник считаешь юнит-экономику AI-функций для образовательной платформы, в среду разбираешь legal design требований 152-ФЗ, а в четверг применяешь кейсы из Mobility, чтобы найти архитектурное решение? Ведь именно такие кейсы встречаются в стартапах и компаниях до 200 человек.

Сейчас я занимаю позицию учредителя, генерального и технического директора в компании, разрабатывающей AI-решения. Поэтому при работе с клиентом приходится управлять полным циклом: от бюджета в 638 млн рублей и безопасности до людей и продукта. Недавно как fractional-CTO я взял кейс: десять B2B-контрактов находились на грани расторжения. Чтобы сохранить шесть из них, требовалось одновременно:

- разговаривать с заказчиками на языке бизнеса (переговоры и MBA),
- оценивать обязательства и риски (юридический бэкграунд),
- перестраивать оркестрацию агентов в ERP через MCP-серверы и промпт-инжиниринг (инженерная и AI-экспертиза),
- закладывать архитектуру, которая выдержит промышленную эксплуатацию (кибербезопасность и продуктовое мышление).

Ни одна из этих компетенций по отдельности не решила бы задачу быстро, так как потребовались бы доп люди и раздувание ФОТ. Сработала именно их синергия.

Дальше — выход из кризиса поставки: мы прошли путь от нуля до регулярных релизов. Я нанял двух ключевых инженеров (управленческий навык), провёл технический аудит и встроил контроль качества там, где его раньше не существовало: версионирование промптов, аналитика поведения агентов, юнит-экономика. Попутно сократили количество контейнеров на 60% и снизили расходы на токены. Параллельно готовили продукт к запуску: платёжные шлюзы, нагрузочное тестирование, анализ безопасности — области, в которых опыт FinTech и юридической практики оказался незаменимым.

Проекты последних месяцев были очень разными: agentic CRM для строительной отрасли, RAG-система семантического поиска для лингвистов, рекомендательные сервисы для EdTech, Low-Code / No-Code агентная сеть. И в каждом случае помогала не абстрактная «технологическая эрудиция», а насмотренность, накопленная в Mobility, FinTech и образовательных продуктах. AI — сквозной инструмент, но отраслевая память превращает его из прототипа в рабочий сервис, который приносит деньги.

Именно эта гремучая смесь вывела меня в эксперта по созданию курсов по ИИ для руководителей. Потому что захотелось преподавать и потому что через меня прошёл поток реальных внедрений. Теперь я упаковываю этот опыт в образовательные траектории для топ-менеджмента — EdTech, выросший из FinTech, Mobility и AI. Такой гибрид сложно отразить в резюме, но именно за ним обращаются клиенты.

Я до сих пор не знаю, как упаковать этот путь так, чтобы он корректно считывался автоматическими фильтрами карьерных платформ. Вероятно, никак. Но рынок — особенно в турбулентное время — платит не за умение точно попасть в ключевые слова, а за способность удерживать картину целиком: от бэкенда до бюджета, от безопасности до отраслевой специфики, от инженерной детали до продажи.

Мой опыт - попытка выживания в 90х и 2000х из самоучки в технического эксперта, который в нужный момент позволяет решать задачи любой сложности за короткий промежуток времени. Если вы тоже чувствуете, что ваш профессиональный путь шире стандартных описаний, - давайте обсуждать. Возможно, проблема не в нас, а в слишком узких рамках, которые пока не учитывают мультиролевых специалистов.

Не ИИ, а «Емели»: почему деградация менеджмента разрушает индустрию (программисты тут ни при чём)

В русском фольклоре есть персонаж Емеля — парень, который лежит на печи и ждёт, что всё сделается само, по щучьему велению. Сегодня это архетип целого класса IT-менеджеров. Они не умеют управлять скоупом, не считают экономику, не понимают инженерной культуры. Но главное — они ищут не экспертизу, а «вайб» или «мэтч», веря, что правильная энергия и культурное совпадение важнее профессиональных навыков.

Этот тип массово захватил управленческие позиции, и у него появилось новое оружие — ИИ. Не против инженеров, а против самой инженерии.

ИИ как «щучье веление»
Данные не подтверждают истерику о том, что ИИ заменяет программистов. SignalFire (2026): инженеры — 55% новых наймов в тех-гигантах, исторический максимум. Спрос на квалифицированных разработчиков растёт. Дженсен Хуанг, CEO Nvidia, сказал прямо: «Маловероятно, что вас заменит ИИ. Вас обойдёт человек, который умеет его использовать».

Проблема не в технологии. Проблема в том, как её использует Емеля. Для него ИИ — та самая волшебная щука, которая должна исполнить любое желание без его участия. А раз так, зачем вообще напрягаться?

Атака на джуниоров: «печь» стала уже
Логика Емели-менеджера проста: «Сеньор с ИИ делает задачу джуниора за часы. Зачем нам джуниор?» И он прав — сегодня. Завтра станет некому стать тем самым сеньором.

Цифры жёсткие: в США количество junior-позиций рухнуло вдвое от пика 2022-го. Занятость разработчиков 22–25 лет упала на 20% (Stanford). Буткемпы, обещавшие 72% трудоустройства, скатились к 18%. Емеля не экономит — он уничтожает лестницу, по которой инженер годами карабкался от простых задач к архитектурным решениям.

Сеньор как надсмотрщик вместо мастера
Оставшихся сеньоров Емеля превращает в надзирателей ИИ-кода. Вместо созидания — бесконечный надзор за генерацией, которая «выглядит правильно, но ошибается». Сеньор-ремесленник становится конвейерным контролёром. Ирония: именно его глубокая экспертиза позволяет замечать эти ошибки, но использовать её по назначению ему больше не дают.

По данным Gartner (2025), CEO активно ищут способы сократить средний менеджмент с помощью ИИ. AI берёт на себя рутину, но не делает Емелю умнее. Напротив, теперь один Емеля с хорошим «вайбом» может управлять ещё большей командой, вообще не понимая, что происходит.

«Вайб» и «мэтч» против экспертизы
Это ключевой сдвиг. Емели нанимают и продвигают не тех, кто доказал свои компетенции, а тех, с кем «совпали по вайбу». Техническое собеседование заменяется вопросами про «культурный фит», а глубокая экспертиза воспринимается как угроза — слишком сложно, слишком непонятно, «ты просто не мэтчишься с командой».

Так управленческий класс замыкается в аквариуме с комфортной водой, где нет неудобных вопросов, нет архитектурных споров, нет критериев качества — только ощущение, что «мы классно вибрируем». Результат: решения принимаются не на основе данных и опыта, а на основе того, насколько идея «заходит» эмоционально.

Замкнутый круг деградации
Цепочка неумолима:
1. Емеля не разбирается в инженерии и ищет «мэтч», а не навыки.
2. Он убирает джуниоров — потому что «сеньор с ИИ дешевле и не спорит».
3. Сеньоры перестают строить и становятся контролёрами машин.
4. Новых сеньоров неоткуда взяться — джуниоров не обучают, «вайб» не растит экспертизу.
5. Качество падает, а ИИ продолжает генерировать код, ошибки в котором способен заметить только опытный глаз — и которого скоро не будет.

Индустрия, где управленцы — Емели, а инженерная культура подменена «вайбом» и верой в волшебного ИИ, через пять-десять лет окажется без тех, кто умеет строить. Это не прогноз, это данные 2025–2026 годов. Программисты тут ни при чём. Вирус — в менеджменте.

20 лет в разработке. MBA. «Бауманка». 10 лет в руководстве. И я устал, но...

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

Особенно там, где вроде бы пытаются сохранить дух стартапа, а сами уже — ентерпрайз на 2500 человек. Митинги ради митингов. Согласования ради согласований. И момент, когда Вася без технического образования вдруг ловит «озарение», как правильно делать авторизацию. Или почему синхронные вызовы — это ад. И ты сидишь и думаешь: «Господи, за что».

Я долго считал, что агентная разработка — это очередной хайп. Ну, такой же фейк, как «мы переходим на Agile» в департаменте из трёх тысяч человек. Но в прошлом году начал погружаться. И понял: не фейк.

Да, работает нестабильно. Примерно так же, как люди. Иногда сотрудники приходят на работу пьяными или под грибами — и ничего, терпим. LLM тоже глючит, галлюцинирует, путает языки. Но есть одно критическое различие.

Нет подковёрных решений.

С LLM ты хотя бы точно знаешь её особенности и пределы непредсказуемости. Она не играет в политику. Не копит обиду. Не «забывает» предупредить о риске, потому что «ну, я думал, это и так понятно». С ней ты — дирижёр. Или, если угодно, Аид. Подземный Зевс. Тот, кто не просто управляет, а властвует над самими основами процесса. Гефест куёт свои механизмы, а ты — решаешь, как они будут работать, без оглядки на чьё-то эго.

Я как архитектор хочу одного: свести дебильное общение к минимуму. Оставить только суть. И вот тут AI-агенты дают то, чего не даёт ни одна org structure: прозрачность без политики и исполнительность без переработок.

В моей текущей системе агент закрывает роли разработчика, ревьюера, девопса и даже продакт-менеджера. Я лишь задаю направление. И главное — больше никаких «озарений» от Васи. Есть зафиксированные правила, архитектурные решения и автоматический аудит того, что раньше приходилось вылавливать руками.

Это не волшебная таблетка. Это архитектура. Методология. Её нужно правильно выстроить, но когда она работает — ты перестаёшь быть пожарным и становишься создателем.

Если вам тоже надоел базар-вокзал и хочется обсудить, как перевести рутину на агентов, а себе оставить стратегию и архитектуру — напишите в личные сообщения. Я расскажу, с чего начать и какие грабли я уже собрал за вас.

Гибридный стек и трезвый взгляд на агентные системы

Предыдущие два поста подводят к центральному архитектурному принципу: агентная система должна состоять из двух чётко разделённых слоёв.

Первый — детерминированный скелет. Это код, базы данных, REST/GraphQL API, очереди сообщений, workflow-движки. Всё, что можно протестировать, верифицировать и гарантировать. Второй — недетерминированный мозг. LLM и промпты. Вся вариативность, которую мы допускаем, должна быть ограничена этим слоем, а его выходы обязаны проходить через жёсткие валидационные ворота обратно в скелет.

MCP и A2A в этом стеке — адаптеры, а не замена существующей инфраструктуры. За каждым MCP-сервером стоит проверенный API с контрактом. Агент получает доступ к инструментам, но не подменяет их собой. Ровно так же A2A (Agent-to-Agent) стандартизирует взаимодействие между агентами, но не отменяет необходимости в классических протоколах передачи данных.

Отдельное требование — observability как first-class citizen. К классическому distributed tracing добавляются LLM-специфичные метрики: токсичность, галлюцинации, стоимость задачи, количество вызовов инструментов. Принципиально важно отвечать не только на вопрос «что произошло», но и «почему агент принял такое решение». Без этого инженерная команда остаётся слепа.

HITL в критических точках и Event Sourcing для аудита решений — не опциональные украшения, а страховочные механизмы. Агент может предлагать действие, но не выполнять его без подтверждения, а каждое его решение должно быть сохранено как событие для последующего анализа и, при необходимости, отката.

Итог не новый, но отрезвляющий. Мы знаем, что агентные системы нестабильны, что промпты плывут, MCP-серверы падают, а оркестрация может превратиться в хаос. Однако мы знаем, как это исправить — не магией, а инженерной дисциплиной. Разделение скелета и мозга, валидация выходов, observability, контроль человека, событийный аудит. Это не хайп, это эволюционное расширение проверенных архитектурных паттернов. И именно в этом — зрелость AI-инжиниринга.

Оркестрация: workflow-движки против LLM-графов

Второй срез, где агентные системы вступают в конфликт с классической инженерией, — оркестрация.

Традиционные workflow-движки (Temporal, Camunda) строятся на жёстких схемах. Шаг A всегда предшествует шагу B, откат идёт по компенсационным транзакциям, идемпотентность гарантирована. Агентная оркестрация устроена иначе. Здесь оркестратором выступает LLM, которая динамически определяет последовательность действий. Паттерны ReAct, Plan-and-Execute, Supervisor + Workers, LangGraph-графы объединяет отказ от заранее заданной схемы в пользу рантайм-планирования.

Это даёт гибкость, недоступную классическим workflow, но плата за неё — потеря предсказуемости. Тот же промпт, тот же контекст — и агент может пойти по разным цепочкам вызовов. Он может зациклиться, выбрать нерелевантный инструмент, сгенерировать галлюцинацию. Метафора «русской рулетки» здесь описывает не эмоции, а реальный инженерный риск: отсутствие гарантий повторяемости.

Что из классики необходимо заимствовать в обязательном порядке:
1. Structured Output (JSON Schema). Без жёсткой валидации выходных данных агента любая последующая детерминированная логика обречена.
2. Hard checkpoints и Human-in-the-Loop. Критические действия — платежи, изменения в production, юридически значимые операции — не должны выполняться без подтверждения человека.
3. Retry с детерминированной логикой. Не всякая ошибка исправляется переспросом LLM; для некоторых операций нужен классический экспоненциальный backoff и fallback.

Отдельного внимания заслуживает попытка применить паттерн Saga к мультиагентным взаимодействиям. Если рассматривать каждое решение агента как событие, которое можно сохранить (Event Sourcing), мы получаем воспроизводимость, аудит и потенциальную возможность отката. Но реализация упирается в недетерминизм повторов (тот же промпт может дать иной результат) и объём данных. Тем не менее без этой базы мы даже не можем установить, почему агент ошибся. Event Sourcing для агентов — не серебряная пуля, а необходимый гигиенический минимум.

Агентный оркестратор, таким образом, не заменяет workflow-движок. Он надстраивается над ним. Сильный инженер оставляет жёсткий детерминированный скелет и позволяет LLM импровизировать только внутри проверенных, валидированных ворот.

Почему промпт не заменяет GraphQL, а MCP — не шина данных

Начинать разговор об агентных архитектурах стоит с отрезвляющего тезиса: промпт не является заменой ни агрегирующим запросам, ни GraphQL, ни контекстному поиску. Это распространённое упрощение, которое на практике ведёт к архитектурной деградации.

Промпт — слой интерпретации. Он получает уже собранные и переданные в контекст данные и объясняет модели, что с ними делать. Сам он не умеет обращаться к базе, строить join'ы и резолвить эндпоинты. Путать его со средствами доступа к данным — значит добровольно отказываться от контрактов, строгой схемы и предсказуемости.

Однако возникает закономерный вопрос: если промпт только интерпретирует, то каким образом агент динамически выбирает инструменты и источники? Здесь появляется Model Context Protocol (MCP) — и вместе с ним новая волна заблуждений. MCP-сервер описывают как замену шины данных и GraphQL, что технически некорректно.

MCP — это универсальный адаптер. Он предоставляет агенту стандартизированный интерфейс к трём сущностям: Tools (действия), Resources (данные), Prompts (шаблоны). Но под капотом MCP-сервер вызывает те же REST, GraphQL или SQL, а не подменяет их. Он не занимается трансформацией сообщений, не гарантирует доставку, не обеспечивает транзакционную целостность и, главное, не принимает решений о маршрутизации. Решение о том, какой инструмент вызвать, принимает LLM — недетерминированно, на основе описания.

Именно здесь возникает то самое «поле чудес и русская рулетка», о которых говорилось ранее: агент угадывает инструмент, а результат этого угадывания может быть как точным, так и разрушительным. MCP здесь выполняет роль стандартизированного слоя доступа, но не роль шины данных. Считать «агент + MCP» эволюцией ESB — ошибка. ESB обеспечивает детерминированную маршрутизацию по правилам; MCP обеспечивает стохастический выбор, ограниченный лишь качеством промпта и описаний инструментов.

Практический вывод: антипаттерн «заменили GraphQL промптом» не просто неточен, он опасен. Правильная архитектура подразумевает чёткое разделение: GraphQL и REST — для детерминированной работы с данными, промпты и MCP-адаптеры — для недетерминированного принятия решений. Агент без проверенной API-подложки беспомощен, а его «гибкость» превращается в генератор ошибок.

Парадокс управления при разработке AI-продуктов

Сейчас во все щели и дыры нам пихают ИИ. Мы массово переходим на генеративные инструменты, планируем продукты с GenAI, думаем о том, как сократить, переиспользовать и автоматизировать разработку. Бизнес этого хочет и мечтает. Но стоит нам начать использовать GenAI для общения с самим бизнесом — возникает любопытный парадокс. Нас тут же обвиняют в нейрослопе и brain rot.

За последние восемь месяцев я собрал минимум пять разных кейсов — заказная разработка, fractional CTO, консультации по исследованиям. В сумме с чужими наблюдениями из соцсетей складывается тревожная картина. Мы внедряем AI везде: анализируем ответы клиентов через генеративные модели, генерируем вопросы для коммуникации, работаем с суппортом, пишем тексты, проводим аудиты, создаём отчёты для начальства. Но когда тот же самый бизнес, который требует экономии, скорости и масштабирования, получает от нас AI-сгенерированное сообщение — он чувствует себя оскорблённым. Ему не хватает «человеческого общения».

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

Я смотрю на стол, где перед каждым лежит телефон. Любой телефон — включённый или выключенный — это микрофон, процессор, хранилище, батарейка и сетевой адаптер. Мы всегда сидим с диктофоном. Приватность разговора, когда у всех на столе гаджеты и любой может начать запись, — оксюморон. Тем не менее иллюзия приватности и «живого» контакта перевешивает здравый смысл.

Тут я вспоминаю принцип Toyota из кайдзен: мы должны сами использовать свой продукт, чтобы прожить боли клиентов и на основе этого анализа улучшать продукт. Если ты строишь бизнес на GenAI-решениях, но тебя тошнит от GenAI-письма — значит, ты отказываешься есть собственную собачью еду. Но почему?

Разгадка, как выясняется, имеет научное обоснование. Свежие исследования 2025–2026 годов вскрывают системный психологический сдвиг.

Во-первых, Coman и Cardon (2026) опросили 1100 профессионалов и выявили «разрыв восприятия». Когда руководитель использует AI в письме с похвалой или обратной связью, сотрудники оценивают его искренность на 40–52% ниже, чем если бы письмо было написано вручную. Но собственное использование AI теми же сотрудниками не вызывает у них сомнений в искренности. Люди думают: «Я-то AI-текст проверяю и вкладываю душу, а руководитель — просто поленился». Двойной стандарт налицо.

Во-вторых, Hunter.io (2025) обнаружили парадокс холодных писем в B2B. 47% профессионалов говорят, что не ответят на письмо, если заподозрят в нём AI. Но 67% тех же самых людей, выступая в роли получателей, признают, что им всё равно, написано письмо AI или человеком, если оно релевантно. Мы боимся, что получатель накажет нас за AI, хотя на деле он наказывает только за плохой контент.

В-третьих, Hajder (2025) экспериментально доказал: сама по себе пометка «создано AI» снижает воспринимаемую подлинность сообщения, даже если получатель отлично знаком с AI и активно им пользуется. Это чистая эмоциональная реакция, которую не снимает рациональное понимание технологии.

Объединим: бизнес видит в нашем AI-письме не результат работы умного инструмента, а сигнал «мы не захотели тратить на тебя своё драгоценное человеческое время». Требуя от нас внедрять AI для экономии, заказчик невольно требует признать, что его собственное время не настолько ценно, чтобы на него тратили живого человека. А с этим смириться невозможно.

Значит ли это, что «есть свой продукт» в эпоху GenAI — утопия? Должны ли мы принять, что AI-коммуникация всегда будет восприниматься как угроза статусу, и оставить людям островок «настоящего» общения, даже если он технологически иллюзорен? Или наша задача — последовательно приучать бизнес к тому, что AI-сообщение — это и есть проявление уважения: мы потратили меньше рутины, чтобы освободить голову для сложных задач?

Что думаете вы? Вам знакомо такое отторжение — и с какой стороны баррикад вы его наблюдали?

Мой стиль работы с AI-агентом — это не магия и не «сгенерируй мне приложение». Это task plan-based метод:
1. Формулировка задачи с приоритетом.
2. Создание чек-листа (focus chain) — агент понимает, куда идти.
3. Фаза plan — исследование, CoT, валидация архитектуры.
4. Фаза act — быстрая реализация под присмотром.
5. Итеративная приёмка и движение по чек-листу до 100%.

Цифры показывают, что такой подход даёт предсказуемо высокий процент завершения, ничтожную стоимость, высокий темп итераций и минимальный оверхед на переделку. Конечно, данные не идеальны: метрики churn (реального переписывания файлов) пока не собираются, и без них я не могу утверждать, что модель не переписывает одно и то же. Но косвенные признаки — высокий процент завершённости, быстрые итерации, малое активное время — скорее свидетельствуют о том, что переписываний немного.

Если вы слышите «вайб-кодинг» и представляете хаотичное «сделай красиво», мои 787 задач показывают обратное: за фасадом простого общения с агентом стоит строгая система планирования, приоритезации и рефлексии. Именно она позволяет превратить AI в производительного напарника, который не просто отвлекает, а методично закрывает пункты бэклога — быстро, дёшево и с понятным результатом.