Teamlead Good Reads – ежедневные советы про менеджмент людей и команд

Про AI психоз целых компаний

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

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

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

Про AI психоз

Если ваш СЕО уже рассказывал вам с горящими глазами про то, как он сутками пишет код, или про то, как скоро всех сотрудников заменят самоуправляемые рои агентов, или просил теперь со всеми запросами обращаться напрямую к его OpenClaw – поздравляю, скорее всего, у него острая стадия AI психоза.

Вот в чем она выражается:

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

Если ваш СЕО, или кто-то еще рядом находится в этой стадии, отнеситесь к нему с пониманием, и постарайтесь защитить продукт и команду.

Теперь компетенции нельзя оценить по результату работы

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

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

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

Оцениваем успех внедрения AI через скорость обучения

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

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

Чтобы не продолбать внедрение на этом этапе, в статье советуют прокачивать три веточки:

👉Agent Operations – контроль за тем, какие агенты работают в компании, к каким системам им выдается доступ, как этот доступ ограничивается, что там по аудитам.
👉Loop Intelligence – в каких циклах AI реально помогает, в каких нет, чего командам может не хватать, чтобы эти циклы сходились успешно, а где они превращаются в сайд-квесты, не несущие компании пользы.
👉Agent Capabilities – как полезные открытия и способности агентов распространяются по всей компании.

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

Если AI удаляет вашу базу данных, виноваты вы, а не AI

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

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

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

Structured-Prompt-Driven Development

Большинство команд, активно начавших использовать агентов, быстро приходят к двум идеям, которые сейчас принято называть Spec-Driven Development:

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

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

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

Когда корреляция врет

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

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

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

Инженер, который говорит нет

For 50 years, software engineering ran on code rationing. Writing code was expensive, so we rationed it carefully through roadmaps, RFCs, prioritization meetings, and scope reviews.

This created a role: the No Engineer. No, that won't scale. No, we don't have bandwidth. No, that's out of scope. No, we need a design doc first. The No Engineer was valuable for 50 years. Every "no" saved real money. Their judgment was the rationing system.

LLMs will be the end of code rationing. Code is cheap now. And while the No Engineer is explaining why something can't be done, the Yes Engineer has already shipped three versions of it.

If you're a Yes Engineer, the next decade is yours.

На прошлой неделе весь твиттер спорил вокруг тейка очень умного инженера, архитектора в Nvidia, и автора гугловых TPU.

Если кратко, то суть такая: раньше самыми ценными были разработчики, которые умели говорить "нет", и таким образом сохранять деньги бизнеса, а вот ближайшие 10 лет намного ценнее будут те, кто наоборот говорит "да", и быстро-быстро пилит все с AI.

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

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

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

Лучший способ проверить какую-то идею на жизнеспособность – это провести эксперимент, а не спорить о ней на душном митинге. Чем больше идей мы проверили, тем больше шансов у какой-то из них на успех. Раньше мы пытались ускорить эксперименты в довольно ограниченных кусочках продукта – например, внедряя штуки вроде Backend-Driven UI в мобильных приложениях, который позволял очень сильно сократить цикл выкатки эксперимента. Или давая в руки продактам инструмент для быстрого запуска A/B тестов на небольшие изменения в лэйауте фронтенда.

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

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

Продуктивность – это ловушка

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

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

Что работает и не работает для Agents.md

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

👉Progressive disclosure лучше, чем очень подробный файл. Лучше всего структурировать его как скилл, на верхнем уровне держать общие рекомендации, а детали и примеры в отдельных референс файлах. Лучше всего перформили в экспериментах Agents.md на 100-150 строк.
👉Один из самых эффективных паттернов – описывать задачу или сложный воркфлоу как серию пронумерованных шагов.
👉Сильно помогают decision tables – в случаях, когда в кодовой базе есть несколько разных способов решения одной задачи. По сути это набор вопросов с весами в пользу того или иного варианта.
👉Короткие сниппеты из реальной кодовой базы сильно повлияли на переиспользуемость кода.
👉Все don't надо сопровождать соответствующими do.
👉Не нужно слишком детально описывать архитектуру, в том числе во вложенных файлах.
👉Избегайте слишком длинных секций "dos/donts", когда их количество уходит за 15, все становится плохо.

Как нанимать людей, которые сильнее вас

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

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

Как слышать других

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

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

Продолжим тему AI-native собеседований. В июне в Podlodka AI Engineers Club я планирую организовать стрим про то, как меняются процессы интервью в разных компаниях с учетом того, насколько сильно поменялась рабочая рутина разработчиков. Если вы в вашей компании делали с собеседованиями что-то интересное в этом направлении, отпишитесь в Google Form – я ищу еще пару участников, и буду рад позвать кого-то из подписчиков!

👉Гуглоформа тут

Подход к AI-native интервью

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

Держите кейс компании, которая переработала этот процесс так, чтобы он лучше отражал, как они работают на самом деле.

Основная часть – онсайт интервью. Оно состоит из следующих этапов:

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

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

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

Мне понравилась идея того, что несговорчивость – это не бинарная характеристика человека, а раскладывается как волна на частотность и амплитуду. Частотность – это то, насколько часто вы готовы входить в спор, чтобы отстоять свое мнение. Амплитуда – это то, на что вы готовы пойти, чтобы его отстоять.

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

Новые выпуски менеджерских подкастов

👉"Три тимлида заходят в бар" про обучение менеджеров: как много нужно учиться, чему конкретно и какими способами.
👉Бреслав и Ложечкин: продолжение предыдущего выпуска про спецификации вообще и новый язык программирования для AI в частности.
👉КОДА КОДА про сложные переговоры: какие инструменты и практики использовать, чтобы договариваться о важных вещах

AI вредит нашей способности учиться

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

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

Про будущее Figma

На прошлой неделе Anthropic выпустили Claude Design – агента, который умеет готовить дизайн с полным знанием всей дизайн-системы и конвенций в вашей кодовой базе. Акции Figma, которые и так очень сильно падали весь последний год, упали еще сильнее. В статье – хороший анализ, почему Figma вообще постепенно становится нерелевантной тому, как развивается индустрия:

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

Закрывшиеся стартапы продают свои внутренние данные

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

Так что, если вам когда-то казалось, что создавать кучу тикетов в Jira, писать статей в Notion, и переписываться в Slack – это бесполезная работа, то вы просто еще не поняли, что это новое золото!