Принс Кохли, президент и генеральный директор Sauce Labs — серия интервью

Prince Kohli, президент и генеральный директор Sauce Labs, является опытным технологическим руководителем с обширным опытом в области искусственного интеллекта, корпоративного программного обеспечения, облачных вычислений, автоматизации, сетей и кибербезопасности. До того как присоединился к Sauce Labs в феврале 2025 года, он более шести лет занимал должность технического директора Automation Anywhere, где способствовал развитию технологий автоматизации на основе ИИ для крупных предприятий. Ранее Кохли работал старшим вице‑президентом по инженерии в ThoughtSpot и занимал руководящие позиции в Ericsson, включая руководство глобальными подразделениями НИОКР, насчитывающими более 10 000 инженеров. Он также почти десятилетие проработал в Citrix, возглавляя инициативы в области платформ, облачных сетей, инженерии и операций. В начале карьеры он со‑основал компанию по безопасности приложений Teros и работал техническим лидером в SGI. Наряду с исполнительными ролями Кохли вносил вклад в инициативы по управлению технологиями через Ethical AI Governance Group и ранее участвовал в рабочей группе World Economic Forum по безопасным системам и технологиям.

Sauce Labs — компания, занимающаяся обеспечением качества программного обеспечения и непрерывным тестированием, предоставляющая предприятиям инфраструктуру и инструменты для тестирования веб‑ и мобильных приложений в разных браузерах, операционных системах, виртуальных средах и на реальных устройствах. Ее платформа поддерживает такие возможности, как автоматическое и ручное тестирование, визуальное тестирование, распространение мобильных приложений, отчётность об ошибках и создание тестов и аналитика на базе ИИ, при этом интегрируется с типичными конвейерами непрерывной интеграции и поставки. Sauce Labs всё активнее позиционирует свою технологию вокруг AURA — платформы AI‑Unified Release Assurance, использующей AI‑агентов для генерации, выполнения и анализа тестов при сохранении человеческого контроля на протяжении всего процесса выпуска программного обеспечения. Компания заявляет, что её инфраструктура поддержала более 8,7 млрд запусков тестов и более 300 000 корпоративных пользователей, опираясь почти на два десятилетия данных о кроссплатформенном тестировании.

До присоединения к Sauce Labs вы руководили автоматизацией на основе ИИ в Automation Anywhere и управляли крупными облачными и инженерными подразделениями в компаниях, включая Ericsson и Citrix. Как этот опыт сформировал ваше видение проблемы качества программного обеспечения, и что убедило вас сделать AI‑нативную проверку релизов центральным приоритетом в Sauce Labs?

В Ericsson и Citrix я увидел, как быстро дефект в программном обеспечении может распространиться и затронуть глобальную инфраструктуру, вызывая серьёзные последствия для безопасности, операций клиентов, доверия и доходов. Automation Anywhere показала мне, как ИИ меняет скорость и структуру работы, и стало ясно, что тестирование необходимо перестроить под темпы программного обеспечения, генерируемого ИИ. Sauce Labs стала пионером в автоматизации тестов, поэтому AI‑нативная проверка релизов — следующая крупная задача, которую мы созданы решать.

Sauce Labs’ исследование показало, что 80 % организаций отследили инцидент в продакшене, сбой или дефект, влияющий на клиентов, до кода, сгенерированного ИИ. Указывает ли это в первую очередь на слабости кода, созданного ИИ, или на то, что предприятия принимают инструменты кодирования ИИ без обновления своих процессов тестирования и управления?

Показатель в 80 % указывает на проблему во всей системе поставки программного обеспечения. Индустрия ИИ привлекла более триллиона долларов частного капитала, большая часть которого основана на предположении, что ИИ делает бизнес значительно более продуктивным. Однако генерация большего объёма кода создаёт ценность только тогда, когда компании могут быть уверены в его качестве и безопасности до того, как вывести его в продакшн.

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

В отчёте говорится, что разработчики создают на 741 % больше кода, тогда как скорость релизов увеличилась менее чем на 20 %. Что мешает системам валидации идти в ногу, и где обычно возникает крупнейшее узкое место в жизненном цикле разработки программного обеспечения?

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

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

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

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

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

AURA предназначена для проверки программного обеспечения в соответствии с «бизнес‑намерением». Как это намерение определяется и преобразуется в проверяемые требования, кто отвечает за их утверждение, и как платформа обрабатывает требования, которые являются неоднозначными, неполными или открытыми для интерпретации?

Бизнес‑намерение исходит из требований к продукту, критериев приёмки, бизнес‑правил, пользовательских сценариев и того, как клиенты действительно используют приложение. Руководители продукта определяют ожидаемый результат, а инженерные и команды обеспечения качества преобразуют этот результат в поведение, которое система может проверить. Когда требования неполные или неоднозначные, AURA должна выявлять эту неопределённость и запрашивать человеческое одобрение перед изменением ожидаемого результата.

Sauce Labs сообщает, что предприятия, использующие AURA, испытали на 90 % меньше инцидентов в продакшене, на 47 % ускорили циклы релизов и вернули 38 % инженерных ресурсов. Как измерялись эти результаты, за какие периоды внедрения, и какая независимая валидация использовалась, чтобы отделить влияние AURA от других организационных или инженерных изменений?

В рамках корпоративных внедрений мы измеряли изменения в количестве инцидентов в продакшене, скорости циклов релизов и доступных инженерных ресурсах после того, как команды внедрили AURA. Эти внедрения показали более чем на 90 % меньше инцидентов в продакшене, ускорение циклов релизов на 47 % и возврат 38 % инженерных ресурсов, при этом результаты были независимо подтверждены. Клиенты, такие как Walmart и Keller Williams, также сообщили о значительном росте частоты релизов, покрытии тестами и сокращении времени цикла.

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

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

По мере того как AI‑агенты берут на себя ответственность за создание, запуск и интерпретацию тестов, где люди должны сохранять полномочия принятия решений? Какие типы неопределённости, рисков безопасности или потенциального воздействия на клиентов должны автоматически останавливать релиз или вызывать человеческий обзор?

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

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

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

Вы также работали с Ethical AI Governance Group и рабочей группой World Economic Forum по безопасным системам и технологиям. По мере того как код, генерируемый ИИ, и автономное тестирование становятся всё более тесно связанными, какие стандарты управления потребуются предприятиям, чтобы ускоренное создание программного обеспечения не приводило к новым системным, безопасностным или ответственностным рискам?

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

Спасибо за отличное интервью, читатели, желающие узнать больше, могут посетить Sauce Labs.