Как проводить встречи эффективно

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

Подготовка
– Избегай звонков без необходимости – большинство вопросов решаются в чате
– Не дергай “на минутку” – если прод не упал, значит не срочно
– Анонсируй: кто, когда, зачем. Иногда достаточно треда в чате
– Проверяй доступность участников через календарь
– Ограничивай время – 30 минут обычно хватает, 1 час — максимум
– Готовь повестку заранее: тема, пункты обсуждения, цель встречи, уважай чужое время
– Рассылай материалы и документы до встречи
– Предупреждай об отмене или задержке как можно раньше
– Опаздываешь? Не опаздывай 🙂

Старт встречи
– Начинай вовремя – без «ждём ещё кого-то»
– Проверь комнату ожидания и список участников
– Напомни повестку – это фокусирует команду

Фасилитация
– Держись повестки и возвращай к цели встречи
– Дай слово молчунам, притормози болтунов.
– Подводи итоги каждые 10–15 минут: «Итак, договорились, что…»
– Следи за чатом и поднятыми руками
– Делись экраном, глаза – тоже канал восприятия
– Включай камеру по возможности
– Не перебивай – сначала дослушай, потом задавай вопросы.
– Паркуй спорные темы после трёх заходов
– Уважай выделенный слот – если нужно больше времени, спроси
– Веди пост-мит в реальном времени

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

#devfm

Еще один способ организовать рабочие чатики

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

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

И некоторое время назад я придумал (вряд ли я, но в моем мире – именно я), как иначе организовать рабочие чатики – по срочности.

Сделал 4 папки:
🔹Now – то, на что мне нужно реагировать незамедлительно. Таких чатов всего 1–2, но стремиться нужно к нулю
🔹Hourly – то, на что нужно посмотреть в течение часа
🔹Daily – пробежаться раз в день, узнать, что происходило
🔹Later – оно же «никогда», оно же «когда-нибудь». Это чаты, где просто нужно присутствовать :)

В результате стало гораздо легче ориентироваться и не отвлекаться на лишний шум.

#devfm

Шаблонный сервис

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

Так зачем же нужен шаблонный сервис?

Легко ориентироваться в других сервисах. Иногда нужно залезть в сервис коллег, или поддерживаешь несколько сервисов. Никаких проблем – структура везде одинаковая, всё знакомо, не нужно тратить время на раскопки.

Быстрый старт. Стартуете новый сервис? Полчаса – и он готов. Никаких лишних приседаний.

Единые практики. Шаблон определяет, не только структуру, но и то, как мы, например, делаем ретраи, какие у нас зависимости. как устроен circuit breaker, обработка ошибок и т.д.

Лучшие практики – в одном месте. Если появляется что-то классное, мы добавляем это в шаблон и новые сервисы сразу это наследуют.

Обсервабилити, логирование, работа с секретами – готово из коробки. И меньше шансов, что кто-то забьёт на логирование до лучших времён»:)

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

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

Унификация линтинга. Конфиги линтеров лежат в шаблоне. Ничего настраивать не нужно, а код-ревью идёт быстрее – обо всём уже однажды договорились и зафиксировали.

Базовый CI/CD. Для шаблонного сервиса существует шаблонный ci/cd – и это очень удобно.

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

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

В общем – заходите, смотрите, ставьте звездочки. И если с чем-то не согласны – пишите в комменты, автор обязательно ответит 🙂

#devfm #systemdesign

Ух, вчера вспомнил давно забытую боль.

Некоторое время назад мы пилили b2b-продукт и интегрировались по HTTP с большим сервисом большой компании.

И вот представьте моё удивление, когда приходит разработчик и говорит, что мы получаем код 200, а в body – что-то типа «произошла ошибка». Мы тогда повозмущались и смирились, потому что альтернатив всё равно не было.

И всё бы ничего, если бы вчера я не рассказал эту историю своему хорошему товарищу. А он, представьте себе, вообще не удивился. Сказал: «Да, всё так и есть. Видел это не раз. И во вполне приличных конторах – тоже».

И вот у меня вопрос – ну как так то, доколе?! Может, у этого есть какая-то логика?
Вы такое встречали?

#devfm

Хотел написать небольшой пост – а в итоге получилась целая статья.

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

Собрал в статье практические советы, которые помогают при работе с агентами:
– как организовать удобный флоу
– почему не стоит просить «сделать всё под ключ» и как стоит
– как формировать рабочие rules
– зачем переключать модели и когда это спасает
– почему экспертиза разработчика всё ещё критично важна

Заходите почитать, если понравилась ставьте лайкосики.

#devfm

Зачем вы проводите код-ревью?

Большая часть команд, с которыми я работал, проводят код-ревью. Код-ревью – как священная корова: “А код поревьюили?”, “Без ревью не пушим” и всякое такое.

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

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

Ответы бывают разные.

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

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

Код-ревью нам нужно для шаринга знаний – такой ответ дают самые прогрессивные. Честно говоря, какое-то время это был мой любимый аргумент, и я очень им гордился. Но если задуматься: для шаринга знаний предполагается, что разработчик, у которого куча своих задач и контекстов, переключится на чужую задачу, впитает всё, что там написано, разберётся и получит ценные знания. Вопрос – сколько же времени нужно для этого? Как говорят классики: «сомнительно, но окэээээй». Если услышите такой аргумент, спросите у разработчиков, сколько времени они тратят на ревью, и подумайте, можно ли за это время действительно перенять знания. Ответы, которые получал я, говорят: скорее нет, нельзя.
Моё мнение – код-ревью создаёт иллюзию шаринга знаний, но по факту распространяет только очень поверхностный контекст. Если вы реально хотите шарить знания, есть куда более прямые и честные инструменты – дизайн-доки, обсуждения решений до реализации, грумминги задач.

И это я ещё не затронул другие проблемы и крайности: когда в PR появляется миллион комментариев, когда какой-то очень умный разработчик упирается рогом и говорит, что такой PR "только через мой труп", когда PR-ы висят днями, копят строчки, а потом полдня тратится на разруливание конфликтов. В общем – красота.
Так зачем это всё?

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

Первое – составить гайд, хотя бы выровняться по одной линейке: как в команде проводится ревью, что мы ревьюим, на что обращаем внимание, а что считаем минором, тайминги проведения, выбор ревьюера, правила оформления PR-ов.

Второе – автоматизировать всё, что можно автоматизировать: линтеры, форматеры и вот это всё. Чтобы на ревью об этом даже не думали.

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

Ревью действительно должно быть:
– когда вы залезли в чужой сервис или область знаний и сами просите эксперта посмотреть код
– когда вы мейнтейнер опенсорсного проекта
– когда вы менторите новичков или джунов и осознанно инвестируете время

Если вы прочитали и подумали: "Что это за бред?" – ну что же. Либо вы никогда критически не смотрели на этот процесс, либо вам действительно повезло с командой. Во втором случае искренне за вас рад – держитесь за неё. Так бывает далеко не у всех.

#devfm

Каникулы ещё не закончились – самое время спокойно почитать что-нибудь полезное.

Собрал подборку лучших постов за прошедший год – если пропустили или хотите вернуться к избранному:
– Зачем нужен шаблонный сервис и пример такого сервиса на FastAPI
– Чтобы провести встречу продуктивно, нужно постараться. Мы написали, что сами применяем на практике
– Видео про роли в крупном проекте – аналитики, разработчики, тестировщики и как всё это живёт вместе
– Набор заметок о том, зачем нужны архитектурные схемы, как их составлять и где проходят зоны ответственности
– Пост-стенание на тему код-ревью
– Революционный метод организации рабочих чатов
– Сайт с сериалами на разных языках и бот для изучения иностранного языка методом карточек
– Мой опыт работы с ai-агентами
– Приём, который помогает быстрее принимать решения в команде
– Как не забивать на написание постмитов
– Статья о том, как написать своего первого ai-агента
– Советы и антипаттерны при работе с Postgres
– Очень крутой курс по System Design, который искренне рекомендую

#devfm #backup

Когда у задачи нет даты

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

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

Но есть такие задачи, которые не привязаны к дате – они привязаны к событию.
Примеры из жизни: “когда поеду в Сочи – сходить в такое то место”, “когда будет синк по проекту – обсудить текущий CI/CD”. У этих задач нет конкретной даты, и непонятно, куда их складывать. Если просто кинуть в общий список – они точно потеряются. Если поставить произвольную дату – будут раздражать напоминаниями не в тот момент и постоянно еще придется переносить.

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

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

В общем мне такой прием помогает. Пользуетесь ли чем-то подобным?

#devfm #productivity

Правило трёх итераций – когда диалог зашел в тупик

Бывает обсуждаете что-то с коллегой или смежниками, не можете договориться. Обмениваетесь аргументами раз, два, три – и всё никак. Такой словесный пинг-понг получается.

И в этом потоке обсуждения почему-то кажется, что ещё одна итерация – и точно договоримся. Ещё раз объясню свою позицию, приведу новый аргумент, и собеседник наконец поймёт.

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

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

Три итерации – и тормозим, работает удивительно хорошо.

#devfm

Заходите – будет интересно

Когда плотно работаешь в какой-то области, всегда интересно подсмотреть – а как делают другие? Что у них там интересного происходит?

Ребята уже второй раз организовывают митап AI Dev Day. Главная идея – поделиться опытом, как AI-инструменты внедряются в процесс разработки.

Мне особенно интересно послушать, как в других компаниях разрабатывают кодовых ассистентов. И еще тема, которая цепляет – опыт внедрения метрик для оценки AI в цикле разработки. Как это делать правильно – кажется, никто еще не знает.

Ну а я поделюсь нашим опытом: как мы развиваем агента для разработчиков в IDE. Как продвигаем инструмент внутри компании и растим адопшен. Отдельно расскажу про агента за пределами IDE на примере YQL-агента – как адаптировать к внутреннему домену, как оценивать качество и где брать для этого данные.

Мероприятие пройдёт 15 марта офлайн, но будет онлайн-трансляция. Регистрируйтесь, приходите, буду рад пообщаться.

#devfm #ai

Вот и прошёл AI Dev Day. Классное получилось мероприятие. Делюсь выжимкой моего доклада.

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

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

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

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

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

А кто любит движуху вокруг LLM – 21 марта будет ещё один любопытный митап в офлайн и онлайн форматах.

#devfm #ai

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

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

Аналогично с Фигмой – я в ней нечастый гость. Нужно было скопировать себе чужой проект, и я понятия не имел, как это делается. Скриншот → агент → готово.

Тот же паттерн кстати с ридмишками проектов. Открываю README, начинаю вчитываться, пытаюсь понять что за проект, как запустить... а потом бью себя по рукам – зачем? Скидываю агенту, и через минуту у меня полная картина: что за проект, как развернуть, какие есть нюансы. И можно задать уточняющие вопросы, если что-то непонятно.

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

#ai #devfm

Скиллы в агентах – часть 1: база

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

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

Модульность
Скилл – это обычная папка. Внутри обязательный SKILL.md – основная инструкция, которую читает агент: что делает скилл, когда его применять и как именно действовать. Рядом можно положить что угодно: референсы, примеры, вспомогательные скрипты, которые агент вызывает по ходу работы.

my-skill/
├── SKILL.md
├── references/
│ └── examples.md
└── scripts/
└── helper.py

В SKILL.md обязателен фронтматтер с двумя полями – name и description.

Progressive disclosure
В отличие от правил (rules) или agents.md, которые грузятся в начале каждой сессии, тело скилла в контекст не попадает. Изначально там только name и description из фронтматтера – буквально пара строк. Агент сам решает, нужен ли скилл под текущую задачу, и только тогда подтягивает содержимое.

Думаю, именно поэтому скиллы набирают такую популярность.

В проектах, которые я видел, бывает куча рулов, которые грузятся по умолчанию, и контекст забит ещё до того, как ты начал работать. С MCP та же история (хотя с этим пытаются бороться – писал тут). Добавил несколько MCP-серверов, и добрая часть контекстного окна уходит под описания тулов, которые в этой сессии даже не пригодятся. Всё это осложняется тем, что обычный пользователь агентов не сразу поймёт, в чём у него проблема, будет страдать и не понимать, почему агент тупит на ровном месте.

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

Чтобы лучше разобраться, как работают скиллы – подготовил визуализацию.

В следующем посте посмотрим, а так ли всё хорошо с этими вашими скиллами.

#devfm #ai

Где брать скиллы (часть 3)

С тем, как устроены скиллы, разобрались, даже в движении. А где их брать?

Мне нравится простой каталог skills.sh. Удобно, что можно отсортировать по популярности или посмотреть, что сейчас набирает обороты – можно позалипать, вдохновиться.

Из тех, чем сам пользуюсь:
frontend-design – уже про него рассказывал. Лучший способ получить адекватный дизайн, когда дизайнера рядом нет.

brainstorming – запускаешь перед началом работы над задачей, и агент начинает задавать уточняющие вопросы. После 5–6 вопросов требования становятся заметно полнее. На практике брейншторм почти всегда поднимает что-то, о чём не подумал или отложил на потом.

pptx – скилл от антропика для работы с презентациями. Два режима: с нуля (чтобы было не вырви глаз) или создать по существующему шаблону – очень удобно. У ребят есть аналогичные скиллы и для pdf, docx, xlsx – тоже стоит присмотреться.

playwright-skill – никогда написание тестов не было таким простым и бесплатным. Если необходимость unit-тестов для агента ещё под вопросом, то полноценные e2e – мастхев, и плейрайт-скилл сильно облегчает задачу.

Делитесь, какими скиллами пользуетесь – интересно собрать подборку.

#devfm #ai

Создаем свои скиллы (часть 4)

Что касается создания своих скиллов – тут я обычно беру skill-creator от Anthropic. Очень мощная штука: проводит по всему флоу создания, задаёт уточняющие вопросы и помогает написать евалы – чтобы при доработке скилла сразу видеть, что старые сценарии не сломались.

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

Например, на работе периодически нужно делать релиз-ноты – и в продукте, и на информационных площадках. Процесс довольно топорный:
1. Достать из таск-трекера то, что вошло в релиз
2. Методом пристального взгляда отфильтровать то, что важно пользователям
3. Сформулировать всё на пользовательском языке, перевести на английский
4. Найти в кодовой базе json, который отвечает за релиз-ноты, и дописать нужное – то же самое для английского
...
N. Закоммитить, запушить
N+1. Взять эти релиз-ноты, расписать подробнее по шаблону и разложить по площадкам

Руками это задача на час минимум. Топорно с агентом – минут пятнадцать. Со скиллом – три минуты.

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

Аналогично есть скилл для моего таск-менеджера TickTick. Надиктовал задачу – а он уже знает, в какое место её положить, какую дату поставить, какие теги навесить. Очень удобно.

Ещё пара моментов:
– Скиллы стоит делать от сценариев. Обычно сначала просто решаешь задачу через агента, а потом понимаешь, что это можно обернуть в скилл
– Не жди, что заработает с первого раза – особенно на сложных скиллах. Это инкрементальный процесс: нашёл, где не работает – подточил, написал евал – и так из раза в раз
– skill.md не резиновый. Общая рекомендация Anthropic – не больше 5000 токенов, но и это кажется дофигамба. Держим skill.md маленьким, остальное выносим в references
– Не пиши в скилле общеизвестное. Как понять, что лишнее? Только опытным путём: есть сомнения – удаляешь кусок информации и смотришь, как работает. Опять же, skill-creator при прогоне евалов сам подсказывает, что можно улучшить

#devfm #ai

Скиллы: как создавать, улучшать и распространять на команды

Недавно выступал на Podlodka и рассказывал про скиллы.

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

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

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

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

#ai #devfm

Голосовой ввод и visul explainer – чтобы структурировать мысли

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

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

Здесь хорошо сработала связка голосового ввода в Handy и скилла visual explainer.

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

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

Получившийся текст я отдал агенту с visual explainer и попросил структурировать.

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

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

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

#ai #devfm

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

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

И тут вспомнил, что вообще-то очень люблю горы. Значит, надо ехать. Хотелось уложиться в 3–4 дня и ничего не организовывать самому – обычно я как раз всё делаю сам.

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

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

В общем, если очень устали – рекомендую. Гифка для затравки :)

#devfm

Codex Desktop – просто красота нечеловеческая

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

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

По долгу службы я еще делаю презентации. HTML-презентацию можно открыть прямо в Codex, не переключаясь отдельно в браузер, и ревьюить конкретные элементы. Наводишь курсор на то, что не нравится, оставляешь комментарий (голосом, конечно же) – и агент получает точную привязку к месту. Код из приложения можно ревьюить так же.

Удобно уточнять
Бывает, агент что-то выдал, а хочется уточнить небольшую деталь: что он имел в виду или что означает какой-то термин. Раньше был выбор: разрывать основной диалог или создавать отдельный чат. Теперь можно выделить блок текста и выбрать More Details – агент сразу начнет объяснять именно этот фрагмент. Или Ask in side chat – рядом откроется аккуратный чат, где можно уточнить что угодно в свободной форме.

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

/goal
То, что раньше делали сторонние решения вроде Ralph loop, где агент работает до потери сознания, лишь бы выполнить задачу, теперь можно делать в Codex. Пишешь /goal – и вперед.
Я пока только пробую этот функционал, но мне нравится. Например, нужно написать CLI-обертку над чужим API. DoD понятен – работай на здоровье. Агент ковыряется уже 11 часов, посмотрим, что из этого выйдет.

Автоматизации
На автоматизации тоже подсел: появился полноценный раздел Scheduled, из которого удобно запускать разные задачи по расписанию. Я сразу завел несколько:
– анализ прошлых диалогов: что стоит вынести в AGENTS.md, какие существующие скиллы подправить и какие новые создать
– разбор календаря: посмотреть встречи на день, найти встречи без повестки и подготовить организатору драфт сообщения с просьбой ее добавить и уточнить, зачем я нужен на встрече
– разбор почты: собрать несмердженные PR, которые ждут моего ревью, и тикеты, где меня призывают, – сразу с прямыми ссылками, чтобы не открывать письма
– мониторинг пет-проектов: посмотреть логи и рассказать, не случилось ли чего

Remote-подключение
К сессиям Codex на компьютере можно подключаться через мобильное приложение – очень удобно продолжить работу не за столом. Если в вашем App Store нет ChatGPT, мне помогла смена страны аккаунта: после этого приложение появилось.

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

В общем, все стало сильно продуманнее – попробуйте.

#ai #devfm

Когда появился OpenClaw, я поставил его себе, поигрался, но полезных сценариев так и не нашел.

Недавно решил сделать еще один заход – на этот раз с Hermes. Взял виртуалочку, установил туда Codex. Ну как установил: попросил локальный Codex подключиться по SSH и все настроить. Через него же поставил Hermes и сделал канал для общения в Telegram. На все ушло не больше получаса.

На этот раз придумал два сценария.

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

Дальше зафиксировали интересные мне источники, добавили еще несколько вариантов, которые предложил агент, написали пару парсеров – и в целом всё. Теперь Hermes каждый день присылает подборку новостей, которые должны быть мне интересны. Если что-то оказывается неинтересно, так и говорю ему: "Такое больше не присылай потому то".

Мониторинг продуктов со скидкой
Второй пример немного шутейный. Я заказываю продукты из ВкусВилла, а у них бывают зеленые ценники со скидкой 40% и такие товары быстро разбирают.

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

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

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

#ai #devfm