Diasoft объяснила, почему джуны, магия ИИ и своя платформа не спасают dev-проекты

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

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

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

Второй миф связан с генеративным ИИ. Здесь позиция у экспертов более тонкая: они не спорят с тем, что инструменты вроде Cursor, внутренних моделей и агентных сценариев уже реально ускоряют time-to-market, снижают объем ручной рутины и помогают быстрее закрывать баги. Некоторые команды даже делают расход токенов отдельной метрикой эффективности.

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

Для массовой миграции и транспиляции по-прежнему нужны детерминированные инструменты, парсинг, AST-преобразования и люди, которые понимают бизнес-контекст и могут проверить, что именно сгенерировала модель. Третий миф — «построим свою платформу и перестанем зависеть от рынка». В обсуждении отмечают, что такой путь иногда действительно работает, но только у компаний с очень длинным горизонтом инвестиций, огромным бюджетом и критической зависимостью бизнеса от собственной цифровой платформы.

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

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

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

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

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