Алі-Реза Адл-Табатабаї, засновник і генеральний директор Gitar – Серія інтерв’ю

Алі-Реза Адл-Табатабаї, засновник і генеральний директор Gitar, є ветераном інженерного лідерства, чиє кар’єра охоплює деякі з найбільш впливових технологічних компаній у Кремнієвій долині, включаючи Uber, Google (GOOGL ), Facebook (META ), Intel (INTC ), AMD та IBM. До заснування Gitar у 2023 році він обіймав посаду старшого директора інженерії в Uber, де допоміг очолити ініціативи компанії щодо платформи розробників, після попередніх керівних ролей у Google, де він наглядав за інженерією сайту для продуктів, таких як Комунікації, Фото, Соціальні мережі, Хмарні обчислення та технічна інфраструктура.

Раніше в своїй кар’єрі він працював над технологіями компіляторів, віртуальних машин, паралельних обчислювальних систем та апаратної оптимізації в Intel Labs і команді HipHop VM у Facebook, а також викладав курси з проектування компіляторів у Стенфордському університеті. Його багаторічна робота у сфері мов програмування, надійності інфраструктури, інструментів розробників та архітектури великомасштабних систем поставила його на чільне місце в галузі штучного інтелекту у сфері програмної інженерії.

Gitar зосереджується на зростаючій проблемі, що виникає з поширенням розробки програмного забезпечення з використанням штучного інтелекту: перевірка та забезпечення безпеки величезного обсягу машинного коду, який зараз надходить до корпоративних систем. Платформа використовує агентів штучного інтелекту для автоматизації перевірки коду, дослідження відмов у конвеєрах CI/CD, виявлення помилок та уразливостей, рекомендацій щодо виправлень та безпосередньої інтеграції до існуючих інженерних робочих процесів за допомогою інструментів, таких як GitHub, GitLab (GTLB ), Jenkins, Jira та Slack. Замість того, щоб конкурувати лише у сфері генерації коду штучним інтелектом, компанія позиціонує себе навколо того, що вона описує як “агентські ворота якості”, допомагаючи інженерним командам підтримувати надійність, безпеку та оперативний нагляд під час того, як розробка програмного забезпечення все більше переходить до автономної та штучно інтелектуальної кодової роботи.

Ви очолювали інженерію в Uber, Google та Intel Labs, працюючи над великомасштабними платформами розробників та інфраструктурою. Які конкретні досвіди з цього шляху привели вас до заснування Gitar, і чому ви зосередилися на перевірці коду замість генерації коду?

Під час роботи в Uber, Google, Facebook та Intel Labs я працював над платформами розробників у дуже різних масштабах, і одне й те саме урок повторювався: досвід розробника є конкурентною перевагою. Великі інструменти приваблюють і утримують найкращих інженерів та дозволяють компаніям рухатися швидко. Розробники хочуть швидкі, безшумні інструменти, які тримають їх у потоці та автоматизують рутинну роботу. Але інструменти розробників дуже фрагментовані, і більшість компаній витрачають величезні інженерні ресурси просто на створення цілісного досвіду. Я бачив на власні очі, скільки є можливостей для поліпшення цього.

Штучний інтелект змінює ситуацію, роблячи можливим автоматизацію набагато більшої частини робочого процесу розробника, ніж раніше. Генерація коду вже досить добре покрита, але це тільки змістило вузьке місце далі за потоком, до перевірки, рефакторингу та підтримки коду, який ми зараз виробляємо в безпрецедентному обсязі. Саме там зосереджена увага Gitar. Коли штучний інтелект пише більше коду, дефіцитним ресурсом не є генерація; це довіра, правильність та підтримка того, що відправляється. Перевірка коду – це частина робочого процесу, яка визначає, чи дійсно генерація коду штучним інтелектом робить його до виробництва безпечно, і це складша, більш цінна проблема для вирішення.

З поширенням генерації коду штучним інтелектом багато команд зараз стикаються з тим, що деякі називають “перевантаженням коду”. Наскільки серйозна ця проблема всередині корпорацій сьогодні, і де команди стикаються з найбільшими труднощами?

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

Кожна зміна все ще повинна пройти перевірку. Перевірка коду. CI. Перевірки безпеки. Ухвалення. Ніщо з цього не зникає просто тому, що код генерується швидше. Що раніше було керованим потоком, перетворилося на затор. Команди не блокуються на ідеях або реалізації більше. Вони блокуються на довірі. Чи можна це відправити? Чи це безпечно? Чи це зламало щось тонке?

Саме там зараз знаходиться тертя. Не у створенні, а у тому, щоб код пройшов фінішну лінію без введення ризику.

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

Бо система вниз по потоку від генерації коду не еволюціонувала з тією ж швидкістю. Коли вихід збільшується, все вниз по потоку стає напруженим. Запити на прийняття стають більші та частішими. Відмови CI починають накопичуватися. Цикли перевірки стають стиснутими, тому що ніхто не має часу глибоко розглянути кожну зміну.

Якість починає падати, не тому, що інженери не піклуються, а тому, що обсяг змушує до компромісів. Команди платформи беруть на себе більшу частку навантаження, обробляють проблеми конвеєра, діагностують відмови та намагаються тримати все в русі. Старші інженери виступають у ролі координаторів, збираючи логи, діагностуючи проблеми та вирішуючи, що безпечно для злиття.

Команди стикаються з вибором, який не працює ні в одному випадку. Швидко пропустити код і пізніше розібратися з регресіями, або сповільнитися і захистити якість, але прийняти, що швидкість падає. Це напруження зараз проявляється по всім інженерним організаціям.

Gitar використовує агентів штучного інтелекту для обробки перевірок коду, тестування та робочих процесів неперервної інтеграції (CI). Як ці агенти фундаментально відрізняються від традиційних статичних інструментів аналізу та правилних конвеєрів?

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

Більшість систем не відповідають цьому стандарту. Вони генерують вивід, але не керують виконанням. Коли ці інструменти розміщуються у реальних робочих процесах, пробіли швидко з’являються. Вони не зменшують складність. У багатьох випадках вони додають ще один шар, який хтось повинен керувати.

Це чому розмова переходить від “чи маємо ми агентів” до “яку роботу можна фактично обробляти надійно”.

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

Шаблон, який працює, простий. Розбити роботу на менші кроки. Визначити чіткі межі. Перевірити вивід безперервно. Залишити людей залученими там, де рішення несуть ризик.

Агенти можуть переглянути код і виявити проблеми, які легко пропустити у масштабі. Вони можуть проаналізувати відмови CI, згрупувати пов’язані помилки та вказати на ймовірну причину. Вони можуть запропонувати виправлення та в деяких випадках застосувати їх у контрольованому порядку.

Це зменшує кількість ручної тріажі, яку інженери повинні виконувати. Це не видаляє інженерів з циклу, а змінює місце, де вони витрачають час. Більшість систем працюють з контрольними точками, а не повною незалежністю.

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

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

Gitar згортає цю роботу. Команди платформи можуть написати спеціальні перевірки, використовуючи промови природної мови, які дозволяють їм перевірити речі, які є важкими або неможливими з традиційним програмним аналізом, наприклад, прапорець рядків, що є двозначними для перекладу, або перевірку оновлень файлів AGENTS.md. Вони також можуть автоматизувати спеціальні робочі процеси над запитами на прийняття: посилання запитів на прийняття до питань Jira, відкриття наступних квитків для незакритих коментарів до перегляду, автоматичне повторне виконання нестабільних тестів або додання спеціальних списків завдань до підсумків запитів на прийняття.

Найцікавіші випадки використання tend до тих, яких ми не передбачали. Команди знають свої бази коду та болючі місця краще, ніж будь-який постачальник, тому коли ви даєте їм примітив, який перетворює “ми бажаємо, щоб CI просто перевірив X” на 10-рядковий запит, вони негайно починають автоматизувати речі, які ми б ніколи не побудували за замовчуванням. Це саме те, чого ми хочемо.

Сучасні інженерні команди залежать від складного стеку інструментів, таких як GitHub, GitLab та Jira. Наскільки важливо для Gitar інтегруватися до існуючих робочих процесів, а не намагатися їх замінити?

Прийняття залежить від зустрічі з розробниками там, де вони вже знаходяться. Інженери не хочуть ще одну поверхню для вивчення, ще одну панель керування для перевірки або більше контекстного перемикання між інструментами. Вони хочуть, щоб їхні існуючі робочі процеси стали швидшими і тихішими. Тому глибока інтеграція з GitHub, GitLab, Jira та рештою стеку не є приємністю для нас; це вся стратегія.

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

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

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

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

Перший рівень – виявлення. Команди будують довіру до того, що агенти знаходять реальні проблеми з низьким рівнем помилкових позитивних результатів. Як тільки ця довіра встановлена, вони дозволяють штучному інтелекту автоматично блокувати PR, коли він знаходить критичні проблеми.

Другий рівень – виправлення. Штучний інтелект не просто прапорить проблеми, а виправляє їх, розблокуючи PR і роблячи CI зеленим без людського втручання. Довіра тут означає, що агент може вирішувати проблеми та відмови CI точно, без порушення чогось.

Третій рівень – схвалення. Як тільки команди бачать, що агенти надійно роблять PR зеленим, вони дозволяють штучному інтелекту схвалювати PR за правилами, які вони визначають. Надання організаціям явного контролю над умовами для автоматичного схвалення робить цей крок безпечним, а не безрозсудним.

Четвертий рівень – злиття. Штучний інтелект висаджує зміну, знову ж таки під умовами, з якими команда комфортна. Цей крок має свій власний бар’єр: агент повинен вирішувати конфлікти злиття точно, без введення регресій або порушення основної гілки. Це має значення більше, ніж люди розуміють, тому що частота конфліктів зростає з пропускною здатністю коміту, а пропускна здатність вибухає, оскільки штучний інтелект генерує більше коду. Великі монорепозиторії вже відчувають це; всі інші ось-ось відчують.

Зсув до штучного інтелекту як до замовчуваного рецензента не є одним стрибком довіри. Це сходи, і організації піднімаються по них крок за кроком, оскільки докази накопичуються.

Як ви бачите еволюцію ролі старших інженерів протягом наступних кількох років, оскільки штучний інтелект бере на себе більше кодової роботи?

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

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

Gitar нещодавно підняв 9 мільйонів доларів, щоб масштабувати платформу. Які ваші головні пріоритети для цього капіталу, і що таке успіх протягом наступних 12-18 місяців?

Капітал спрямовується на два пріоритети. Перший – рух до ринку: ми масштабуємо наш рух підприємства та інвестуємо в осведомленість розробників, так що команди, які бенефіцитують від Gitar, дійсно знають, що ми існуємо. Другий – продукт: ми продовжимо будувати до нашого бачення повністю автономної перевірки коду та якості, що означає глибші можливості агентів, ширше покриття робочих процесів та тіснішу інтеграцію з інструментами, які розробники вже використовують.

Успіх протягом наступних 12-18 місяців виглядає як значна база корпоративних клієнтів, які запускають Gitar по всьому своєму коду, спільнота розробників, яка розпізнає нас як замовчуваний вибір для перевірки коду, керованої штучним інтелектом, і чіткі докази того, що наші агенти роблять більше роботи перевірки, виправлення та злиття автономно з часом. Якщо ми на правильному шляху, розмова через рік не полягає в тому, чи може штучний інтелект перевірити код, а в тому, скільки частини процесу перевірки команда передала агентам. Дякую за велике інтерв’ю, читачам, які бажають дізнатися більше, слід відвідати Gitar.