Korenev AI - GPT в тапочках🩴

➡️Сначала раскидывал по кучкам, теперь собираю их вместе

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

Много чего переделал и сейчас итоговый принцип в скилле для Гермеса у меня примерно такой (перевел его в понятный человеческий):

1️⃣ Не дроби задачу просто потому, что её можно раздробить.
Одна карточка = одна цельная тема. Внутри спокойно может быть 3–7 связанных пунктов. Если их восемь — это ещё не повод создавать вторую задачу.

2️⃣ Не превращай этапы работы в отдельные задачи.
Изучить текущее состояние → сделать → протестировать → исправить → снова проверить — это одна задача одного исполнителя.

3️⃣ Создавай нового агента только если есть реальная причина.
Другой специалист, другой независимый компонент/репозиторий либо работа, которую действительно можно выполнять параллельно. Если двум агентам сначала придётся читать одни и те же файлы — скорее всего, нужен один агент.

4️⃣ Не разрешай агентам плодить агентов.
Оркестратор может раздать работу специалистам. Специалист выполняет свою тему целиком. Если по дороге нашёл ещё работу — сообщает оркестратору, а не создаёт ещё пять подзадач самостоятельно.

5️⃣ Передавай агенту минимум контекста.
Цель, важные ограничения, критерии готовности и ссылки на исходные файлы. Не тащи за ним всю историю чатов и результаты предыдущих агентов — пусть читает первоисточники.

6️⃣ Один артефакт — один исполнитель.
Не надо двум агентам одновременно править одно и то же. И ревью запускается после окончания работы, а не параллельно с ней.

7️⃣ Ограничивай параллелизм.
У меня сейчас максимум четыре одновременно работающих делегированных агента. Обычно нужно ещё меньше.


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


Ваши мысли, господа? Что еще можно добавить?

➡️ На каком топливе ездить Гермесу?

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

Сначала подключил OpenRouter. Одна рабочая сессия на Гемини Флеше обошлась почти в доллар. Решил посмотреть варианты подешевле.

В итоге пришел к идее использования Дипсика 4.1 Флеш. По многим бенчмаркам он уже рядом с ЖПТ Сол и Опусом 5, а где-то даже их обгоняет!

В Дипсике я не встретил подписок, у них только потокенная тарификация. Начал искать другие варики и наткнулся на OpenCode. У них есть тариф за 10 долл в мес, в рамках которого отсыпают токенов на 60 долл - можно юзать многие популярные модели типа Дипсика, GLM, Kimi, Muse и т.д. - см скриншот с популярными.

По данным Опенкода для Дипсика 4.1 Флеш эти 10 долл эквивалентны примерно 130к типичных агентных запросов (это до 27.09, потом в 4 раза меньше)

Для сравнения, ChatGPT Plus за 20 долл, по пользовательским замерам отгружают токенов Сола примерно на 250 долл.

Если привести все к одинаковым 10 баксам за подписку, получается:

DeepSeek через OpenCode - примерно в 9 раз больше агентной работы.
А на текущем x4-промо - до 36 раз.

Вот такая занимательная арифметика.

А дальше пошла социология для тех кто хочет попробовать Опенкод:

лови рефералки:

1. тебе $5 за регистрацию / мне $5 за привлечение
2. тебе $5 / мне $50
3. тебе $0 / мне $0

Посмотрим, насколько ты "хрен тебе, а не рефералка"😄

Ставь 🔥 - если выбрал вариант 1
❤️ - если вариант 2
👍 - для варианта 3

➡️ Корпорация передастов или подзадача для подзадачи и оценка оценки

Похоже, при проектировании архитектуры мы с Чатом ЖПТ немного перестарались с принципом декомпозиции задач и незаметно построили там целую корпорацию стрелочников.

Получился прям полноценный аппарат управления:

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

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

На одной из несложных задач это гребаная система умудрилась наплодить 50+ агентов.
Хотя умозрительно кажется, что для этой задачи вполне достаточно максимум 2-3 агента, которые параллельно разбирают разные части работы, а потом собирают результат.

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

Обнаружил это шапито случайно. Показалось, что как-то очень медленно задача выполняется и какой-то перерасход токенов. Начал разбираться, попросил выгрузить список созданных подзадач и отправил в ЖПТ. Пофиксили. Посмотрим как будет по факту.

Кажется, я нашел еще один способ на изи разгрузиться на сотню млн токенов и при этом практически ничего не сделать😄

➡️Кто куда а мы на свадьбу

Как-то так сложилось, что вся моя работа с ИИ живет кусками:
С ЖПТ я что-то обсуждаю в браузере. Клод живет своими сессиями. Скиллы раскиданы по компьютеру. Гермес что-то делает локально. Где-то заметки, где-то идеи, где-то результаты работы.

И почти ничего нормально не циркулирует между ними.

Последней каплей стал прослушанный мною на прогулке подкаст. В нем нашел много полезного и решил извлечь ключевые тезисы. За кофейком пришло вдохновение, поэтому закинул транскрибацию в чатЖПТ и попросил создать скилл для просеивания бизнес-идей. Чтобы не забыть.

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

Подобный цикл уже не раз проделывал.

И тут вдохновение говорит: ватафа, Александр! Завязывай этой суетой заниматься! Пусть вкалывают роботы, а не человек.

В общем пришел к тому, что весь этот зоопарк нужно переженить и завезти в одно место.

Так у меня появилась единая база знаний для агентов. Реализовал ее на базе Гитхаба. В базе сейчас следующие разделы:
- все скиллы с компа + их реестры
- всякие полезные идеи и знания, которые хочется не потерять
- отдельная переписка между агентами + результаты их работы
- ну и дальше туда же постепенно переезжает всё, что агентам полезно знать друг о друге и обо мне

Теперь мой алгоритм работы выглядит примерно так:

Кейс первый - тот самый разбор по продажам.

Мы в чате с ЖПТ его обсудили, вытащили полезные мысли. ЖПТ сходит в гит за актуальным скиллом. Потом дополнил его новыми вводными.
Все это сразу уехало в Гит.

Гермес по расписанию подтянул изменения - и с этого момента у меня на компе уже актуальная версия скилла. Мне не надо вечером вспоминать, что именно я хотел сохранить, выгружать чат, искать файлы на компе и руками всё это склеивать.


Кейс второй - уже про самого Гермеса.

Гуляя по улице я обсуждал с ЖПТ проблему: Гермес запускает субагентов, а я толком не понимаю, что там происходит: кто работает, кто ждет, кто завис, где посмотреть конкретную сессию.

Мы обсудили как я хочу видеть всю эту кухню, и ЖПТ сформировал полноценную задачу на доработку. После чего сам положил ее в Гит.

Гермес по расписанию увидел новую задачу, автоматически взял ее в работу, внес изменения и туда же в гит отчитался о результате.
А ЖПТ потом посмотрел что именно Гермес реализовал, правильно ли понял задачу, и при необходимости отправил замечания на следующий круг.

То есть я могу вообще не участвовать в передаче работы между ними.


Заодно я сделал еще один отдельный репозиторий - с настройками самого Гермеса.
Во-первых, чтобы не профукать однажды все то, что я там под себя адаптировал
Во-вторых, теперь ЖПТ может видеть, как Гермес устроен, и при необходимости его перенастраивать напрямую, без отправки задач. А потом Гермес подтянет новые настройки и пересоберет себя.


И бонусом от всей этой истории я получил несколько довольно приятных вещей:

1️⃣Вся история теперь трекается. Можно посмотреть, кто что менял, зачем, что получилось, откатиться назад.

2️⃣Сами мои идеи о том, как должна работать агентная система, больше не прибиты гвоздями к конкретному Гермесу.
Завтра мне захочется переехать на другой стек - например на тот же BB, который тоже хочу покрутить - у меня уже есть вся архитектура, правила, скиллы, задачи и накопленные решения.

По сути я постепенно отделяю свои знания и способ работы от конкретной нейронки или конкретного агента.

Сегодня это ЖПТ + Гермес.

Завтра состав зоопарка может поменяться.
А хозяйство останется, все уже переженено😄

➡️Наконец понял, зачем мне Hermes!

У меня постепенно накопилась одна проблема - я стал мальчиком на побегушках у ИИ агентов.

Типичный сценарий:

Даю задачу одному агенту. Он что-то делает, потом начинает тупить или зацикливается на одной гипотезе.
Открываю другого:
"Вот задача. Первый что-то фигню делает, посмотри независимо."

Второй находит другой вариант. Иногда передаю результат обратно первому.

Иногда одну и ту же идею обсуждаю сначала в вебинтерфейсе ЖПТ, потом отдаю в Клода. Какие-то сложные задачи хочется отправить в Астре, но не хочется тратить ее на все подряд.

И начинается жонглирование:

Веб ЖПТ - Клод - обратно Веб ЖПТ - другой агент - скопировать кусок контекста - объяснить, что уже пробовали - не забыть, какие решения приняли.

Работает. Но похоже на цырк с конями.

Есть и второй сценарий, еще муторнее.

У меня один продукт может состоять сразу из нескольких технически независимых частей.

Например, сервис речевой аналитики:
интервью с РОПами - разбор болей и требований - создание прототипа без реальных данных - интервью с РОПами - разработка рабочей версии.

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

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


После обсуждения с ЖПТ этого недо-бизнес-процесса пришел к Гермесу.

Идея Гермеса в том, что появляется не просто еще один кодер, а слой управления агентами:

Один постоянный специалист знает колл-центр. Другой - сайт. Третий - аналитику.

Есть координатор, который может сначала зафиксировать общий контракт, потом раздать части задачи двум специалистам и в конце проверить, что результаты совместимы.

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

Звучит ровно как автоматизация того, что я до этого делал руками.

Но важная оговорка! Это пока это теория.

Я еще не пожил с этой системой нормально в работе. Несколько дней уже занимаюсь настройкой инфраструктуры.

Причем самому лениво думать, подключаем ЖПТ:
Сначала я выгрузил , чем вообще занимаюсь, какие у меня проекты, какие агенты, где какие данные и какие навыки уже накоплены.
ЖПТ выступил архитектором: формировал задания, которые я отдавал Гермесу.

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

В какой-то момент выяснилось, что у меня вообще десятки репозиториев и под сотню различных навыков/их вариантов. Раньше все это существовало довольно стихийно.
Теперь из этого собрана хоть какая-то система.

Будет ли она реально экономить мне время - пока хз.

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

В общем, "Сашенька, занесите нам кофе" вроде как отменяется😄

➡️Куча постов, что ИИ наконец-то решил теорему Навье-Стокса. Ну офигенно же?

Заживем, братцы!😄

Начал разбираться с логичным вопросом: "и чо?"

Даю трибуну для ЖПТ:

Вообще Навье-Стокс - это не одна теорема, а уравнения, которыми описывают движение жидкостей и газов.

То есть воздух вокруг крыла самолёта, воду вокруг корабля, потоки в турбинах и двигателях, атмосферу, океан, дым, кровь в сосудах и вообще почти всё, что куда-то течёт.

Самое смешное: этими уравнениями человечество пользуется почти 200 лет. Самолёты летают, корабли плавают, турбины крутятся.

Но математики до сих пор не доказали одну фундаментальную вещь: что в трёхмерном мире эти уравнения всегда дают нормальное, гладкое решение и в какой-то момент математически не "взрываются".
Вот это и есть знаменитая задача тысячелетия.

Что даст её решение?

Не будет такого, что завтра самолёты станут в два раза быстрее, а прогноз погоды - точным на месяц.

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

Причём в таких задачах самое интересное часто даже не само "доказали / не доказали", а какие новые математические инструменты пришлось для этого придумать.

И вот они потом могут неожиданно выстрелить вообще в других областях.

Так что ответ на "и чо?" пока примерно такой:
сегодня - почти ничо.
В перспективе - возможно, очень даже чо. Но не факт😄

➡️Как начать вайбкодить лучше?

Группа ИТ/ИИ мудрецов на стриме обсуждала разработку с ИИ-агентами.

Я вытащил с ЖПТ из него несколько вещей, которые можно довольно быстро применить у себя. Текст очистил от всякой бесовщины типа "эвалы", "целевые функции", "проекции" и прочих терминов, после употребления которых нужно мыть рот с мылом😄

Итак, как вайбкодить лучше:

1️⃣ Проверять описание скилла.

Именно по нему агент понимает, какой скилл подходит под задачу. Если описание неудачное, нужный скилл может просто не найтись или вместо него вызовется другой.
Проверять на 2-3 примерах недостаточно. Можно взять 15-30 реальных формулировок своих задач и посмотреть: находит ли агент нужный скилл каждый раз, когда должен, и не вызывает ли его там, где не надо.

2️⃣ Перед задачей спросить: "А как автоматически понять, что агент сделал все хорошо?"

Можно самому придумать критерий или прямо спросить об этом агента до начала работы.

Например: должны пройти определённые тесты, API должен вернуть конкретную структуру, в БД должны появиться нужные записи, старый функционал не должен сломаться.

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

3️⃣ Важные правила переносить из инструкций в автоматические проверки.

Можно десять раз написать в CLAUDE.md: "никогда не делай X". Агент все равно иногда решит, что конкретно сейчас можно.
Если нарушение правила может дорого обойтись, лучше сделать так, чтобы нарушить его технически было сложно: тест, lint, hook, проверка в CI, архитектурный тест.

То есть CLAUDE.md объясняет правило, а код проверяет, что агент действительно его соблюдает.

4️⃣ Иногда специально ломать код и смотреть, заметят ли это тесты.

Особенно если код и тесты к нему написал один и тот же агент.
Получить 143 tests passed приятно, но это ещё не означает, что эти 143 теста что-то реально ловят.

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

Если после поломки всё по-прежнему GREEN, у нас не тест, а зелёная лампочка для успокоения.

5️⃣ Дать агенту КОМПАКТНУЮ карту проекта.

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

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

Но есть ловушка: если «краткая карта проекта» разрастается в 70 КБ Markdown, к которому потом нужен ещё один индекс, мы просто создали второй проект.
Карта должна действительно сокращать пространство поиска, а не добавлять новое.

6️⃣ Научить агента говорить: "Стоп, тут проблема больше, чем задача".

Послали исправить маленький баг. В процессе выяснилось, что под ним архитектурная проблема.
Разработчик может вернуться и сказать: "Я бы пока не фиксил, тут надо сначала решить другую вещь".

Агент по умолчанию скорее продолжит старательно выполнять исходную задачу.
Поэтому в скилл разработки стоит прямо добавить правило: если найденное существенно меняет архитектуру, объём задачи или исходные предположения - не маскировать проблему локальным фиксом, а вынести её пользователю и предложить варианты.



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

Например, чтобы перед началом работы спрашивал:
➖ Как будем проверять результат?
➖ Какие ограничения здесь критичны?
➖ Можно ли проверить их автоматически?

А после работы:
➖ Действительно ли тесты ловят ошибку?
➖ Не обнаружилось ли что-то, что меняет исходную постановку?
➖ Не нужно ли обновить карту проекта?


Как-то так❤️

➡️Мое открытие дня:

Просить ЛЛМ делать экстрацию данных (Extract) вместо саммаризации.

Спустя время понял, что я так давно и делаю😄

Для извлечения смыслов из больших текстов я прошу модель выделить 100-200 фактов/ тезисов и сгруппировать их по смыслу. Ну а потом из этих групп что угодно можно лепить далее.

Повторно открыл открытое😄

➡️Где ИИ действительно может быть полезен в HR

Продолжаю выгружать содержание нашего разговора по HR:

Одна из тем, на которой мы довольно долго остановились - адаптация новых сотрудников.

Во многих компаниях она до сих пор устроена примерно так:
- вот CRM;
- вот продукт;
- вот коллеги;
- если что, спрашивай.

А через два-три месяца руководитель пытается понять: человек вроде справляется или все-таки нет?

При этом ошибка найма обходится дорого. Сергей оценивает уход сотрудника во время адаптации примерно в шесть его зарплат.

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

Сам подход к адаптации Сергей формулирует довольно просто:

это не экзамен на три месяца, а маршрут до конкретного рабочего результата.

Например, задача «проанализировать конкурентов» почти бесполезна.
Что значит проанализировать? Сколько конкурентов? Каким способом? Что должно получиться на выходе?

А если поставить задачу:
"Изучи 10 конкурентов по такой-то методике, пройди их путь как тайный клиент, сравни по этим критериям и подготовь презентацию",
появляется результат, который можно проверить.

Таких контрольных точек во время адаптации должно быть несколько.

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

Если человек системно не достигает четко описанных результатов, это можно увидеть гораздо раньше.

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

И вот здесь ИИ вполне может пригодиться.

Не как замена руководителю или HR, а как система управления адаптацией:
У нового сотрудника есть маршрут и контрольные точки. ИИ следит за прохождением, напоминает участникам процесса, собирает результаты и обратную связь, помогает выявлять отклонения.

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

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

Но у Сергея был хороший холодный душ на эту тему.

То, что бизнесу что-то полезно, еще не значит, что он готов это покупать.
По его опыту, компании редко приходят с прямым запросом: "Нам нужно исправить адаптацию".
Человек ушел - ищут следующего.
Если рекрутинговое агентство еще и дает гарантию на испытательный срок, мотивация разбираться в причинах становится еще меньше.
Как хорошо, что я задал этот вопрос! А то уже бы побежал реализовывать😄

Есть и организационная проблема:
Можно построить прекрасную систему, но адаптацией все равно должны заниматься руководители.
HR может координировать процесс, но он не способен профессионально адаптировать разработчика, технолога или директора по производству вместо их непосредственного руководителя.
А если у руководителя позиция "я нанял человека, пусть теперь сам разбирается", никакой ИИ это не исправит.

Поэтому технология здесь, похоже, далеко не самая сложная часть.

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

➡️Куда точно не стоит внедрять ИИ в HR

Продолжаю поток мыслей после разговора с Сергеем

В прошлый раз писал про ИИ в найме. А тут была еще одна мысль, которая мне кажется даже шире HR.

Я спросил Сергея, какие HR-процессы сейчас было бы интересно автоматизировать с помощью ИИ.

И довольно быстро выяснилось, куда он точно не полез бы:
делать еще одну HR CRM.

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

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

Но Сергей задал очень простой вопрос:
"А зачем мне переходить?"

У его команды уже есть рабочая система.
В ней вся воронка.
Аналитика.
Статистика.
Процессы.
И главное - накопленная за годы база примерно из 300к кандидатов.

Допустим, появляется новая система.
Она современнее.
В ней есть ИИ.
Она даже стоит на 2 000 рублей в месяц дешевле.
И что?

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

Экономия в 2 000 рублей на этом фоне вообще ничего не значит.

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

наш продукт / старый продукт.

У нас быстрее.
Красивее.
Умнее.
Есть ИИ.
На 20% дешевле.

Но клиент сравнивает совсем другое:
выгода от нового продукта / стоимость перехода на него.

А стоимость перехода - это далеко не только деньги.
Это данные.
Привычки.
Обучение сотрудников.
Интеграции.
Регламенты.
Риск что-нибудь сломать.
Время руководителя.
И просто человеческое: "у нас сейчас все работает, зачем это трогать?"

Получается неприятная для стартапа математика.
Если текущий продукт решает задачу на 7 из 10, а вы сделали решение на 9 из 10, этого может быть совершенно недостаточно.
Потому что клиенту надо не просто получить +2 к качеству.
Ему сначала надо заплатить огромный налог на переход.

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

Например:
не "замените свою HR CRM нашей",
а "оставьте все как есть, а мы подключимся сверху и дадим вам то, чего ваша система делать не умеет".

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

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

И, возможно, перед разработкой любого B2B-продукта стоит задавать себе не только вопрос:
"Насколько мы лучше текущего решения?"
Но и второй:
"Насколько мы лучше текущего решения + всей цены перехода на нас?"

Вот тут многие красивые стартапы внезапно перестают выглядеть такими красивыми. Пупупууу😱

➡️Клод банит из-за Гермеса?

Где-то полгода назад, если не ошибаюсь в сроках, встречал инфу, что как только Клод встречал в проекте папку .Hermes - он сразу же начинал тарификацию по токенам, а не по подписке.

Как сейчас с этим дело обстоит? Как ЖПТ и Клод реагируют на то что их под Гермесом эксплуатируют?

➡️Как ИИ может сделать найм хуже

На днях обсуждали ИИ в HR с Сергеем, CEO HR-агентства HuntX.

Сергей много работает с наймом и адаптацией сотрудников, поэтому разговор довольно быстро ушел от модных ИИ-фич к тому, что реально происходит в компаниях.
Мыслей набралось на несколько постов. Начну с найма.

Казалось бы, это идеальное место для ИИ.

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

Но тут возникает интересный парадокс:

мы оптимизируем работу HR и одновременно можем переложить эту работу на кандидата.

Раньше рекрутер созванивался, рассказывал про компанию, отвечал на вопросы.
Теперь кандидату предлагают сначала поговорить с ботом. Где-то заполнить большую анкету. Где-то записать видео. Где-то подробно рассказать, почему он хочет работать именно в этой компании.
Хотя человек пока вообще не знает, хочет ли он у вас работать.

Сергей рассказал интересный кейс. Его команда спрашивала кандидатов, которых устраивала на работу, как те относятся к подобной автоматизации верхней части воронки.

Около 80% сказали примерно следующее: если бы конкретная компания встретила их таким ИИ-фильтром, они бы просто не пошли дальше.

Получается забавно.

Компания думает:

«Мы технологичные. У нас ИИ в рекрутинге».

А кандидат:

«Вы просто сэкономили время своего HR за счет моего времени».

При этом есть сегменты, где все может работать иначе. Например, Сергей отдельно отмечает IT-рекрутинг: разработчикам текстовое взаимодействие с системой зачастую может быть вполне комфортно.

То есть проблема не в самом ИИ.

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

Есть и второй момент.

ИИ отлично работает там, где есть понятные критерии. Например, проверить конкретные профессиональные знания.

Но хорошее собеседование - это не просто список вопросов.
Рекрутер услышал странный ответ - переспросил. Почувствовал противоречие - копнул глубже. Видит, что человек волнуется, - помог раскрыться.

И тут появляется еще один риск.

Умение проходить собеседование и умение хорошо делать свою работу - это разные навыки.

Продажник или маркетолог может великолепно себя презентовать. А сильный технический директор может быть плохим рассказчиком.

И если слишком много отдать автоматической системе, есть риск начать оценивать не профессионализм, а умение правильно пройти алгоритм оценки.

При этом я совсем не думаю, что ИИ в найме не нужен.

Скорее наоборот.

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

То есть делать больше работы самому, а не заставлять кандидата делать больше работы ради удобства HR.

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

Продолжу про ИИ в HR. Самое интересное в разговоре оказалось вообще не в найме, а в адаптации новых сотрудников.

➡️Кто богатеет на ИИ

Одним из крупнейших бенефициаров бума искусственного интеллекта (ИИ) на Тайване стал производитель мебельных комплектующих King Slide Works. Как пишет The Wall Street Journal (WSJ), компания, выпускающая петли и направляющие для ящиков, также поставляет направляющие для серверных стоек, используемых в ИИ-инфраструктуре.

Простые на первый взгляд детали выдерживают вес тяжелых серверов и обеспечивают их охлаждение. Поскольку любая неисправность может стоить миллионы долларов, клиенты, по словам аналитика Counterpoint Research Брейди Вана, «не заботятся о цене направляющих, они заботятся о качестве».

King Slide занимает около 80% на рынке высококачественных серверных направляющих. С начала года акции компании выросли почти на 280%, а основатель Линь Цзунци стал богатейшим человеком на Тайване. По оценке Forbes, его состояние составляет $20,2 млрд.

В прошлом квартале валовая прибыль King Slide достигла 87% против примерно 50% несколько лет назад. Для сравнения, этот показатель у TSMC составляет 68%, у Nvidia — 75%, а у Arm — 97%.

РБК

Лопаты во все времена тоже неплохо продавать

➡️Не спрашивайте бизнес, что ему автоматизировать

начало тут

Параллельно с интервью продавцов я много разговариваю с РОПами и собственниками компаний.

И здесь обнаружился неожиданный побочный эффект.

Я думал, что интервью нужно прежде всего мне, чтобы собрать информацию. Но в процессе руководитель сам начинает заново рассматривать собственную работу.

Вспоминает забытые решения, связывает события, которые раньше существовали отдельно, и периодически говорит:
"Точно! Я же давно хотел это сделать".

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

Особенно хорошо это проявилось в разговоре с одним из собственников компании.

Он описал типичную ситуацию. Приходит залетный разработчик и говорит:
"Давайте ИИ внедрять! Что вам нужно сделать?"
А собственник честно отвечает:
"Я даже не знаю, чего хочу. Я не знаю, как это выразить".
Все. Тема скисла.

И это нормально, не знать своих хотелок.

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

Если бы он уже мог сам сформулировать готовое решение, вероятно, давно бы его сделал.

Поэтому прямой вопрос "что вам автоматизировать?" почти бесполезен.

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

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

Много общаюсь и с небанковским бизнесом. Там это длинные сделки, продажи оборудования, переписки, внутренние задержки, потерянные договоренности и другие места, где компания теряет скорость, клиента или деньги.

Мой рекорд это трехчасовое интервью (хотя на часик всего собирались😄). Еще два разговора продолжались примерно по два с половиной часа.

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

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

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

Не начинать с вопроса "куда бы прикрутить нейросеть".

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

Здесь мне сильно помогает технический бэкграунд. Я могу не только услышать проблему, но и примерно понять, что из найденного реализуемо, каких данных не хватает и где автоматизация принесет пользу, а где добавит еще один бесполезный отчет.

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

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

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

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

Записанное с моих слов верно. ЖПТ помог обобщить несколько голосовых надиктовок в структурированный рассказ📞

➡️Неожиданно я стал интервьюером

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

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

Вообще в продажи как отдельную профессиональную область я всерьез ушел всего три-четыре месяца назад.

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

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

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

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

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

При этом постоянно вижу контринтуитивные вещи.

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

То есть просто усилить контроль активности совсем не значит усилить продажи.

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

Где-то это подготовка перед звонком. Где-то поиск клиентов и выход на ЛПР. Где-то точная договоренность о следующем контакте. Где-то умение вовремя подключить другого специалиста.

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

Там оказалось еще интереснее.

➡️Третью неделю гоняю Кодекс параллельно с Клод Кодом под VSC

Оба тарифа по 20 долл. Отчитываюсь.


Особенности исполнения задач:

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

У ЖПТ дополнения чаще встают в очередь и принимаются в работу уже после выполнения текущей задачи. Если же принудительно переключить его на новое сообщение, он переключается, но иногда после этого забивает на предыдущую задачу.

В этом плане реализация Клода мне кажется удобнее.


Лимиты:

У ЖПТ нет этих 5-часовых окон лимитирования. То есть при желании можно за один присест выжрать весь недельный запас. У меня пару раз получалось разгрузиться буквально за сутки.

Но есть нюанс.
Я заметил, что GPT периодически просто сбрасывает лимиты до нуля раньше обещанной недели. Гады, и тут кинули!😄

Не очень понятно, происходит это у всех или маркетологи ЖПТ решили подсадить новичка на более интенсивное использование, чтобы потом я радостно переполз на жирный тариф.

Судя по перепискам в чатах, сбросы все-таки массовые, а не индивидуальные. В одну неделю у меня было 4 сброса, в другую - всего 1.

Клод - кремень! Сколько отгрузил изначально - столько и дал расходовать. Это вам не у бабушки пирожки в добавку просить.


Я и лимиты:

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

"Так, лимитов ещё много, скоро обнулятся. Дай-ка побыстренькому заряжу Клода на какой-нибудь объем работ, а то потом добро пропадет".

Выходные? Вечер? Пофиг. Работаем.

И вот это уже нездоровая тема.

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


Я в ожидании сброса лимитов:

С одной стороны, круто, что ЖПТ позволяет практически бесперебойно реализовывать задачи.

Но есть и обратная сторона.

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

И вот окончание лимитов иногда очень кстати помогает оторваться от процесса получения дофамина просто вырваться из процесса.

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

Так что Клод со своими ограничениями в каком-то смысле даже экологичнее.

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


Управление контекстом:

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

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

Кажется что удобно!


У Кодекса все идет до победного:

"Сам решу!"

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


Качество работы:

А вот здесь однозначного фаворита у меня пока нет.

Скорее они дополняют друг друга.

Бизнесовые и маркетинговые задачи, по моим ощущениям, ЖПТ решает чуть лучше. Например: проанализировать сайты конкурентов, потом пройтись по нашему сайту и проверить, хватает ли там нужных смыслов, функций, аргументов и т.д.

А еще Кодекс мне больше нравится в роли промпт и пайплайн инженера.

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

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


Ну и отдельный плюс обоим моделям:

Они хотя бы не облизывают меня так, как это любит делать Гемини.

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

За это обоим твердая пятерка.


Как-то так❤️
Лайк, репост, колокольчик😄

Kimi рвет рынок

Цитата из твиттера:

Kimi K3 на юридических задачах показывает производительность ~в 2 раза выше, чем у fable 🤯

Бенчмарк от Harvey и включает сложную автономную юридическую работу

Kimi K3 — 26,7%, против Claude Fable 5 — 14,2%.

➡️Как увеличить лимиты в Клод Коде

Лови лайфхак по увеличению первой утренней сессии в Клоде.
В разделе Routines (запуск по расписанию) выстави запуск простой задачи рано утром. Сброс лимитов будет от этой точки.

Т.е. запуская Клод в 6 утра, сброс лимитов будет в 11. И после можно продолжить работать с обновленными лимитами.

Этот лайфхак будет полезен скорее всего только для нищебродского 20ти долл тарифа.
Состоятельных господ прошу извинить за беспокойство😄