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

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

👉Результат, полученный без дополнительных инструкций, оказался выше, чем с любой из добавленных техник верификации.
👉Инструкция использовать 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!

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

Как менеджерам перестать быть кожаными роутерами

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

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

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

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

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

Про профилактику выгораний

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

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

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

Про новое чувство потока

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

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

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

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

Но топы не могут ошибаться, поэтому Amazon не отыгрывает свои решения, а запускает перспективный проект под кодовым названием "Boomeranf Reengagement Initiative". А такое уже тянет на повышенную премию в performance review!

Зачем платить за софт, когда все можно завайбкодить

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

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

Несмотря на этот довольно ожидаемый итог, мне очень понравился один вывод из этого эксперимента:

Сложная система обладает эмерджентными свойствами. Это свойства, которые возникают на стыке компонентов, а не внутри них.

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

Я открыл клуб Подлодки про AI в разработке уже полгода назад. Он сильно помог участникам изменить рабочие процессы в их командах и научиться самим работать с агентами. За это время мы:

👉Провели 90 стримов про harness engineering и внедрение AI в команды
👉Собрали большую базу знаний про AI в разработке
👉Устроили аж два хакатона – делали автономные фабрики фичей и самообучающихся агентов
👉Собрали сообщество, в котором получается очень дельно обсуждать новости и помогать друг другу с решением проблем

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

Если вы хотите просто держать руку на пульсе происходящего в индустрии

Я вытаскиваю очень крутых экспертов из Uber, xAI, Meta, Яндекса, Cursor, а еще из кучи стартапов. Они рассказывают, как работают их команды – и вы можете узнать у них то, о чем на конференциях начнут говорить только через год.

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

Если вы хотите вкатиться в лучшие практики AI разработки

Каждую неделю мы проводим 2-3 стрима на разные темы, где есть куча полезной информации – от автоматизации процессов QA или SRE до того, как строить внутренние AI платформы.

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

А еще вам доступен RAG по всему контенту чата и прошедших стримов, так что найти нужный совет очень просто!

Если вы уже активно внедряете AI в свою работу или команды

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

🔗Детали, расписание, заявки в клуб

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

Путь менеджера в 2026

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

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

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

Бесплатный онлайн-тулкит по выживанию в IT для руководителей

Зарплатные гонки и “розовые единороги” в IT закончились. Layoffs говорит, что ожидаемое кол-во увольнений в 2026-м будет ровно в десять раз выше, нежели в 2021-м. LinkedIn переполнен постами о поиске работы, Хабр — очередными разборами рынка, а фраза “реорганизация” звучит, скажем так, по-другому.

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

Потому вместе с экспертами извне мы задумали бесплатный интенсив «ИТ-зима. Набор для выживания». Каждый день разбираем один конкретный инструмент, чтобы не просто не “замерзнуть”, но и вырасти, потому что именно зимой освобождаются роли и решается, кому доверять больше.

Без подписок на каналы и платы за вход

По датам – 12–23 октября, по будням, в формате вечерних онлайн-эфиров с записями и лонгридами.

Регистрация здесь: https://stratoplan-school.com/marathon/tlgr

О чем будем говорить:

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

Ветра зимы уже здесь, давайте готовиться вместе!

Где стафф инженеру брать идеи проектов

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

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

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

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

Состояние нашей индустрии в 2026

Хороший срез основных трендов в разработке на сегодня:

👉Все меняется очень быстро – мы и раньше привыкли к довольно быстрому темпу смены технологий, но ничего даже близкого к текущей скорости еще не было.
👉Никто не пишет код руками (тут подтверждаю, я в последнее время интервьюировал десятки инженеров по всему миру, и руками хорошо если 5% работы делаются).
👉Большинство одновременно работает с несколькими агентами в параллель, и учатся справляться с когнитивным перегрузом из-за этого.
👉Количество PR за авторством агентов точно стало больше, чем человеческих. Это касается и всего GitHub, и ситуации в отдельных компаниях.
👉Скиллы стали стандартным используемым примитивом и внутри компаний, и в сообществе.
👉IDE очень-очень быстро умирают.
👉Довольно значимая часть агентских задач инициируются из Slack.
👉Все вокруг экспериментируют с разными видами автономных фабрик.
👉Большие миграции с одной технологии на другую занимают недели и месяцы, а не годы.
👉Токенмаксинг уходит в прошлое, все начинают следить за тратами на AI и искать пути сэкономить.
👉Проектная работа постепенно превращается в задачи на одного или максимум двух человек, но никак не на большую команду.
👉Инженерные специализации пропадают. Например, уменьшается спрос на iOS/Android/Frontend, но растет спрос на более универсальных инженеров.