Мне всегда хотелось, чтобы генераторы Django-проектов работали совсем иначе:

Вы пишете одно предложение: «Доска вакансий. Postgres, вход через Google, фоновые задачи, Stripe, деплой на мой VPS». Через пару минут у вас уже есть заготовка проекта: нужные пакеты подключены и связаны между собой, настройки для разработки и продакшена разделены, CI настроен, проект запускается.

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

Чтобы это проверить, я сделал Skill для AI-агентов, который генерирует Django-проект по одному предложению, а затем автоматически проверяет результат. Несколько недель я итеративно улучшал его: модель генерировала проекты, проверка находила ошибки, инструкции в SKILL.md сокращались и уточнялись, после чего цикл запускался снова. За это время было сгенерировано несколько сотен проектов, и постепенно стало понятно, какие ошибки повторяются чаще всего.

Устаревшие API. Знания модели ограничены датой обучения, поэтому она опирается на то, что было актуально на тот момент. Когда я просил подключить Stripe, она порой писала код под SDK, отстававший на два мажорных релиза, из-за чего интеграция с вебхуками уже не работала. Иногда код биллинга и вовсе отсутствовал. С самим Django та же история: не всегда, но достаточно часто проект генерировался на Django 4.2 вместо актуальной шестой версии.

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

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

Ломается на деплое. Иногда сгенерированный код пропускал шаги, которые выполняются только при деплое. В одном проекте не было команды, применяющей миграции базы при запуске контейнера, — и приложение падало на первом же запросе. В другом модель настроила периодическую задачу для Celery Beat, но забыла добавить сам celery beat в конфигурацию деплоя. В итоге задача существовала, но никогда не запускалась.

Слишком много компонентов, чтобы всё удержать в голове. Django давно перестал быть фреймворком, где «всё включено». Реальный проект опирается на десятки сторонних пакетов: аутентификация, фоновые задачи, почта, файловые хранилища. Главная ценность генератора — знать, какие библиотеки выбрать и какие из них сегодня действительно стоит использовать. Именно с этим модель справлялась хуже всего. Когда я просил её самой решить, что понадобится проекту, некоторые категории библиотек просто исчезали из результата, и принимать эти решения приходилось уже мне.

Что с этим делать?

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

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

Из этой идеи и вырос seedkit — Skill для AI-агентов (Claude Code, Cursor, Codex и других), набор аккуртано созданых справочных Markdown-файлов

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

Задача модели — не вспоминать, как правильно настроить проект, а следовать этим инструкциям и генерировать код. Благодаря этому рутинную настройку можно доверить более дешёвой и быстрой модели, а дорогие запросы к мощным моделям приберечь для сложной логики, ради которой всё и затевается.

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

Один важный урок: промптить модель — не бесплатно. Когда текста для чтения слишком много, модель теряет контекст, и качество ответа падает. Каждой строчке инструкции приходилось отвоёвывать своё место. В итоге чем короче становились справочные файлы, тем лучше был конечный результат. После нескольких сотен итераций качество генерации практически стабилизировалось: проекты, созданные с помощью seedkit, уже редко получали замечания от проверяющего промпта.

Если хотите проверить на своём проекте, попробуйте сами.

Сгенерированные примеры с логами проверок лежат в seedkit-examples.

Claude Code:

/plugin marketplace add viewflow/seedkit
/plugin install seedkit@viewflow

Cursor, Codex и другие AI-агенты:

npx skills add viewflow/seedkit

Запуск:

/seedkit

Может ли LLM создать заготовку Django-проекта?