Али-Реза Адл-Табатабай, Основатель и Генеральный Директор 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 начинают накапливаться. Циклы проверки сжимаются, потому что никто не имеет времени глубоко изучить каждое изменение.

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

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

Gitar использует агентов ИИ для обработки проверок кода, тестирования и рабочих процессов непрерывной интеграции (CI). Как эти агенты фундаментально отличаются от традиционных инструментов статического анализа и правилных конвейеров?

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

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

Это почему разговор смещается от “есть ли у нас агенты” к “какая работа может быть обработана надежно”.

Доверие является значительным барьером для автоматизации в разработке программного обеспечения. Как Gitar обеспечивает, чтобы его процесс проверки был достаточно надежным для команд, чтобы полагаться на него?

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

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

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

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

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

Gitar сводит эту работу к минимуму. Команды платформ могут писать пользовательские проверки, используя естественно-языковые запросы, которые позволяют им проверять вещи, которые являются трудными или невозможными с помощью традиционного анализа программ, например, флагирование пользовательских строк, которые являются двусмысленными для перевода, или проверка обновлений файлов AGENTS.md. Они также могут автоматизировать пользовательские рабочие процессы поверх запросов на вытягивание: связывание PR с проблемами Jira, открытие последующих тикетов для нерешенных комментариев к проверке, автоматическое повторное выполнение нестабильных тестов или добавление пользовательских списков дел к сводкам PR.

Наиболее интересные случаи использования, как правило, являются теми, которых мы не предвидели. Команды знают свои кодовые базы и болевые точки лучше, чем любой поставщик, поэтому, когда вы даете им примитив, который превращает “мы хотим, чтобы 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.