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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фича-реквесты
Увидев, что всё работает, я решил добавить в ретро-доску еще несколько фич:
- выбор цвета и иконки для колонок;
- группировку карточек;
- голосование за карточки;
- отдельную панель с теми, кто сейчас онлайн;
- онлайн-игру с рисовалкой в реальном времени через вебсокеты.

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

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

После этого попросил агента сделать Makefile для локального запуска и развернуть всё это на сервере.

UI за 10 минут и первый вывод о скиллах

С бэкендом разобрались, дальше — UI. Выбрал Nuxt, потому что на работе использовался именно он.

Сначала я попросил агента сделать Swagger для бэкенда. А во втором промпте написал:

Сделай UI на Nuxt для этого API.

И указал Swagger, чтобы агент мог по нему собрать интерфейс.

Минут 10 ожидания — и агент поднял работающий интерфейс)

Для фронта я скиллы писать не стал. Код агент разложил по папкам, но структура не до конца совпала с моими ожиданиями: например, `composables` и `stores` он не сделал.

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

На том этапе меня это, впрочем, не волновало. На всё с самого начала, включая тесты и проверки, ушло около часа. И у меня уже был рабочий прототип — с бэкендом и UI https://uretro.ru)

Бэкенд за 20 минут

После проверки правил на небольшом примере я перешел к самому проекту. Написал агенту:

Сделай доску для проведения ретроспектив спринта IT-команды с колонками и карточками.

В ответ агент начал задавать вопросы. Нужны ли вебсокеты? Нужна ли регистрация? Могут ли гости просматривать доски? Было что-то еще, сейчас уже не вспомню.

Первым в списке ответов всегда шел вариант с пометкой «Рекомендуется». И каждый раз он меня устраивал.

После этих уточнений примерно через 20 минут был готов бэкенд.

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

Первые правила для агента

Ну что ж, код пишет. И пишет быстро)

Теперь хотелось получить привычную структуру проекта вместо одного `main.go`. Видимо, для этого нужны правила.

Как их описывать, я еще не знал, поэтому поручил это самому агенту:

Создай правило: код должен писаться по чистой архитектуре и DDD. Используй богатую доменную модель — rich domain model.

Файл получился подробнее моего запроса: агент добавил еще несколько строк с пояснениями про DDD.

Для проверки я дал агенту небольшую задачу:

Создай агрегат «Доска», в котором могут быть карточки. Напиши только доменную часть.

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

Всё началось с одного main.go

Начал я с бэкенда для uretro.ru. Хотел проверить, как быстро ИИ справится с простой задачей и какой код получится.

Про скиллы я уже слышал. Но что туда писать? Я еще не понимал, как с этим работать и что будет без скиллов.

В итоге просто открыл IDE и написал:

Сделай бэкенд на Go для простой ретро-доски, где можно создавать доски и карточки на них.

Через пару минут у меня был рабочий прототип. Всё в одном main.go: несколько роутов и запросы к базе данных. Агент сам запустил бэкенд и подергал ручки через curl.

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