Пост Глеба про методичку функционера навеял. А как часто вы тонете в созвонах без цели?)

Самый занятой руководитель — самый бесполезный

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

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

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

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

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

Что конкретно помогает мне? Влетающие задачи я сразу кидаю в бэклог, чтобы они не застревали в голове. Там спокойно расставлю приоритеты, когда будет время. Забавное наблюдение: когда я перестал мгновенно отвечать на «влёты», часть вопросов начала решаться сама — человек просто успевал подумать. Для крупных задач выделяю слоты по 1,5–2 часа, где точно никто не потревожит. Для меня лучше всего работают утренние часы. Параллельных крупных задач не больше трёх между пересмотрами бэклога. И отдельно: ритм пересмотра. Раз в неделю, каждое утро — универсального рецепта нет, пробуй и ищи свой ритм.

И главное. Тот руководитель из начала поста — он не тащит. Он тонет и тянет за собой других. Не будь им.

О самоудовлетворении на работе.

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

Для меня один из ключевых навыков руководителя — самоудовлетворение (гусары — молчать). Хвали себя за продвижение к цели, даже если до финиша ещё далеко. Забавно: мы легко хвалим команду за промежуточные результаты, но себе в этом отказываем. Как будто руководителю не положено.

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

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

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

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

Вайбкодинг, который не стыдно показать

Мой дружок-пирожок Глеб, он же вечно Уставший техдир, в одного навайбкодил телеграм-бот для разделения счетов.

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

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

Я участвовал в альфа-тестировании с первых дней. Мы обкатали бота на нескольких посиделках и в последний раз раскидали счёт минут за пять.

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

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

https://killthebill.ru
@kill_the_bill_bot

Не бойтесь быть вторым. Не успел = опоздал?

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

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

В индустрии сейчас то же самое. Каждую неделю — новый инструмент, фреймворк, подход. Не попробовал первым — уже отстал. Остановился — проиграл. Но так ли это? Давайте разберём на примере ИИ — тут уже хватает протоптанных и брошенных троп.

Волна 1. Тропа промтинга

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

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

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

Волна 2. Тропа кодинговых агентов

Cursor, Copilot, Claude Code, Bolt — каждый месяц новый инструмент, и каждый раз ощущение: именно сейчас нужно всё бросить и внедрить. Знакомо?

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

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

Когда тропить первым всё-таки стоит

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

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

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

Дойти всем

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

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

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

Ваш продукт умрёт не от нехватки фич — а от их избытка

Мы годами жили в мире, где главным ограничением был ресурс разработки. Приоритизация, бэклог, «возьмём в следующем квартале». ИИ убрал это ограничение. И выяснилось, что оно нас защищало.

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

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

Зачастую лучшее приложение — это приложение, которое закрывает ровно одну потребность и делает это филигранно.

Ярким примером считаю DevOps Radio от товарища Синицына. Минималистичный интерфейс, понятная ценность и никаких назойливых попыток впихнуть что-то дополнительное. А за этим приложением ещё и стоит теоретическая база, которую Андрей собирал как настоящий маньяк — 18 источников для одной статьи на Хабре, где это видано.

Окей, проблема понятна. А что с ней делать-то?

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

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

Считай фичи затратами, а не активами. Каждый экран, каждый элемент интерфейса — это то, что нужно поддерживать, объяснять и за что нужно отвечать. Продукт растёт не когда в нём больше функций, а когда ценность на единицу взаимодействия становится выше.

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

Открой свой последний проект. Посмотри на интерфейс. Если ты не можешь объяснить за десять секунд, зачем тут каждая кнопка — может, пора перестать добавлять и начать уже выкидывать?

Не спеши, а то успеешь. Очерк о важности отдыха

Зайчик допрыгался.

Последние пару месяцев вайбкодинг (он же Agentic Engineering) стал моим новым наркотиком. Агенты, эксперименты, прототипы до часа ночи — стадия, когда глаза горят, а организм тактично намекает, что он тоже участвует. Я — человек крайне увлекающийся, и мне свойственно класть на режим, когда находится новая блестяшка. Организм в итоге дёрнул ручник и высадил меня на больничный.

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

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

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

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

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

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

Отдельно скажу про электронные девайсы. Когда ты две недели живёшь в режиме «утром чат, днём созвоны, вечером Claude», мозгу нужен полный детокс от экранов. Хотя бы на день. Первые пару часов чувствуешь себя не в своей тарелке, потом отпускает.

И набор тупых, но работающих советов, которые я сам регулярно игнорирую, а потом жалею:
— нормально спать (7–8 часов, а не «я высплюсь на выходных»);
— разнообразно питаться (нет, кофе и дошик — это не разнообразие);
— гулять на свежем воздухе (без подкастов в ушах — просто гулять);
— физические нагрузки (тело, которое целый день сидит, потихоньку мстит).

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

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

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

Берегите себя, братцы. Мир подождёт.

А какие ритуалы помогают вам поддерживать кукуху на месте?

Я тут про ИИ набухтел. А как у вас с AI adoption в жизни?

Мой набор лекций по вайбкодингу и Agentic Engineering — в открытом доступе

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

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

Просто чтобы это увидеть, нужна понятная структура с нарастающей сложностью, а не россыпь ссылок на статьи и видео. Так появился набор лекций: презентации и конспекты по Agentic Engineering. 9 лекций, от вайбкодинга до субагентов и оркестрации — 4 уже готовы, остальные в работе.

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

Основное кредо, которое транслирую на всех лекциях:

«Пробуйте сами, ошибайтесь, делайте свои открытия»

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

Забирайте, делитесь, пробуйте. И если в следующий раз на встрече вместо тишины будут вопросы — значит, всё не зря.

vladsazonov.com

Два типа разработчиков с ИИ: «просто работает» vs «а почём это работает»

Замечаю интересное разделение среди разработчиков, которые используют LLM в работе. И дело не в том, кто пишет промты лучше — а в том, насколько глубоко человек хочет понимать, что происходит под капотом.

Первый тип — прагматики. Открыл чат, закинул задачу, получил результат. Работает? Работает. Всё, следующая задача. Никаких вопросов про контекстное окно, токены, количество подключённых MCP-серверов. И знаете что? В этом нет ничего плохого. Большинство из нас именно так пользуется кучей инструментов каждый день — не разбирая, как именно работает компилятор или сборщик мусора.

Второй тип — копатели. Эти ребята лезут глубже: как устроено контекстное окно? Сколько токенов сжирает каждый подключённый инструмент? Как это влияет на качество ответа модели? Они ставят плагины для подсчёта токенов, экспериментируют с размером контекста и осознанно выбирают, что подключать, а что нет.

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

Деньги.

Давайте посчитаем. Подписка на Claude — 20 баксов в месяц. Звучит как цена за пару чашек кофе. Но если вы поставите плагин, который считает токены, и пересчитаете свой объём использования по тарифам API, — вы, скорее всего, будете шокированы. Ваши 20 долларов на самом деле — это сотни долларов в API-эквиваленте. Подписки сейчас сильно субсидированы, и мы привыкли к этому, как к дешёвому бензину: пока цена низкая, никто не думает про расход.

Но что будет, когда субсидии закончатся? Или когда подписки подорожают?

А теперь представьте другой сценарий — и он уже реален для многих компаний. У вас развёрнуто собственное on-premise решение. Свои серверы, свои модели, свой бюджет. И внезапно качество работы всей системы напрямую зависит от того, как именно ей пользуются люди. Один разработчик осознанно формирует запрос, подключает только нужные инструменты и получает точный результат с первой попытки. Другой — закидывает всё подряд, подключает десяток MCP-серверов «на всякий случай», получает мусор, доуточняет, переспрашивает. Нагрузка на сервера растёт, качество падает, а косты улетают в космос.

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

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

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

Модель вам соврёт. И чем она умнее — тем убедительнее

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

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

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

Почему модели врут?

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

Где это больнее всего бьёт

В сложной бизнес-логике. Вы можете пойти по всем правилам: Spec-Driven Development, полная документация, TDD, ручная перепроверка — и всё выглядит хорошо. Вроде работает, все довольны. А потом на проде выясняется, что модель допустила мааааленькую ошибку, и ваш код почти правильный. Вы можете не знать об этом неделями. Но это чеховское ружьё, которое вы точно не хотите видеть в своём продукте. Ведь однажды оно стрельнёт.

Что с этим делать

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

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

Заведите лог сомнительных решений. Один знакомый поделился подходом: добавляешь в системный промт правило «If you are unsure about a decision, log it». Дата, решение, в чём сомнение. Если модель сама фиксирует, где она не уверена, вы хотя бы знаете, куда смотреть первым делом.

Собственный интеллект никуда не делся, не забывайте его включать. Модель не несёт ответственности за то, что вы ей поверили. А вы — несёте.

А у меня на сайте вышло обновление лекций

Помните историю, как я ночью в полпервого факт-чекал сказки модели про Sentry и Pyroscope? Так вот, если бы у меня тогда был нормальный workflow — я бы не тащил непроверенную информацию к архитектору и лидам. А если бы я понимал, как устроен контекст — возможно, не скормил бы модели кашу из десятка источников, из которой она и слепила свою красивую сказку.

Собственно, об этом две новые лекции.

Лекция 5. Workflow и наблюдаемость агентов

Разница между «навайбкодил и молюсь» и инженерным процессом — в дисциплине. Spec, plan, TDD, verification все это звучит как душнила-чеклист, но именно он не даёт агенту тихо уехать не туда. Разбираем трейсы, ревью агентской работы и почему CI — ваш лучший независимый верификатор. Не забыл я и про мой любимый плагин superpowers, без которого уже не представляю разработку фич. Погружаемся с вами в тот самый «копательский» подход из поста про два типа разработчиков.

Лекция 6. Context Engineering

Контекстное окно не резиновое (в отличие от Москвы). Системный промпт, файлы, история, tool results — всё это жрёт токены. И когда агент «тупеет» на двадцатой итерации — это не он плохой, это вы ему физически не оставили места думать. Токенизация, стратегии управления контекстом, memory-системы — после этой лекции станет понятно, почему стоит контролировать используемые инструменты и шум который они могут приносить.

Все лекции можно найти тут: vladsazonov.com