Разработка программного обеспечения с помощью ИИ: как создавать безопасный и надежный код

В Telefónica Tech искусственный интеллект (ИИ) уже стал частью нашей повседневной работы, помогая в создании программного обеспечения и новых сервисов. Он применяется для самых разных задач: анализа требований, проектирования решений, генерации кода, написания тестов и ревью реализаций.

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

Сегодня создавать ПО становится все проще. Однако гарантировать, что это ПО корректно, поддерживаемо и безопасно — задача, которая приобретает все более важное значение.

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

Каковы риски Vibe Coding, когда сгенерированный ИИ код вроде бы работает?

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

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

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

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

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

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

Как работает разработка на основе спецификаций с использованием искусственного интеллекта?

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

Поэтому все большее значение приобретают методологии работы, рассчитанные на интеграцию ИИ на всех этапах, такие как разработка на основе спецификаций (Specification-Driven Development).

По нашему опыту, такие инструменты, как Spec Kit, AI-Powered Specification-Driven Development Toolkit, способны упростить этот подход к разработке на основе спецификаций. Отправной точкой обычно служит пользовательская история (user story) или требование, определенное в Jira командой спецификации.

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

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

Какие риски сохраняет генерация кода с помощью искусственного интеллекта?

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

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

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

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

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

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

Если риски становится все труднее выявлять с помощью простого визуального осмотра результата, нам требуются механизмы, способные объективно и непрерывно верифицировать соответствие сгенерированного ИИ кода функциональным, архитектурным требованиям и стандартам безопасности, установленным для решения.

Почему ручного ревью кода, сгенерированного ИИ, может быть недостаточно?

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

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

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

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

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

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

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

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

Благодаря такому тестированию становится возможным развертывать целые модули решения в локальных песочницах (sandbox) и тестировать их в различных сценариях. Это позволяет проверять сложное поведение, тестировать нештатные ситуации, снижать риски перед развертыванием и уменьшать потребность в использовании реальных сред для ряда проверок.

Как можно использовать ИИ для проверки кода, сгенерированного другим ИИ?

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

По нашему опыту, GitHub Copilot Code Review можно применять как дополнительный инструмент проверки кода перед его слиянием в репозиторий — всегда в качестве дополнения к анализу со стороны разработчиков.

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

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

Кибербезопасность также может быть интегрирована в такие автоматические проверки. Настоящая ценность раскрывается тогда, когда эти возможности обогащаются профильными знаниями и признанными стандартами безопасности.

Например, при таком ревью можно учитывать критерии и лучшие практики на основе таких стандартов, как OWASP Top 10.

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

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

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

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

Заменит ли искусственный интеллект разработчиков программного обеспечения?

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

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

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

Потому что будущее, скорее всего, принадлежит не бесконтрольному Vibe Coding. Оно принадлежит командам, способным объединить возможности искусственного интеллекта с дисциплиной программной инженерии.

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

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

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

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

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

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

Часто задаваемые вопросы

Что такое Vibe Coding?

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

Каковы риски кода, сгенерированного ИИ?

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

Что такое package hallucinations?

Это ситуации, когда система ИИ рекомендует несуществующие, некорректные или, в определенных случаях, опасные зависимости.

Почему важны спецификации перед генерацией кода с помощью ИИ?

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

Какую роль играют автоматизированные тесты в разработке с использованием ИИ?

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

Можно ли использовать искусственный интеллект для проверки кода, созданного с помощью ИИ?

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

Заменяет ли ИИ проверку кода человеком?

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