Привет, Хабр! 

Меня зовут Александр Сахаров, я директор по работе с партнерами в компании «Диасофт». Мы в уже много лет развиваем экосистему Digital Q — это наш ответ хаосу в разработке, платформенный подход, который позволяет командам не изобретать велосипед каждый раз, а собирать сложные системы из надежных компонентов.

Часто, заходя в крупные ИТ-проекты, мы наблюдаем одну и ту же картину: заказчики выбирают «странные пути», которые кажутся логичными на бумаге, но на практике сжигают миллионы рублей и годы времени. Это не просто ошибки планирования, а фундаментальные мифы, которые до сих пор живут в головах топ-менеджмента.

Недавно мы собрались с коллегами из Рексофта, Rapporto, Smekalka и других компаний, чтобы препарировать эти заблуждения. В этом материале я собрал самую суть нашей дискуссии — живой опыт тех, кто ежедневно разгребает завалы «быстрой и дешевой» разработки. Свои слова я добавил в цитаты, чтобы донести свое мнение по ходу обсуждения. 

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

«Наберем 5000 -- и свернем горы»

«Заказчики довольно часто до сих пор думают, что если нанять большое количество программистов, те решат любую задачу. И обращаться к партнерам, к компаниям, которые профессионально занимаются IT, смысла нет -- можно просто набрать пять тысяч разработчиков и быстренько написать все, что нужно. Так делают, например, крупные банки и другие корпорации. Но эти программисты получают большую зарплату, дают высокие косты, а то, что они создают, почему-то имеет низкое качество. Результаты плохо синхронизируются между собой, возникает большое количество ошибок на интеграциях, сложности сопровождения, рассинхронизированные UX-процессы. Единых стандартов горизонтальной масштабируемости нет, с инфобезом постоянные проблемы», -- обозначил проблему Александр Сахаров, директор по работе с партнерами компании «Диасофт».

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

«Как владелец большой IT-команды и человек, отвечающий в том числе за бюджет, я постоянно стремился оптимизировать работу. Пробовал на разных этапах различные подходы, в том числе набирать менее квалифицированных специалистов и выращивать их внутри. В итоге пришел к мысли, что акцент должен быть на командных процессах и на зрелости IT-команды. Все риски, связанные со спонтанным расширением ради ускорения разработки, сводятся к двум вещам: накопление технического долга, который рано или поздно бьет по производительности, и проблемы с информационной безопасностью. Можно передать функции контроля лидам, но это дает обратный эффект: растут издержки, нужны квалифицированные специалисты для проверки, их надо удерживать, и мы сильно завязываемся на человеческом факторе», -- рассказал Роман Кучерский, CTO Rapporto.

И массовое применение ИИ не спасет. 

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

«Мы даже сейчас специально разделяем проект на несколько фаз: сначала заходит меньше народа, потом больше. Потому что нельзя взять девять человек и за месяц сделать то, что по естественному ходу требует семи месяцев. Огромные издержки на коммуникации -- заказчики этого просто не понимают. У джунов нет архитектурного видения, и большое их количество порождает хаос: растет технический долг, и через шесть-двенадцать месяцев приходится все переделывать. Кстати, все проекты с большим количеством агентных роев -- это новые проекты. Как только у нас устоявшийся код на 150 тысяч строк и десять тысяч объектов, никакой гигантский ИИ с огромным контекстным окном его не переварит. Вот вам аналогия из другой отрасли: Boeing не может строить 747-й, потому что людей с нужными компетенциями просто не осталось. Самая главная проблема -- коммуникации, отсутствие архитектурного опыта и издержки на управление толпой. Все это приводит к одному: проект становится только дороже», - развернул мысль  Потапов на примерах из собственных проектов.

«Нельзя нанять дешевых специалистов с опытом на десять условных единиц и ожидать, что они выполнят задачу на четырнадцать. Если дать им поработать с агентом два часа, задачу сложностью в двадцать единиц они все равно не решат. Без вариантов придется нанимать более дорогих специалистов. И чем больше мы наберем дешевых людей, тем меньше шанс выполнить задачу», -- резюмировала Виктория Смирнова, руководитель проектов Outlines Tech.

«ИИ перепишет нам все за ночь»

Второй миф звучит еще соблазнительнее первого.

«Вокруг ИИ сейчас настоящая магия. Он, безусловно, полезен, вопросов нет. Но встречаются совсем крайние случаи: заказчик говорит, что у него есть старый код, и он собирается переписать его с помощью нейросети. Мол, она все разложит, зарефакторит, и сложную систему, которую писали пятнадцать лет, удастся пересобрать за считанные месяцы. И снова -- никакие профессионалы, никакие IT-компании не нужны. Нам это странно слышать, потому что на практике так не работает», -- описал ситуацию Сахаров.

«До нас как раз докатывается волна Cursor -- в Америке она началась полтора года назад. Крупнейшие софтверные компании уже сделали расход токенов одной из ключевых метрик эффективности. Лидеры мнений вроде Карпати говорят прямо: я больше не пишу ни строчки кода, работаю только через промпты. Мультиагентность, параллельные задачи на нескольких экранах одновременно -- это давно не вайб-кодинг, а полноценная гонка 24 на 7. У меня есть знакомый, чья команда устроена так: пять моделей в связке генерируют код, а люди его перепроверяют. Звучит олдскульно, но работает. Индустрия движется к десяткам и сотням тысяч долларов ежемесячных расходов на токены. Компании, которые встроили это в процесс, отрываются от конкурентов: у них сокращается time-to-market, баги закрываются быстрее», -- парировал Сергей Жучков.

«Когда речь идет о системах в сотни тысяч строк, бездумно вставлять туда сгенерированный код опасно. Я не говорю, что ИИ не нужен. Я говорю, что недостаточно просто считать потраченные токены -- нужна инфраструктура, которая берет на себя контроль качества. Все, что генерирует нейросеть, должно ложиться в единый фреймворк стандартов. Тогда результаты работы четырехсот разных команд складываются в целое, а не рассыпаются на части», -- ответил Александр Сахаров.

«Все в итоге упирается в экспертизу людей, которые либо уже прошли этот путь, либо глубоко понимают бизнес-контекст. Даже если искусственный интеллект используется как инструмент -- а тут отдельная тема, какие модели брать и насколько безопасно их применять -- главное остается за человеком: задать верные рамки, провалидировать результат. Это не просто промпт написать. Нужно еще до генерации кода выстроить архитектурные артефакты, ограничения по информационной безопасности. А для этого нужна глубокая экспертиза в проектировании систем, а не просто навык работы с инструментом», -- поддержал Кучерский.

«С Cursor я работаю больше года, у нас развернуты внутренние модели в собственном контуре. Но есть фактор, который в разговорах про ИИ-разработку постоянно упускают: безопасность. Нужно гарантировать, что чувствительная информация не утечет наружу, а она утекает. В последнем тендере мы прямо в оценке указали, что часть кода будет генерироваться с помощью ИИ, и за счет этого сократили состав команды. Мы выиграли тот конкурс. Но в следующем -- проиграли, хотя точно так же закладывали ИИ в безопасном периметре. Заказчик просто хотел дешевле. Мы занимаемся валовой транспиляцией кода, перелопачиваем миллионы строк. И решаем эту задачу не искусственным интеллектом, а своим собственным. Парсинг, построение абстрактных синтаксических деревьев, их преобразование -- это классические методы computer science, начиная с Дональда Кнута. У нас детерминированная генерация, а нейросеть подключается только на периферии, как тряпочка для финальной полировки, но не как основной инструмент. Мы пришли к такому подходу именно потому, что ИИ пока не способен делать это филигранно. Когда речь идет о миллионах строк и нужно переписать старую систему целиком, справиться одним искусственным интеллектом нереально -- при текущем уровне его развития», - отметил Потапов. 

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

«Напишем свою платформу -- и заживем»

«Сбербанк пишет собственную платформу уже десять лет. Дважды за это время признавал проект неудачным и начинал заново. Я специально нашел публикацию "Ведомостей" 2016 года, когда впервые было официально признано, что на первую итерацию потратили тридцать миллиардов рублей -- и она не взлетела. Сбербанк, ВТБ и другие крупные корпорации с большими бюджетами могут себе позволить такие эксперименты. Но это единицы. В России наберется от силы десять-пятнадцать компаний, способных потянуть подобное. Все остальные, если попытаются повторить этот путь, вынуждены будут потратить десять-пятнадцать лет и огромные деньги. А платформу нужно не просто написать -- ее нужно сопровождать, развивать, догонять рынок. И вместо того чтобы решать бизнес-задачи, деньги и время уходят в создание инструментария», -- предупредил Александр Сахаров.

«Большинство известных нам вещей -- React, Angular, Prometheus, Node.js, тот же GitLab -- создавались не в IT-вендорах, а на стороне бизнеса. Маленькие команды из двух-трех энтузиастов собирались, поднатуживались и делали то, из чего потом условный Сбербанк пытается собрать платформу и все равно не может. Это феноменальная вещь. Инициатива зарождалась именно в бизнесе, потому что вендоры не могли закрыть потребность. И мне кажется, когда вендор заявляет, что создание платформ -- его прерогатива, лучшим доказательством были бы не проприетарные продукты, а вклад в open source. Вот тогда можно верить», -- возразил Михаил Соколов.

«Как раз опыт Альфа-банка это подтверждает. Когда банк осознал, что четыреста с лишним команд начинают плохо синхронизироваться между собой, он разработал единую платформу и посадил на нее всех подрядчиков. Платформа взяла на себя контроль целостности, горизонтальную масштабируемость, информационную безопасность, нагрузочное тестирование, единые стандарты фронтенда и UX. Это позволило четыремстам командам работать слаженно. Но банки -- особая история: они могут позволить себе потратить деньги несколько раз, попробовать разные варианты и выбрать лучший. Все суперуспешные компании используют платформенный подход -- и Amazon, и Meta. Просто у них были деньги и возможности создать платформы с нуля. Имеет смысл воспользоваться этим опытом и взять готовое решение, сделанное по образу и подобию того, что используют лидеры, а не пытаться пройти весь путь заново», -- продолжил Александр Сахаров.

Но и здесь нашлась альтернативная точка зрения. «Можно схантить пару топовых синьоров или тимлидов из того же Альфа-банка или Тинькова, вооружить их безлимитными токенами и полномочиями -- и просто пройти тот же путь в десять раз быстрее. Они уже знают, где спотыкались, знают, как писать правильные промпты. И все то, что раньше делалось на неограниченные бюджеты банка, можно сделать в разы, а может и в десятки раз дешевле. Сейчас не надо нанимать ни джунов, ни мидлов -- только синьоров. Синьор плюс безлимитные токены творят чудеса и по скорости, и по качеству. Имеет смысл экспериментировать в обе стороны. У компании будет куда более сильная переговорная позиция, если она скажет: мы параллельно развиваем собственную разработку, выделили бюджет и слоты на наем -- а теперь давайте обсудим, на каких условиях внедрять вашу платформу и сколько будет стоить ее поддержка. Ложной дихотомии тут нет», -- убежден Сергей Жучков.

«Крупные компании, да и не только крупные, сейчас все активнее забирают разработку к себе. У нас в прошлом году было несколько проектов, которые клиенты в какой-то момент перевели на собственные команды за счет высвобождения внутренних ресурсов. Компании, у которых цифровой продукт составляет ядро бизнеса, это ядро не аутсорсят -- на нем держится собственная команда. На внешний подряд уходят отдельные сервисы, микросервисы, какие-то периферийные задачи. Рынок заказной разработки за последние годы серьезно изменился. Раньше мы хорошо продавали часы разработки: клиенты были готовы платить за наше умение нанимать и управлять программистами, потому что сами этого не умели. Сейчас рынок сдвинулся в сторону работодателя, резюме больше, чем вакансий, и компании научились нанимать самостоятельно. Ценность все больше переходит к тому, способны ли мы сделать продукт или его часть полностью под ключ -- быстрее и качественнее, чем это сделает штатная команда заказчика. За счет отраслевой экспертизы, сработанных команд, грамотного применения ИИ в разработке», -- описал ситуацию Даниил Васильев, руководитель ASAP.

«Никакого критического противоречия тут нет. Заказная разработка прекрасно работает в синергии с внутренними командами. Ядро может оставаться у заказчика, а внешние команды закрывают то, на что в моменте не хватает ресурса, или берут проектные задачи. Все зависит от запроса. Если речь о гигантах с четырьмястами командами -- конечно, они будут строить для себя. Но выбор между "все делаем сами" и "все отдаем вендору" -- это ложная постановка вопроса», -- заключила Виктория Смирнова.

Конвейер, а не волшебная палочка

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

«Альтернатива ручному контролю через лидов, к которой сейчас все стремятся, -- это автоматизация командных процессов. Статический анализ, причем не только качества кода, но и информационной безопасности, различные SAST-решения. В ту же сторону смотрит и искусственный интеллект: мы воспринимаем его не как замену конкретного сотрудника, а как замену определенных функций сотрудника. Разработчик для нас -- это не просто человек, который пишет код. Это специалист, обладающий экспертизой для принятия архитектурных решений, следящий за унификацией подходов в компании. А вот ту часть его работы, которая связана с непосредственным написанием кода, вполне можно отдать ИИ -- при условии, что выстроен процесс контроля на каждом этапе цикла поставки», -- дополнил Роман Кучерский.

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

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