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

Prince Kohli, президент і генеральний директор Sauce Labs, є досвідченим технологічним керівником з широким досвідом у галузях штучного інтелекту, корпоративного програмного забезпечення, хмарних обчислень, автоматизації, мереж та кібербезпеки. До приєднання до Sauce Labs у лютому 2025 року він понад шість років працював головним технічним директором Automation Anywhere, де допомагав розвивати технології автоматизації, керовані ШІ, для великих підприємств. Раніше Кохлі був старшим віце-президентом інженерії в ThoughtSpot і займав провідні керівні посади в Ericsson, включаючи керування глобальними R&D‑організаціями, що налічували понад 10 000 інженерів. Він також майже десять років працював у Citrix, керуючи платформою, хмарними мережами, інженерією та операціями. На початку кар’єри він співзаснував компанію з безпеки додатків Teros і працював технічним лідером у SGI. Поряд із виконавчими ролями Кохлі вносив внесок у ініціативи з управління технологіями через Ethical AI Governance Group і раніше брав участь у робочій групі World Economic Forum «Safe Systems and Technologies».

Sauce Labs — це компанія з забезпечення якості програмного забезпечення та безперервного тестування, яка надає підприємствам інфраструктуру та інструменти для тестування веб‑ і мобільних застосунків у різних браузерах, операційних системах, віртуальних середовищах та на реальних пристроях. Платформа підтримує можливості, включаючи автоматизоване та ручне тестування, візуальне тестування, розповсюдження мобільних додатків, звітування про помилки та створення тестів і аналітику на базі ШІ, інтегруючись із поширеними процесами безперервної інтеграції та доставки. Sauce Labs все більше позиціонує свою технологію навколо AURA — платформи AI‑Unified Release Assurance, яка використовує агентів ШІ для генерації, виконання та аналізу тестів, зберігаючи людський контроль протягом усього процесу випуску ПЗ. Компанія заявляє, що її інфраструктура підтримала понад 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 %. Що заважає системам валідації йти в ногу, і де зазвичай виникає найбільша вузька ділянка в життєвому циклі розробки ПЗ?

Генерація коду випередила створення, підтримку та аналіз тестів. Найбільші вузькі місця зазвичай з’являються після написання коду, коли його потрібно перевірити в контексті шляху користувача. Це часто дуже складно, іноді складніше, ніж сам код, оскільки треба враховувати сквозні шляхи, що охоплюють функції та об’єкти коду, причому, здавалося б, незначні зміни в семантиці в одному місці створюють великі downstream‑ефекти. Авторство цих тестів таким чином, щоб вони правильно і повністю відображали намір застосунку, традиційно майже неможливе і вимагає значних ручних зусиль і підтримки. Більше того, після запуску тестів і виявлення збою команди повинні розібратись і діагностувати проблему, включаючи рішення, чи походить збій від продукту чи від застарілого тесту. Ця робота все ще сильно залежить від ручного перегляду та інженерного контексту.

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

Організації приймають ризик, тому що цілі випуску пов’язані з негайними зобов’язаннями перед клієнтами, доходами та продуктом, а витрати на дефекти часто проявляються пізніше в кількох командах. Якість стає бізнес‑пріоритетом лише тоді, коли керівники вимірюють інциденти в продакшн, вплив на клієнтів, безпекові ризики, витрати на переробку та затримані доходи разом зі швидкістю випуску.

Sauce Labs позиціонує AURA як замкнуту платформу, яка створює, виконує та аналізує тести, навчаючись на кожному випуску. Чим це технічно та операційно відрізняється від AI‑асистованого генерування тестів, самовідновлюваних тестових скриптів або інших інструментів автоматизації, які вже використовуються інженерними командами?

Більшість інструментів AI‑тестування вирішують конкретне завдання, наприклад генерацію тесту або виправлення поломленого локатора. AURA з’єднує весь процес, розуміючи намір застосунку, створюючи та виконуючи тести, аналізуючи збої та передаючи поведінку продакшну назад у розробку. Вона може автоматично обробляти багато змін і залучати людину, коли значення застосунку або очікувана поведінка змінюються. Крім того, тести, які вона генерує, стабільні, тобто їх не потрібно модифікувати, коли відбуваються зміни, що не впливають на семантику, у застосунках, браузерах, пристроях тощо. Нарешті, оскільки AURA вбудовує у себе хмару виконання тестів, вона може звільнити розробника або команду інженерії якості від усього процесу.

AURA розроблена для перевірки ПЗ відповідно до “бізнес‑наміру”. Як цей намір визначається і перетворюється у тестовані вимоги, хто відповідає за їх затвердження, і як платформа працює з вимогами, які є неоднозначними, неповними або відкритими до інтерпретації?

Бізнес‑намір походить від вимог до продукту, критеріїв прийняття, бізнес‑правил, шляхів користувачів та того, як клієнти фактично використовують застосунок. Лідери продукту визначають очікуваний результат, а інженерні та якісні команди перетворюють цей результат у поведінку, яку система може перевірити. Коли вимоги неповні або неоднозначні, AURA має виявляти невизначеність і запитувати людське схвалення перед зміною очікуваного результату.

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

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

Дослідження виявило, що 64 % організацій збільшили кількість персоналу з контролю якості, хоча інциденти продовжували зростати. Чому підприємства не можуть усунути розрив у верифікації просто наймаючи більше тестувальників, і як ви очікуєте, що зміняться обов’язки розробників, інженерів якості та команд з надійності сайтів, коли тестування стане більш автономним?

ШІ може збільшити обсяг коду значно швидше, ніж компанія може збільшити кількість тестувальників, а додавання людей створює більше передач і координації. Розробникам доведеться чітко визначати намір, інженери якості зосередяться більше на ризиках, покритті та управлінні, а команди з надійності сайтів передаватимуть поведінку продакшн назад у процес випуску. Агентам вдається виконувати повторювані запуски та аналіз у масштабах, які вимагає ця нова модель розробки.

Коли агенти ШІ беруть на себе відповідальність за створення, запуск та інтерпретацію тестів, де люди повинні залишатися в ролі прийняття рішень? Які типи невизначеності, ризику безпеки або потенційного впливу на клієнтів мають автоматично зупиняти випуск або викликати людський перегляд?

Люди повинні зберігати остаточну владу над рішеннями про випуск, особливо коли мова йде про судження, вплив на клієнтів або бізнес‑ризик. Агенти ШІ можуть автоматизувати нудні, повторювані та чітко визначені тестові завдання, проте люди мають схвалювати випуски в продакшн, коли код або результати тестів не можуть бути повністю зрозумілі, пояснені або відтворені. Перегляд також має бути обов’язковим, коли вимоги неясні, можливі уразливості безпеки, сторонні компоненти не пройшли належну перевірку, або збої можуть вплинути на доходи, конфіденційні дані, досвід клієнтів чи критичні операції.

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

Ми бачили випадки у наших клієнтів, коли тест, який здавався “нестабільним”, проходив нерівномірно без очевидного патерну збою, часто ігнорувався. Однак добре керовані процеси у деяких з цих клієнтів вимагали належної ретельності, і за допомогою нашої платформи вони змогли простежити збій до тонкого, але критичного дефекту, пов’язаного з таймінгом, який міг би призвести до серйозних наслідків при випуску, з дуже високими витратами.

Ви також працювали з Ethical AI Governance Group та робочою групою World Economic Forum «Safe Systems and Technologies». Оскільки код, згенерований ШІ, і автономне тестування стають все більш пов’язаними, які стандарти управління потрібні підприємствам, щоб швидке створення ПЗ не створювало нових системних, безпекових або відповідальності ризиків?

Чим швидше ШІ може створювати ПЗ, тим сильнішою має стати шар верифікації та управління. Цей шар має багато складових. Підприємства повинні мати чіткі межі щодо того, що агенти можуть вирішувати автономно, з вимогою людського перегляду, коли існує невизначеність щодо бізнес‑наміру, безпеки, відповідності або суттєвих семантичних змін. Вони також потребують простежуваності того, що саме змінив агент, чому він це зробив і які докази підтримували рішення про випуск. Зрештою, управління має вимірюватися якістю та передбачуваністю того, що потрапляє у продакшн, наприклад, шляхом спеціального відстеження, як часто згенерований код спричиняє інциденти протягом 90 днів після випуску, а не тим, наскільки швидше ШІ може генерувати код.

Дякуємо за чудове інтерв’ю, читачі, які бажають дізнатися більше, повинні відвідати Sauce Labs.