Профессор Эран Яхав, сооснователь и соCEO Tabnine – Интервью

Профессор Эран Яхав, сооснователь и соCEO Tabnine, является профессором компьютерных наук в Технионе – Израильском технологическом институте, чья исследовательская деятельность сосредоточена на языках программирования, машинном обучении и программной инженерии, в частности, на синтезе программ и анализе больших объемов кода. Вместе с академической работой он стал сооснователем Tabnine (первоначально Codota), чтобы применить годы исследований к практическим инструментам для разработчиков, помогая пионерам в области кодирования и автоматизации, основанных на ИИ. Его работа соединяет академию и промышленность, с фокусом на том, чтобы сделать код, сгенерированный ИИ, более надежным, безопасным и контекстно-зависимым для реальных корпоративных сред.

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

Вы провели годы, исследуя анализ и синтез программ в Технионе, и ранее работали в IBM Research. Какая проблема в разработке программного обеспечения убедила вас стать сооснователем Tabnine, и как ваша академическая исследовательская деятельность сформировала первоначальную концепцию компании?

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

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

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

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

Tabnine стала пионером в области инструментов кодирования ИИ много лет назад, задолго до того, как генеративный ИИ стал мейнстримом с инструментами вроде моделей OpenAI. Оглядываясь назад, как изменилась роль ИИ в разработке программного обеспечения с тех ранних дней, и какие уроки промышленность извлекла из первого поколения кодирования-копилотов?

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

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

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

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

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

Программные системы – это сложные сети отношений. Одно изменение может повлиять на несколько сервисов, API или компонентов.

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

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

В этом смысле контекст становится следующей границей для корпоративной разработки ИИ.

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

Генерация, дополненная извлечением, – это полезная техника. Она позволяет моделям извлекать соответствующие документы или фрагменты кода при генерации ответа.

Но извлечение само по себе не создает понимание. Оно предоставляет доступ к информации, а не структуру.

Enterprise Context Engine предназначена для дальнейшего развития, создавая структурированное представление программной среды. Она анализирует репозитории, сервисы, зависимости, API и архитектурные отношения и организует их в модель того, как система на самом деле работает.

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

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

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

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

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

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

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

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

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

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

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

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

Доверие – один из наиболее важных факторов корпоративного внедрения ИИ.

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

Решение этой проблемы зависит от двух критических столпов:

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

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

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

Если посмотреть, как эволюционирует корпоративная технология, мы часто видим появление новых слоев инфраструктуры.

Базы данных стали основой для управления данными. Облачные платформы стали основой для запуска приложений в масштабе.

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

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

В этом смысле контекст становится общей основой для корпоративного ИИ.

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

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

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

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

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

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

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

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

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

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

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