AI-агенты — это ответ! А какой был ваш вопрос?

Все бегут в разработку через AI.
Во-первых, это прикольно.
Во-вторых, это ускоряет!
Да? А как вы это поняли? Больше строк кода в минуту?

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

Ускорил ли клод разработку? Да, я быстро написал код. Предыдущие 6 лет руки не доходили.
Но в итоге всё равно изменение доехало до прода через 1.5 месяца. А потом еще потратили время на починку баги.

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

При прочтении нейрослопа меня самого аж выворачивает: автор потратил собственного времени меньше, чем я потрачу на чтение. И нахрен оно мне?

Попробуйте измерить cycle time по задачам. Удивитесь, но вполне вероятно, что ускорения не увидите, потому что задачи застревают на более поздних этапах.

А дальше вопрос: как ускорять ревью. И надо ли?
Или может быть надо отменить ревью человеками и доверить ревью агентам?
И обмазать это всё quality gate’ами.

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

Но в чем отличие от вашего текущего легаси?
В любом случае такого кода у вас 95%. А если это не так сейчас, то станет так через несколько лет: новые фичи пишутся, старый код выветривается из головы, разработчики меняются.
Остается только дока.
Так что с появлением LLM-сгенерированного кода ситуация не ухудшится.

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

В этом посте вопросов больше чем ответов, потому что у меня самого их нет. Давайте порассуждаем.

На сколько у вас увеличилась скорость разработки?
Делаете кодревью сгенерированного кода?
Если нет, то какие доп меры обеспечения качества внедрили?

Avito.Tech.Conf — 26 сентября, Москва, бесплатно

Бесплатных конференций вам в ленту! Спикеры — мои коллеги, так что рекомендую с чистой совестью.

Avito.Tech.Conf — для тех, кто управляет продуктами, процессами и командами. Один день, главная сцена плюс зал воркшопов, 12 спикеров, панель с СТО Яндекс Карт, Х5, Т-Банка и Циана. После 18:30 афтепати.

Программа на лендосе. Что бы я пошёл слушать:

1️⃣ — Александр Лукьянченко, СТО Tech Platform Авито. Как меняется разработка и сетап команд с внедрением агентов
Keynote про то, как измерять эффект от AI и где он создаёт новые узкие места. У меня по этой теме вопросов больше, чем ответов, так что очень интересно будет поразмышлять вместе.

2️⃣ — Артём Арюткин, Developer Experience Авито. Как реально меняется PDLC, или почему вы ускоряете не то, что нужно
См мой прошлый пост: Код пишется за вечер, до прода едет месяц.

3️⃣ — Михаил Павлов, кластер Infrastructure. Повышать планку, не превращаясь в «эффективного менеджера»
Про личные триггеры: бесконечные итерации в гуглодоках и попытки спрятаться за инструментами, когда надо принять решение. Узнал себя еще по описанию.

4️⃣ — Александр Афенов, кластер Доставка. Нам и так было норм: антипаттерны реоргов
Саша — мой коллега, я уже зазывал вас на его доклад про Жоку и Боку. А я за прошлый год провел три реорга, так что тема в сердечке.

Из воркшопов — Tech Strategy Canvas от Игоря Гранщикова. Свою стратегию кластера я писал 4 месяца, и в процессе мне очень помог фреймворк Игоря. Хочу посмотреть, как это собирают за полтора часа.

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

26 сентября, AG Loft (Варшавское шоссе, 33), Москва. Сбор с 11:00, доклады с 12:00.

Участие бесплатное.
Оффлайн — по заявке, мест немного.
Онлайн — регистрация, пришлют трансляцию и записи.

Зарегистрироваться

Почему AI-агенты не заменят кожаных

Disclaimer: постов будет 2, второй — «Почему заменят» 🙃

———

Давайте отмотаем.

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

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

Потом появился Notepad++ с подсветкой синтаксиса.
Потом появились IDE. Половина продолжала писать в блокноте, потому что тормозит.
Потом появился автокомплит.
Потом IntelliSense, который дописывает строку целиком.
Потом Copilot.

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

Но это тула. И у тулы пока нет важнейших свойств, из-за чего она никого не заменит.

1️⃣ — У тулы нет страха смерти

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

2️⃣ — У тулы нет ответственности

— Да, я дропнул продакшен базу. Надо было сначала сделать бэкап.
(и нихрена ты мне за это не сделаешь, кожаный ублюдок)

Кого будят ночью? Кто пишет постмортем? Кого зовут к СТО объясняться?
Кожаного оператора ллм. Того, кто кнопки жмёт.

Пока ответственность на человеке, человек будет в цепочке.

———

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

Заменят ли агенты разработчиков? Нет.
Заменят ли тех, кто умеет только писать код по принесённому ТЗ? Вот тут я бы призадумался. Впрочем, спрос на таких сокращался и до распространения агентов.

Знаете, кого точно заменят? Того, кто снимает с себя ответственность словами типа "это не я, это клод написал". Впрочем, это уже часть следующего поста..

Автономность команды. Больше = лучше?

Обычно автономность преподносится как безусловное добро:
«Чем больше автономии, тем более зрелая команда».
«Чем меньше вмешательства сверху, тем здоровее процессы».

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

На этой неделе на ProductSense услышал у Евгения Васильева (директор по продукту ВКонтакте, VK Видео и VK Музыки) мысль, которая эту картину меняет. Пересказываю своими словами и со своими выводами.

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

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

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

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

Отсюда два вывода, которые мне не нравятся, но приходится признавать.

1️⃣ — В период глобальных пертурбаций C-level в регулярной работе команды — норма

Год назад я бы назвал это микроменеджментом. Сейчас вижу иначе. Директор на еженедельном синке команды стоит дешевле, чем месяц работы команды в мусорку.
Ессно, у CPO тридцать команд и на все синки он не придёт. Ходит только к тем, кого перестройка задевает, и только пока она идёт.

2️⃣ — Зрелость менеджера видна по работе с масштабом задачи

Увидел, что задача больше его уровня -> собрал варианты с последствиями -> вовремя согласовал на достаточном уровне.
Потом отвечает за реализацию того, что выбрали.

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

———

Что это меняет в моих 5 уровнях.
Уровень 3, «консультироваться, потом действовать», я считал промежуточной ступенькой.
Похоже, во время шторма он самый взрослый из пяти.
А пятый в этот момент опасен: команда быстро и уверенно едет по старой карте.

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

Крутит руководитель, и ему же проговаривать команде, что это временно, иначе прочитают как недоверие.

Кого и почему заменят AI-агенты

Пост наполнен ненавистью, я вас предупредил.

Это вторая часть, первая тут.
В прошлый раз я писал, что AI-агент — это тула, и тула сама по себе никого не заменит.
Это как если бы сисадмины боялись, что ci/cd пайплайны их заменят.

На текущем этапе я бы не стал готовиться к тому, что у нас будут AI-сокомандники, и им нужно будет писать "доброе утро" в командных чатах.

Но! Тула делает ценнее того, кто умеет ей пользоваться, поэтому заменят на самом деле не AI-агенты, а люди, которые умеют ими пользоваться.

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

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

Это экономит когнитивный ресурс, а человек — существо ленивое.
Поэтому очень легко стать "мясным прокси" без добавленной ценности.

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

За прошедший месяц у меня было три бесячих ситуации от трёх разных людей.

———

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

———

Ситуация 2. Скидывают документ на 11 страниц, "почитать". То что слог слоповатый и постоянно противопоставления "это не тёплое, это мягкое" — подбешивает, но ладно, уже привык.
К сутевой части возникли вопросы. Внутри в том числе организационный сетап новой команды и перечислено, кого надо нанять.
Читаю: собрались нанимать сисадмина в команду. Это очень странно, потому что инициатива продуктовая и должна по идее спокойно лечь поверх текущей техплатформы. А если и нанимать сисадмина, то опять же в техплатформу. В продуктовой команде ему просто нечего будет делать.

Задаю вопрос. Оказывается, эту часть читать не надо было. Документ читать надо вместе с автором на встрече, чтобы он показывал пальцем: «тут читай, тут не читай, тут ллм нафантазировал».

Бл#%ть! Почему я должен тратить время на чтение документов, на написание которых автор не потратил времени?! Это тупо неуважение к читателю.

———

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

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

———

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

Заменят ли агенты кожаных? Вот таких — да.

Хорошая напоминалочка каждому: почаще задаваться вопросом "а какая моя добавочная ценность?"

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

Аналитический паралич

Людям хочется верить, что они контролируют будущее и исходы своих решений. Отсюда желание всё измерить. Отсюда же data-driven культура в корпорациях.

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

Аналитический паралич — это когда менеджеру не хватает яиц, чтобы принять решение, и он зависает в попытках получить хоть какой-нибудь значимый результат A/B-теста или исследования. Это, в целом, довольно частая побочка data-driven культуры.

Когда услышал первый раз, термин показался мне модным, из серии «скорость принятия решений в условиях неопределённости».

В оригинале — analysis paralisys, красиво, рифмованно, убедительно. Рифма как довод — вообще гениальный приём.

Словосочетание встречается в тексте впервые в 1928г, почти 100 лет назад, в речи какого-то там епископа.
В 1950х-60х было несколько статей и докладов про менеджмент, где так или иначе звучало: "не сдохните, принимая решения интуитивно, и не впадайте в паралич от анализа." В The Times самые ранние употребления «analysis paralysis», относятся к 1970-м.

То есть модному термину больше 50 лет!

Обожаю такое 🙂

На этот пост меня навели мысли из последнего эпизода Make Sense с Вадимом Дороховым из VK Видео. Если решение упёрлось в «давайте ещё померим», а мерить нечего — надо сказать вслух: данных под эту развилку не будет, принимать решение нужно самостоятельно. И дальше в ход идёт сценарное планирование. Будущее не контролирует никто, но каждый его вариант можно заранее написать план. Именно это и отличает решение без данных от решения наугад.

SaaS мертв!
...да здравствует SaaS

Disclaimer: пост рекламный — мои мысли по мотивам одного из докладов предстоящей бесплатной конференции GuardConf от уважаемых господ из кибербеза.

———

Раньше решение о покупке вендорского софта принималось достаточно просто: если это дешевле и быстрее купить, чем написать - покупаем. А теперь все принялись делать свои inhouse - *aaS, потому что навайбкодить стало дешевле и быстрее.

В феврале, после выхода Claude Cowork, рынок акций SaaS компаний просел на триллион (!) баксов за неделю. Потому что инвесторы решили, что раз агенты могут написать софт за вечер, то никто больше не будет продлевать подписки. Тогда это назвали SaaSpocalypse, но отросло обратно примерно за полгода.
Т.е. все-таки подписки продолжили продлевать и немедленного банкротства не случилось.

В августе McKinsey опубликовали отчет "State of AI". Среди прочего - любопытный тренд: треть компаний хотя бы раз отказалась от покупки софта, потому что агенты могут собрать его внутри.
Очень часто "свою бесплатную альтернативу" делают энтузиасты в свободное от основной работы время. Но что люди склонны недооценивать - это стоимость поддержки. Не бывает продуктов типа "один раз написал, навсегда теперь работает". Из банального - надо патчить уязвимости, обновлять библиотеки, чинить баги. А еще постоянно появляются фича-реквесты. И вот уже есть объем работы на целую команду.

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

Мой вывод пока такой: SaaS умирает там, где вендор продавал тонкую обёртку над API. Там, где есть существенная нагрузка на поддержку — еще будет жить.

–––

Рассуждение выше навеяно докладом Антона Башарина на Guardconf. Его и ещё три из программы я бы послушал:

1️⃣ — Написать стало дешево, владеть — нет. Build vs buy, когда код пишет ИИ. Антон Башарин, AppSec Solutions.
Ровно то, о чём выше. Спикер руководит разработкой из пяти команд и разбирает, почему классическая оценка build vs buy теперь систематически ошибается: своё решение, допиленный опенсорс или коробка. Отдельно про теневой build: приложения, которые навайбкодили без решения build vs buy и без владельца.

2️⃣ — Исключение и принятие рисков ИБ без владельца и коммитментов — это бэкдор. Илья Шмаков, СберСпасибо.
Кейс перехода от разового аудита кода к проверкам на каждый PR. Что делать, когда проверка нашла риск, а релиз откладывать нельзя: единый реестр исключений, у каждого владелец, срок и причина. И ИИ-код там ревьюится так же, как человеческий.

3️⃣ — Модель монетизации как отражение продуктовой реальности. Екатерина Цыкина, Контур.
Почему одна модель монетизации работает для одного продукта и не подходит другому. На реальных примерах: как понять, что в монетизации пора что-то менять, сколько стоит ошибка и как протестировать изменение.

4️⃣ — Кейноут. Что ждёт вендоров российского ПО в 2027 году. Михаил Чухломин, Guardant, и Пётр Городецкий, «Квадрант Технологий».
Впервые покажут «Оценку российского рынка ПО участниками отрасли с прогнозом на 2027 год»: как рынок видят сами вендоры, от маленьких до больших. Для контекста, по оценке «Квадрант Технологий» российский ИТ-рынок в 2025-м просел на 3%. Золотая эра импортозамещения подошла к концу, интересно послушать версию "что будет дальше".

📍12 ноября, Лофт #2 (Ленинская слобода, 26), Москва.
Открытие в 11:00, доклады до 18:15, потом нетворкинг.

Бесплатно, заявки модерируют, регистрация до 11 ноября.
Онлайн тоже есть.

Зарегистрироваться

Теория Ограничений Систем
"команда идёт со скоростью самого медленного"

Disclaimer: пост — ТОС на пальцах + анонс бесплатного митапа от VK, где будет мастер-класс по ТОС.

В 1984 году физик Элияху Голдратт написал производственный роман «Цель». Директор завода ведёт в поход отряд скаутов. Отряд растягивается по тропе: жирный Херби с тяжёлым рюкзаком идёт в середине, передние убегают вперёд, задние упираются в Херби. Привалы уходят на то, чтобы собрать всех обратно. Директор ставит Херби первым и раздаёт его рюкзак остальным. Тогда отряд идёт со скоростью Херби, зато весь вместе и быстрее, чем раньше.

Так Голдратт объясняет теорию ограничений: пропускная способность системы равна пропускной способности узкого места.

Переложим на команду. Шесть инженеров кодят, а ревью делают между делом. С агентами кодить стали вдвое быстрее. А cycle time задачи не изменился. Задачи стоят в очереди на ревью, и чем быстрее кодим, тем длиннее очередь.

Голдратт предлагает пять шагов:

1️⃣ Найти ограничение. Этап, перед которым задачи ждут дольше всего. В джире это колонка, в которой копятся карточки. В нашем случае это ревью.

2️⃣ Помочь ограничению. В «Цели» перед станком поставили контроль качества, чтобы станок не точил уже бракованные детали. В случае ревью это:
• маленькие PR
• линтеры и зелёный CI до того, как PR попал человеку
• описание к PR, чтобы ревьюер не восстанавливал задачу по диффу.

3️⃣ Подчинить остальное ограничению. Ревью с утра, до своего кода. Разработчик, у которого три PR висят на ревью, не начинает четвёртую задачу, он идёт ревьюить чужую. Да, писать код приятнее. Нет, команде это сейчас не нужно.

4️⃣ Расширить ограничение. Нанять, отдать первый проход агенту, автоматизировать.

5️⃣ Ограничение переехало. Вернуться к 1.

Большая часть улучшений, которые делает команда, не меняет итоговую скорость системы. Каждый ускоряет свой этап, потому что это умеет.

Голдратт просит ускорять этап, который тормозит, даже если он чужой. У него же есть фраза для тимлидов, которые считают закрытые задачи на человека: «Скажи мне, как ты меня измеряешь, и я скажу, как буду себя вести».

———

У теории ограничений есть вторая часть: мыслительные инструменты.

Главный инструмент — дерево текущей реальности. Внизу симптомы, которые бесят: задачи висят на ревью, релиз раз в две недели, на ретро один и тот же пункт третий спринт. Вверх от них стрелки «потому что», и каждую стрелку проверяют по правилам.
1. Причина существует?
2. Её одной достаточно?
3. Если причина верна, какие ещё следствия мы должны наблюдать, и наблюдаем ли?

Проверка на себе. «Ревью медленное, потому что ревьюеры ленятся». Если это правда, маленькие PR должны висеть так же долго, как большие. Смотрю в джиру: PR на 100 строк уходят за день, на 1500 висят неделю. Причина в размере PR.

Второй инструмент, «туча», для конфликтов. Разработчик хочет писать свой код и хочет, чтобы команда катила быстро. Два желания тянут в разные стороны, и команда ищет компромисс: день кодим, час ревьюим. Голдратт просит компромисс не искать. Под каждой стрелкой конфликта лежит предположение, и его надо достать и проверить. Здесь оно звучит так: «моя задача закрыта, когда я написал код». Очевидно, это не так: задача закрыта, когда всё в проде и обмазано мониторингом. А что надо чтоб оно доехало в прод? Правильно, ревью!

На VK JT TeamLead 28 октября в Питере будет Мастер-класс по теории ограничений с Александрой Брызгаловой, сертифицированным тренером по ТОС Голдратта.

Еще будут:
— Дискуссия «Лидер и стратегия: насколько глубоко тимлид должен погружаться в бизнес»
— Менторская гостиная, встреча 1–1 с тимлидом VK
— «Своя игра» по управленческим кейсам

Санкт-Петербург, 28 октября, 17:30, офис VK у Красного моста.

Офлайн, бесплатно, нужна регистрация.

Зарегистрироваться