Никогда не злитесь на работе

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

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

У ситуации три выхода:

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

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

Как AI влияет на дублирование и переиспользование кода

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

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

👉Процент файлов, содержащих дублирующиеся 5+ строк, вырос на 80% с 2023 года.
👉Доля коммитов, содержащих в себе перенос строк из одного файла в другой, упала на 70%.
👉Все меньше и меньше нового кода переиспользует существующие функции – доля строк, содержащих такие вызовы, упала на 35%.
👉Легаси код, написанный больше 12 месяцев назад, стали изменять или удалять еще реже – процент коммитов с такими изменениями упал с 1.7% до 0.46%.

Как вы думаете, что будет с джунами?

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

Я собрал мнения нескольких участников нашего Podlodka AI Engineers Club с большим опытом работы с джунами, и смотрящих с немного разных сторон индустрии. Кто такой хороший джун в 2026? Стали ли джуны, вооруженные агентами, более полезными, и быстрее приносить пользу команде? Что изменилось в механизме их обучения? По каким сигналам оценивать, становится ли джун сильнее, и когда он станет мидлом? И самое главное – есть ли вообще смысл их нанимать?

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

Как считать ROI команды

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

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

👉Считаем стоимость команды как единого целого с учетом заралат и токенов
👉Привязываем команду к каузальной модели того, как бизнес приносит ценность, при необходимости через прокси-метрики

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

Новые выпуски тимлидских подкастов

Мне вообще не верится, что Подлодку я пишу уже почти ДЕСЯТЬ ЛЕТ. За это время подкасты в России успели набрать популярность, достичь своего пика в период ковида, а потом постепенно откатиться к адекватной норме. Сейчас люди продолжают слушать подкасты, но мало кто доходит больше, чем до 1-2 выпусков в неделю. Поэтому держите подборку, которую сможете слушать еще месяц вперед!

👉Бреслав и Ложечкин про типологии личности, и то, можно ли извлечь из них пользу, даже несмотря на их антинаучность.
👉"Три тимлида заходят в бар" про политические игры в корпорациях и то, как научиться в них не проигрывать.
👉"Едим слона целиком" про стратегическое мышление – из каких элементов состоит этот навык, и как его развивать.
👉Weekend Talk с Иваном Поддубным про то, как рабоатть всю карьеру в одной компании, и должен ли СТО писать код

У нас больше нет оправданий делать медленный софт

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

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

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

Что такое ответственность за фичу

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

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

Ирония автоматизации

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

Из этой серии интервью в 1983 родилась статья "Ironies of Automation", которая ну до боли напоминает сегодняшние разговоры о нашей индустрии.

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

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

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

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

Надо ли ревьюить код

Вообще, все споры про то, надо ли ревьюить весь AI-generated код, на мой взгляд, довольно бессмысленны. Разговор стоит вести на другом уровне абстракции – нужен ли в целом процесс code review, вне зависимости от того, кто этот код написал.

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

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

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

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

Как в Uber управляют экономикой AI

Uber выпустил интереснейший разбор всех деталей того, как AI используется во всех этапах их SDLC, как они выросли в нагрузке в 7 раз с февраля, при этом существенно сократив затраты на каждую отдельную сессию. Вот некоторые интересные инсайты:

👉Основные рычаги влияния на экономику AI: цена за токен, количество шагов в сессии, количество запросов к модели на каждый шаг, и количество токенов на каждый запрос.
👉Дефолтную модель меняют чуть ли не каждую неделю, постоянно гоняя их на собственных бенчмарках, и выбирая оптимальную по цене/качеству.
👉У всех инженеров форсится максимальный размер контекста в 400к токенов и medium reasoning – это помогает контролировать количество токенов в запросе.
👉Все MCP тулы находятся за единым гейтвеем, что и экономит токены, и позволяет навесить единые политики авторизации.
👉Собственный графовый движок помогает существенно ускорить поиск агентом нужного контекста (с 20 минут до 40 секунд для довольно типичной задачи).
👉Внутренний дэшборд подсвечивает каждому человеку антипаттерны в том, как он работает с AI.

Как измерить слоп

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

Есть несколько альтернативных количественных методов:

👉Просто смотреть на количество строк кода, но есть нюанс – если сделать эту метрику целевой и оптимизироваться под нее, то смысл она быстро потеряет.
👉Verbosity – количество продублированных или бесполезных строк (реализовано через ast-grep)
👉Erosion – насколько значимая часть кода сосредоточена в небольшом количестве больших и сложных функций. Считается через цикломатическую сложность.

Verbosity и Erosion довольно заметно отличаются между завайбкоженными проектами и просто старым добрым человеческим легаси – для AI кода в среднем они в два раза выше.

Как дать фидбэк по итогам собеседования

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

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

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

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

Универсальные отказы на интервью

У отказов на интервью есть и другая крайность – универсальные, ничего не значащие ответы, которые вообще не отвечают на вопрос кандидата "почему меня не взяли".

Пара примеров из статьи:

👉У кандидата пустой GitHub? Скажите, что вам не нужен человек, который не увлечен программированием.
👉GitHub с проектами, но звезд нет? Вам не нужен кандидат, который не может писать полезные и востребованные вещи.
👉GitHub со звездами? Вам не нужен человек, который вместо работы будет своими пет-проектами заниматься.

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

Как агенты следуют разным техникам верификации

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

👉Результат, полученный без дополнительных инструкций, оказался выше, чем с любой из добавленных техник верификации.
👉Инструкция использовать TDD дала вдвое больше тестов, но результаты оказались хуже.
👉Формальные доказательства касались тривиальностей вместо корректности реализации.
👉Фаззинг активировался не всегда, инпуты генерировались бессмысленные, многократно проверялись ветки отказа.
👉Лучше всего работали очень конкретные инструкции – искать вероятные ошибки, выбирать граничные и асимметричные примеры, генерировать содержательные инпуты при фаззинге, но даже тогда следование инструкциям было не полным.

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

Кроссплатформа теряет смысл

Shopify, которые безумно топили за React Native последние годы, решили дропнуть кроссплатформу и уйти обратно на натив. Причины, которые они называют вслух:

👉Агенты могут легко переносить готовые фичи из iOS в Android и обратно, так что преимущество от ускорения разработки сходит на нет.
👉Разработчики могут контрибьютить в обе кодовые базы, не испытывая проблем из-за незнания Swift или Kotlin, и это убивает преимущество от использования одного языка.
👉Feature Parity поддерживать стало дешевле из-за единых спек и тестов, так что косты в этом месте тоже упали.
👉Делать нативные приложения все еще лучше, так как ты находишься ближе к железу, используешь нативный тулинг, и тащишь меньше зависимостей.

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

Как писать с помощью LLM

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

Но это не значит, что LLM нельзя использовать, чтобы сделать человеческие тексты лучше. Начнем с того, чего делать нельзя:

👉Не нужно использовать никакие слова и обороты, которые LLM вам предлагает, именно они дают ощущение AI текста.
👉Не нужно обращать внимание на то, когда модель хвалит вас или ваши идеи.

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

Еще очень помогает направлять модель на конкретные проблемы – чтобы собрать себе нужный словарик и набить руку в статье советуют книгу Lessons in Clarity and Grace, я не читал, но в бэклог забрал.

Как Bending Spoons переделывает компании

Bending Spoons – это итальянская компания с очень интересной бизнес-моделью. Они выкупают бывшие когда-то легендарными компании, которые либо перестали расти, либо стали убыточными, и жестко их оптимизируют – увольняют большую часть команды, встраивают в свою инфру, выкручивают цены для лояльных пользователей, и заменяют дорогих американских инженеров дешевыми европейскими. Чисто чтобы понимать масштаб, им сейчас принадлежат Meetup, Airtable, Evernote, Issuu, Vimeo, StreamYard, Eventbrite и даже AOL. А на прошлой неделе они купили Miro!

Так вот, вышла статья от инжиниринг менеджера из Evernote, который рассказал, как поглощение и оптимизация выглядят изнутри. Там не то, чтобы какая-то eye opening история была, но вот несколько интересных шагов:

👉Каждому департаменту назначили дополнительного менеджера из Bending Spoons, задачей которого было присматривать за происходящим и задавать направление.
👉До сокращений всем желающим предложили уйти по собственному желанию с тремя зарплатами и ноутбуком.
👉Bending Spoons жестко оптимизировали косты – отказались от офиса, перевели всех с платного Zoom на уже доступный в офисном пакете Google Meet, заменили часть сервисов вроде платформ для проведения интервью или пушей на самодельные внутренние решения.
👉Подняли цену на подписку на Evernote в два раза.
👉Постепенно запустили сокращения в несколько волн, в результате весь персонал в США уволили и перевели разработку в Италию. Кому-то даже релокацию предложили!

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

Менеджеры как вымирающий вид

Компании продолжают резать косты и повышать эффективность за счет уменьшения количества прослоек между топ-менеджментом и рядовыми сотрудниками. Самые заметные примеры:

👉Uber планирует в два раза сократить количество маленьких команд, и в итоге на 20% срезать общее количество менеджеров.
👉Google еще в прошлом году срезали такие команды и их менеджеров на треть.
👉В Intel уменьшили количество слоев менеджмента с 12 до 6.
👉В Coinbase посокращали кучу людей с целью свести количество этих слоев до 5.

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

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

Как использовать агентов в легаси кодовых базах

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

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

Про силовые тренировки

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

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

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

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

А помимо выпусков Подлодки, можете почитать его канал!