Искусственный интеллект быстро меняет разработку программного обеспечения, но тезис о том, что сложный продукт можно вести силами одного тимлида и набора ИИ-инструментов, выглядит слишком упрощенным. По мнению инженера и предпринимателя Сергея Немчинского, бизнес, рассчитывающий заменить полноценную команду одним сильным техническим лидером, рискует потерять не только скорость, но и качество, устойчивость архитектуры и контроль над продуктом.
Почему бизнес поверил в идею «тимлид вместо команды»
Главная причина интереса компаний к такой модели — деньги. В технологическом бизнесе значительная часть расходов приходится не на серверы, облака или лицензии, а на зарплаты инженеров. Поэтому появление генеративного искусственного интеллекта многие руководители восприняли как возможность резко сократить издержки.
Логика на первый взгляд кажется простой: если ИИ может писать функции, тесты, разметку и типовые запросы, то можно оставить одного опытного тимлида, дать ему мощные инструменты автоматизации и отказаться от большей части команды. Однако эта схема путает две разные вещи: написание кода и поставку готового продукта.
ИИ действительно способен быстро генерировать фрагменты кода, но это лишь видимая часть инженерной работы. Основная сложность начинается там, где появляются архитектура, бизнес-контекст, наследуемые системы, безопасность, стабильность и ответственность за результат.
Код — это не весь продукт
Генерация класса, стандартной формы, простого запроса к базе данных или небольшого фрагмента на языке программирования действительно стала значительно быстрее. Но реальный продукт состоит не только из таких задач.
За пределами рекламных демонстраций остаются вопросы, которые невозможно закрыть простым запросом к нейросети:
- как новый микросервис будет взаимодействовать со старой системой без документации;
- что произойдет с базой данных при резком росте нагрузки;
- кто отвечает за безопасность пользовательских данных;
- как соблюдаются требования регуляторов и банковских клиентов;
- кто будет разбираться с аварией в продакшене ночью;
- как сохранить совместимость интерфейсов между сервисами;
- кто контролирует архитектурные ограничения и технический долг.
Именно эта невидимая часть работы определяет, будет ли система надежной, масштабируемой и понятной для команды через несколько месяцев или лет.
Почему один тимлид с ИИ не ускоряет разработку
Один из распространенных аргументов сторонников сокращений звучит так: компания якобы получит серьезную экономию, пусть и без большого прироста скорости. Немчинский считает такую оценку ошибочной: в реальности бизнес может проиграть и в стоимости, и в темпе разработки.
Время тимлида или архитектора стоит дорого. Если оставить его без команды, значительная часть этого времени будет уходить не на стратегию, архитектуру и развитие продукта, а на постоянное уточнение задач для ИИ, проверку сгенерированного кода, поиск скрытых ошибок и восстановление контекста.
Главная проблема не в синтаксисе. Современные ИИ-инструменты уже умеют исправлять простые ошибки, дополнять импорты и подсказывать стандартные решения. Проблема в другом: у искусственного интеллекта нет полноценного бизнес-контекста.
Модель не понимает сама по себе, создается ли быстрый прототип для проверки гипотезы или долгосрочная корпоративная система. Она не знает внутренних договоренностей, истории продукта, компромиссов в архитектуре и границ доменов. Попытка полностью загрузить этот контекст в нейросеть может привести к перегрузке, потере качества рассуждений и ошибочным выводам.
Узкое место — внимание тимлида
В реальной компании тимлид не пишет код весь рабочий день. Значительная часть его времени уходит на созвоны, планирование, обсуждения с заказчиками, синхронизацию с другими командами, технические интервью, ревью, управление конфликтами и индивидуальные встречи.
Пока тимлид находится на встречах, ИИ-агенты без контроля могут пойти в неверном направлении, сгенерировать большой объем кода, который затем придется долго чистить, или просто остановиться в ожидании подтверждения. Поэтому узким местом становится не скорость генерации текста, а пропускная способность внимания человека.
Живая команда в это время может параллельно писать тесты, закрывать задачи, продвигать релиз и поддерживать качество кода. Один человек, даже очень сильный, остается ограниченным человеческим вниманием и временем.
Риск «фактора автобуса»: когда все держится на одном человеке
Еще одна опасность модели «один тимлид и ИИ» — катастрофический фактор автобуса, равный единице. В здоровой команде знания о системе, архитектуре и бизнес-решениях распределены между несколькими разработчиками. Если один специалист заболел, ушел в отпуск или покинул компанию, проект продолжает жить.
Если же весь продукт держится на одном человеке, кодовая база постепенно превращается в черный ящик. Только этот специалист понимает, какие решения были приняты, что сгенерировал ИИ, где находятся слабые места и почему система устроена именно так.
Для инвестора, крупного клиента или зрелого технологического бизнеса такая зависимость от одного человека на ключевой системе — серьезный операционный риск.
ИИ-код может увеличить объем переделок
В разборе приводится несколько тревожных показателей, связанных с первой волной массового использования ИИ в разработке. По словам автора, ИИ-сгенерированный код может содержать больше ошибок, а скрытые логические дефекты встречаются заметно чаще, чем в коде, написанном человеком.
Также отмечается рост доли кода, который приходится выбрасывать или переписывать в течение короткого времени после создания. При этом объем системного рефакторинга может снижаться, поскольку модели склонны копировать существующие решения, не всегда улучшая архитектуру.
Отдельно подчеркивается, что часть руководителей, проводивших сокращения под лозунгом оптимизации с помощью ИИ, впоследствии пожалела об этом из-за потери институциональной памяти и контроля качества. Некоторые компании уже возвращают инженеров на прежние позиции.
Почему опытные тимлиды переоценивают свои возможности
У сильных разработчиков и тимлидов может возникнуть иллюзия, что они способны заменить команду. Она часто появляется после успешных экспериментов с ИИ на небольших личных проектах: за выходные можно собрать приложение, сервис или прототип, и это создает ощущение почти безграничной продуктивности.
Но личный проект в вакууме — это не корпоративная система с миллионами пользователей, сложными данными, платежными шлюзами, распределенными транзакциями и строгими требованиями к надежности.
В реальном продукте появляются:
- грязные данные;
- наследуемый код;
- интеграции с внешними системами;
- юридические и регуляторные ограничения;
- нагрузочные пики;
- сложные сценарии отказов;
- потребность в командной передаче знаний.
ИИ может ускорить отдельные действия, но не превращает одного человека в полноценную инженерную организацию.
Пять тимлидов вместо пяти команд — тоже не решение
Вторая популярная идея звучит так: если один тимлид с ИИ может заменить команду, то для масштабирования бизнеса достаточно нанять несколько тимлидов вместо нескольких команд. Однако такая структура может быстро привести к конфликту архитектурных подходов.
Каждый сильный технический лидер имеет собственные предпочтения, опыт и представления о правильной архитектуре. Без команды, процессов и согласованных ролей это может превратиться в спор амбиций: один переписывает модуль на одном стеке, второй выбирает другой, третий меняет базу данных, четвертый перестраивает интеграции.
В итоге вместо ускорения компания получает хаос, несовместимые решения и отсутствие людей, готовых заниматься ежедневной инженерной «сантехникой»: логами, миграциями, очередями, исправлением старого кода и рутинной поддержкой.
Кого действительно может заменить искусственный интеллект
Это не означает, что увольнений из-за ИИ не будет. Но под угрозой находятся не разработчики как класс, а специалисты, чья ценность ограничивается механическим выполнением однотипных задач.
Если работа человека сводится к копированию шаблонного кода, созданию одинаковых форм, переписыванию простых циклов или переносу решений из поисковой выдачи в проект, такие задачи действительно легко автоматизируются.
Однако инженер, который понимает систему, архитектуру, доменную область, данные, нагрузку и последствия решений, становится только ценнее.
Какие навыки будут важны для разработчиков
Разработчикам среднего и старшего уровня бессмысленно соревноваться с языковыми моделями в скорости набора кода или знании синтаксиса. Это проигрышная стратегия. Главная ценность инженера теперь смещается в сторону системного мышления.
Ключевыми становятся следующие навыки:
- архитектурное мышление;
- проектирование сложных систем;
- понимание границ бизнес-контекстов и доменов;
- создание модульных и слабо связанных решений;
- работа с распределенными транзакциями;
- понимание согласованности данных;
- проектирование под высокие нагрузки;
- умение контролировать качество ИИ-сгенерированного кода;
- способность принимать инженерные решения с учетом долгосрочных последствий.
ИИ может быстро написать код отдельного класса или модуля. Но собрать систему так, чтобы она была надежной, понятной, безопасной и развиваемой, по-прежнему должен инженер.
Новая роль младших разработчиков
По мнению автора, рынку нужны не беспомощные исполнители, а разработчики нового формата, включая сильных младших специалистов. Такой инженер должен иметь прочную базу: понимать компьютерные сети, реляционные базы данных, транзакции, операционные системы и основы архитектуры.
При этом он должен уметь использовать ИИ как мощный инструмент ускорения, а не как замену собственному мышлению. Такой специалист способен брать на себя рутинные задачи, фильтровать результат нейросети и разгружать тимлида, не превращая репозиторий в набор случайно сгенерированных фрагментов.
Главный вывод для бизнеса и разработчиков
Искусственный интеллект уже меняет разработку и будет дальше ускорять многие процессы. Но идея заменить сложную инженерную команду одним тимлидом с ИИ игнорирует реальность продуктовой разработки: контекст, ответственность, архитектуру, поддержку, безопасность и передачу знаний.
Для бизнеса ставка только на сокращение людей может обернуться ростом стоимости функций, техническим долгом и потерей контроля над системой. Для разработчиков главный вывод другой: нужно не паниковать и не соревноваться с ИИ в наборе кода, а укреплять фундаментальные инженерные навыки.
Будущее разработки — не в отказе от инженеров, а в сочетании сильной инженерной базы и грамотного использования искусственного интеллекта.
На основе ШІ в розробці: чому один тімлід не витягне складний продукт