Разработка собственного AI-ассистента для кода: спринт или марафон? (Рубрика AI)

Недавно у нас прошла конференция Platform Engineering Night, которую открывал Игорь Маслов докладом про "AI и Platform Engineering", основные мысли из которого я уже рассказывал. Но на этой конфе еще был целый ряд выступлений, одно из которых было Дениса Артюшина, который рассказал про то, как мы разрабатываем собственного ассистента Nestor, под которым зонтиком объединяются copilot вещи для SDLC (но первым делом copilot для кода в IDE). Основные мысли выступления были примерно следующими

1. В чем мотивация создания собственного ассистента? Начал Денис с объяснения, а зачем делать своего ассистента, где были несколько основных моментов

• Безопасность решения, что сложно соблюсти при отправке кода внешним вендорам
• Санкционные риски, которые защкаливают в текущих сложных геополитических условиях
• Необходимость интеграции с внутренней инфраструктурой, которую так и так пришлось реализовывать 2. Как подходить к вопросу: как спринтер или как стайер? Сначала Денис рассказал про быстрые эксперименты в режиме спринтеров - так ребята запустили commit-сообщения, где от идеи до готового прототипа прошел один вечер пятницы. Схема была простой: берем diff, добавляем примеры, формируем промт и отдаем в модель. А потом он рассказал, что code completion требует серьезной инфраструктуры с A/B-тестами, анализом поведения пользователей и поиском похожего кода в кодовой базе, то есть тут нужен системный и размеренный подход 3. Что умеет Nestor? Основные фичи сейчас достаточно классические
• Автодополнение кода
• Чат с поиском по внутренней документации
• Генерация commit-сообщений
• Прототип редактирования кода
• Генерация тестов (сейчас в разработке) 4. Какие метрики использования у ассистента? Они уже впечатляют: WAU: 5k, MAU: 9.5k. В некоторых профессиях проникновение превысило 60%, а acceptance rate поднялся до 30% на Go (пора переходить на go, ведь ассистенты на нем лучше всего ассистируют 😉) 5. Как сделали поиск по документации? На самом деле про поиск можно посмотреть в докладе Егора Прохоренко, про который я уже рассказывал. Но в Nestor пошли примерно так: структурированная документация → краткие описания → эмбеддинги → поисковая база. Также использовали русскоязычную модель TP Pro для лучшего качества ответов. 6. Как решали проблему масштабирования UI в плагине для IDE? Первоначальные чаты на TypeScript/CSS и Swing оказались немасштабируемыми. Перешли на React и Compose позволил легко добавлять новую функциональность. 7. Как балансировать тем в команде разработки? Спринты помогают тестировать гипотезы и поддерживать мотивацию олимпиадников в команде (значимая часть команды Nestor - это олимпиадники по программированию). А вот марафоны нужны для создания качественного продукта. 8. На какие метрики качества обращают внимание? Метрики есть разные
• Adoption Nestor
• Acceptance rate (очищенный от мусорных показов)
• Внутренние бенчмарки для поиска по документации
• Пользовательский фидбек и предложения по улучшению. 9. Какие планы по развитию? Планов много, но сейчас они видятся такими
• Полноценное редактирование кода
• Генерация тестов
• Платформа агентов для всех отделов компании
• Интеграция в другие продукты экосистемы (платформа для работы с данными Helicopter, observability платформа Sage)

Если подводить итоги и отвечать на вопрос в названии доклада, то создание собственного ассистента требует сочетания быстрых экспериментов (спринты) для проверки гипотез и системной работы (марафоны) для качественного продукта.

#AI #Software #Engineering #Architecture #Agents