Привет, Хабр. Расскажу, как я собрал ИИ-Автопилот — замкнутый цикл разработки, где задача входит тикетом в YouTrack, а выходит GUI-проверенным исправлением в продукте. Агент разбирается в задаче, правит C+±код, собирает, идёт в живой интерфейс нашего геофизического приложения, проверяет там результат — и закрывает тикет ответом человеку в YouTrack. Дальше расскажу, как оно выросло и где людям всё ещё есть чем заняться.
А началось всё с того, что я поймал себя на довольно странной работе. Коллеги присылают описание бага или новой фичи. Я копирую его в Claude Code, иногда целиком вставляю задачу из YouTrack, жду, а потом копирую готовый ответ обратно. Агент к тому моменту уже прилично разбирался в нашем C++: находил нужное место, вносил правки, билдил проект.
От моей многолетней программерской квалификации в этом цикле не осталось практически ничего. Требовалось одно: самому запустить приложение, потыкать GUI, сделать скриншоты и убедиться, что ответ модели адекватен.
Работа стала эффективнее. Ощущения от неё — не очень. Я стал копипастером и специально обученным кнопкодавом.
Тогда у меня впервые появился неприятный, но резонный вопрос: а зачем здесь я?
Ответ пока ещё был — хоть и довольно слабый. Между «код собрался» и «задачу можно отдать пользователю» стоял интерфейс. А у нас большое десктопное геофизическое приложение: около трёх миллионов строк C/C++, Qt-виджеты вперемешку с QML-сценами, сейсмические разрезы, поверх которых пользователь рисует горизонты и разломы, 3D view на Qt3D — там попадание мышью в объект считает сам движок сцены. Модель могла написать правильный код и всё равно сломать реальный пользовательский маршрут.
Значит, до полного автомата не хватало сущей мелочи: научить агента видеть собранное приложение и самому в нём действовать. Всего-то дать ему глазки и ручки.
«Глазки» и «ручки»
Начал я с того, что написал на Python самый простой GUI-тестер. Он был тогда настолько мал, что и названия ему достались младенческие.
У агента появились глазки: сделать скриншот и посмотреть, что сейчас открыто. И ручки: навести мышь, кликнуть, перетащить объект, набрать текст. Ему давалась цель вроде «открой этот мастер, поменяй параметр, запусти расчёт и приложи кадр результата». Если он не понимал, куда идти дальше, мог посмотреть исходники формы, найти подпись кнопки или objectName, снова сделать скриншот и продолжить.
На удивление, это сразу заработало. Обычный Qt-диалог, риббон, дерево, галочка, таблица — со всем этим он справлялся. Агент находил кнопку, нажимал её, видел следующий экран. Несколько простых GUI-доказательств мы получили почти без специальной инфраструктуры.
И тут вопрос «а зачем здесь я?» всплыл второй раз — уже по полной. До этого я хотя бы сам тыкал GUI. А теперь, на свою голову, я научил агента и этому.
Решили идти до победного. После кнопок и комбобоксов взялись за графику: 2D-сцены на QML, а там и 3D. Вот тут простота и закончилась.
Скриншот говорит модели, что на экране есть поверхность. Но он не говорит, какой это объект в C++, где у него ID и к какой процедуре он относится. Клик по координатам работает, пока окно не сдвинулось, масштаб не изменился, а элемент не оказался внутри области рисования. QWidget::grab() хорошо снимает обычные виджеты, но может не увидеть содержимое QQuickView или поверхности OpenGL, на которой рисует Qt3D. Перетаскивание в дереве и выбор объекта в 3D требуют совсем разных механизмов, хотя для человека оба выглядят как «взял и перетащил».
Можно было бесконечно улучшать распознавание пикселей. Но я пошёл в другую сторону. Если агент имеет доступ к нашему коду, зачем заставлять его каждый раз угадывать, какая картинка соответствует какому объекту? У нас уже был внутрипроцессный тестовый API на C++ — правда, умел он тогда немного: прогнать записанный заранее сценарий. Вот из него и вырос Test Engine — движок, которым можно рулить уже запущенной программой. Назовём его Управляла.
Здесь мы приняли решение, которое многое определило. Можно было пойти привычным путём: агент пишет скрипт, скрипт прогоняется, на выходе отчёт и скриншоты. Так работает большинство тестовых фреймворков, и так было бы проще. Но простота — не наш путь.
Мы сделали наоборот — живое управление. Приложение поднимается один раз и живёт. Внутри него сидит C+±движок, снаружи Python-клиент, между ними постоянное соединение через named pipe. Агент не запускает сценарий, он работает в открытой программе: открыл окно — посмотрел, что получилось, подумал, куда нажать дальше, нажал, снова посмотрел. Ровно как человек, только читая при этом исходники.
Разница выясняется на первом же нестандартном случае. Скажем, посреди сценария выскочило неожиданное окно. Записанный скрипт на этом и умирает: он не знает, что это такое, и следующий его шаг уходит в никуда. А живой агент окно видит, читает заголовок, решает, что это и надо ли закрывать, и идёт дальше. Прогон перестал быть одноразовым: между шагами приложение не перезапускается, состояние сохраняется, и можно вернуться на шаг назад и попробовать иначе.
Записанные макросы при этом никуда не делись. Живой тестировщик по-прежнему проходит сценарий руками, а программа его запоминает — обычная запись макроса: клики, ввод в поля, выбор пунктов меню и списков, раскрытие веток в дереве объектов, зум колесом, перетаскивание мышью. Потом всё это воспроизводится. Агент тоже умеет такие сценарии писать и править. Просто теперь есть и второй режим, где никакого сценария заранее нет.
Операции в этом API живут очень разные: от «нажми кнопку с таким текстом» до «дай мне дерево объектов моделью, а не картинкой», «сними именно этот вид», «подставь ответ в нативный файловый диалог». Глазки и ручки остались, просто ручки перестали быть координатами мыши, а глазки — снимком рабочего стола.
Отдельная радость — всё это крутится на Windows в свёрнутом RDP-сеансе. То есть рабочего стола, строго говоря, в этот момент нет. Половина обычных способов потыкать интерфейс там просто не работает: нет фокуса, нет настоящего курсора, скриншот рабочего стола отдаёт чёрный прямоугольник. Каждый такой случай мы разбирали отдельно, и для некоторых пришлось придумывать довольно неочевидные обходы. Зато теперь машина может быть заперта в углу серверной без единого подключённого монитора — и проверка идёт.
Test Engine (Управляла): движок, который рос на боевых задачах
Заранее предусмотреть в тестовом движке все ручки, которые понадобятся агенту, мы не могли. Продукт большой, сложный, графический — какие именно органы управления потребуются, заранее не знает никто. Попытка расписать всё наперёд была бы надёжным способом потратить полгода и всё равно забыть нужную кнопку.
Поэтому мы пошли от обратного: я запускал агента на настоящей задаче. Упёрся, скажем, в отсутствующий способ выбрать объект, открыть всплывающее меню или получить кадр 3D-вида — значит, у Управлялы не хватает ручки. Добавляли, закрепляли смоук-тестом и возвращались к той же задаче.
Первое время это случалось буквально на каждой задаче — движок-то был почти пустой. Правило было простое: задачу не сдаём, пока решатель не пройдёт её целиком и не перестанет спотыкаться о нехватку инфраструктуры. Наслоения и дубли, конечно, лезли: ручки, добавленные в разные дни под похожие нужды, приходилось периодически пересматривать и сводить в одну общую.
Позже, когда весь конвейер уже работал, а Управляла более-менее устоялся, мы перестали чинить каждый затык с наскока. Теперь агенты складывают повторяющиеся жалобы в общую очередь — Infra Feedback, по-нашему Доработница. Раз в день-два отдельный агент её разгребает: смотрит, где у разных жалоб общая причина, и предлагает правки покрупнее — так их выходит меньше, чем самих жалоб. Дальше смотрю я и вполне могу сказать: нет, это костыль под один случай.
Цифры такие. В середине мая Управляла занимал 2 899 строк C++ и отдавал наружу 37 методов. К концу июля — 13 836 строк и 120 методов, почти девяносто ревизий и два десятка разных задач в истории компонента.
Сам по себе рост ничего не доказывает, но объём работы за ним виден неплохо. Каждая ручка появилась потому, что на ней однажды застряла живая задача.
А из тех же затыков выросло и умение честно сказать «не могу». Не хватает ручки, нет подходящих данных, не получается снять нужный кадр — проверка останавливается, и задача ждёт человека. Поначалу такие остановки меня злили: код-то готов, а дело стоит. Теперь считаю их лучшим, что в конвейере есть. Бодрое «готово» без доказательства обходится как минимум в один возврат на доделку от пользователя (реопен). Да и вообще, вовремя сказать «не могу» — недооценённое умение. В агенте оно ценно не меньше, чем в человеке: всяко лучше, чем уверенно придумывать глупости.
Issue Understand (Понимала): сначала тикет надо понять
Боевой тикет редко похож на хорошее техническое задание. В нём бывает двадцатисекундное видео без комментариев, ZIP с проектом, скриншот, S3-ссылка и фраза «вот здесь иногда мигает». Человек быстро достраивает контекст. Агент без специальных инструментов либо теряет половину входных данных, либо начинает очень уверенно додумывать.
Тут выяснилась мелочь, без которой всё остальное не работает: прежде чем чинить тикет, его неплохо бы понять.
Так появился Понимала. Он читает описание и всю переписку в тикете, ходит по связанным задачам, находит опорные места в коде, забирает вложения, умеет скачать из S3 или по разрешённой ссылке фикстуру — проект или данные, на которых баг воспроизводится, — и распаковать архив в каталог задачи. На каждый большой файл есть лимит и опись содержимого: вложения приходят и неожиданно увесистые.
История SVN тоже стала частью контекста, а не только местом финального коммита. Был случай, когда пять багов выглядели пятью разными поломками, пока история ревизий не показала их общий источник — одну необязательную косметическую правку. Правильным решением оказалось откатить всё: и её саму, и пять заплаток поверх. А не класть сверху шестую.
Видео мы тоже не отправляем модели целиком. Сначала ffprobe записывает длительность, размер и кодек. Потом первый проход снимает редкую раскадровку — примерно кадр в секунду, а для длинных записей и реже, чтобы уложиться в шесть десятков кадров. Если между двумя соседними кадрами явно что-то произошло, но непонятно что, агент просит сгустить именно этот отрезок. Потом ещё раз. И ещё, пока не разберёт, что там случилось.
Получается такой поиск в глубину по времени. Причём агенту важны не только отдельные моменты, но и порядок: что происходило до, что после, и как связаны события в разных концах записи. А иногда из сорокасекундной записи для диагноза хватает двух кадров — и платить токенами за остальные тридцать восемь секунд совершенно незачем.
Бывает, что итог разбора не «сразу чинить», а «сначала разделить». Если тикет состоит из нескольких частей и каждую пользователь может проверить отдельно, Понимала заводит в YouTrack связанные подзадачи и выставляет порядок. Попросить о разбиении может и человек, механизм тот же. Критерий не размер, а раздельная проверяемость: неделимая фича едет целиком, сколько бы файлов она ни задела.
Понимала ничего не чинит. Его задача скромнее, но не менее важная: собрать из бытового сообщения пользователя всё, с чем уже можно идти разбираться, — видео, данные, историю и настоящие названия элементов GUI.
Solver (Решала): скрипты стали конвейером
Сначала всё это жило отдельными кусками. Я запускал батники по очереди: сперва Понимала, потом правка кода, потом сборка, потом GUI-проверка. Копипастером я на этом этапе быть перестал — остался кнопкодавом-запускателем. Прогресс, конечно, сомнительный.
Так что я взял и сцепил всё это в одну цепочку. YouTrack — вход и место для вопросов. Понимала собирает контекст. Claude Code разбирает C++, планирует и пишет. Отдельное ревью читает дифф, дальше сборка. Испытала, он же GUI-пилот с глазками и ручками, идёт в живую программу, а GUI-ревью пытается его же скриншоты опровергнуть. В конце коммит и ответ человеку в YouTrack.
Этот конвейер целиком мы назвали «Решала». Не какая-нибудь «агентная платформа автономного жизненного цикла», а просто Решала. Получил задачу — реши.
И каждый блок этого конвейера — не один большой промпт. Внутри эстафета субагентов: только у правки кода их около десятка, каждый со своей узкой задачей и результатом предыдущего. Когда что-то ломается, видно, на каком шаге, а не «модель почему-то не справилась».
Не все стадии на этой схеме — ИИ. Скачать вложения, собрать проект, сделать коммит — обычный код: он либо отработал, либо упал, и от ещё одного мудрого промпта умнее не станет. Модель нужна там, где надо разобраться, повыбирать и посомневаться. А там, где сомневаться уже нельзя, стоит обычная проверка и просто не пускает дальше.
Отдельно меня повеселило, во что превратился тот самый «простейший механизм на Python», с которого мы начинали, — в нём поначалу были только глазки и ручки. Теперь вместе со скриптами и смоук-тестами там набралось около 110 тысяч строк, и ещё почти 8 тысяч — на одни только промпты ролей. Конечно, в эпоху ИИ количество строк часто говорит скорее о глупости инженера, чем о сложности задачи. Но если предположить, что инженер не совсем дурак, то кое-что эти цифры всё же показывают: маленький GUI-тестер незаметно вырос во взрослый проект.
Людей мы из цикла тоже не выкинули. Упёрлась задача в продуктовое решение — система идёт с узким вопросом к тому, кто за эту функцию отвечает. И принимает работу всё равно человек: репортёр или тестер. Мы автоматизировали инженерную середину, а не право решать, каким быть продукту.
Auditor (Проверяла): решать стали быстро, но реопенов стало больше
Первые недели выглядели отлично: задач закрывалось много, старый бэклог таял. Но потом я посмотрел на реопены — задачи, которые репортёр вернул на доделку.
Раньше их было около 11%. После запуска Решалы в отдельные недели — за 20%.
Причины были предельно банальные. Где-то агент не прошёл настоящий путь пользователя. Где-то ответил шире, чем доказали скриншоты. А где-то задачу вернули из-за мелочи, которую торопливый решатель счёл несущественной. Мне это очень не понравилось: выходило, что я разогнал поток, а вместе с ним и процент переделок.
Так появился Проверяла — второй независимый проход после результата Решалы. Он заново читает задачу, дифф, доказательство и ответ и ищет, где диагноз неверен, где утверждение не доказано, где забыли живой путь пользователя. Причём не только читает: Проверяла работает на отдельной машине, со своим запущенным приложением, и вполне может пойти в живой GUI и перепроверить чужой скриншот руками. Нашёл проблему — либо доделывает сам, либо возвращает работу Решале.
Сначала аудит доверили Claude — той же модели, что и у Решалы. Дёшево, быстро и, как выяснилось, почти бесполезно. Рассуждение коллеги, устроенного точно так же, он читал сочувственно: соглашался с уже построенной логикой и ограничивался косметикой. Задним числом это кажется очевидным, но попробовать стоило.
Потом аудит отдали Codex. И вот тут всё ожило. Он дольше роется в репозитории, чаще лезет проверять сам — особенно хорош оказался как раз в живом GUI, — но по токенам обходится заметно дороже. Зато регулярно приносит именно то, ради чего второй эксперт и нужен: «диагноз неверен», «это лечится не здесь», «такую же правку надо сделать ещё в четырёх местах».
После июньского пика реопены начали снижаться. Причинность я здесь не доказываю: одновременно менялись и аудит, и сам конвейер, и набор задач. Но главное я для себя вынес: несогласие с результатом лучше получать внутри системы, чем первым комментарием от пользователя. Числа и стоимость будут во второй части.
Fleet Chat (Совещальница): машин стало несколько
Отдельная машина Проверяле нужна не из вредности: иначе он и Решала толкались бы локтями в одном интерфейсе и в одной рабочей копии. Так у нас появился не один компьютер, а несколько: на одном идёт марафон — это когда Решала сам берёт задачи одну за другой и крутится без остановки, — на другом аудит. А когда задач много, я поднимаю ещё одну машину с ещё одним Решалой. Всю эту компанию мы зовём флотом.
Папка задач у них общая, на сетевом диске. Там лежит вся история: журналы рассуждений каждого участника, скриншоты, временные проекты, фикстуры. Любой агент флота видит про задачу всё, что делали до него, — включая чужие тупики.
Чтобы двое не взялись за одну работу, каждый ставит на задачу лок. А кроме этого у них есть общий чат, Fleet Chat, по-нашему Совещальница, где они переговариваются обычным человеческим текстом. Лок гарантирует, что двое не возьмут один тикет. А что две разные задачи не полезут в одни и те же функции, гарантирует только такой разговор. Проверяла с марафоном там же решают, чья это задача — вернуть в марафон или доделать на месте.
Выглядит это примерно так — настоящие куски чата, номера задач и адреса машин заменены:
[23:47] auditor -> all #GEO-00422 У меня из графики только базовый адаптер удалённого стола. Замерить настоящую скорость 3D-вида нечем. У кого-нибудь есть живая видеокарта? Отвечайте только про железо.[23:52] solver -> auditor #GEO-00422 У меня то же самое: RDP-сессия, видеокарты нет. Ни одна из наших машин этого не может. Нужна отдельная машина с железом, через человека.[08:16] gpu-host -> all #GEO-00422 Беру GEO-00422 на прогон с настоящей видеокартой. Лок мой, в рабочую копию не заходите. ... тремя днями позже ...[06:44] solver-2 -> all #GEO-00447 Меня выключают. Одно напоследок: кадр может быть пустым, даже когда счётчик уверяет, что всё отрисовано. Кто придёт после меня — не верьте счётчику. Файлов не менял, лок свободен.
Первый раз читать такую переписку было жутковато. Потом я перестал её читать, и мне полегчало.
MCP-шлюз (Наставляла): тестер Гена и человек, который знает весь продукт
Пока я разбирался с реопенами, Управлялой, тем самым Test Engine, начал пользоваться живой человек. Назовём его Гена. Он быстро упёрся в то же, что и агенты: хороший тестировщик, но не разработчик продукта, и исходников у него нет. Гена пишет регрессионные тесты: проходит сценарий в программе живыми руками, программа его запоминает, а записанное потом при необходимости допиливается — сейчас уже его ИИ-агентом. Вопросы возникают постоянно: с какими ключами запустить приложение для этого прогона, как выбрать объект, почему свежая возможность ещё не описана, это баг тестового контура или я неправильно построил сценарий?
Я некоторое время давал универсальный совет: «Спроси своего ИИ-агента». Совет был прекрасен всем, кроме одной мелочи: агент Гены знал ровно столько же, сколько успел прочитать в документации. А самые интересные вопросы начинались как раз там, где документация заканчивалась.
Сначала мы сделали саппорт-проект в YouTrack. Там и раньше жили задачи, все умели им пользоваться. Человек заводит в этом проекте задачу (кстати, её видят только он сам и наш агент) и спрашивает что угодно про продукт. На сервере, где лежит весь наш C++, агент читает код, документацию и историю изменений и готовит ответ. Сам код при этом никуда с машины не уходит: спрашивать-то можно что угодно, а вот у ответа есть границы. Дальше пользователь может продолжить разговор в комментариях, а если случай совсем сложный и неоднозначный — агент зовёт тимлида.
Кстати, понадобилось это не только Гене. Наш тимлид, который в продукте уж, наверное, лет пятнадцать, однажды сказал занятную вещь: в компании не осталось человека, который знает продукт целиком. Когда-то, наверное, такой человек и был. Потом продукт рос, люди специализировались, старые решения забывались — и целого знания не осталось ни у кого, при всех наших ведущих инженерах с многолетним стажем. Просто время.
Так саппорт неожиданно занял вакансию всезнающего сотрудника. Оракула. Жаль, что мы его так и не назвали. Работает он быстро: собирает актуальный ответ из кода, документации и истории задач. Геофизики довольно скоро стали пользоваться им как живой документацией — той, которая всегда соответствует сегодняшней версии.
Гене, впрочем, ходить с вопросами в YouTrack было неудобно. Тут надо сказать, что Claude Code у него был, но особой любви к нему Гена не питал. Пришлось показать, что из агента можно делать вообще всё: запускать наше приложение с нужными ключами, записывать и воспроизводить макросы для регрессионных тестов, читать и объяснять логи, проверять и править уже записанные сценарии. Дело пошло — и уткнулось в то, что агент всего этого про наш продукт не знает.
Поэтому тот же саппорт-контур мы открыли его агенту напрямую, через MCP-шлюз — Наставляла по-нашему. К репозиторию агент Гены при этом не подключается: он спрашивает, а Наставляла сам смотрит в код и отдаёт наружу только то, что разрешено.
Эффект получился заметный. Claude Гены сразу оказался в курсе всего проекта: как называются элементы интерфейса, какие ключи запуска бывают, почему вот эта штука ведёт себя именно так. Причём отвечает Наставляла не по одним исходникам: у него есть вся история рассуждений нашего Испыталы и накопленная база знаний. То есть реальный опыт — где в этом интерфейсе легко ошибиться, что имеет смысл проверять, куда кликать, чтобы протестировать вот эту функцию по-настоящему. Для человека, который придумывает регрессионные сценарии, это оказалось важнее любой документации. При том что сам Гена исходников по-прежнему не видит.
Потом такой же шлюз подключили нашему геофизику и одному из главных поставщиков тикетов в YouTrack — назовём его Русланом. Продвинутый пользователь: заказывает новые фичи, пишет багрепорты и заодно тестирует то, что получает. Раньше стройно оформить описание ему помогал ChatGPT — поэтому и поставили ему VS Code с Codex, подключённым к шлюзу. Теперь его агент может спросить внутреннего эксперта, проверить реальные названия элементов GUI, узнать, какие функции уже существуют, и собрать задачу в контексте продукта. Иногда по ходу дела выясняется, что новую фичу заказывать не нужно: она уже есть, просто лежит не там, где её искали.
Забавно, что весь этот контур вырос из моего ленивого совета «спроси своего ИИ-агента». Совет оказался правильным. Просто чтобы он заработал, агенту надо было сначала дать, у кого спрашивать.
А для меня тут открылось кое-что поинтереснее. Раньше границу доступа пользователей мы проводили по файлам: этот каталог можно, тот нельзя. Теперь её можно проводить по смыслу — не «какие файлы отдать», а «что человеку можно знать».
Исходники остаются за шлюзом, а отдельная проверка читает готовый ответ пользователю и может его не выпустить. Примечательно, что она уже срабатывала.
Infra Feedback (Доработница): агент научился не только спрашивать, но и жаловаться
Дальше вышло само собой. Раз агент Гены умеет спрашивать шлюз, пусть умеет и жаловаться.
Жалоб у него хватает, и все довольно скучные. Не хватило ручки в тестовом API. Что-то в нём работает криво. Непонятно, баг это или сценарий сам кривой. Или уже Наставляла ответил ерунду. Всё это агент через шлюз складывает в нашу Доработницу — ту самую очередь, из которой растёт Управляла. Круг замкнулся: раньше туда попадали затыки только наших собственных ролей, теперь пишет и агент живого тестировщика. Спотыкается он о те же ручки, только с другой стороны.
Подробности агент собирает сам, и ему даже не приходится гадать, что именно собирать. Он может спросить у Наставлялы: вот такой симптом, что нужно приложить, чтобы в этом разобрались? Шлюз смотрит в код и отвечает предметно, а заодно подсказывает направление: похоже, копаешь верно, пришли ещё вот это.
А настоящие баги продукта живут отдельно: им, как и прежде, положен тикет в YouTrack — с автором, историей, обсуждением и всей цепочкой до доказательства. Руслан их и заводит, просто теперь точнее.
DocWriter (Писала): документация не поспевает за разработкой
А потом ускорение аукнулось на документации. Фичи стали выходить быстрее, чем мы успевали про них писать. Код уже в продукте, пользователь видит новые кнопки, а справка честно рассказывает про позавчерашнюю версию.
Так появился DocWriter — Писала по-нашему. Устроен он как Решала и так же читает продукт, только правит не C++, а документацию: Help&Manual, скриншоты, публикация.
Схема похожая. Когда задачу приняли, Писала берёт продукт на конкретной ревизии, находит затронутые темы, правит текст, снимает свежий скриншот и собирает PDF на проверку. Новый текст в нём подсвечен жёлтым, изменённая картинка обведена оранжевым, удаления тоже видно. Человек смотрит готовые страницы и ставит Approved.
Дальше Писала коммитит документацию — она живёт в своём SVN, отдельно от продуктового, — собирает WebHelp и выкладывает готовую справку на S3. Человек открывает её там, смотрит уже полный собранный документ и, если всё устраивает, ставит Verified. И только после этого справка едет на официальный сайт. Итого два человеческих решения на цикл: на текст и на публикацию.
Принцип, как видите, тот же, что у Решалы: пока живой человек не посмотрел результат своими глазами, работа не сделана. Только у Решалы это кадр из окна программы, а у Писалы — страница справки, открытая в браузере.
Так зачем здесь я?
Теперь, когда всё это работает, продуктового C++ я пишу заметно меньше. Причём «пишу» у меня давно означает другое: своими руками я общаюсь с агентом.
Зато появилось другое. Сами тикеты я почти не трогаю, их берёт Решала. Моя работа теперь — то, на чём он держится: роли, инструменты, доступы, проверки, правила приёмки. Если Решала застрял, я не подхватываю тикет руками, а разбираюсь, чего не хватило системе: где придумать доказательство, где дать агенту канал к живому продукту, а где красивый скриншот не доказывает ничего. Я много лет руководил разработкой, и этот опыт пригодился в новом качестве: раздать работу, снабдить каждого инструментом, дать ровно те права, которые нужны, и разобраться в причинах, если команда пошла не туда. Разве что руковожу я теперь не людьми, а роботами — и совещания у нас проходят в консоли.
Программисты, кстати, никуда не делись, и работы у них не убыло. Просто рутина уехала агентам, а людям осталось то, что рутиной никогда и не было: докопаться до настоящей причины, выбрать между несколькими разумными путями и решить, что вообще считать правильным результатом. Инженеру это выгодный обмен: меньше однообразной работы, больше той, ради которой в профессию и идут. Компании тоже: дефицитные часы сильных людей уходят туда, где без них правда никак.
Так что на свой вопрос я ответил, хоть и не сразу. Быть копипастером между пользователем в YouTrack и консолью агента мне действительно незачем, туда я больше не вернусь. А вот собрать из людей, агентов и кода механизм, который решает задачу и умеет доказать, что решил, — это всё ещё инженерная работа, и её мне хватает с избытком.
Но это только начало. Мы продолжаем биться, а реальность всё время оказывается на шаг впереди автомата: находится случай, который система пройти не может, мы её достраиваем — и находится следующий. Пока конца этому не видно.
Впереди другие продукты и другой уровень автоматизации. С отдельным тикетом агент сейчас справляется целиком и сам. Но агент у нас уже не один: есть марафон Решалы, есть Проверяла, есть Писала, и каждого при нужде можно размножить — поднять ещё одну машину, потом ещё. Вот их-то и интересно научить работать друг с другом по-настоящему.
Координация у них уже есть, но одноранговая: в Совещальнице все равны, начальника нет. Пока все живы, это работает. А если марафон подвиснет или разлогинится — чинить иду я. И обновления агентам накатывать тоже: выходят они бодро, и почти каждое требует моего участия. Сложные случаи разгребаю сам, хотя нередко всё, что я делаю, — говорю агенту: подумай ещё раз и посоветуйся со второй моделью.
Вот это и просится на уровень выше. Агент-начальник раздавал бы задачи марафону, звал Проверялу, передавал принятую задачу Писале, присматривал за их состоянием, перезапускал упавших и накатывал обновления. А когда один Решала перестаёт справляться — поднимал бы в облаке ещё одну машину и запускал на ней второго. Потом третьего. Агент, который управляет облаком, у меня, кстати, уже работает — только пока я говорю с ним руками, в обычном окне чата, и в общую цепочку он не встроен. Так что фантазия эта вполне себе ближайший план.
Сейчас агент верхнего уровня называется Саша, работает без API и сделан из мяса. Судя по темпам, автоматизируем и его.
Про то, как всё устроено, я рассказал. Остался резонный вопрос, тем более если смотреть на это глазами бизнеса: а польза-то от этого есть или мне так кажется? Поэтому мы подняли историю задач в YouTrack, коммиты в SVN и журналы Решалы с Проверялой, и я сел считать. Засчитывал только то, что приняли живые люди.
Во второй части: почему поток принятых задач вырос в 13 раз, хотя в исследованиях METR и Microsoft эффект куда скромнее. Отчего при этом полезли вверх реопены и откуда взялся независимый аудитор Проверяла. Куда девается машинное время, если на код уходит лишь пятая часть. И во сколько обходится всё это удовольствие: по подписке вышло в 11 раз дешевле, чем стоили бы те же прогоны по цене токенов.
Если про что-то захочется подробностей — спрашивайте в комментах, расскажу.
ссылка на оригинал статьи https://habr.com/ru/articles/1064242/