Опрошенные порталом The New Stack эксперты объясняют, кто такой ИИ-нативный разработчик, как будет развиваться эта роль и почему ИИ-разработка на основе спецификаций (spec-driven) является движущей силой этой тенденции.

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

Термин «ИИ-нативный разработчик» вообще может быть неверно истолкован, поскольку он не обязательно связан с созданием приложений, концепций, алгоритмов или моделей ИИ. Речь в данном контексте идет о внедрении ИИ в весь жизненный цикл разработки ПО (SLDC) с помощью ИИ-дополнений, которые работают над конкретными задачами, чтобы разработчики могли сосредоточиться на предоставлении дифференцированной ценности. При этом генеративный ИИ (GenAI), основанный на естественном языке, будет продолжать активно работать в паре с программистами.

Но как извлечь максимальную пользу из своих будущих команд ИИ-нативных разработчиков? Как стратегически интегрировать ИИ в SLDC? Как сделать все это безопасно?

Восход ИИ-разработки на основе спецификаций

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

«Настоящий потенциал заключается в том, чтобы действительно переосмыслить рабочий процесс, — говорит Гай Поджарни, основатель Snyk и Tessl. — Во что превратится разработка с появлением этой мощной технологии? Мы считаем, что она перейдет от ориентированности на код к ориентированности на спецификации».

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

  1. Использование простого языка для описания новых функций.
  2. Разработка кода на основе этих новых спецификаций.
  3. Тестирование кода, чтобы убедиться, что он соответствует спецификациям.

Кроме того, ИИ-разработка на основе спецификаций устанавливает ограждения вокруг того, что делает ИИ-приложение.

Как и вся разработка, ориентированная на спецификации, она обеспечивает:

  • Улучшение согласованности и управления.
  • Более раннее подтверждение того, что создаваемое является тем, что должно быть создано.
  • Сотрудничество и общение между вовлеченными техническими и бизнес- сторонами на естественном языке.

Последнее преимущество особенно важно, поскольку код, сгенерированный ИИ, часто не сопровождается объяснением того, какие решения и почему приняла большая языковая модель (LLM).

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

«Современная разработка ПО очень ориентирована на код. Вы получаете какие-то требования, пишете какой-то код, принимаете сотню решений, которые никогда не будут реализованы, никогда не попадут в систему, — говорит Поджарни. — Иногда создаются тесты и документы, но они редко бывают тщательными и не всегда остаются актуальными».

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

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

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

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

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

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

Доводы в пользу запуска собственных LLM с открытым исходным кодом

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

Даже не решив эту проблему, 42% организаций в США рассматривают возможность разработки собственных LLM. Можно предположить, что очень немногие из них на самом деле являются компаниями, занимающимися ИИ, поэтому они могут втянуть себя в работу, которая не принесет им дифференцирующих преимуществ, но обойдется дорого.

«Многие компании изучают вопрос, как создать свой собственный внутренний ChatGPT, которому можно доверять. Потому что тогда вместо того, чтобы заниматься теневым ИИ и ставить ChatGPT на свой телефон, они смогут использовать внутреннюю версию», — говорит Люк Марсден, генеральный директор HelixML. Однако, по его мнению, решение не лежит в области проприетарных предложений, таких как ChatGPT или Gemini, поскольку LLM с открытым исходным кодом, например DeepSeek, становятся конкурентами по скорости и качеству.

«Если вспомнить противостояние Linux против Windows, то на сервере победил Оpen Source, — говорит Марсден. — Почему бы этой истории не повториться для новой волны ИИ?».

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

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

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

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

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

Такая возможность была недоступна в прошлом году во время кризиса нехватки GPU; но теперь, по словам Марсдена, цена на GPU значительно снизилась, и они снова стали широко доступны.

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

Еще один большой выигрыш ИИ-нативной разработки на основе Open Source заключается в том, что ее можно интегрировать в рабочие процессы DevOps. Это позволяет командам задавать вопросы, специфичные для их организаций, отмечает Марсден и приводит несколько примеров:

  • Что находится в текущем спринте?
  • Можете ли вы помочь мне написать код для задачи, которая была мне поручена?

«У вас может быть 10 различных дел, и вы хотите, чтобы Jira-помощник хорошо с ними справился. Вы можете записать эти сценарии в виде тестов», — говорит он. — Это похоже на то, как вы пишете тесты для созданного вами ПО, но в данном случае для приложений GenAI, и эти тесты используют спецификации на естественном языке для определения правильных ответов«.

Затем, продолжает Марсден, вы можете применить паттерн «LLM как судья» (LLM-as-a-Judge) в качестве метода оценки качества этих ответов — не только по общим стандартам, но и в контексте организации и ее руководящих принципов. При этом у вас все еще есть возможность привлечь человека, чтобы проверить, насколько хорош тест, прежде чем интегрировать эту возможность тестирования в существующий рабочий процесс CI/CD, чтобы тест выполнялся каждый раз.

Упадок инженерии подсказок

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

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

«На самом деле это происходит из-за появления таких моделей рассуждений, как DeepSeek-R1 и некоторые из разработок OpenAI, полезность ответов которых может снижаться, если в подсказку вкладывается слишком много», — говорит Майк Мейсон, главный специалист по ИИ в Thoughtworks.

По его словам, генеральный директор OpenAI Сэм Альтман «намекнул», что ChatGPT-5 будет представлять собой слияние стилей моделей, в результате чего она сможет рассуждать «в самый раз». «Это может изменить наши представления об инженерии подсказок, — говорит Мейсон, — а вскоре и вовсе отменить потребность в этой роли».

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

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