PRO продукты и системы | Иннокентий Бодров

Ну что ж, сегодня у меня двойной день X.

Редко бывает так, что в один день сходятся сразу две точки, к которым ты долго шёл:
— запуск первого собственного вайб-продукта,
— и старт нового курса, который долго складывался в голове, разговорах, заметках и экспериментах.

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

Сегодня как раз такой день.
Дальше — подробнее, отдельными постами.

🎯 ПРОГРАММА АМ16 СОБРАНА!

Коллеги приглашаю всех в эту субботу 7го февраля на 16 мега выпуск Аналитического марафона.

Основные блоки конференции:

БЛОК 1: АРХИТЕКТУРА И ИНТЕГРАЦИЯ
- Практика гибридных архитектур — получите готовую схему выбора и чек-лист для принятия решений
- Нефункциональные требования к асинхронной интеграции — научитесь задавать требования к брокерам сообщений так, чтобы их понимали все
- Будущее ИТ-архитектуры в эпоху ИИ — узнаем, останемся ли мы нужны, когда код пишут нейросети

БЛОК 2: API, БЕЗОПАСНОСТЬ И ДАННЫЕ
- Restы: базовые навыки + фишки — пройдём полное собеседование и получим чек-лист для работы
- Безопасность API: от Basic Auth до OAuth 2.0 — live-демо с реальными тестами на публичных API
- ETL, ELT, CDC, Stream — наконец-то расставим всё по полочкам в мире данных

БЛОК 3: ИНСТРУМЕНТЫ И ПРАКТИКА
- Как выкатить сервис без команды и без магии — от идеи до работающего API с live-демо
- Лего-программирование для аналитика — no/low-code на практике, от автоматизаций до AI-агентов
- Как создать хорошее API: сторона аналитика — почему DTO и структуры данных — ваша зона ответственности
- A/B-платформа: трудности перевода аналитика — от бизнес-гипотез до отказоустойчивых микросервисов

🔥 СПИКЕРСКИЙ СОСТАВ — ТОПОВЫЙ
🔥 ТЕМЫ — ОГНЕННЫЕ И ПРАКТИЧЕСКИЕ
🔥 ФОРМАТ — БЕЗ ВОДЫ, ТОЛЬКО ПРИМЕНЯЕМЫЕ ЗНАНИЯ

❤️ Зарегистрироваться и посмотреть всю программу можно по ссылке:
ССЫЛКА НА КОНФЕРЕНЦИЮ

По промокоду PROANALIS_AM16 - 15% скидка подписчикам канала.

Чем я занимаюсь в 8 утра в воскресенье?

Редкий случай: рано лёг, нормально выспался, проснулся бодрым и в хорошем настроении.
И на что я решил это потратить?

Правильно — на вот эти три чудесных экрана.

Три разных проекта, запущенных в Antigravity. За сегодняшнее утро я уже полностью высадил квоту на Gemini 3 Pro. Сейчас добиваю Gemini Flash, а дальше в ход пойдёт Claude — его тоже можно довольно эффективно «сжигать» в этом сетапе.

С одной стороны, выглядит это, конечно, слегка идиотично.
С другой — это именно то, что меня по-настоящему радует и от чего я получаю удовольствие.

Очень надеюсь, что сегодня получится запустить хотя бы один из этих проектов.
Ладно, если честно — два.
Потому что третий — это рабочий прототип, который я собираю под показ в понедельник–вторник.

А вот два других — это мои собственные сайд-проекты, сайты, которые я давно хотел довести до релиза. И я правда надеюсь порадовать вас ими уже в ближайшие дни.

Так что — stay tuned 🚀

POST-запрос с пустым телом, или Как не надо проектировать API

Я думал, такое бывает только в айтишных страшилках. Но нет — это реальный прод.

Делаем интеграцию. Задача простая: добавить комментарий к сущности в сторонней системе. Присылают Swagger, Postman-коллекцию — всё чинно. Открываю и проваливаюсь в кроличью нору.

Картина маслом: Есть эндпоинт на добавление коммента. Это POST. Казалось бы, логично. Но дальше начинается магия:

Тело запроса (Body) — абсолютно пустое.

Текст комментария, все ID, метаданные — всё запихнуто в URL и PATH параметры.

Что должно произойти в голове человека, чтобы спроектировать API вот так? Это как прийти в ресторан, заказать суп, но вместо того чтобы положить его в тарелку, официант распишет его состав на чеке и скажет: «Ешьте текст».

Почему это больно: Мы часто спорим о «высоких материях», но иногда всё упирается в базу.

GET — получить.

POST — создать.

PUT/PATCH — изменить.

Это не просто «душные правила» из учебников. Это семантика. Это язык, на котором общаются системы. Когда вы его ломаете, вы создаете легаси, которое будет сниться в кошмарах следующим поколениям аналитиков.

К чему я это всё: В «Вайб-аналитике» есть важное правило: структура возникает в процессе, но она должна опираться на фундамент. ИИ — крутой напарник, он может собрать прототип за час, но если вы не понимаете семантику HTTP, вы просто научите нейронку плодить такой же треш быстрее, чем человек.


А какой самый странный эндпоинт видели вы? Пишите в комментах, померимся шрамами. 👇

Последний шанс запрыгнуть на эфир!

А я напоминаю, что буквально через 1,5 часа у нас будет первый в этом году эфир Аналитик и ИИ
Регистрация в боте

Привет. Давненько я не разбирал статьи.

На днях попалась статья с говорящим названием:
«Как аналитику работать в условиях неопределенности, когда бизнес не знает, чего хочет».

Сначала, честно, было желание написать гневный пост:
«Ну вот, опять бизнес плохой, опять не знает, чего хочет».

Открыл — и неожиданно понял, что она… нормальная. Более того, полезная.

Да, местами базово. Местами наивно.
Но если у тебя не десять лет за плечами — это реально важные вещи.
Особенно понимание почему люди не могут чётко сформулировать, что им нужно.

И главный вывод автора мне зашёл полностью:
сначала разберись, в чём проблема, а уже потом начинай что-то делать.

Потому что корень большинства конфликтов между бизнесом и аналитиками — в языке.

Бизнес говорит на языке бизнеса:

— «мы теряем деньги вот здесь»
— «этот процесс слишком долгий»
— «клиенты отваливаются на этом шаге»

Но бизнес не обязан и не будет рассказывать:
— как правильно автоматизировать процесс
— какую систему спроектировать
— какие поля и статусы нужны в сущностях
И это нормально.

Придумать, как решить проблему — это и есть наша работа.
За это нам, вообще-то, и платят деньги.

Ждать, что заказчик полностью распишет решение, принесёт готовое ТЗ или «выложит всё на блюдечке» — это, если честно, довольно наивная позиция.

Аналитик здесь ровно в той же роли, что и маркетолог:
есть бизнес-проблема → есть цель → дальше ты подбираешь инструменты, гипотезы, решения.

Не потому что «бизнес тупой», а потому что это зона нашей профессиональной ответственности.

Именно поэтому я всегда говорил и продолжаю говорить: чтобы решать задачи бизнеса, нужно общаться с бизнесом.
Понимать, как он зарабатывает.
Где у него боли.
Какие у него цели.

А не просто идти на поводу и писать ТЗ «по запросу».
И уж тем более не сразу бежать кодить.

Практически все мои последние обучения крутятся вокруг этой идеи:
личные форматы в Аналитической мастерской, курс по Technical Product Management, будущая «Вайб-аналитика», курсы для других школ.

Это всё про одно:
аналитик должен понимать, как работает бизнес.
А не ждать, что бизнес разберётся, как работает айтишка.

Потому что если бизнес начнёт разбираться в айтишке сам —
в эпоху вайб-кодинга и ИИ он вполне сможет обойтись без нас.

А значит, в наших же интересах быть теми, кто:
— понимает контекст
— видит систему целиком
— и реально помогает решать задачи, а не просто «обслуживает требования»

Что думаете?

Почему 12, а не 100?

Вчера открыл предзапись на курс по вайб-аналитике — сейчас осталось 6 мест из 12.

Я специально зарезал размер группы.
На практических занятиях будем работать подгруппами по 4 человека. В четвёрке каждый успевает думать вслух, никто не прячется за спинами активных. Я могу зайти в каждую группу и разобрать конкретный затык — в логике, в промпте, в том, как вы пытаетесь упаковать хаос требований в рабочую систему.
Мне не нужны 100 человек, которые поставят лекцию на фон и выпишут три инсайта в notion. Мне важно видеть, как вы думаете. Где буксуете. Что не получается, даже когда вроде всё понятно.
Это не может работать в большой группе.

Коротко:
12 человек, занято 6, свободно ещё 6.
Старт 4 февраля, открытый эфир.
Дальше — среды, 20:00 МСК.
Цена сейчас — 8 900₽. Это цена первопроходца. Следующий поток будет кратно дороже, когда методология обкатается и превратится из эксперимента в продукт.
Я честно говорю: первый поток — это живой процесс. Мы вместе будем ломать привычку «писать ТЗ ради ТЗ» и учиться думать через прототипы.
Если готовы запрыгнуть в этот эксперимент — ссылка на оплату в боте

В какой-то момент я понял, что про партнёрства и интеграции мы слишком часто говорим абстрактно — на уровне «API есть, документация есть, поехали». А вот про реальное качество этих API и про то, как с ними живётся, говорим куда реже.

Вспомнилась история из практики. Работали мы с одним итальянским провайдером квалифицированной электронной подписи. По европейским меркам — вполне себе серьёзный игрок, что-то вроде местного аналога Контура. И здесь сразу важный нюанс: в Европе электронная подпись используется не только для фиксации неизменности документа и авторства подписанта, но и как инструмент KYC. То есть это уже не совсем «каноничный» кейс подписи, а такой сайд-кейс. Формально подпись есть, но сценарий использования чуть шире, чем предполагал оператор. Ладно, с этим можно жить.

А дальше начинается самое интересное — ответы API.

Например, регулярно прилетает 413 Request Too Large. В запросе — несколько PDF-документов на подпись. Да, их семь. Но каждая PDF весит меньше 500 КБ. В сумме — около 3,5 МБ. Не 300. Не 30. Три с половиной. И, конечно же, в документации ни слова про лимиты. Вообще ни слова. Просто «413». Дальше думай сам.

Другой пример — прилетает 5xx. Ну окей, серверная ошибка. Но в теле ответа при этом очень подробно описано, почему сервер «упал». Я, честно говоря, такое видел впервые. По логике это чистая 4xx — некорректные данные или состояние запроса. Но нет, это 5xx, потому что… потому что так.

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

И вот здесь у меня всегда возникает один и тот же вопрос:
а мы вообще помним, что с API работают люди?

Да, формально API — это интерфейс «машина-машина». Но на другом конце почти всегда есть разработчик, аналитик, интегратор. Человек, который пытается понять:
— это моя ошибка?
— это ограничение сервиса?
— это временный сбой?
— можно ли ретраить?
— нужно ли писать в саппорт и ждать три дня?

Когда ответ выглядит как «413 Request Too Large» без указания лимитов — это не техническая ошибка. Это провал в developer experience. Когда сервер возвращает 5xx с текстом «потому что данные не такие» — это не архитектура. Это отсутствие заботы о пользователе.

Я всегда стараюсь делать свои API так, чтобы ошибка помогала диагностировать проблему. Не просто код, а контекст: какой лимит, какое поле, какое ожидание нарушено, что можно сделать дальше. Потому что иначе вы перекладываете свою неопределённость на чужую команду.

И вот тут мы снова возвращаемся к теме, которую много обсуждали на курсе по Technical Product Management — developer experience. Он не появляется сам. Его не создаёт документация «для галочки». Его создаёт мышление: относиться к пользователям API так же, как к любым другим пользователям продукта.

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

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

Вайб-аналитика. Или почему аналитику пора перестать бояться ИИ

Я долго думал, как назвать то, что происходит с аналитикой прямо сейчас.
Есть такой термин — Vibe-coding. Это когда ты пишешь код «по ощущениям», в диалоге с AI, без тяжелой архитектуры в голове, но с чутьём на то, как это должно работать. Инженеры-олдскулы морщатся, а аналитики вообще не понимают: «При чём тут мы? Нам же просто ТЗ писать».

А мир-то уже поменялся.

Раньше работа аналитика была похожа на «глухой телефон». Ты месяц пишешь требования, еще месяц разработка собирает MVP. В итоге выясняется, что половину забыли, а вторую поняли не так. Выгорают все.
Сейчас аналитик может за вечер собрать прототип сам. Не «картинку в Figma», которую программисты потом назовут невозможной, а рабочую штуку — с логикой, базой и кнопками. И прийти к команде не с бумажкой, а со словами: «Вот. Покликайте. Я имею в виду именно это».
Это не делает вас программистами. Это делает вас проектировщиками, которые тестируют гипотезы со скоростью мысли.

Что такое «Вайб-аналитика»? Это не про хаос. Это про то, что структура рождается в процессе, а не «до». Вы начинаете с нечёткой идеи, проговариваете её с AI, уточняете, ошибаетесь и тут же фиксите.

Это чистый кайф — видеть, как твоя мысль мгновенно превращается в код.

Я запускаю курс про это. Мы не будем учиться «писать калькулятор» (хотя для разминки сделаем и это). Мы будем учиться:
Использовать AI как расширение своего мозга, а не как замену поисковику.
Скармливать контекст так, чтобы на выходе была архитектура, а не каша.
Собирать рабочие прототипы, которые «продают» вашу идею лучше любого документа на 40 страниц.

Формат:

4 февраля — открытое занятие (бесплатно). Расскажу, почему аналитик без AI в 2026 году — это как бухгалтер со счетами.
5 занятий + защита проекта. 70% времени вы будете кодить (да-да!) и проектировать в группах.

Цена: Пока что Early Bird — 8900₽. К февралю подниму.

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

Наконец-то ИИ дал нам эту суперсилу. Пора её забирать.

Всем привет! Короткое обновление, эфир про аналитика и ИИ с Ильёй перенесли на среду, 28 января!
Регистрация по прежнему в боте (дату там скоро поправлю)

Вчера была защита проектных работ на интенсиве по переходу в технический продакт-менеджмент.

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

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

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

При этом за четыре занятия мы, по сути, сделали довольно базовую, но для многих болезненную работу:
— перевернули привычное технарское представление о продукте,
— попробовали выстроить в голове реальный код бизнеса, а не абстрактные «value» и «impact»,
— разобрали, чем платформа или техническое решение на самом деле помогает бизнесу,
— и как это всё объяснять так, чтобы тебя понимали и бизнес, и разработчики.

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

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

Так что да — первый блин точно не получился комом.
Отзывы это подтверждают, но, если честно, даже без них было понятно, что польза случилась.

Скорее всего, будет второй запуск.
И, кажется, в следующий раз планку придётся поднимать уже с самого начала.

Иногда автоматизация начинается не с «давайте сделаем продукт», а с очень приземлённого раздражения.

Я заметил, что у меня есть мысли — длинные, неаккуратные, часто хорошие, — но путь от них до опубликованного поста в Telegram каждый раз почему-то занимал несоразмерно много энергии.
Не потому что сложно.
А потому что нужно сесть, собраться, начать, а потом ещё и не скатиться в либо занудство, либо упрощение.

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

Не «пишет за меня».
Не «генерирует контент».
А именно — берёт мой сырой текст, голосовые заметки или обрывок мысли и превращает это в первый слой формы. Черновик. Заготовку. Поверхность, об которую уже можно думать.

И тут вскрылась интересная точка напряжения.

Я не хочу отдавать мышление модели.
Но я с радостью отдаю ей сопротивление пустого листа.

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

Самое ценное — я перестал путать:

мышление и форматирование

позицию и редактуру

смысл и усилие начать

В итоге я почти всегда переписываю черновик. Иногда — полностью. Иногда — оставляя только структуру.
Но я больше не начинаю с нуля.

И, кажется, в этом и есть здоровая модель взаимодействия с AI:
не как с автором,
не как с оракулом,
а как с очень терпеливым черновиком, который никогда не устает и не обижается, что ты всё переписал.

Вопрос, который у меня остаётся открытым:
где для каждого из нас проходит граница между «AI помогает думать» и «AI думает вместо» — и как не проскочить её незаметно?

Коллеги, добрый день! ✨

Мы работаем над программой не покладая рук! Только на этой неделе можем похвастаться новыми тремя спикерами

🔮 Бодров Иннокентий | «Как аналитику выкатить сервис без команды и без магии»
Разберём вайб-кодинг без хайпа, управление смыслами и рисками с LLM и создадим работающий backend-сервис с деплоем. В финале — live-демо: от идеи до curl-запроса к настоящему API.

🔧 Бурмистров Владимир | «Restы. Базовые навыки + фишки»
Пройдём полное собеседование: спроектируем API с нуля, разберём REST, безопасность, версионирование и получим чек-лист для работы

📊 Половинкина Татьяна | «ETL, ELT, CDC, Stream: Как не запутаться в алфавите данных»
Навигационная карта по миру данных: отличия ETL от ELT, пакетная и потоковая обработка, CDC, а ещё Reverse ETL и Zero ETL.

И это не конец! На следующей неделе программа станет ещё сильнее

🔥 Спешите зарегистрироваться до подорожания!
👉🏻 ссылка 👈🏻
👉🏻 ссылка 👈🏻
👉🏻 ссылка 👈🏻

А тем, кто оформляет участие от юрлиц, лучше начать согласование пораньше. Ссылка для оплаты юридическим лицам

Следите за анонсами — впереди ещё много интересного! 🚀

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

❓Как ускорить разработку в 3 раза с помощью ИИ?

Если вы всё еще пишете весь код вручную - вы теряете время. Современные нейросети - это не просто «чат», это полноценный напарник (Pair Programmer).

Что ИИ делает лучше всего прямо сейчас:
1️⃣Поиск багов: Скормите нейросети кусок кода, и она найдет утечку памяти или логическую ошибку быстрее любого отладчика.
2️⃣Документирование: Самая скучная часть работы теперь делается мгновенно.
3️⃣ Перевод на другой стек: Нужно переписать скрипт с Python на Go? ИИ сделает 90% работы за вас.
4️⃣Генерация фиктивных данных: Мгновенное создание баз данных для тестов.

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

Будущее разработки - это умение эффективно управлять искусственным интеллектом. А наша подборка каналов поможет Вам в этом! ⤵️
https://t.me/addlist/kbnn_yWvqHsyODky

🎙 Аналитик и ИИ — первый эпизод 2026 года

Начинаем год с большого и, честно говоря, очень своевременного разговора.
В этот раз солирует Илья Богословский с темой:

«Эволюция ИИ в аналитике — от генерации кода до агентных экосистем»

Рынок данных к 2026 году заметно сместился: от экспериментов с чат-ботами — к внедрению автономных агентов и устойчивой инфраструктуры. На вебинаре мы разберём этот переход на практике, шаг за шагом, используя VS Code и реальные инженерные сценарии.

Что будем разбирать

1. Проектирование и архитектура
Использование ИИ для генерации физических схем БД (DDL) напрямую из бизнес-требований — без ручного рисования диаграмм.

2. Инженерия данных и self-healing
Python-пайплайны, которые не просто переносят данные, а автоматически исправляют ошибки при изменении схем источников.

3. Семантический слой
Создание единого источника правды: метрики описываются кодом, чтобы избежать галлюцинаций моделей и обеспечить корректную контекстную инженерию.

4. Генеративная визуализация
Подход Dashboard as Code: автоматическое создание интерактивных аналитических веб-приложений (например, на Streamlit) вместо ручной настройки BI-отчётов.

5. Подключение через MCP
Внедрение Model Context Protocol (MCP): превращаем базу данных в безопасный инструмент для вызова внешними ИИ-агентами.

6. Агентная оркестрация
Переход от одного ассистента к мультиагентной системе — запуск команды специализированных агентов (планировщик, аналитик, критик) для решения комплексных задач.

7. Управление и безопасность
Guardrails, автоматические проверки, защита чувствительных данных и соблюдение регуляторных требований в автономных сценариях.

В итоге вебинар показывает полный цикл создания современной data-платформы, готовой к работе в эпоху Agentic AI — не в теории, а в реальной инженерной практике.

🗓 Дата: 28 января
⏰ Время: 19:00 по МСК

Если вы работаете с аналитикой, данными, платформами или ИИ — это ровно тот разговор, который помогает сложить картинку целиком, а не по отдельным хайповым кускам.


UPDATE. Регистрация тут

Так, ну и ещё немного наблюдений про контент и вообще про то, что происходит вокруг нас.

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

А сейчас ловлю себя на мысли, что это уже не совсем смешно.

Мы слишком долго жили в мире, где в IT ценились почти исключительно хард-скиллы. Это было видно и по вакансиям: списки фреймворков, языков, инструментов — чем длиннее, тем круче. Люди этим гордились, компании это поощряли.

Но кажется, что этот маятник постепенно начинает качаться в другую сторону.

Умеешь ты нарисовать sequence diagram или нет — вообще не проблема. Ты можешь закинуть это в ChatGPT, и он тебе её нарисует. Вопрос не в том, как нарисовать, а что именно ты рисуешь и зачем. Как этот процесс будет работать в реальности. Как он решает конкретную проблему. Экономит ли он время, деньги, нервы. Приносит ли ценность бизнесу.

То же самое с сервисами. Не написать gRPC-сервис — не проблема. Проблема — сделать так, чтобы этот сервис был нужен. Потому что я по общению со своими ментии регулярно вижу одну и ту же картину: в энтерпрайзах (и не только российских) делаются сервисы ради сервисов. Ради освоения бюджета. Ради «у нас теперь тоже так». А иногда эти сервисы ещё и ухудшают жизнь пользователям — операторам, аналитикам, поддержке. Процессы становятся сложнее, дольше и, как следствие, дороже.

И вот тут внезапно оказывается, что человек, который может быть вообще не супер-айтишным (как в той самой гифке), но который понимает бизнес, людей и процессы — приносит больше пользы. А значит, и зарабатывает больше.

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

Так что мой личный вывод простой:
если вы хотите быть востребованными — погружайтесь в бизнес, в смыслы и в проблемы, которые реально нужно решать. А не только в очередной инструмент или технологию.

Харды можно догнать. Контекст и мышление — гораздо сложнее.

Всем привет! Сегодня будет небольшой пост про важность критического мышления — и про то, как легко нас можно «поймать» на красивую картинку.

Наткнулся тут в рилс (в одной запрещённой соцсети) на чувака, который с очень серьёзным лицом показывает «the scariest chart in the world». Суть: с момента выхода ChatGPT, мол, «разъехались» два графика — S&P 500 летит вверх (как будто это про “экономика растёт”), а количество вакансий в США падает (как будто “работу отобрал ИИ”). Выглядит эффектно, тревожно, кликабельно. Прямо просится вывод: «всё, ребята, нас заменили».

Я такой: окей, не буду разводить панику — пойду проверю. И вот тут начинается самое интересное.

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

А что же S&P 500? Там тоже нет мистики. С выходом ChatGPT начался AI-бум: капитализация и инвестиции в AI-компании и инфраструктуру резко выросли, драйверы типа NVIDIA (и не только) стали тянуть индекс вверх. Это реально технологический прорыв, и рынки на это отреагировали — но это не означает автоматом, что «ИИ прямо сейчас уничтожил вакансии».

И вот тут ключевая мысль: корреляция — не причинность. Даже если две линии красиво расходятся в одной точке, это ещё не доказательство. Можно вспомнить классические «нелепые корреляции» — типа зависимости количества самоубийств от числа фильмов с Николасом Кейджем (если не видели — погуглите, забавно и поучительно). 🙂

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

Всем хорошего воскресенья ☀️

З.Ы. Вот тут хороший разбор графика на substrack (картинка оттуда)