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

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

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

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

Волна 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

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

Сейчас моё любимое чтиво — рубрика #сережазаваспочитал в канале #безвотэтоговсего. Серёжа берёт статьи из Harvard Business Review, пропускает через себя и выдаёт короткий разбор со своим мнением. Читаешь — и как будто поговорил с умным человеком о статье, которую сам бы не осилил.

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

«Хорошие художники копируют, великие художники крадут». Мы никогда не стыдились воровать гениальные идеи у других. — Стив Джобс

Начнём рубрику, конечно же, с ИИ. Разберём доклад Будущее MCP — Дэвид Сориа Парра, Anthropic.

Дэвид — со-автор Model Context Protocol и знатный матершинник (а все уже знают, что использование мата при общении с ИИ экономит токены). Кому как не ему рассказывать, какое у протокола будущее.

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

Progressive discovery

Подход работает за счёт tool discovery и даёт модели возможность не подгружать сразу все инструменты в контекстное окно, а вынести этот этап на обработку простым regexp (совпадение по словам). За счёт этого снижается расход токенов и уменьшается шум в работе модели. Модель в процессе работы может обратиться к tool search и найти подходящий инструмент в своей библиотеке.

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

Programmatic tool calling

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

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

Но хватит о настоящем, что же там в будущем?

SDK v2. TypeScript SDK и Python SDK получат вторую версию — с учётом всех уроков прошедшего года.

Cross-app access. История для энтерпрайза. Один раз логинитесь в корпоративный IDP — Google, Okta, неважно — и дальше пользуетесь MCP-серверами без повторных логинов, прокидываний токенов и настроек.

Server discovery. Автоматическое обнаружение серверов по well-known URL. Краулеры, браузеры, агенты заходят на сайт и спрашивают: «кроме HTML-страницы, у вас тут MCP-сервер не стоит?» — и сразу его подхватывают. Обещают в июне, вместе со следующей версией спецификации.

Skills over MCP. Вместе с подключением MCP будет поставляться инструкция — как правильно использовать весь этот зоопарк. Для меня основная ценность — в бизнес-агентах, а не в кодинговых. Они заточены под конкретные задачи, и логично сразу поставлять инструкцию и бизнес-сценарии, в которых используется MCP-сервер.

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

#владсноваутащил

Рекомендательные системы давно собрали каждому из нас удобный, замкнутый мир. У кого-то про AI и сноуборд, у кого-то про политику и крипту, у кого-то про детей и сериалы. У каждого — свой пузырь.

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

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

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

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

А откуда у меня это «правильное» представление? Кто и когда меня в нём убедил?

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

— Можно. А зачем? А зачем я это делаю? Самый простой и самый игнорируемый вопрос. Чаще всего я не знаю ответа — и продолжаю делать, потому что страшно признать, что не понимаю зачем.
— Откуда я это знаю? Закинуть запрос в чат ещё не значит разобраться.
— Я искал правду или подтверждение? Формулировка запроса часто уже содержит ответ, который ты хочешь услышать.
— Когда я последний раз слушал человека, который думает иначе? И слышал — а не ждал, когда он замолчит.

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

Так что да, пузырь — это нормально. Не нормально никогда из него не выглядывать.

А ты вообще знаешь, в каком ты сейчас?

До 15 мая ловим доклады на Saint HighLoad++

Мы открыли добор докладов в стрим «Внедрение AI в SDLC» на Saint HighLoad++. Ищем тех, кто реально катает AI-инструменты или агентов в проде — на любой стадии цикла. Дедлайн — 15 мая.

Конференция 22–23 июня в Питере, 1500+ участников. Помощь в подготовке, проезд и проживание — на организаторах.

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

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

Подача и подробности: cfp.highload.ru

Пока я активно погружаюсь в работу нового направления и завален работой, ребята из A?.Frontend Community делают то, что я люблю — мероприятие на стыке Frontend и AI.

A?.Frontend Техно-квартирник — неформальная встреча с разбором реальных кейсов ИИ-агентов во фронтенд-разработке. Эксперты из Альфы, Сбера и других команд, живые дискуссии после каждого доклада, а в конце — диджей-сет и Networking party.

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

⚡️ Данила Звягин и Илья Агапов — «Чистая архитектура frontend-приложений и причём здесь AI-агенты?» Про то, как ИИ сначала ускоряет разработку, а потом начинает тащить в новый код старые костыли и думать только о «сейчас», а не о том, как проект будет жить через полгода. Разберут, как делегировать реализацию агенту и не потерять контроль над системой.

⚡️ Рома Троицкий — «Как я поднял AI-агента и снова стал высыпаться: OpenClaw, скиллы и корпоративная рутина» Про превращение рабочего хаоса (заметки, PR-ы, встречи, контекст полугодовой давности) в систему на агентах и скиллах. Рома обещает, что уйдёте с готовым OpenClaw-сетапом, который можно склонировать к себе.

📍 Москва, Проспект Андропова, 18к3 (офис Альфа-Банка, метро Технопарк)
🗓 27 мая, 19:00 (регистрация с 18:30), офлайн + онлайн
❗️ Записи не будет — ловите вживую

Приходите сами, зовите друзей и коллег.

Регистрация

Экстраполяция мышления
Когда случайность принимаешь за закономерность

В последнее время всё чаще ловлю один и тот же паттерн: человек берёт опыт из одной точки и натягивает его на всё подряд.

Пример. Кто-то попробовал одну модель, скормил ей кашу из кривых данных, получил на выходе мусор. Вывод готов: «Да эти ваши ИИ бесполезны, только мешают. Выбрасываем, не смотрим, не трогаем».

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

Объяснение простое и не очень лестное для нас. Мы ленивы. Чтобы понять, почему здесь взлетело, а там провалилось, нужно глубоко погрузиться в конкретный кейс. А с высоты helicopter view куда проще: взял одни данные и растянул на всё остальное.

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

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

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

Что помогает мне не скатиться в скоропалительные выводы:

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

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

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

Учу ребят формировать конкретные предложения. Большая разница между «меня что-то не устраивает» и «вот замечание: в таком-то процессе это создаёт такое-то неудобство, и, по моему мнению, починить можно вот так». Первое — фоновый шум, который ни к чему не приводит. Второе — готовый материал для решения. Этот навык вытаскивает наружу тот самый контекст, без которого любое улучшение остаётся гаданием.

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