10065
Канал про IT менеджмент ex-Дир-р по тех. разв-ю в Сбере: данные, AI, рек.системы. Ex-head of PMO СБОЛ. Автор:Арюткин Артём Реклама: @Badtechproject_contact Рег № 4923327959
В книге про искусственный интеллект глава про LLM начинается на 388-й странице 😁
И знаете, мне нравится такой порядок.
Я тут постоянно пишу про AI, агентов, изменения в разработке. И за всеми этими обсуждениями полезно иногда вернуться к вопросу: а как вообще устроены штуки, на которых мы собираемся строить наши продукты и процессы? И, кажется, жизнь и безопасность ‘
Короче, «Грокаем алгоритмы искусственного интеллекта» Ришала Харбанса - это 544 страницы: от поиска пути и эволюционных алгоритмов до языковых моделей и генерации изображений.
Что в ней интересного?
1. Помогает увидеть, насколько разные задачи мы называем одним словом «ИИ».
Найти выход из лабиринта. Уложить в рюкзак самые ценные предметы с ограничением по весу. Построить маршрут между аттракционами. Научить машину добираться до владельца через парковку.
Для каждой задачи автор разбирает свой подход: как представить возможные решения, как их искать, по каким признакам выбирать хорошие.
2. Объясняет через примеры, которые можно разобрать руками.
У генетического алгоритма есть варианты решения, отбор, скрещивание и мутации. У муравьиного: пути и следы, влияющие на выбор следующего маршрута. У нейросети - вычисления, ошибка и изменение весов.
3. Конечно-конечно про токены, эмбэдинги, само внимание и прочее там прямо тоже будет.
Только прикол в том, что подведут тебя к этому аккуратненько за ручку, как первоклашку.
Что мне кажется ограничением книги?
Во-первых, доступное изложение всё равно требует работы. Здесь есть формулы, код и упражнения. Базовое понимание программирования понадобится.
Во-вторых, глубина разная. На механизм внимания отведён подробный разбор, а RAG занимает примерно половину страницы. Поэтому по наличию термина в оглавлении нельзя судить, насколько глубоко получится его изучить.
Кому рекомендовать книгу?
Я бы рекомендовал книгу разработчикам, техлидам и техническим продактам, которым хочется собрать знания об ИИ в более связную картину. Для человека, который уже профессионально занимается ML, значительная часть материала будет знакомой.
Мне кажется, особенно полезно сейчас понимать две вещи: каким способом система ищет решение и что именно она считает хорошим результатом.
P.S. Ну и мой восторг природе, когда я в этой книге разобрался, как же все-таки устроен «рой» и «муравьиный механизм»
#пятничное
Я пойму, если вы отпишитесь 😁
Вы только посмотрите, какую штуку мы запускаем вместе с southHub: HRV Club!
Зачем?
Да чтобы разобраться с тем, как нам сохранить физическое и ментальное здоровье в дико-меняющемся мире!
Ииии на первой встрече клуба не обойтись без AI!
Так что мы решили пригласить на встречу CEO Biodata Станислава Скакуна и разобрать, как построить свою систему здоровья с нуля (из устройств, анализов и ИИ) и не дать ей себя обмануть 🫀.
Это не лекция. Станислав Скакун из опыта приложение BioData и на его примере покажет, как собрать свою систему без готовых платформ, где данные и ИИ ошибались и что реально помогает принимать решения.
📅 14 ноября, 11:00–14:00
🎟 Регистрация — в личном кабинете
Вот я супер много занимаюсь метриками и ресерчами исследований и продуктивности и знаете, что меня сильно расстраивает?
Что, короче, вот люди смеются, что считать количество строк кода - это фу-фу-фууу!
Ну согласен, сейчас звучит отстойно, но представьте себе, что вы менеджер в IBM в 80-х: что вы придумаете?
Сейчас все говорят, что CycleTime - фигоооово! Я же могу нарезать маленькие задачи и делать их быстрее. Можешь, ага! И это будет супер полезно, потому что инкремент станет меньше и цикл ускорится.
Но самый важный вопрос, который у меня тут возникает:
а нафига вы, блин, все время пытаетесь обмануть метрику?
То есть проблема не в метрике, а в том, что вы хотите обмануть всех вокруг 😩
К чему я это?
Именно такую мысль я задвигал на круглом столе в подлодке, где обсуждали метрики в эпоху AI.
Ваще, вот Демычу 10 лет и можно с ним теперь и в UFC поиграть вечерком 15 минут 🥳
Читать полностью…
Шикарный пример того, как инфраструктура становится узким местом даже у топовых компаний в мире!
ИИ начал писать столько кода, что Anthropic пришлось пересадить свой монорепозиторий с Git на собственную систему 😁
Короче, ребята выпустили инженерный разбор, как у них меняется инфраструктура разработки.
В мае они вливали около 2 500 изменений в день. В сентябре — уже больше 30 000.
И тут выяснилось, что код можно генерировать быстрее, чем существующая инфраструктура успевает его переваривать.
Оооокей!
Купили разработчикам ИИ, ускорили написание кода. А дальше что?
А дальше сборки, тесты, ревью и доставка всего этого добра пользователям.
Что сделали в Anthropic?
1. Построили Scion - собственную систему контроля версий. Агенты и CI постоянно онлайн, поэтому историю, сравнение изменений и другие операции можно обрабатывать на сервере. Для части задач вообще не нужна локальная копия репозитория достаточно API.
2. Сократили потребность инфраструктуры контроля версий в CPU и памяти в 200 раз относительно прежней системы Git-зеркал. Получение кода для CI и исследовательских задач ускорили примерно в 100 раз.
3. Командой из семи человек за пять месяцев сделали Scion, инструмент ревью Antique и ещё несколько связанных систем. И перевезли туда монорепозиторий.
4. Поменяли работу инженеров. По словам команды, важной частью работы стало говорить Claude «нет»: удерживать архитектурные ограничения и останавливать ненужное усложнение.
Это, конечно, специфический масштаб и доступ Anthropic к собственным моделям. Бежать переписывать Git всем подряд ребята не предлагают.
А теперь моя любимая часть!
Представьте разговор:
— Мы ускорили разработчиков в десять раз!
— Отлично! А выпускать изменения стали быстрее?
— Пока не знаем. Они теперь стоят в очереди на сборку.
Кажется, платформенным командам пора привыкать к новому пользователю.
Раньше человек мог пару минут подождать, переключиться на встречу, сходить за кофе.
Теперь к вам придут тысячи агентов. И каждый захочет среду, данные, тесты и возможность выкатить результат.
Поэтому вместе с вопросом «сколько времени ИИ экономит разработчику» я бы уже задавал следующий: сколько из этого ускорения наша платформа способна довезти до прода?
Разработчики отказываются работать без ИИ. Даже за деньги! 😁
Ну ка не ржать, матросы!
Короче, у METR случилась прекрасная проблема с исследованием продуктивности.
Помните ребят, которые в 2025 году выяснили, что опытные разработчики с ИИ выполняли задачи на 19% дольше? Хотя сами считали, что ускорились.
Так вот, они решили провести новый эксперимент. И столкнулись с тем, что часть разработчиков просто не захотела участвовать.
Потому что пришлось бы половину задач делать без ИИ. Даже за $50 в час. (metr.org)
Дальше ещё прикольнее.
1. Некоторые вообще не приходят в исследование: отказываться от ИИ не хочется.
2. Среди опрошенных участников 30–50% признались, что не отдавали в эксперимент отдельные задачи. Вдруг выпадет условие «без ИИ», а делать руками совсем не хочется.
3. Один участник не завершил ни одной задачи, которую ему назначили выполнять без ИИ.
В итоге METR объявила о пересмотре методики: из исследования выпадают люди и задачи с наиболее высокими ожиданиями пользы от ИИ. Это может занижать измеренный эффект. Правда, оплату участия тоже снизили — со $150 до $50 в час, что могло повлиять на отказы. (metr.org)
Знаете, что самое клевое?
Мы пытаемся ответить на вопрос «насколько ИИ ускоряет разработчика», предлагая ему поработать так, как он уже не хочет работать.
Это как измерять пользу IDE, периодически выдавая человеку блокнот. Эксперимент провести можно. Добровольцев найти сложнее 😁
При этом нежелание отказаться от инструмента ещё не доказывает рост продуктивности. Он может экономить силы, убирать скуку или просто создавать приятное ощущение скорости.
Но для нас, людей, которые делают инженерные платформы, здесь есть ещё один вопрос:
Как измерять эффект инструмента, когда вокруг него уже перестроилась сама работа?
Человек иначе выбирает задачи, иначе распределяет внимание, запускает несколько агентов параллельно.
И сравнение «та же задача с ИИ и без» всё меньше рассказывает о том, как теперь работает команда.
Исследование METR
Обожаю-обожаю-обожаю исследования!
Это же прямо золотая жила знаний о реальности!
Вот ловите: мы тут всей телеграмно-менеджерской тусовкой проводим ресерч!
Ребята из DevCrowd запустили ежегодное исследование руководителей разработки, а мы помогаем собрать побольше ответов.
Потому что про работу тимлидов все всё знают.
Одни рассказывают, что настоящий руководитель должен делегировать. Другие — что обязан сам писать код. Третьи предлагают просто нанять сильных людей и не мешать.
Оооокей!
А сколько за всё это платят? Вот команда выросла с 5 до 30 человек. Зарплата тоже выросла в шесть раз? 😁
А полномочий добавилось? Или только людей, за которых теперь отвечаешь?
Вот такие вещи и хочется выяснить:
1. Деньги. Сколько платят руководителям и как это связано с размером команды.
2. Выгорание. Кто уже всё, а кто ещё бодр и весел. И чем отличаются условия их работы.
3. Полномочия. Что руководитель действительно решает сам, а что несёт согласовывать следующему руководителю. И как это связано с тем, насколько ему тяжело работать.
4. AI-агенты. У кого они уже делают часть работы и кто потом отвечает за их код. Подозреваю, что самого агента на неприятный разговор к CTO пока не вызывают 😁
DevCrowd делают независимые исследования IT-профессий: за всё время собрали больше 15 000 участников, отчёты выкладывают в открытый доступ.
Новый отчёт обещают в декабре.
Но сначала нужны наши ответы. Иначе опять будем обсуждать зарплаты, нагрузку и полномочия по методу «а вот у одного моего знакомого».
👉🏼 Опрос анонимный, займёт 12–15 минут:
https://survey.devcrowd.ru/tl-2026
Можно даже поставить себе в календарь встречу «Исследование рынка». Мы же менеджеры, нам так привычнее 😉
Следующая неделя - неделя школьных каникул.
Предлагаю официально назвать ее «Монстры на каникулах»😁
Нет! Нет! Это не может быть правдой 🙈
Читать полностью…
Все вокруг теперь программисты
Короче, у Gergely Orosz в The Pragmatic Engineer вышла интересная статья про новый тренд: крупные компании начали создавать собственные аналоги Lovable для сотрудников.
И нет, не для разработчиков!
А для менеджеров, маркетологов, финансистов и прочих ребят, которые хотят сделать себе какой-нибудь инструмент, но писать код не умеют.
Вот вам два примера.
1. Ramp и их Glass
Ребята собрали собственную платформу для вайб-кодинга внутренних приложений.
Причём первую версию сделали всего два инженера за несколько недель.
Теперь любой сотрудник может описать, что ему нужно, подключить корпоративные источники данных и получить работающее приложение.
Например, маркетолог собрал себе CRM с более чем 50 полями и фильтрами.
И знаете, что самое интересное?
В Ramp создание первого инструмента через Glass уже стало частью онбординга новых сотрудников!
А 13 октября компания вообще вывела Glass на внешний рынок.
2. Stripe и их Harbor
Здесь ещё интереснее.
Один инженер за 40 дней создал внутренний инструмент для генерации интерактивных прототипов.
И вот результаты с мая 2026 года:
• Более 12 000 созданных прототипов.
• Более 3 000 сотрудников воспользовались инструментом.
• 25% сотрудников Stripe создали хотя бы один прототип.
Причём используют его не только дизайнеры.
Финансисты собирают интерактивные отчёты вместо презентаций, продавцы калькуляторы ROI, аналитики - дашборды.
А самое интересное технически: Harbor интегрирован с другими AI-инструментами Stripe через MCP. То есть прототип можно передать coding-агенту для дальнейшей реализации.
Оооокей! А зачем делать свой Lovable, когда уже есть готовые?
Orosz выделяет несколько причин:
1. Данные. Корпоративную информацию не хочется отправлять в сторонние сервисы. Своя платформа позволяет контролировать доступ к ней.
2. Интеграции. Можно сразу подключить внутренние API, базы данных и другие системы компании.
3. Стандарты. Генерируемые приложения используют корпоративную дизайн-систему, а не выглядят как результат очередного хакатона.
4. Стоимость внедрения. Иногда собрать собственный инструмент оказывается сопоставимо по усилиям с выбором вендора, согласованием безопасности и последующим внедрением.
5. Компетенции. Инженеры заодно учатся строить собственную AI-инфраструктуру.
А теперь моя любимая часть!
Кажется, мы наблюдаем довольно интересную трансформацию роли инженерных платформ.
Раньше у нас был внутренний заказчик, который приходил к разработчикам и говорил:
- Ребята, сделайте мне дашборд, форму или какой-нибудь маленький инструмент!
Разработчики брали это в бэклог, приоритизировали, обсуждали, оценивали…
А через полгода сообщали, что в этом квартале ресурсов нет. 😁
Теперь этот же сотрудник может собрать себе нужный инструмент самостоятельно.
И вот тут возникает интересный вопрос.
Если создавать приложения сможет каждый, кто будет отвечать за весь этот зоопарк?
Кто управляет доступами? Кто контролирует стоимость исполнения? Что делать, когда автор приложения увольняется? И кто гарантирует, что какой-нибудь вайб-кодер не откроет доступ ко всей корпоративной базе?
Кажется, ответ опять - платформенные команды.
Только теперь их задача не просто делать удобные инструменты для инженеров, а создавать безопасную среду, в которой приложения могут создавать вообще все сотрудники.
И, на мой взгляд, это куда более интересная история, чем очередное ускорение написания кода на 30%.
Потому что мы меняем не скорость разработки.
Мы меняем то, кому вообще нужна команда разработчиков для создания программного обеспечения.
Быть папой девочки, это когда в гостях, она на тебе показывает «как правильно делать удушающий»!
И удушающий делает действительно отлично!😁
Всех с днем отца!👨
Я и Клод выживаем как можем!
Час ночи и Наташке нужно срочно сделать коллаж из 300 фото!
После попытки сделать это через какой-то существующий софт, просто навайбкодили решение и все!
Так что сну сегодня быть!
#пятничное
Пу-пуу-пуууу
А ты жил в эпоху таксофонов?
❤️ - если да!
😱 - пошел гуглить, что это такое!
💊 - пооддержать старичков из пункта 1!
Можно построить идеальную инженерную платформу, которой никто не хочет пользоваться! 😁
И самое забавное, что с точки зрения инженерных метрик у вас всё будет прекрасно!
Короче, сходил я тут к ребятам из подкаста «В SREду на кухне» поговорить о том, зачем инженерам продуктовое мышление.
И, кажется, это одна из моих любимых тем!
Я вообще считаю, что одна из главных проблем платформенных команд — мы слишком часто думаем о том, что и как построить, и слишком редко о том, зачем это кому-то нужно.
В итоге получаем технически прекрасные решения, которые либо никто не использует, либо используют исключительно потому, что выбора нет.
О чём поболтали:
1. Зачем инженерам продакты? И в какой момент внутренний инструмент вообще становится продуктом?
2. Как измерять успех платформы? Вот у вас 100% adoption. Это успех или просто разработчикам запретили пользоваться альтернативами? 😁
3. Зачем нужны контрметрики? Можно же здорово ускорить разработку, а заодно уронить надёжность. Или сделать супернадёжную платформу, на которой невозможно работать.
4. Алертинг как продукт. Почему даже такую сугубо инженерную штуку можно и нужно проектировать вокруг пользовательского опыта?
5. Кто вообще заказчик надёжности? И почему пользователь, заказчик и тот, кто за всё это платит, — далеко не всегда один человек?
6. Что важнее — надёжность или Developer Experience? И почему вообще приходится выбирать между этими двумя вещами?
Ну и поговорили про SLO, исследования пользователей, продуктовые метрики и прочие штуки, от которых у настоящего инженера иногда начинает дёргаться глаз.
В общем, если вы строите внутренние платформы, инженерные инструменты или просто хотите понять, зачем в инженерных командах нужны продуктовые менеджеры — рекомендую посмотреть!
Смотреть и слушать:
📺 YouTube
📱 VK Видео
📺 Rutube
🎧 Mave
Ну и приходите в комментарии спорить!
А кругом разговоров только о том, сколько ИИ сэномил
Короче, тут методологию оценки финансовой эффективности ИИ подвезли от Альянса в сфере ИИ и Ассоциации ФинТех. Документ про то, как считать эффект, с примерами финансовых организаций.
Кажется, как база, прямо хорошая!
1. Сэкономленное время ещё нужно во что-то превратить
Методология разделяет реальное сокращение численности и отказ от дополнительного найма. Для признания такого эффекта расчёт должен быть подтверждён и отражён в бизнес-плане. (a-ai.ru)
А теперь мой условный пример.
Тысяча разработчиков экономит по часу в неделю. Получается тысяча часов. По 3 тысячи рублей за час — уже 3 миллиона!
Только зарплаты мы заплатили прежние.
Возможно, ребята выпустили больше полезных изменений. Возможно, перестали перерабатывать. Возможно, освободившееся время съели согласования.
Все три сценария требуют разных управленческих решений. Табличка с часами их за нас не примет.
2. Сравнивать нужно с разумной альтернативой
Авторы рекомендуют оценивать ИИ относительно лучшей ближайшей альтернативы без него. Иначе в эффект модели попадёт польза от самого изменения процесса.
Мой пример: мы годами вручную переносили данные, потом сделали агента.
А обычный скрипт эту задачу мог решить?
Если мог, то на защите хочется увидеть стоимость обоих вариантов. Особенно когда агенту ещё нужны поддержка и проверка результатов.
3. Из эффекта придётся вычесть расходы
В методологии предлагают учитывать затраты на создание и поддержку: людей, инфраструктуру, лицензии, внешние услуги.
Есть показательный кейс Московской биржи: агент собирает один слайд из большой презентации. В расчёте 50 сэкономленных рабочих дней в год, 40 дней на создание и 20 дней ежегодной поддержки. ROI за три года получается 50%. Это модельная оценка потенциальных расходов.
Сколько раз инструментом воспользуются? Сколько времени займёт проверка слайда? Что случится с окупаемостью, если пользоваться будут вдвое реже?
4. Красивую формулу ещё нужно наполнить доказательствами
В документе приоритет отдают рандомизированным экспериментам и отдельно разбирают двойной учёт эффекта нескольких инициатив.
Для меня отсюда простой вывод: расчёт ROI полезен ровно настолько, насколько можно доверять его исходным данным.
Что с этим делать?
Перед запуском договориться:
- что конкретно должно измениться для бизнеса;
- как проверим вклад ИИ;
- кто превратит освободившееся время в результат;
- какие расходы учтём;
- когда вернёмся проверить обещания.
Решил за вас пересмотреть классику и подготовиться 🤣🤣🤣
Читать полностью…
Вот если вам кажется, что все эти ваши модели фигня полная, то вот вам кусочек магии, которая пугает…
Исследователи дали GPT6 Astra задачу улучшить мелкую модель 0.8B Qwen, и Astra вручную поменяла веса внутри модели (без обучения, без всякий сложности, просто текстовый файл) и устранила проблему зацикливания.
Она нашла и поменяла всего 0.016% весов, блин, а доля решённых задач на математическом тесте MATH-500 выросла с 7,9% до 48,1%
Я, конечно, всегда отношусь к этому как инструменту, но, блин, человек так вот не мыслит ни сколько!
- В 2007 году, придумываешь, что у тебя болит, чтобы не идти на физру.
- В 2026 году, говоришь себе, что у тебя ничего не болит, чтобы идти в зал😁
50 миллионов пользователей. Продукту почти 30 лет. А тебе всё равно нужно показывать рост! 😁
Короче, представьте, что вы продакт в компании, у которой уже десятки миллионов пользователей.
Рынок давно поделён, а привлечение новых пользователей становится всё сложнее.
И тут к вам приходит бизнес и говорит: ну что, давай расти!
Оооокей!
А куда, собственно?
Тут ребята из make sense выпустили интересный подкаст, где Юра Агеев поговорил с Русланом Арзумановым, руководителем продуктового направления Почты Mail в VK.
И мне понравилось, что разговор получился не про очередной успешный успех, а про вполне реальные кейсы зрелого продукта.
Вот несколько мыслей, которые я для себя забрал:
1. Иногда лучший способ расти — перестать привлекать новых пользователей.
Звучит странно, да?
Но когда у тебя уже десятки миллионов пользователей, гораздо интереснее разобраться, что они вообще делают внутри твоего продукта.
Кто-то использует почту для работы, кто-то хранит фотографии и документы, а кто-то просто получает туда коды подтверждения.
И вот тут начинается интересная продуктовая работа.
Вместо попыток привести ещё миллион пользователей можно сделать существующие 50 миллионов счастливее, активнее и, в конце концов, прибыльнее.
2. Среднестатистического пользователя не существует.
В Почте Mail через сегментацию пользователей пришли к трём продуктовым ставкам.
И вместо одной универсальной подписки начали развивать предложения под разные сценарии: для семей, фотографов и работы.
По сути, продукт один, но ценность для разных людей совершенно разная.
А значит, и продавать всем одно и то же — идея так себе.
3. Зрелому продукту нужен портфель ставок, а не одна великая стратегия.
Вот это мне особенно близко.
Когда у тебя десятки миллионов пользователей, нельзя просто взять и переделать всё, потому что кому-то из менеджеров приснилось светлое будущее.
Нужно одновременно развивать то, что уже работает, экспериментировать с новыми сценариями и искать будущие источники роста.
Причём часть ставок обязательно не сработает.
И это нормально!
4. А теперь моя любимая часть — ИИ может превратить твой продукт в обычную трубу. 😁
Представьте, что завтра ИИ-агенты начнут самостоятельно читать вашу почту, находить билеты, документы, бронирования и отвечать на письма.
И зачем тогда вообще открывать приложение?
Вот это уже интересная проблема!
Можно 30 лет строить продукт, наращивать аудиторию, улучшать интерфейсы, а потом обнаружить, что интерфейс больше никому не нужен.
И твой продукт теперь просто транспорт для чужих ИИ-агентов.
Причём это касается далеко не только почты.
А знаете, какой вывод я тут для себя сделал?
Чем более зрелым становится продукт, тем меньше его развитие похоже на бесконечное добавление новых функций.
И тем больше — на поиск новых способов создавать ценность для уже существующих пользователей.
И, кажется, с распространением ИИ эта задача станет только сложнее.
В общем, рекомендую послушать разговор. Особенно тем, кто управляет зрелыми продуктами и уже устал придумывать, где найти следующие 20% роста.
🎧 Слушать выпуск make sense | Apple Podcasts
К слову, если вы вдруг, как-то связаны с метриками, внедрением ИИ и продуктивностью разработки, то отсюда простой вывод:
1. Если вы меряете долю кода, сгенерированного ИИ - вы отстаете. Это уже неактуально
2. Если факт того, что разработчики не хотят писать код без ИИ вас удивляет, то скорее всего вы недостаточно погружены в их работу)
Признайтесь, мы?)))
🦄 - если ты не такой
🔥 - если будем сидеть в одной клинике
💊 - если ты уже там
#пятничное
🦄 - если ты не такой
❤️ - если ты сдался даже не начав
🙈 - если давайте уже после праздников😁
Мне нравится, как изменился мир.
На встрече все чаще звучат фразы:
Так, ща я своему агенту закину, пока давайте двигаться дальше, как ответит я вернусь!
Самый дорогой способ проверить идею — полгода её разрабатывать.
Сначала проверьте спрос. Так сделали эти ребята:
— Юра выбрал нишу, которую все считают скучной, но там уже платят. Начал с $100 в месяц, через год вышел примерно на $10K.
— Денис один собрал AI-игру в Telegram. За первые полтора месяца ~$1 500.
— Аня не пишет код, но запустила AI-бота для английского. Первые ~$200 пришли в первый же месяц.
Масштабы разные, схема одна:
1. Найти, за что люди уже платят.
2. Быстро собрать MVP.
3. Проверить спрос на живых пользователях.
4. Только потом докручивать продукт.
Это не рецепт «как точно сделать $10K». Гарантий вообще нет.
Но так вы узнаете ответ за недели, а не за год.
В @its_capitan разбирают такие запуски по шагам: что сделали, сколько получили, где облажались.
Подписывайтесь, чтобы запускать продукты, которые нужны пользователям, а не пилить в стол.
Реклама: ИП Зуев Игорь Владимирович, ИНН: 360408359441, Erid: 2VtzqwWFhVo
Около 80% времени интерактивных сессий Claude проводит в ожидании действий человека!
Короче, Anthropic выпустила исследование о том, как ИИ меняет работу внутри самой Anthropic.
Почему это круто?
Потому что ребята не стали спрашивать очередную тысячу CEO, как они планируют внедрять ИИ. А взяли реальные данные собственной компании: найм, производительность, использование агентов, встречи и даже оценки кандидатов на собеседованиях.
И вот что получилось.
1. Джуны больше не особо нужны?
Доля младших технических специалистов среди новых технических сотрудников сократилась с 27% до 9%.
А среди всех сотрудников технических подразделений — с 21% до 14%.
Причем компания продолжает активно расти и нанимать людей!
То есть это не история про массовые увольнения. Просто структура спроса на людей начинает меняться.
Я, кстати, отношусь к этому спокойно и считаю, что происходит инфляция грейдов.
2. Агенты уже работают больше людей.
В марте 2026 года суммарное время работы AI-агентов впервые превысило рабочее время сотрудников Anthropic.
А к августу агенты, запускаемые самими сотрудниками, работали уже в 6 раз больше часов, чем люди.
Конечно, это не значит, что агенты заменили шестерых сотрудников. Они работают параллельно, а их часы нельзя напрямую приравнивать к человеческим.
Но масштаб впечатляет!
3. Производительность растет. Но есть нюанс.
Количество коммитов на инженера выросло примерно в 5 раз за полгода.
Продавцы закрывают больше сделок, юристы обрабатывают больше контрактов, финансисты — больше счетов.
Причем исследователи проследили, как менялась производительность одних и тех же сотрудников после внедрения агентов.
Но тут важный момент: в 5 раз больше коммитов - не обязательно в 5 раз больше бизнес-ценности.
4. Люди становятся бутылочным горлышком для ИИ.
Около 80% времени интерактивных сессий Claude проводит в ожидании действий человека!
Это я считаю ваще просто какая-то бомбическое осознание!
А знаете, сколько времени потребуется сотрудникам нетехнических подразделений, чтобы просто прочитать весь результат работы своих агентов?
Больше половины рабочей недели!
И вот сотрудники начинают заниматься новой работой: создавать инструменты наблюдения за агентами, проверять их результаты, координировать выполнение задач.
Доля такой «метаработы» в сессиях с Claude выросла с 10% до 22%.
Поздравляю! Мы из исполнителей превращаемся в менеджеров ИИ-агентов. 😁
5. А встреч стало БОЛЬШЕ!
Вот это мне особенно понравилось.
Медианный сотрудник Anthropic проводит на встречах на 20% больше времени, чем год назад.
Даже у технических специалистов, которые не являются менеджерами, рост составил 16%.
Почему?
Потому что написать код, собрать аналитику или подготовить предложение становится проще.
А вот договориться, принять решение, разрешить конфликт интересов и взять на себя ответственность ИИ пока не особо помогает.
И чем больше агенты производят результатов, тем больше этих результатов нужно обсуждать.
6. Меняется само представление о хорошем сотруднике.
Раньше при найме технических специалистов оценивали прежде всего экспертизу и способность решать конкретные задачи.
Теперь Anthropic всё больше внимания уделяет самостоятельности, качеству суждений и умению использовать ИИ.
Знание конкретной технологии постепенно уступает место способности разобраться в незнакомой области и принять правильное решение.
Кстати, на одного продакт-менеджера в Anthropic приходится примерно 17 инженеров. А сами менеджеры стали делать вдвое больше коммитов.
Похоже, просто координировать чужую работу становится недостаточно.
И что из этого следует?
Мне кажется, мы наблюдаем довольно интересный парадокс.
ИИ должен был освободить нас от работы.
Но вместо этого он освобождает нас от выполнения работы и оставляет нам всё больше управления работой.
А это принципиально разные вещи!
При этом Anthropic — всё-таки специфическая компания. Нельзя просто взять её результаты и перенести на всю экономику.
Короче, Клод - это Apple в мире AI: внимание к деталям и клиентский опыт.
ChatGPT предложил мне вначале 300 фотографи перемещать задав каждой по номеру новое значение!!!!😱
А потом, когда я попросил, сделал «приложение», но оно не работает))
Сидит тут рядом довольная такая, фотки туда сюда перемещает!
Бормочет что-то 😁
Жалуется, что чуть размеры поплыли)
Сначала я обленился и перестал ездить в магазины за продуктами. Реально, я использую только доставку.
А что дальше?
Автопополнение корзины — идеальный пример такой «фантазии о будущем». Ритейлер или маркетплейс видит твои регулярные покупки, собирает привычный набор и предлагает до того, как ты вспомнил. Удобно? Да.
Но как отличить реальную потребность от навязанного потребления?
И где метрика, которая покажет, что это не просто «продать побольше», а реально польза для клиента?
Вот как раз посмотрел выпуск «ПродАктовой корзины», где эксперты разгоняли про потребление будущего. Для аналитика — прям поле для размышлений про метрики, этику и инкрементальность.
Рекомендую глянуть: YouTube или VK Видео
Вы знаете, что хуже бесполезной метрики?
Бесполезная метрика, на основе которой менеджеры начинают принимать решения! 😁
Короче, тут ребята из Google опубликовали интересную статью — What Makes a Good Productivity Metric о том, как правильно мерить продуктивность!
Начнем с метрик.
Мы, менеджеры, очень любим что-нибудь измерять.
Сколько задач закрыли, сколько коммитов сделали, сколько дней провели в офисе (пу-пу-пууууу).
Проблема в том, что мы часто измеряем не то, что действительно важно, а то, что проще посчитать.
Авторы предлагают 4 критерия хорошей метрики:
1. Понятность. Метрику можно объяснить нормальному человеку без защиты кандидатской по математике.
2. Соответствие реальности. Если ситуация объективно ухудшается, метрика должна это замечать.
3. Отсутствие странностей. Метрика не должна показывать ерунду там, где мы точно знаем, как устроен мир.
4. Полезность. По результатам измерений можно принимать решения.
Вот такой вот вам проверочный вопрос для хорошей метрик:
Если метрика изменилась, а вы не понимаете, что теперь делать, то зачем вы вообще её измеряете?