Путь ИИ-инженера

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

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

Сейчас у нас в команде десятки скиллов: написание кода, подготовка контрактов, ресерч по документации, создание задач и так далее.

Если всё это каждый раз целиком загружать в модель, контекст будет забит инструкциями ещё до того, как начнётся работа. Даже когда нужно просто создать задачу, рядом окажутся подробности написания кода и подготовки контрактов.
Со скиллами загрузка устроена иначе. Сначала модель видит их названия и краткие описания, чтобы понять, какие из них подходят для текущего запроса. А полные инструкции подгружает по мере необходимости.

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

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

Проблема контекста

В контексте агента накапливаются наши сообщения, ответы модели, код и результаты работы инструментов. Часть этих данных со временем становится лишней.
У контекстного окна есть предел. Поэтому в длинных сессиях может использоваться сжатие контекста — compaction: историю заменяют более компактным представлением, сохраняя важное для продолжения работы.

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

Кэширование может снизить затраты на обработку истории, но место в контекстном окне не освобождает.

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

Как устроен агент

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

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

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

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

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

То есть мы пишем короткое «да, продолжай», а рядом с ним в контексте уже могут быть десятки сообщений, куски кода и логи)

Одна опечатка может перевернуть всё

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

Однажды я написал «ну активити» вместо «не активити».

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

У меня в голове всё ещё было «не активити». А модель получила совсем другой текст.

Поэтому мало сформулировать задачу. Нужно ещё перечитать то, что отправляешь, и проверить, совпал ли результат с тем, что ты хотел получить.

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

Как объяснить задачу ИИ

Есть такое упражнение: одному человеку показывают картинку, а остальные должны нарисовать её по его описанию. Саму картинку они не видят.

Потом все показывают свои рисунки и сравнивают их с оригиналом. И оказывается, что у каждого получилась своя версия)
Все слушали одно описание, но недостающие детали каждый додумал по-своему.
Мне кажется, с ИИ примерно так же.

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

Модель же ориентируется на описание задачи и доступный ей контекст. Если важных деталей там нет, она заполняет пробелы сама.

В итоге можно получить совсем другую картинку)

Второй проект — в проде
Второй проект уже работает: https://wg.alexd.ru

После истории с несовпавшими контрактами дописал в правила обязательный Swagger.

Но в том случае само его наличие не решило бы проблему: контракты для бэкенда и фронтенда создавались параллельно.

Можно было сначала описать общий контракт в OpenAPI, а уже потом запускать двух агентов на бэкенд и фронтенд. Для этого проекта, скорее всего, такого порядка было бы достаточно.

В более крупных проектах и это не гарантия: по ходу исправлений после тестов и код-ревью контракты иногда меняются. За этими изменениями тоже нужно следить.

И снова всё прошло быстро: всего два часа — и второй проект уже в проде)

Попытка номер два

Ко второму проекту я подошел уже более организованно.

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

Включил режим планирования. Агент задал ряд вопросов, составил план и сохранил его в файл. Я несколько раз перечитал план и руками отредактировал.

После этого написал:

Сделай бэкенд и фронтенд параллельно, двумя субагентами.

Агенты приступили к работе: один собирал бэкенд, второй — фронтенд. Обе части были готовы, но вместе сразу не заработали.

Контракты почти совпали)

В большинстве мест всё сошлось. Но где-то различались имена полей, где-то — сами передаваемые данные. Этого хватило, чтобы бэкенд и фронтенд не состыковались с первого раза.

В десятки раз быстрее?

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

Мне тогда было сложно с этим согласиться. У меня перед глазами был собственный результат: четыре часа — и готовый проект. По моим прикидкам, руками я бы делал его больше недели.

А тут — даже не в два раза?

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

На тот момент мне казалось, что я уже это проверил на практике.

Спойлер: я ошибался)

Итоги первого проекта с ИИ

На весь проект ушло четыре часа.

За это время появились бэкенд, UI, фичи ретро-доски и онлайн-игра с рисовалкой по WebSocket. Успел посмотреть код, уточнить правила и попросить агента внести исправления.

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

Думаю, на простых проектах это может давать ускорение в десятки, а на отдельных задачах — даже в сотни раз.

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

Еще увидел, куда можно двигаться дальше: идти от контрактов и делать бэкенд и фронтенд параллельно. А внутри них — распределять независимые задачи между агентами.

Но об этом позже)

Время код-ревью

Решил подробнее посмотреть, что же получилось под капотом.

Местами валидация оказалась в юзкейсах, были возможны гонки данных, не хватало транзакций на уровне application. Общее правило «писать по DDD» оказалось недостаточным.

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

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

Решил дописать правила явно: про транзакции на уровне application, доменную валидацию и другие требования к организации кода.

Заодно заметил, что миграции оформлены по-разному: часть — обычные SQL-файлы, часть — под `goose`. Зафиксировал в правилах, что все миграции нужно делать под `goose`.

Затем попросил агента найти расхождения с обновленными правилами и переписать код.

Примерно через час результат меня уже устраивал)