Команды, создающие платформу разработки с нуля, гораздо чаще сообщают об отсутствии четкой стратегии. Поскольку искусственный интеллект упрощает создание платформы, обоснование подхода имеет большее значение, чем когда-либо, пишет на портале The New Stack Шарлотта Флеминг, исследователь индустрии разработки в Octopus Deploy.
Выбор между созданием и покупкой обычно рассматривается как инженерный компромисс, где время разработчиков сопоставляется с затратами на интеграцию и миграцию, а также с контролем и бременем обслуживания индивидуальной сборки. Когда мы готовили отчет «2026 Future of Platform Engineering», мы не пытались разрешить этот компромисс; мы пытались выяснить, раскрывают ли решения о выборе поставщиков функций платформы что-либо о команде, работающей над платформой. Оказывается, раскрывают. На основе ответов 379 специалистов по платформам мы обнаружили, что команды, преимущественно создающие платформу с нуля, реже имеют четкую стратегию и достигают меньшего количества целей, поставленных перед платформой.
Этот выбор значительно изменился с появлением ИИ. Агенты сделали создание платформы проще, чем когда-либо; внутренний инструмент, на создание которого раньше уходили месяцы, теперь можно собрать за один день. Но ИИ избавляет от необходимости писать код, а не от работы по его управлению. Поддержка, обновления и контроль, связанные с функцией, созданной с нуля, остаются, в то время как объем изменений, проходящих через конвейер, увеличивается. Это делает вопрос «создать или купить» более актуальным, чем когда-либо.
Мы спросили платформенные команды, как они поддерживают каждую функцию, которой владеют: созданную с нуля, созданную на основе существующего шаблона или приобретенную в качестве базового инструмента. Команды, чей основной подход — создание с нуля, гораздо чаще сообщают об отсутствии четкой стратегии для своей платформы. Эта взаимосвязь выражена ярко, однако ситуация не сводится к простой формуле: «разработка с нуля означает отсутствие плана».
Большинство команд покупают и выбирают осознанно
Мы обнаружили, что использование базового инструмента является наиболее распространенным среди функций, которыми владеют платформенные команды,: 51,3% респондентов заявили, что это их основной подход, далее следуют создание на основе существующего шаблона (31,2%) и создание с нуля (17,5%). Высокоэффективные команды чаще используют инструменты (58,8%), чем создают решения на основе шаблонов (47,8%) или с нуля (33,3%). Это может отражать более широкую тенденцию достижения зрелости: по мере того, как архитектурные решения в области платформенной инженерии становятся более четкими, команды все чаще стандартизируют инструменты, а не поддерживают собственные. Дэвид Туит описал эту альтернативу как «ловушку создать или купить», когда команды, вынужденные поддерживать пользовательские интерфейсы, тратят от 6 до 18 месяцев на обновления и операционные издержки вместо того, чтобы приносить пользу.
Исключения — вот где начинается самое интересное. Локальные среды разработки, проекты, создаваемые в один клик, и временные (эфемерные) среды чаще используют шаблоны, чем инструменты, поскольку они привязаны к определенному технологическому стеку и «золотым путям», которые редко предоставляют готовые инструменты. Временные среды заслуживают внимания, поскольку они также показывают, где ИИ хорошо себя зарекомендовал. Команды, чьи платформы предоставляют такие возможности, гораздо чаще сообщали о положительном влиянии ИИ на скорость и стабильность разработки ПО; то же самое касалось покрытия кода и контроля затрат. Среди команд, сообщивших об исключительно положительном эффекте, более трех четвертей имели временные среды разработки.
Эта взаимосвязь, вероятно, отражает скорее особенности платформы, чем саму функцию. Команды с временными средами разработки, как правило, работают на широких платформах с различными возможностями автоматизированной разработки, и эта широта сама по себе коррелирует с положительным влиянием ИИ на разработку. Таким образом, временные среды разработки могут быть признаком достаточно зрелой платформы, способной поглощать объем и изменения, генерируемые ИИ, без потери стабильности. Это согласуется с результатами отчета DORA «2025 State of AI-assisted Software Development», согласно которым выгоды для организаций от ИИ зависят от качества платформы: сильные платформы усиливают эффект, а более слабые — ослабляют его.
Функции, которые нарушают эту закономерность, отражают скорее соответствие шаблону, чем нежелание покупать, и доводы, стоящие за этими решениями, подтверждают это. Когда респондентов попросили объяснить логику выбора между созданием и покупкой, наиболее распространенным ответом был анализ затрат и выгод (29,6%), за которым следовали предпочтение открытого исходного кода (28,6%), оценка соответствия требованиям (22,4%), предпочтение коммерческих инструментов (22,4%) и разработка для обеспечения ключевой дифференциации (16,3%). Как резюмировал один из респондентов: «Создавайте то, что делает вас уникальными, покупайте или адаптируйте то, что является стандартом, и всегда учитывайте долгосрочные затраты и привязку к поставщику». Это та же центральная идея, что и в предметно-ориентированном проектировании, которое выделяет основную область, где заказная разработка создает конкурентное преимущество, от вспомогательных и общих областей, где она в основном добавляет сложность и обслуживание тому, что можно было бы купить.
Подход «создание с нуля»
Учитывая, насколько взвешенно большинство команд подходит к выбору, вопрос формирования стратегии представляет особый интерес. Если классифицировать команды по преобладающему методу, то те, кто создает решения с нуля, примерно в 3,5 раза чаще называют препятствием отсутствие четкой стратегии (57,9%), чем команды, использующие шаблоны (15,6%) или готовые базовые инструменты (16,7%).
Здесь также прослеживается связь с использованием ИИ: команды, предпочитающие создание с нуля, чаще применяют ИИ (умеренно или активно) для модернизации унаследованных систем и миграции на другие языки программирования. Налицо четкая закономерность: именно создатели собственных решений активнее всего полагаются на ИИ при их последующем сопровождении. Дело не в том, что они в целом используют ИИ чаще: показатели внедрения, реального влияния и ожидаемых результатов у них такие же, как и у остальных. Разница заключается именно в задачах, возникающих после создания кастомного функционала.
Сначала создание, решение — потом
Одно из возможных объяснений таково: сначала определяется стратегия, а затем принимается решение о покупке или создании. У команды без четкого вектора развития нет оснований для выбора готового продукта, поэтому она по умолчанию выбирает путь создания. Другая точка зрения гласит, что создание и есть стратегия, а не признак ее отсутствия. Процесс создания помогает выявить проблему и продемонстрировать прогресс еще до того, как команда окончательно определится с назначением платформы.
Это интересная трактовка, однако имеющиеся данные не позволяют однозначно сказать, какой подход верен. В работе Саймона Уордли, посвященной картированию (mapping), описывается схожая закономерность: команды, не осведомленные о существующих инструментах, склонны создавать собственные решения для проблем, которые уже были более эффективно решены другими.
С появлением ИИ разрыв между возникновением идеи и получением работающего инструмента практически исчез. Теперь ИИ-агент может создать специализированный инструмент для управления инцидентами еще до того, как кто-либо вообще задастся вопросом о его необходимости. Создавать стало проще, но вот поддерживать созданные решения — нет. Исследование DORA объясняет, почему это важно: качественные платформы предоставляют определенные возможности и одновременно задают границы их использования — и в условиях разработки с применением ИИ эти границы могут играть решающую роль. В готовые инструменты такие ограничения уже заложены, тогда как платформа, собранная из отдельных компонентов, обладает лишь теми ограничениями, которые кто-то догадался предусмотреть.
В любом случае эта закономерность сохраняется. Проблема не в самом создании с нуля. Стратегический просчет возникает тогда, когда создание с нуля выбирается по умолчанию, без веских на то оснований.
Более важный вопрос, чем «создавать или покупать»
Речь не идет о том, чтобы покупать абсолютно всё: мы выяснили, что некоторые функции необходимо создавать с учетом специфики конкретной организации. Важен осознанный подход к покупке. Если команда создает решение с нуля, на это должна быть причина. Когда же команды приобретают готовый инструмент, причина обычно очевидна: практически все покупают решения для четко определенных компонентов платформы, и по мере того, как ИИ-агенты пишут всё больше кода, ценность инструментов, эффективно решающих подобные задачи, только возрастает.
