Примеры из жизни

Пример 1. Фича для Маттермоста

Задача - сделать так, чтоб командой из Маттермоста можно было запускать и стопать демо-стенд (5 машин в Яндекс-облаке). Сначала я сам сел и подумал, какие есть варианты, исходя из нашей текущей инфраструктуры. Решил остановиться на n8n, но стало лень самому разбираться в API.

Фаза 1 - Брейнсторминг

Я описал задачу просто текстом и попросил вместе со мной побрейнстормить и задать уточняющие вопросы. Он заюзал скилл Brainstorming из Superpowers и стал задавать мне вопросы по одному:

• какие машины надо стопать - фиксированный список или динамический
• предпочитаемый формат команд
• настроена ли уже аутентификация в Яндексе (нет)
• что это за машины, сколько их, включаем и выключаем все сразу или нет
• нужна ли команда статуса
• как и куда будем писать ответ

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

Фаза 2 - Изучение инфры

Я попросил CC прочитать .env, куда засунул ключ от n8n (нестрашно, так как он за VPN + могу потом перегенерить). Дальше он сделал curl к API n8n, получил список существующих пайплайнов, изучил их содержимое и как выстроена работа с Маттермостом.

Фаза 3 - Дизайн архитектуры

CC по частям начал выдавать дизайн архитектуры, подтверждая у меня, что всё верно. Также запросил дополнительную информацию (JSON-ключ для запроса токена в Яндекс-облаке, айдишники машин).

Фаза 4 - Имплементация

CC написал JSON с описанием n8n-воркфлоу и через curl POST-запросы попытался создать его. Были ошибки импорта, и CC явно упёрся в стенку, повторяя примерно одно и то же разными способами. Я его стопнул и предложил самому импортнуть JSON через браузер. Так получилось намного быстрее и сразу заработало.

Вывод: желательно послеживать за агентом во время фазы имплементации.

Фаза 5 - Отладка

Естественно, с первого раза ничего не заработало: воркфлоу падал на этапе генерации JWT с ошибкой “Module crypto is disallowed”. CC предположил, что нужно поменять настройки n8n. Попросил девопса прокинуть энв-переменную в контейнер n8n, и всё завелось!

Вывод: отладку часто лучше делать совместно, особенно если у CC нет полностью самостоятельного способа проверить результаты.

Пример 2. Реализация DL-статьи

Задача - изучить новую архитектуру из DL-статьи, а затем реализовать в коде.

Фаза 1 - Планирование

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

После этого был создан план реализации по шагам. Я попросил выгрузить в md-файл, прочитал и обнаружил, что некоторые штуки из статьи адаптированы некорректно. Закинул отдельно три скриншота архитектуры из статьи — по ним план был адаптирован.

Фаза 2 - Итеративная реализация по шагам

Реализация шла файл за файлам: после каждого шага я задавал уточняющие вопросы и просил проверить корректность. В процессе приходилось останавливать его пару раз - зачем-то стал писать TODO вместо реальной реализации и поставил no_grad на новый компонент, хотя это противоречило плану.

Фаза 3 - Ревью

Далее я попросил CC сделать ревью написанного кода через субагента /code_reviewer из Superpowers. Нашёл пару багов, я ещё раз попросил - нашёл ещё пару багов.

Фаза 4 - Отладка

Я попросил его использовать MCP ClearML, чтоб прочитать параметры успешного эксперимента и локально поставить эксп для проверки.

Работающий код в ML ничего не значит, поэтому я решил отдельно визуализировать работу каждого компонента. Естественно, оказалось, что ничего не работает, поэтому за этим последовала долгая сессия совместной отладки. Вывод тут один - как и в работе без ИИ всегда смотрите на данные, на входы и выходы нейронки. CC ускоряет процесс, так как быстро создаёт любые нужные визуализации.