В прошлой статье я говорил, что конвейерная модель производства софта несовместима с AI, и что вместо конвейера нужен дирижёр — сильный инженер с продуктовым мышлением, управляющий оркестром агентов.

Ту статью многие прочитали как «вот и хорошо, нанимаем нескольких сеньоров, увольняем середину, экономим на FTE». Это понятно с точки зрения CFO — но это полупонимание.

Дирижёр без мотивации — это не дирижёр. Это дорогой пассивный наблюдатель. AI рядом с ним даст ровно ноль ускорения.

Сегодня — про вторую половину. Кто реально получает 10× от AI и почему это вопрос лояльности, а не технологии.

10× — это не миф. Но он есть не у всех

Когда люди говорят «AI ускоряет разработку в 10 раз», они обычно имеют в виду статистику от вендоров. Эта статистика собрана на синтетических тасках или в lab-условиях. Если переложить её на реальный продукт в регулируемой среде — она не работает.

Реальные 10× случаются. Я наблюдал их лично. Но не «у всех с Copilot». А у конкретных людей.

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

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

10× — это не миф. Это конкретное число, которое появляется у конкретных людей в конкретных условиях.

Условие первое — компетенция. Условие второе — желание

С компетенцией всё понятно: нужен сильный инженер с продуктовым мышлением. Эту часть мы разобрали в прошлой статье.

А вот «желание» — гораздо интереснее, и почти никто из руководителей его не считает.

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

• его мнение игнорируют;

• роадмап составляет PM, который не знает архитектуры;

• ему за всю работу спасибо сказали один раз — и то когда он бесплатно вышел в выходной;

• бонус привязан к скорости, а не к продукту;

• HR раз в полгода присылает форму engagement-survey, и больше культура не существует.

Сколько 10× он выдаст?

Ноль. Он выдаст 1.0 — норматив. Сделает то, что попросили, и пойдёт домой.

И это не его вина. Это рациональное поведение. У AI нет skin in the game — у инженера тоже нет. Зачем ему гнать на максимум?

Старая модель производства софта прощала низкую лояльность. У тебя был конвейер из 30 человек. Если один не вкладывался — компенсировали остальные. Скорость падала на 3%, но продукт ехал.

Новая модель — нет. У тебя теперь 1 дирижёр на участок. Если он не вкладывается — провален весь участок. И никто его не подстрахует, потому что подстраховывать некому: AI не подстраховывает, а соседний дирижёр занят своим оркестром.

Лояльность стала единственным мультипликатором. Не процессы. Не инструменты. Не методологии. Не курсы Cursor для джунов. Лояльность конкретного человека к конкретной задаче.

Лояльность сквозь зубы — это не лояльность

Тут важно разделить две вещи.

Первое — показная лояльность. Когда человек ходит на standup, кивает на decision'ы руководства, говорит «понял, сделаю», ставит лайки в корпоративном Slack, и при этом считает дни до увольнения. У него нет внутреннего конфликта — он просто играет роль до момента, пока не появится оффер получше.

Этой лояльности AI-эра дала вторую жизнь. С Cursor / Claude Code человек может имитировать продуктивность ещё качественнее. PR летят, тикеты закрываются. Метрики зелёные. Только продукт от этого не лучше — потому что человек не вкладывается, он закрывает таски минимальным усилием через агента.

Второе — реальная лояльность. Это когда инженер в час ночи лезет в логи прода, потому что ему стрёмно, что фича может сломаться у пользователей. Не потому что ему за это заплатят. Не потому что его уволят если он не полезет. А потому что это его продукт. Он хочет, чтобы он работал.

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

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

Что её рождает

Не курсы по AI. Не корпоративный merch. Не Slack-каналы с эмодзи.

Реальная лояльность инженера к продукту собирается из нескольких компонентов. Все они банальные. Все они известны 30 лет. Большинство компаний их системно нарушает.

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

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

Связь с продуктом, а не с тикетом. Если инженер видит реальных пользователей, реальные метрики, реальные деньги — он работает на продукт. Если он видит JIRA-тикеты, story points и velocity — он работает на тикет. AI-эра обостряет этот выбор: AI отлично закрывает тикеты, но плохо строит продукты. Если ты замеряешь velocity — ты получишь velocity, а не продукт.

Признание ответственное, а не дежурное. Не «спасибо за релиз», а «помню, как ты в феврале сделал миграцию баз, на которой сейчас весь bilable объём держится». Точечно. Конкретно. С памятью. Это в десять раз ценнее годовой премии, потому что это сигнал «тебя видят как человека, а не как FTE».

Защита от бюрократии. Лучший инженер ненавидит бессмысленную работу больше, чем неправильную. Если ему нужно собирать справки, оформлять плановые отпуска через 5 одобрений и согласовывать commit-message с тимлидом — он сгорит за полгода. Не на самой работе, а на её обёртке. Дирижёру нужно отбивать это бюрократическое давление руководителем — иначе он уволится и пойдёт туда, где не отбивают, но хотя бы не давят.

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

Что её убивает

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

• Сравнение между инженерами по velocity / closed tickets. Раньше — стимул конкуренции. Теперь — стимул халтуры через AI.

• Назначение задач сверху без обсуждения. Раньше — нормально для исполнителя. Теперь — отказ дирижёру в его роли.

• Микроменеджмент по форме оформления PR / коммитов / документации. Раньше — необходимое для масштаба команды. Теперь — повод уволиться.

• «Срочно надо к пятнице, мы пообещали». Раньше — стандартная мобилизация. Теперь — сигнал «нам не важно, что ты думаешь о реалистичности».

• Замена ушедшего сеньора джуниором с Copilot. Раньше — иногда работало. Теперь — нет, потому что джун с Copilot не дирижёр, и от него нельзя ждать 10×. От него можно ждать 1.5×, и то не всегда.

• Onboarding-курсы по AI как замена культуре. Курс — это инструмент. Культура — это среда. Курс без культуры производит обученных, но немотивированных людей с Cursor.

Что это значит на практике

Если ты руководитель команды, то новая иерархия приоритетов получается такой:

• Удержать сеньоров-дирижёров любой ценой. Не «соразмерной рынку», а «любой». Потому что замена одного дирижёра обходится не в его зарплату × 6 месяцев (классическая формула). Она обходится в скорость продукта. Дирижёр ушёл — участок просел на 50% на полгода. Это не FTE-расчёт, это P&L.

• Перестать оценивать сильных через метрики, придуманные для слабых. Velocity, closed tickets, story points — это инструменты учёта на конвейере. Применять их к дирижёру — оскорбление.

• Открыто разговаривать о смысле работы. Не корпоративная миссия в рамке. А «вот в этом квартале мы делаем X, потому что это даст бизнесу Y, и нам важно сделать качественно, потому что Z». Дирижёр работает на смысл, а не на трекер.

• Дать дирижёру право говорить «нет». Это самое сложное для CTO/CEO. Но если у дирижёра нет права отказаться от глупого требования — он либо его выполнит и потеряет уважение к себе, либо уволится. И в обоих случаях ты потеряешь дирижёра.

• Платить выше рынка. Не потому что иначе он уйдёт за деньги. А потому что зарплата — это гигиенический фактор. Если она ниже рынка — она съедает энергию на фоновую тревогу «меня недооценивают». Если выше рынка — она исчезает из головы инженера и он начинает работать на продукт. Это лучшая инвестиция в продуктивность из возможных.

Закрытие

В индустрии часто говорят: «AI заменит инженеров». Может быть, через десять лет — и заменит. Сегодня — нет.

Сегодня AI усиливает лучших и обнажает посредственных. Хороший инженер с AI выдаёт 10×. Посредственный инженер с AI выдаёт 1.0×, но красиво обёрнутого мусора. Это не количественная разница — это разница в типе результата.

И ключ к получению 10× — не покупка лицензии Cursor для всех. Ключ — это лояльность конкретных людей, без которой AI ничего не делает.

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

Если у тебя есть один лояльный дирижёр — у тебя есть бизнес, который растёт быстрее конкурентов.

Если у тебя есть пять — у тебя нет конкурентов.

В прошлой статье — почему конвейер мёртв и нужен дирижёр: https://www.linkedin.com/pulse/дирижёр-вместо-конвейера-как-ai-ломает-классический-pipeline-denisov-tlcge/

Если вы строите AI-native команду — расскажите в комментариях, как вы удерживаете тех, без кого 10× не работает.

#AITransformation #EngineeringCulture #CTO #EngineeringLeadership #AINative