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

Из статьи вы узнаете:

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

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

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

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

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

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

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

Если ИИ пишет код за считанные минуты, почему на задачу по‑прежнему уходит целый квартал?

Попытки найти ответ изменили моё представление о собственной работе.

Дело никогда не было в том, что на написание кода уходил целый квартал.

Искусственный интеллект сделал этот процесс дешёвым, но вместе с тем убрал три вещи, которые раньше сами по себе помогали мне руководить командой:

• Высокую стоимость разработки, которая заставляла нас выбирать.

• Лестницу профессионального роста, которая давала людям статус и ощущение собственной профессиональной идентичности.

• Привычку обращаться друг к другу за помощью, благодаря которой команда оставалась сплочённой.

Ничего из этого не видно на графике скорости разработки. Но теперь за всё это отвечаю я.

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

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

Код больше не узкое место

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

Фредерик Брукс объяснил это ещё сорок лет назад. В работе No Silver Bullet («Серебряной пули нет») он разделил сложности разработки ПО на случайные, связанные с превращением проекта в код, и сущностные, связанные с определением того, какой должна быть система ^[1].

Самая сложная часть создания программной системы — точно определить, что именно нужно разработать.

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

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

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

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

Сложнее стало отвечать и на вопрос «что именно?». Когда разработка обходилась дорого, стоимость сама по себе служила фильтром. Мы не могли реализовать всё подряд, поэтому приходилось выбирать.

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

Исследование DORA за 2025 год показало, что у команд, внедряющих искусственный интеллект без чёткой ориентации на пользователей, производительность может даже снизиться ^[2]. Исследователи называют это фабрикой фич (feature factory): «много активности, мало пользы».

Прототипы скрывают самое сложное

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

Показываем прототип партнёру и быстро выясняем, одинаково ли мы представляем себе будущий продукт. Но Брукс предупреждал, что при создании прототипа «даже не пытаются предусмотреть исключительные ситуации» ^[1]. Макет выглядит как готовый продукт, поэтому окружающим кажется, что работа почти закончена.

Хотя за красивым интерфейсом скрываются все нефункциональные требования:

• масштабируемость;

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

• достаточно гибкая архитектура для подключения следующего партнёра;

• резервные копии, из которых можно восстановить систему за считаные минуты.

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

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

Искусственный интеллект переместил узкое место с тех, кто разрабатывает, на тех, кто принимает решения.

Лестница профессионального роста становится всё более плоской

До появления ИИ в моих командах существовала негласная иерархия. Она никак не была связана с организационной структурой. Её определяли опыт и личные склонности специалистов. Один инженер обожал оптимизировать запросы, сокращая время выполнения с нескольких минут до миллисекунд.

Другой сумел уменьшить задержку на 100 мс, перестроив работу горутин.

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

Такие способности замечали и ценили. Благодаря им люди ощущали собственную значимость и чувствовали себя уверенно в команде.

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

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

Каждая преодолённая ступень добавляла знаний, уверенности и укрепляла профессиональную идентичность: «Я тот, кто способен с этим справиться».

Искусственный интеллект сокращает расстояние между ступенями этой лестницы. Я своими глазами видел, как в моей команде сокращается разрыв между результатами джуниоров и сеньоров.

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

В полевых экспериментах с участием почти 5000 разработчиков из Microsoft, Accenture и одной из компаний рейтинга Fortune 100 менее опытные специалисты активнее использовали ИИ и получали от него больше пользы ^[3].

В клиентской поддержке наибольший прирост показали новички, тогда как у самых опытных сотрудников наблюдалось лишь «небольшое увеличение скорости при незначительном снижении качества» ^[4].

Для джуниоров это хорошие новости. Но что всё это означает для сеньоров, исследования производительности не объясняли. Зато ответ нашёлся в социальной психологии.

В 1959 году Джон Френч и Бертрам Рэйвен описали понятие власти, основанной на экспертности (expert power), — влияния, которым человек обладает благодаря своим знаниям ^[5]. Отчасти авторитет сеньоров держался на знаниях, которые теперь можно получить одним запросом к ИИ.

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

Для людей, на которых раньше равнялись коллеги, это вопрос профессиональной идентичности, а не производительности. Исследователи называют такое явление угрозой профессиональной идентичности из‑за ИИ и считают потерю статуса одним из ключевых факторов её возникновения ^[6].

Исследование с участием 381 сотрудника показало, что внедрение искусственного интеллекта снижало психологическую безопасность, а это, в свою очередь, усиливало депрессивные симптомы ^[7].

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

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

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

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

Когда уверенность побеждает опыт

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

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

Вот только уверенность растёт быстрее реальных навыков. В одном исследовании ИИ повысил результаты заданий на логическое мышление примерно на 3 балла, но при этом участники переоценивали свои результаты примерно на 4 балла.

Причём хуже всех оценивали собственные способности те, кто лучше всего разбирался в ИИ ^[8].

Уверенность ещё и помогает убеждать. Самоуверенные люди получают более высокий статус, потому что окружающие принимают уверенность за компетентность ^[9].

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

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

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

Команда, в которой каждый чувствует себя сеньором, — совсем не то же самое, что команда, где каждый действительно сеньор.

Больше никому не нужно просить о помощи

На первый взгляд просьба о помощи к коллеге — это небольшие издержки: ты отвлекаешь человека от работы и признаёшься, что чего-то не знаешь.

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

Она удовлетворяется через регулярное, позитивное общение с людьми, которым мы небезразличны ^[10].

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

Причём не только в переносном смысле: исследование с использованием нейровизуализации показало, что пожертвование на благотворительную цель активирует ту же систему вознаграждения в мозге, что и получение денег ^[11].

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

• Один отлично разбирался в SQL.

• Другой мог написать однострочник на Python для любой задачи.

• Третий за десять минут чинил сломанный пайплайн развёртывания.

Приходилось подходить к ним или писать в Slack и просить о помощи.

Теперь запрос, однострочник и исправление Terraform можно получить от ИИ-ассистента. Это быстрее. Но и одиночества становится больше.

Причём не только в моей команде. Исследование примерно 187 тысяч разработчиков на GitHub показало, что Copilot смещает работу от сотрудничества к самостоятельному выполнению задач ^[12]. А сотрудники из четырёх стран, которые чаще работали с искусственным интеллектом, сообщали о более сильном чувстве одиночества ^[13].

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

Бенджамин Франклин, как известно, сумел расположить к себе враждебно настроенного коллегу-законодателя, попросив одолжить редкую книгу. А эксперимент 1969 года подтвердил этот эффект: люди начинают относиться к нам лучше после того, как оказывают нам услугу ^[14].

Просьба помочь с SQL‑запросом никогда не была для знатока SQL только лишней нагрузкой. Она помогала укреплять отношения.

Профессиональные сообщества теряют связи

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

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

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

К маю 2025 года количество новых вопросов на Stack Overflow за месяц упало примерно до уровня 2009 года, первого полного года существования площадки ^[15].

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

Коллективная креативность

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

Психолог Дэниел Вегнер назвал это транзактивной памятью (transactive memory): знания команды хранятся не столько в головах отдельных сотрудников, сколько в общем представлении о том, кто что знает^[16].

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

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

Эндрю Харгадон и Бет Бечки выяснили, что коллективная креативность в компаниях, оказывающих профессиональные услуги, возникает благодаря четырём видам взаимодействия. И первые два — просьбы о помощи и её оказание ^[17].

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

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

При этом ни на одном этапе ничего явно не шло не так. В эксперименте с написанием текстов истории, созданные на основе идей ИИ, по отдельности оценивали как более креативные, но при этом они сильнее походили друг на друга ^[18].

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

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

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

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

Готовность признавать ошибки

Как руководителя меня больше всего беспокоит потеря готовности открыто говорить об ошибках.

ИИ-ассистент никогда тебя не осудит, и в этом одна из причин его привлекательности: ведь попросить помощи у коллеги — значит признать, что ты чего-то не знаешь.

Когда Эми Эдмондсон в 1990-х годах изучала работу больничных отделений, выяснилось, что в отделениях с более эффективным руководством регистрировали больше ошибок при назначении и применении лекарств, а не меньше. Просто сотрудники чувствовали себя достаточно безопасно, чтобы сообщать о них^[19].

Именно такую команду я хочу видеть: чтобы люди не боялись вовремя сказать «Я не знаю» или «Я ошибся».

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

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

Что я пробую как руководитель

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

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

1. Измерять ценность, а не скорость разработки

Скорость показывает, насколько мы заняты, но не говорит о том, принесла ли наша работа пользу.

Поэтому я стараюсь показывать стейкхолдерам:

• что изменилось для пользователей;

• сколько времени задача ждала решения по сравнению с тем, сколько заняла сама разработка.

Когда на разработку уходят дни, а на принятие решений — недели, вопрос «Почему искусственный интеллект не ускоряет нашу работу?» превращается в вопрос о том, как мы принимаем решения.

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

2. Поощрять тех, кто ставит предлагаемые решения под сомнение

Сегодня профессиональная зрелость проявляется в том, кто способен сказать:

• «Это не будет масштабироваться».

• «Партнёр вообще об этом не просил».

• «Мы разрабатываем не то, что нужно».

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

3. Следить за тем, кто берёт на себя ответственность за ошибки

Когда что-то ломается, кто готов сказать: «Это моя ошибка»?

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

4. Делиться способами работы с ИИ, а не промптами

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

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

Главный вывод

В начале года я спрашивал себя, что не так с моей командой. Но это был неправильный вопрос.

Гораздо важнее оказалось понять, чего ИИ незаметно её лишил:

• высокой стоимости разработки, которая заставляла нас выбирать;

• лестницы профессионального роста, которая давала людям авторитет и положение в команде;

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

Раньше всё это само по себе помогало руководителю делать свою работу. Теперь такие условия приходится создавать осознанно.

Если в этом году ваш график скорости разработки пошёл вверх, спросите себя, какой ценой.

К кому перестали обращаться за помощью? Кто сам перестал задавать вопросы? И кто по-прежнему готов вслух признать собственную ошибку?

Примечание

1. Brooks, F. P. (апрель 1987). Серебряной пули нет: сущностные и случайные сложности программной инженерии. IEEE Computer, 20(4).

2. DORA / Google Cloud (сентябрь 2025). Состояние разработки программного обеспечения с использованием ИИ. Google.

3. Cui, Z. K. и др. (2025). Влияние генеративного ИИ на высококвалифицированный труд: результаты трёх полевых экспериментов с разработчиками ПО. Management Science.

4. Brynjolfsson, E., Li, D., Raymond, L. (2025). Генеративный ИИ на рабочем месте. Quarterly Journal of Economics, 140(2).

5. French, J. R. P., Raven, B. (1959). Основы социальной власти. В сборнике под редакцией D. Cartwright «Исследования социальной власти», с. 150–167. Мичиганский университет.

6. Mirbabaie, M. и др. (март 2022). Распространение искусственного интеллекта: понимание угрозы профессиональной идентичности на рабочем месте. Electronic Markets, 32(1).

7. Kim, B.‑J., Kim, M.‑J., Lee, J. (2025). Тёмная сторона внедрения искусственного интеллекта: связь использования ИИ с депрессией сотрудников через психологическую безопасность и этичное лидерство. Humanities and Social Sciences Communications, 12.

8. Fernandes, D. и др. (2026). ИИ делает вас умнее, но не мудрее: разрыв между результативностью и метакогницией. Computers in Human Behavior, 175. arXiv:2409.16708.

9. Anderson, C. и др. (2012). Чрезмерная уверенность в себе как способ повышения социального статуса. Journal of Personality and Social Psychology, 103(4).

10. Baumeister, R. F., Leary, M. R. (1995). Потребность в принадлежности: стремление к межличностным связям как фундаментальная мотивация человека. Psychological Bulletin, 117(3).

11. Moll, J. и др. (октябрь 2006). Роль лобно‑мезолимбических нейронных сетей в принятии решений о благотворительных пожертвованиях. PNAS, 103(42).

12. Hoffmann, M. и др. (2024). Генеративный ИИ и изменение характера труда. Рабочий документ Гарвардской школы бизнеса № 25–021.

13. Tang, P. M. и др. (2023). Человек не существует в изоляции: влияние взаимодействия с искусственным интеллектом на работу и жизнь за её пределами. Journal of Applied Psychology, 108(11).

14. Jecker, J., Landy, D. (1969). Как оказание услуги другому человеку влияет на симпатию к нему. Human Relations, 22(4).

15. Orosz, G. (май 2025). Stack Overflow практически мёртв. The Pragmatic Engineer.

16. Wegner, D. M. (1987). Транзактивная память: современный анализ группового разума. В сборнике под редакцией B. Mullen и G. Goethals «Теории группового поведения». Springer.

17. Hargadon, A., Bechky, B. (2006). Когда творческие личности становятся творческим коллективом: полевое исследование решения рабочих задач. Organization Science, 17(4).

18. Doshi, A. R., Hauser, O. P. (июль 2024). Генеративный ИИ повышает индивидуальную креативность, но снижает коллективное разнообразие оригинального контента. Science Advances, 10(28).

19. Edmondson, A. C. (1996). Учиться на ошибках проще на словах, чем на деле: влияние групповых и организационных факторов на выявление и исправление человеческих ошибок. Journal of Applied Behavioral Science, 32(1).

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

Разобраться в этом помогут бесплатные уроки:

• 9 ноября, 20:00. «Качество без микроменеджмента: что должен контролировать CTO». Записаться

• 18 ноября, 20:00. «Компетенции и личные навыки CTO». Записаться

Больше возможностей для профессионального развития — в дайджесте вебинаров на ноябрь.

Важное напоминание