плюс одна успешная автоматизация

🌕
У нас в команде есть практика – оценка брифов.
Брифы – это странички в confluence, которые нам приносят продакты, по сути, описания новых фич и хотелок. Например, хотим умный мониторинг агента, хотим нового агента для планирования маршрутов и т.д.

И они приносят свою страничку нам, а наша задача – взять это и сделать "верхнеуровневую оценку". Что это за зверь? А это надо прочитать бриф, вникнуть в то, что продакт там хочет, подумать, а возможно ли это, а если возможно, то как, как это разбивается на блоки работы, какие есть зависимости и риски, и оценить, сколько рабочих дней это у нас займёт. 😮‍💨🚬 Обычно это надо сделать за 1-2 дня.

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

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

Звучит не очень круто, да? "Полностью автоматизирует" звучало бы лучше. Но это не правда – этот скиллсет не автоматизирует оценку полностью, потому что не может. Много контекста недоступно модели для принятия решений + много контекст сложно формализовать = это моя "интуиция" опыта.

И тем не менее – скиллсет работает!

Что внутри

1) скилл для визуализации брифа. Хорош для длинных и нудных брифов, которые не охота читать, а лучше мультик про них посмотреть. Этот скилл просто перекладывать бриф на html и компанует его в форму "что - для кого - как"

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

Вы скажите "ну это один промпт!", "Вот, посмотри, что тебе непонятно, задай вопросы". Нет) Такой подход генерирует артефакт с кучей мусора – вопросы, ответы на которые уже есть во внешнем контексте и в прошлой работе, вопросы из разряда "а точно надо это делать", кучу ненужных на данном этапе уточнений про продуктовый метрики, масса вопросов технического характера, на которые продакт не может ответить... А с помощью своего скилла я получаю вопросы, которые реально matters и которых не 50 штук.


3) скилл для генерации самой декомпозиции. Предполагается, что закрыты самые острые вопросы из пункта 2, но скилл может работать и в частичной неопределённости. Это нормально – на этапе декомпозиции нам и не нужно знать всю подноготную проекта, нам надо зайти немного с кондачка, игриво оценить проект.

Скилл работает в 2 этапа – сначала делает верхнеуровневую разбивку на "блоки" или "компоненты". Это крупные мазки. Я смотрю на них, и если моё виденье совпадает с виденьем клода, то он переходит к более подробной нарезке на задачи. Такая двух-этапность экономит мне усилия – не приходится потом читать подробно расписанные, но в конечном счёте неправильные задачи.
приятно, что оценки в днях уже +- скорректированы под моё восприятие о том, сколько оно займёт времени.

4) Последний скилл генерит html с результатами декомпозиции – это нужно, чтоб потом представить её в команде. Всё просто – показывать html с красивыми выделениями намного проще, чем md документ или jira задачки.

5) бонусный недоскилл, который надо оформить ещё – он делает "бумажную работу". Ходит в связанные доски / планирования / эпики, проставляет там оценки, тегает зависимые команды, делает задачки в джире.

В итоге экономия ресурсов – ого-го-го. Не буду говорить, во сколько конкретно (а то мало ли). Но ощутимо.

В этом недавнем подкасте с Валерием Бабушкиным была упомянута такая статья под названием "Компании – это просто граф из алгоритмов"

Статья аж 24го года, но актуальности она только набрала. Идея, собственно, следует из названия – любая компания и все процессы в ней – это просто шаги и связи между ними. Где-то шагов меньше, где-то больше, но в конце концов любую компанию и процесс можно представить в таком виде.
И как только мы получаем граф процессов, мы можем посмотреть на каждый компонент и задать вопрос "А точно ли он нужен? А можно ли его автоматизировать?" Таким образом, граф компании будет терять узлы и становиться более компактным. А если теряются узлы, то перестают быть нужны и люди.

Но, конечно, есть нюансы.

- чтоб сделать такой граф алгоритмов, нужно плотно потрудиться. Мы приходим в компанию, в отдел найма, например, берём кейс, анализируем, проверяем, ложится ли он на наш граф. Если да – супер, если нет – мы расширяем граф веточкой. И вот тут-то и вопрос – а сколько кейсов нам нужно проверить, сколько времени должно пройти, чтоб мы построили граф, который покроет хотя бы 80% рутины нашего отдела? А 95%?

На самом деле, мне кажется в большинстве индустрий / процессов / команд – не так уж и много ресурсов надо потратить. Посидеть рядом c HR-ом 1-2 месяца, записать всё, что он делает, в тетрадочку – и хоп, вы можете автоматизировать HR-а. Предположительно именно это и сделала Meta c теми восьмью тысячами сотрудников, которых они уволили одним днём – просто позаписывали их экраны месяц-два и всё.
Вполне вероятно, наш новый AI-HR будет менее эмпатичный и менее гибкий, чем живой hr (или нет), но даже если и так, его можно а) умножить на 10 и б) он всё ещё будет выполнять свою функцию в 80% случаев. Да хоть 60%, это неважно, ведь мы можем умножить этого hr-а на 10!

Другой вопрос – какая у нас цена ошибки. В случае с HR-ом ошибка – это отсеять хорошего кандидата или пропустить плохого... Well, hr-ы и так делаю это каждый день 😃. Если мы можем замерить эффективность HR-а, то мы можем замерить и производительность AI-HR-а и всё аккуратненько подсчитать, получив численное доказательство, что AI-HR нам будет выгоднее. А учитывая, что ai процессы можно улучшать, что модели становятся умнее, то преимущество становится ещё очевиднее.

При этом, кто-то должен будет автоматизировать эти процессы, экспертно их оценивать, объяснять, где AI ошибся и почему. Вполне логично, что это должен делать HR. Вот только это должен быть экспертный HR. эйчар из топ-20% . А все остальные..? Вот и думайте.

Предположение о том, почему некоторые модели так любят тире

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

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

Правда, обратная сторона этого в том, что модели стали этим делом злоупотреблять – так что тире стало восприниматься с подозрением уже и в человеческих текстах 😃

Такая мысль прозвучала в одной из лекций AI Native Sprint

Хорошую автоматизацию делают только те люди, которые очень глубоко в предметной области.
Мой Head of Customer Success за шесть часов собрал себе работающую автоматизацию, потому что это его процесс, он предыдущие три года этим всем занимался.

Глубокое понимание предметной области и как делать вещи – это основа. А вот этот весь AI-обвес он учится за три месяца.

Я это интерпретирую так: снижается роль посредника между идеей и реализацией. Вот отдел маркетологов хочет себя красивый динамический дашборд. Раньше они должны были пойти к разработчикам, чтоб те им это отрисовали. Теперь достаточно дать read доступ к базам данных, и маркетологи в целом и сами могут себе всё нарисовать. И это будет качественнее, потому что они могут мгновенно оценивать результат на основе своего опыта. Разработчики так не могут, они же не маркетологи)

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

А вот инфраструктура – где хранятся данные, как они хранятся, как они туда попадают, когда срабатывают автоматизации, что мы делаем с ошибками, как мы заставляем это работать быстро... Точно будущее есть у инженеров высоконагруженных систем. Наверное, есть будущее ещё у тех, кто будет учить работяг пользоваться ai агентами, но это ненадолго 👁

интересная тема, в общем, обсужу это с клодом как-нибудь ещё

Я все-таки купила Wispr Flow, потому что мне было лень возиться с бесплатными альтернативами (они есть)

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

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

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

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

То есть вот этот барьер между идеей и реализацией, он ещё сокращается за счёт того, что мне не нужно набирать текст. Мне достаточно сказать.

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

p.s. надиктовано на 70%