Год - полтора назад было сложно представить, что, взяв кружку кофе, за один вечер, рассказывая кому-то по ту сторону экрана свои потребности, можно будет получить то, что раньше занимало недели, а иногда и месяцы.
Когда мне нужно закрыть какую-то функциональную потребность, как я поступаю? Я ищу готовое решение в интернете, какое-то недорогое SaaS-решение или какой-то опенсорсный тул. Однако бывают ситуации, когда подходящего решения просто нет, и что тогда делать? Можно написать самому, но это же утомительно - решать какую-то (очевидно не самую важную) задачу, тратя время на очередной CRUD, описывая Helm chart или Docker Compose, придумывая, где хранить данные, и решая ещё с десяток типовых вопросов. Такие задачи либо уходят в долгий ящик, либо решаются каким-то очень костыльным, но быстрым способом. Нет, я, конечно, очень люблю технологии (вы можете поверить на слово человеку, который использует Grafana с Prometheus-алертами для учёта личных финансов), но на каждую проблему времени не найти.
Тут на помощь приходит вайбкодинг! Я периодически вижу посты в формате:
Навайбкодил сервис, очень удобный и красивый, и решает задачу!
Но что там навайбкодили, а что сделано самостоятельно? Мне стало интересно, насколько сложно через AI написать какой-то инструмент, решающий мою задачу с минимальными ручными правками.
Что я буду вайбкодить? Мы в Mayflower выпускаем релизы каждый день, а частенько даже несколько раз в день. Для этих целей у нас уже много процессов и автоматизаций, но с растущим количеством сервисов было бы неплохо иметь инструмент в виде календаря со всей информацией по каждому релизу. А также было бы удобно иметь возможность сказать другим командам, что я хочу выкатить новую версию сервиса в определённый день. Так как этот инструмент, вероятно, будет расширяться, мне важно, чтобы были выполнены парочка нефункциональных требований:
- Код должен быть поддерживаемым;
- Иметь документацию;
- Хорошо расширяться;
Небольшая заметка: я знаю, что есть замечательные вайбкодинг-тулы вроде курсора, но я буду использовать GPT-5, так как на момент написания статьи прошло всего пару недель с его релиза, и мне очень интересно, как он умеет генерировать целые проекты и работать с кодовой базой.
Этап 1 - Подготовка и генерация
Цель данного этапа - написать промпт, который отражает все функциональные и нефункциональные требования, а также корнеркейсы, запустить сгенерированный проект и убедиться, что всё работает.
Описываем требования:
Ты профессиональная студия по разработке IT проектов на заказ, включая дизайн, бекенд, фронтенд, инфраструктуру и документацию. Тебе пришел заказ от крупного и важного клиента на разработку очень важного инструмента для их бизнеса.
Описание проекта: Проект представляет собой веб-приложение для управления всеми релизами компании.
Функциональные требования:
- В приложении есть календарь в котором отмечаются все релизы (может быть несколько релизов в один день или не одного), кликнув на релиз из календаря открывается страница со всей информацией о релизе.
- Управление релизами:
- Создание, редактирование и удаление релизов (через интерфейс, нажимая на кнопку и заполняя данные, а можно через API. Менять можно любые данные)
- Просмотр списка всех релизов с возможностью фильтрации по статусу, релизному дежурному, по типу релиза.
- Возможность добавления комментариев к релизам.
- Что должно быть в информации о релизе:
- Дата и время релиза.
- Статус релиза (запланирован, состоялся, не состоялся).
- Список дежурных, ответственных за релиз.
- Заметки по релизу (возможность добавления и редактирования заметок).
- Полезные ссылки (из api будет приходить название ссылки и ссылка, можно будет добавлять вручную, например: release build: https://example.com).
Варианты использования:
- Из CI будут отправляться данные о релизах в приложение через API;
- Пользователи смогут просматривать календарь релизов, добавлять новые релизы;
Нефункциональные требования и тех. стек:
- фронтенд:
- nextjs 14 версии с новым app роутером
- используй shadcn для компонентов интерфейса
- бекенд:
- golang (можно с использованием gin или чего-то популярнее и удобнее)
- GORM для работы с бд
- инфраструктура: nginx
- база данных: mariadb
- Проект должен быть упакован в docker образы и описан через docker-compose (что бы заказчик мог сразу протестировать что все работает), а все переменные для базы данных, адреса приложения и прочее должны быть вынесены в .env файл.
- Для миграций используй goose, миграции должны быть написаны в виде sql файлов в директории migration бекенд проекта и упаковываться прямо в образ бекенда через embedded.
- Выполнять миграции можно командой
go run main.go migrate(или можно использовать cobra для создания CLI команд).Можешь заложиться еще под какой-то функционал, но не переусложняй
После отправки этого промпта и пары уточняющих инструкций GPT-5 отдаёт мне zip-архив. Открыв его, я вижу 3 директории:
- backend,
- frontend
- nginx
Это именно то, что я ожидал. Правда, после первого запуска пришлось попросить пофиксить пару мелких ошибок, чтобы проект запустился и работал. То, что я увидел в браузере, меня приятно удивило:
На самом деле я не думаю, что мне нужно много изменений на фронте - это именно то, что я хотел. Но при детальном рассмотрении кодовой базы я немного расстроился: она никуда не годится, и не выполнены некоторые требования, которые я описывал в промпте. Первая версия исходников доступна тут - https://github.com/thatqa/release-calendar/tree/v1
Окей, выпишу то, что меня не устраивает, и первым делом попробую исправить это.
- миграции находятся в одном файле;
- не используется gorm;
- грязные* роуты, в них вся логика начиная с валидации каких-то параметров и заканчивая sql запросами
Также, пока я тестировал, обнаружился баг - при добавлении релиза он добавляется на следующий день, а не в тот, который я выбрал.
Результат этапа: сгенерирован проект, который можно запустить и потыкать. Визуально всё выглядит отлично, но кодовая база в текущем виде не годится для будущей поддержки. Выписаны основные моменты, которые нужно поправить.
Этап 2 - исправление ошибок и несоответствий ТЗ
Цель данного этапа - исправить все несоответствия ТЗ и ошибки, убедиться, что всё работает как надо.
Для начала исправим баг с датой добавления релиза, просим GPT-5 найти, в чем ошибка:
Почему при добавлении релиза в какой-то день, он добавляется не в выбранный день а на следующий, можешь подсказать где ошибка?
вот фикс: https://github.com/thatqa/release-calendar/commit/e34de48f840b02f717503bf265a3414a40304ba2. Причина банальна - несоответствие локального времени и UTC на фронте при формировании даты. Дальше разнесем миграции по разным файлам:
После проверки кодовой базы файлы миграций оказались в одном файле, разнеси их по разным файлам и отправь в чат
Тут тоже все ок: https://github.com/thatqa/release-calendar/commit/537a05de4371ffe7b30c4f417c1f19727aad079a. Следующим шагом добавляем GORM. Если функционал будет расширяться, с ним удобнее, чем с сырыми запросами:
После проверки кодовой базы выяснилось что ты не использовал gorm, перепиши все модели на gorm. я не буду использовать эти модели для миграций, только для получения и отправки данных.
Результаты правок:
- https://github.com/thatqa/release-calendar/commit/8fbd01b6cafb062dd90fa31fb8b12221570b8802
- https://github.com/thatqa/release-calendar/commit/1c9334382be32062b11e8d7e799796c7529566ad
Миграции остаются на Goose и в SQL, а GORM используется только как ORM-слой для работы с данными в рантайме. Так проще контролировать схему, ревьюить изменения и избегать "магии" автогенерации.
Последняя правка самая объемная - разнести роуты по слоям, чтобы проект стал хотя бы немного поддерживаемым и расширяемым. Промптов было много, местами писал сам, потому что так быстрее, но общий подход такой: выделил слои use case, entities, repository, а в контроллерах оставил минимум - валидация запросов, вызов use case'ов и ответ. Правки тут:
- https://github.com/thatqa/release-calendar/commit/c14c9fa343ca50cf74d4766aaf5dab9b5903905e
- https://github.com/thatqa/release-calendar/commit/aea5ceb8a9c6d3ec292c5709fb573873bdae7f94
Результат этапа: исправлены неточности и баги из первого этапа, появились зачатки архитектуры, контроллеры распилены на слои. Проект стал заметно более поддерживаемым и расширяемым.
Этап 3 - создание точек маркеров:
Цель данного этапа - проверить, сможет ли GPT-5, имея весь контекст проекта, допилить новый функционал под требования.
Сейчас на календаре не видно, в какие дни есть релизы. Это видно только по клику по конкретной дате. Хочется, чтобы под числом дня появились точки-маркеры - по наличию релизов и по статусу. Минимальное ТЗ:
Необходимо доработать функционал, что бы под каждым днем (когда были релизы) в календаре отображались точки разных цветов:
- красная - если в этот день были релизы и они в статусе failed
- зеленая - если в этот день были релизы и они в статусе success
- синяя - если в этот день были релизы и они в статусе planed
GPT сам предложил оптимизацию - агрегировать статусы релизов по месяцам одним запросом и отдавать компактную структуру для фронта. Изменения тут: https://github.com/thatqa/release-calendar/commit/78f04b1882c6b48add4f186e3f4175b9f8224075
Результат этапа: новая фича работает, и когда у GPT-5 под рукой весь проект, такие фичи делаются реально быстро.
Этап 4 - ai фича!
Куда же без AI. Хотелось бы саммари по комментариям и заметкам релиза одной кнопкой.
GPT предложил два режима бекенда:
-
Если есть OPENAI_API_KEY: обратиться к модели и получить саммари
-
Если ключа нет: сделать простой локальный фолбэк (эвристика: выбрать ключевые фразы, дедуплицировать, собрать краткий вывод)
Изменения тут - https://github.com/thatqa/release-calendar/commit/9f88992a5ac3f90883098a130c07db79f52fd0dc
Результат этапа: AI-фича собралась проще, чем ожидал. Пара точечных правок руками - и готово.
Заключение
За вечер получилось пройти путь от "идеи в голове" до работающего инструмента с фронтендом, бекендом, миграциями и даже небольшой AI-фичей. В первой версии пришлось фиксить кучу мелочей, архитектура требовала доработки, а код было сложно назвать поддерживаемым. Но это отлично решает проблему белого листа - можно быстро получить прототип, а потом шаг за шагом довести его до состояния, где с ним уже не стыдно работать дальше.
GPT-5 в целом справляется лучше, чем я ожидал: он может собрать работающий проект, предложить оптимизации вроде одного запроса на месяц для календаря и иногда подсказать, как сделать чуть умнее. Но без правок и без здравого смысла со стороны разработчика никуда - иначе быстро накопятся костыли.
Для меня этот эксперимент показал три вещи:
- AI это отличная точка старта, что бы бы избежать проблемы белого листа.
- Даже с идеальным промптом часть работы всё равно остаётся за человеком
- Встраивать AI-фич - это проще чем я думал :)
Получившийся проект: https://github.com/thatqa/release-calendar