Заказная разработка: шесть мифов, которые ломают проекты

Рынок разработки живет в состоянии постоянного давления. С одной стороны – ИИ, который уже генерирует значительную часть кода в мире. GitHub забит машинными коммитами. Gartner предупреждает о кризисе качества программного обеспечения. Интерес крупного бизнеса к low-code за год заметно снизился – с 66 до 34 процентов по статистике «Ведомостей» за апрель 2026 года. Параллельно меняется поведение заказчиков. Они реже выбирают подрядчика по ставке человека-часа и чаще требуют предсказуемости – сроков, архитектуры, реального бизнес-эффекта.

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

В новом контексте бизнес снова и снова выбирает привычные стратегии:

• нанять побольше «дешевых» программистов, чтобы ускорить разработку;

• внедрить ИИ, чтобы он «переписал все сам»;

• отказаться от «несерьезных» low-code и платформенных решений;

• считать, что бизнес-требований достаточно, в них уже все понятно;

• недооценивать важность архитектуры и технологического стека, только бы система работала;

• быстро собрать собственную платформу вместо внедрения готовых решений.

На практике – это ловушки, которые не раз приводили к перерасходу бюджета, срывам сроков, архитектурному хаосу.

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

Миф 1. «Если нанять много разработчиков – все заработает быстрее»

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

• вместо 10 разработчиков нанять 100;

• вместо 100 привлечь 500. 

Но в реальности это работает иначе.

На уровне здравого смысла все очевидно:

• больше людей – больше кода;

• больше кода – быстрее продукт;

• больше команд – параллельная работа;

• параллельность – ускорение разработки.

Иногда это формулируют максимально прямо: «Давайте наймем 5000 разработчиков и быстро все сделаем».

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

Усиливает этот миф и то, что в крупных корпорациях действительно много разработчиков. Кажется, что деньги можно «конвертировать» в скорость, достаточно расширить штат, и результат появится быстрее. Но программирование устроено иначе. Разработка – это не конвейер, а система с жесткими связями.

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

Коммуникационные издержки

Каждый новый разработчик – это не просто дополнительная производительность. Это новые:

• коммуникационные связи;

• согласования;

• точки принятия решений;

• конфликты архитектуры.

Чем больше команда, тем сложнее координация. В какой-то момент издержки на нее начинают расти быстрее, чем отдача от привлечения новых людей.

Потеря архитектурного единства

Без сильной архитектуры и платформенного подхода разные команды начинают:

• писать по-разному;

• решать одни и те же задачи разными способами;

• создавать несовместимые решения;

• дублировать функциональность.

Система становится разрозненной и теряет внутреннюю связность.

Проблемы интеграции

Когда много команд работает параллельно, возникает:

• много ошибочных интеграций;

• несовместимость компонентов;

• расхождение в логике процессов;

• нестабильность системы.

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

Разный уровень качества

При массовом найме часто растет доля менее опытных разработчиков. Это естественно. Но есть последствия:

• код становится неоднородным;

• растет количество ошибок;

• увеличивается технический долг;

• усложняется сопровождение.

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

Скорость не растет линейно

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

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

Что делать: проблема не в людях, а в структуре

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

Проблема – в отсутствии общей структуры, которая связывает разработку в одно целое.

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

• архитектуру;

• правила разработки;

• стандарты качества; 

• подходы к интеграции; 

• контроль безопасности и производительности.

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

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

Также важно постепенное масштабирование. Сначала – маленькие команды, потом – расширение. Не наоборот. Система должна выдерживать рост, а не ломаться от него.

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

Миф 2. «ИИ все перепишет и решит проблему легаси»

Этот миф сейчас звучит особенно заманчиво. Он – про надежду на простое решение сложной проблемы. Есть старая система, много лет кода, накопленный технический долг. Разбираться в ней тяжело, поддерживать дорого, а менять страшно. И вдруг появляется мысль: давайте все перепишем с помощью ИИ. Быстро, аккуратно, без дорогих специалистов. Старый код «разложим», отрефакторим и соберем заново.

Миф держится на кажущемся ощущении, что легаси – обычный код, который можно заменить другим кодом. В реальности все сложнее.

Почему легаси нельзя «просто переписать»

Легаси – это не набор файлов и функций. Это система, которая прожила годы в реальной эксплуатации. В ней есть:

• бизнес-правила, которые никто не переписывал в документацию; 

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

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

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

Поэтому идея «переписать все заново» ломается о простую вещь: нет полного описания системы, с которого можно начать. Нельзя идеально воспроизвести то, что формировалось 10–15 лет, потому что оно живет не в документах, а в реальном поведении системы.

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

Где ломается идея полного переписывания кода с помощью ИИ

Частая ошибка – ожидание, что ИИ не просто поможет, но и сделает всю работу целиком. «Разложит» систему, перепишет, соберет обратно и ничего не сломает.

Но сложность – не в написании кода. С этим ИИ справится хорошо. Сложность – в связности системы: 

• как разные части взаимодействуют между собой; 

• как проходят данные; 

• как работают интеграции; 

• как сохраняется стабильность в продакшн.

При попытке «переписать все сразу» часто получается не новая система, а набор разрозненных решений, которые начинают конфликтовать:

• появляются расхождения в логике; 

• ломаются интеграции; 

• растет количество доработок. 

Вместо упрощения система становится хрупкой и дорогой в сопровождении.

Как ИИ реально работает с легаси

Вместо идеи «переписать все заново» с помощью ИИ лучше последовательно улучшать существующую систему:

• модернизировать отдельные части;

• переносить функциональность по слоям;

• использовать ИИ как инструмент помощи, а не как автономного архитектора;

• контролировать результат через стандарты и платформу.

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

Миф 3. «Главное в проекте – качественно описать требования»

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

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

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

Что на самом деле происходит с требованиями

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

Хорошая постановка задачи чаще говорит не об «идеальном документе», а о зрелости компании. Если есть экспертиза запуска проектов, требования получаются более собранными, логичными. Они ближе к реальности, описывают не только старт и финиш, но и весь путь.

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

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

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

Почему уточнения – это нормально

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

Поэтому уточнения – это не сбой процесса. Это и есть процесс.

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

Количество вопросов зависит от экспертизы:

• если ее мало – вопросов будет много;

• если ее много – вопросы будут точечными, по сложным местам.

На практике бизнес-требования работают как приглашение к сотрудничеству. Дальше начинается совместная работа бизнеса и разработки, в процессе которой постепенно уточняется финальная форма продукта.

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

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

Миф 4. «Архитектура и стек не важны – лишь бы работало»

На первых этапах проекта кажется, что главное – быстро запустить функционал. Архитектура подождет. Но со временем система начинает:

• плохо масштабироваться;

• ломаться при изменениях;

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

• зависеть от конкретных людей.

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

• в ходе проекта меняются потребности бизнеса;

• команда находит более удачные способы реализации;

• аналитика не фиксирует скрытые зависимости.

Если архитектура плохо приспособлена к изменениям, каждая новая доработка становится сложнее и дороже.

Почему кажется, что стек не имеет значения

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

Но разработка не заканчивается в день релиза. Продукт постоянно развивается. В нем появляются: 

• новые функции; 

• интеграции;

• дополнительные пользователи; 

• новые требования бизнеса. 

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

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

Поэтому при выборе технологий учитываются:

• доступность специалистов на рынке;

• цена на их услуги;

• требования безопасности;

• возможности масштабирования;

• поддержка продукта через несколько лет.

Поэтому фраза «мне не важно, на чем это написано» часто означает лишь то, что последствия выбора пока не очевидны.

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

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

Универсального стека не существует

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

Но современные системы состоят из разнородных компонентов: 

• фронтенд;

• бэкенд; 

• базы данных; 

• очереди сообщений; 

• аналитические сервисы;

• интеграционные слои; 

• инфраструктурные инструменты. 

У каждой части системы – свои задачи, поэтому и технологии могут быть разными: 

• высоконагруженные API – Go или Java;

• задачи машинного обучения – Python; 

• интерфейсы – TypeScript. 

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

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

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

Но это скорее исключение, чем правило. В долгоживущих системах (корпоративных, интеграционных, высоконагруженных) такой подход оборачивается техническим долгом.

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

Поэтому выбор стека – это всегда баланс между возможностями, рисками и затратами. Главные вопросы – что компания получит взамен и сколько будет стоить возможная ошибка.

Миф 5. «Low-code – это несерьезно и только для простых задач»

Этот миф вырос из старого опыта с ограниченными платформами, где были:

• vendor lock-in;

• монолитная архитектура;

• плохая масштабируемость;

• закрытые ядра;

• ограниченные возможности кастомизации.

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

Но рынок давно изменился. Вместе с ним трансформировались low-code платформы. Поэтому споры вокруг них связаны не столько с их нынешними возможностями, сколько с опытом предыдущих поколений.

Когда-то похожие разговоры велись вокруг CMS-систем. Считалось, что на готовом решении невозможно построить серьезный сайт. Со временем такие платформы стали основой для огромного числа крупных проектов. С low-code – похожий процесс.

Что умеют low-code платформы

Современный low-code уже не выглядит «закрытой коробкой», внутри которой ничего нельзя изменить. Наоборот, платформы стараются дать разработчику прозрачность и контроль:

• код остается доступным, открытым;

• инфраструктурную рутину берет на себя платформа;

• генерируются тесты, документация (вплоть до ГОСТ, РБПО);

• встроен DevOps-пайплайн;

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

«Low-code – это инструмент, экзоскелет, с помощью которого один разработчик выпускает полноценные системы, формируя только бизнес-логику», – говорит Александр Сахаров, директор по работе с партнерами компании «Диасофт».

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

В разработке корпоративных систем много технической рутины: 

• настройка логирования; 

• написание тестов; 

• управление ролями, правами доступа;

• подготовка к масштабированию; 

• разработка документации; 

• настройка, сопровождение инфраструктуры.

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

• автоматически генерируют типовой код; 

• помогают создавать документацию; 

• формируют тесты; 

• поддерживают базовые процессы разработки.

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

При этом разработчик никуда не исчезает. Наоборот, его роль возрастает. Вместо написания однотипного кода он занимается тем, что нельзя автоматизировать: 

• принимает архитектурные решения; 

• продумывает бизнес-процессы; 

• отвечает за интеграции;

• контролирует качество системы. 

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

Где проходят реальные границы low-code

При всех преимуществах low-code подходит не для каждой задачи. Здесь важно избежать другой крайности – убеждения, что платформа полностью заменяет разработчиков.

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

Но это не значит, что low-code бесполезен. Он хорошо работает там, где:

• продукт не слишком сложный по архитектуре;

• есть типовые бизнес-процессы;

• важна скорость разработки;

• система не перегружена сложными интеграциями.

Поэтому вопрос о том, можно ли использовать low-code в серьезных проектах, сменил более актуальный: какую часть системы разумно автоматизировать, а какую оставить за разработчиками.

Миф 6. «Нам не нужна готовая платформа – мы быстро создадим свою»

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

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

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

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

Поэтому идея «сейчас быстро напишем свою платформу» остается одним из самых распространенных и одновременно самых дорогих заблуждений.

А что если не пользоваться платформами

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

Пока над продуктом работают три-пять человек, договориться о подходах и архитектуре легко. Но по мере роста команд до десятков и сотен разработчиков ситуация меняется:

• каждая команда начинает принимать собственные архитектурные решения; 

• по-разному реализуются интерфейсы; 

• возникают отличия в подходах к безопасности, интеграциям, тестированию и сопровождению; 

• код развивается в разных направлениях; 

• система постепенно теряет целостность.

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

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

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

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

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

Что мы предлагаем: платформенный подход

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

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

Платформа берет на себя задачи, которые не надо каждый раз решать заново:

• архитектурные стандарты;

• требования информационной безопасности;

• управление версиями;

• CI/CD-процессы;

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

• единые стандарты UX/UI;

• контроль качества кода;

• сопровождение, развитие технологического ландшафта.

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

Эффект от платформенного подхода измеряется конкретными показателями:

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

• снижение зависимости от количества разработчиков;

• ускорение вывода продуктов на рынок (time-to-market);

• повышение качества кода и архитектуры;

• уменьшение технического долга;

• единые стандарты безопасности;

• единые стандарты UX/UI;

• синхронизация действий между командами;

• упрощенное сопровождение систем;

• масштабирование разработки с сохранением единых стандартов.

Так команды из четырех-пяти человек могут выпускать такой объем работ, который раньше требовал участия 12–15 специалистов.

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

Искусственный интеллект участвует практически на всех этапах жизненного цикла разработки:

• проектирует процессы;

• помогает создавать архитектурные решения;

• генерирует код;

• пишет автотесты;

• участвует в тестировании;

• помогает в сопровождении систем.

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

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

Вывод: всё решает подход, а не технологии

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

• что достаточно увеличить команду, чтобы ускорить разработку;

• что требования можно описать один раз и навсегда;

• что технология сама решит накопившиеся проблемы.

Но разработка – это всегда управление неопределенностью. И успешные команды делают не «больше кода» и не «меньше кода». Они строят системы, где есть:

• платформа;

• стандарты;

• автоматизация;

• разумное применение ИИ.

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