44-минутное выступление Бена О’Махони на QCon AI сводится к простой, но неприятно практичной мысли: AI LSP можно улучшать не только заменой модели на более дорогую, но и за счёт данных, которые разработчики уже генерируют в IDE. Для русскоязычных команд это важный сигнал: телеметрия из рабочих сценариев постепенно становится не только инструментом наблюдаемости, но и сырьём для обучения собственных маленьких моделей, которые обходятся дешевле фронтирных API.
О подходе, как пишет InfoQ, рассказал Ben O’Mahony, Principal AI Engineer в Thoughtworks. Его отправная точка понятна почти любому разработчику, который уже пробовал AI-инструменты в редакторе: стандартные language server’ы вроде pyright или rust-analyzer отлично ловят синтаксис, типы и формальные ошибки, но плохо работают с семантическими проблемами. Они не скажут, что название функции давно не соответствует реальному поведению, что обработка ошибок разваливается по краям или что в коде заново изобретают стандартную библиотечную функцию. Именно в этот зазор и заходит AI LSP: не вместо детерминированных проверок, а поверх них, там, где нужны смысл и контекст.
О’Махони описывает собственный AI LSP как проактивный инструмент: сервер анализирует код при сохранении файла, возвращает диагностику прямо в привычном интерфейсе редактора и предлагает варианты исправлений через code actions. Ключевой момент тут не в том, что модель умеет предложить патч, а в том, что разработчик взаимодействует с подсказкой в рабочем ритме, не уходя в чат и не переключаясь в отдельную панель. В его примере система умеет не только подсветить проблему, но и предложить несколько способов исправления, причём сам патч может затрагивать не только место, где показана диагностика, но и другой участок кода. Это уже не линтер с жёсткими правилами, а агентный слой поверх редактора.
Дальше начинается самое интересное. Такой AI LSP дорог в эксплуатации: если отправлять код в большую модель на каждом сохранении, токены начинают сгорать вполне по-взрослому. Но, по словам О’Махони, в процессе использования инструмент сам начинает производить нужные данные. Он нативно инструментировал AI-агента через OpenTelemetry и стал фиксировать не абстрактные метрики вроде «запрос выполнен», а конкретные действия пользователя: принял ли разработчик предложенное исправление, отклонил его или попросил сгенерировать вариант заново. Это и есть те самые неявные метки, которые обычно так трудно и дорого собирать вручную. Вместо команды разметчиков появляется поток живых производственных сигналов из IDE.
По сути, речь о непрерывном data flywheel для разработки. Фронтирная модель сначала выступает дорогим учителем: она генерирует диагностику и варианты исправлений. Пользователь своим поведением даёт слабый, но массовый фидбек. Телеметрия превращает этот фидбек в обучающий датасет, после чего его можно использовать для дистилляции поведения в более компактную модель. В логике О’Махони именно здесь появляется путь к локальным SLM: маленькая модель не обязана быть универсальной и блистать в бенчмарках, ей достаточно хорошо решать узкую задачу внутри редактора, например ранжировать подсказки, предсказывать, какие замечания будут приняты, или дешево отсеивать слабые предложения до вызова более дорогого API.
Для корпоративной разработки здесь сразу несколько прикладных плюсов. Первый очевиден: снижение стоимости. Если часть работы можно переложить на локальную или просто более дешёвую модель, частота обращений к крупным API падает. Второй менее очевиден, но для многих компаний даже важнее: появляется шанс адаптировать поведение модели под реальные инженерные практики конкретной команды, а не жить на дефолтных настройках вендора. Третий плюс касается приватности и контроля. В выступлении нет обещаний про волшебную on-device замену всего стека, но сама идея локального узкоспециализированного слоя выглядит особенно прагматично для организаций, которым некомфортно каждый раз отправлять код наружу ради базовых редакторских подсказок.
Отдельно полезна мысль про UX. О’Махони довольно жёстко формулирует проблему нынешних AI-инструментов для кодинга: если результат работы агента приходит в виде гигантского диффа или большого pull request, это плохой пользовательский опыт. Он предлагает смотреть на «контекст-инжиниринг» шире и думать не только о том, какой контекст подаётся модели, но и о том, в каком виде человек получает результат. AI LSP в этом смысле выигрывает у многих чатовых сценариев: замечание приходит туда, где разработчик и так привык видеть диагностику, а решение можно принять, отклонить или перегенерировать без лишней церемонии. Для команд, которые устали от демонстраций «агент написал 14 тысяч строк, разбирайтесь», это трезвый и вполне инженерный взгляд.
На уровне тренда доклад хорошо попадает в текущее движение рынка: генеративные инструменты для разработки постепенно сдвигаются от вау-эффекта к экономике и измеримости. Мало встроить модель в редактор; нужно понимать, какие подсказки действительно помогают, где модель шумит, в каких языках и типах задач она полезна, и можно ли перенести часть интеллекта ближе к разработчику без постоянной подписки на самый дорогой API. Для российских и русскоязычных команд тут читается особенно ясный сценарий: кто раньше начнёт собирать качественную телеметрию по использованию AI-подсказок, тот раньше получит собственный обучающий контур, а значит и больше свободы в выборе моделей, инфраструктуры и бюджета.
Главный вопрос теперь не в том, заменят ли маленькие модели большие в задачах разработки. Скорее наоборот: насколько быстро команды научатся использовать большие модели как временно дорогих учителей, а OpenTelemetry — как конвейер для сбора поведенческих меток. Если этот паттерн приживётся, AI LSP перестанет быть просто умной надстройкой над редактором и станет точкой, где сходятся наблюдаемость, продуктовая аналитика и прикладное обучение моделей под реальные инженерные привычки.