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

В общем, сначала была идея. Она облекается в слово, слово становится требованиями, а требования становятся кодом. Все, можно расходиться :D

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

После этого я иду в чат какой-нибудь нейронки и обсуждаю идею с ней. Не финальную, а MVP. Я использую QWEN, но в целом оно не очень принципиально. Можно использовать любую нейронку, в чате которой можно создать проект.

На этом этапе мне важно провалидировать идеи, посмотреть, что я упустил, и составить первый минималистичный README.md. в котором зафиксирую общее описание проекта, стэк и архитектурные подходы.

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

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

Получив первичный README я возвращаюсь в чат и создаю проект, куда этот README складываю.

Дальше идём в кодинговый агент. Чат пока что не нужен.

Ручками, сами (или через задачу агенту) создаём каркас проекта. После этого можно агентом писать базовую инфру: сервер, конфиги проекта и докера, .env и прочее первой необходимости. Я сразу сделал в internal сборщик и конфигуратор сервера, чтобы потом безболезненно расширять его модулями (сборщик и конфигуратор, если что, раздельные). Написал docker, docker-compose и sqlc конфиги, сделал makefile, куда забросил наиболее частые команды: миграции, генерации, управление сборкой и compose. Советую сделать сразу и постепенно, по мере необходимости, добавлять команды. Удобно. И нейронке потом удобнее оперировать make командами, и для нас предсказуемей и проще понимать, что она вообще сейчас пытается сделать.

Когда инфра готова, возвращаемся в чат и начинаем проектировать модули. Да, каждый модуль проектируется отдельно по схеме: домен и пользовательские сценарии -> модель данных. Это всё фиксируется в README, которое мы складываем в корневую папку модуля — это будет источником истины для агента. После — запускаем работать агента.

ВАЖНО! Не нужно давать агенту задачу "пиши модуль A". Вы охренеете потом всё это проверять, да и шанс что агент затупит, вообще не маленький. Реализация модуля должна проводиться итеративно и в строгом порядке, продиктованной зависимостями. Сначала миграции и запросы. После — домен модуля. После реализации домена я пишу репозитории. После репозиториев лимитеры, если нужны. Потом бизнес-логику. В конце — хэндлеры.

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

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