Гайд: как грамотно промптить Codex, чтобы он собирал сильный фронт

Большинство людей промптят Codex слишком общо: “сделай красивый SaaS”, “собери современный интерфейс”, “сделай платформу на Next.js”. Для модели это почти пустая постановка, и в ответ она почти всегда выбирает самый безопасный, усредненный и наименее конфликтный вариант.

Поэтому проблема обычно не в том, что Codex “не умеет фронт”, а в том, что ему не дали достаточно жесткую арт-дирекцию, продуктовую рамку, UX-планку и критерии качества.

Какой результат вообще можно получить от Codex

Codex нормально подходит для сильного фронтенда, если ему задать правильную рамку.

• Собрать интерфейс на Next.js.
• Разложить App Router-архитектуру.
• Развести public/private зоны.
• Настроить SEO-логику для публичных страниц.
• Использовать SSR / Server Components / Client Components осмысленно.
• Быстро прототипировать сложную платформу.
• Разнести UI по компонентам.
• Подготовить проект под будущие API.

Главный принцип: не проси “сделать красиво”

Формулировка “сделай красиво” почти бесполезна. Хороший prompt должен задавать сразу несколько независимых слоев.

Шесть вещей, которые надо задавать всегда

1. Роль. Не просто “frontend-разработчик”, а senior frontend архитектор, продуктовый дизайнер, эксперт по Next.js.
2. Тип продукта. Не “соцсеть”, а creator platform, AI workspace, B2B-система, generative media platform.
3. Технологические ограничения. Что можно использовать и как именно.
4. Визуальная планка. Какой именно уровень интерфейса нужен и какие паттерны запрещены.
5. UX-планка. Состояния, сценарии, onboarding и поведение интерфейса.
6. Процесс. В каком порядке Codex должен мыслить, собирать, аудировать и улучшать результат.

Сильный prompt — это не “сделай красиво”, а “вот роль, продукт, стек, визуальная планка, UX-обязательства, порядок работы и критерии качества”.

Почему Codex часто делает уродливо

По умолчанию модель идет к безопасному завершению задачи. А безопасное завершение обычно выглядит как generic dashboard: одинаковые карточки, слабая типографика, плоская композиция, вялые состояния и ощущение “вроде работает, но не хочется этим пользоваться”.

Самая важная идея: работай не одним промптом, а пайплайном

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

Рабочий pipeline

1. Архитектура и route map.
2. Дизайн-система и app shell.
3. Ключевые экраны.
4. Второстепенные экраны.
5. UI/UX полировка.
6. Next.js / SEO / SSR аудит.
7. Финальная переработка слабых мест.

Именно так Codex перестает быть “рандомным генератором шаблонов” и превращается в инструмент с управляемым качеством.

Как правильно задавать роль

“Ты frontend-разработчик” — слишком узко. Тогда модель думает прежде всего про “собрать и чтобы не падало”. Более сильная роль добавляет архитектурное и дизайнерское мышление.

Как правильно задавать стек

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

Почему обязательно нужно просить states

Большинство слабых AI-интерфейсов разваливается не на layout, а на состояниях. Если явно не попросить loading, skeleton, empty, error, success и first-time-user states, они почти всегда будут недоделаны.

Почему дизайн-систему надо требовать отдельно

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

Как заставить его мыслить в терминах реального Next.js

Если нужен именно сильный Next.js-результат, фразы “используй Next” недостаточно. Надо отдельно задавать App Router, public SEO pages, server/client boundaries, metadata и готовность к будущему API. Иначе он может собрать React-проект, просто завернутый в Next.

Как правильно критиковать слабый результат

“Ну как-то не очень” — слабый фидбек. Сильный фидбек должен называть конкретный слой: слабая типографика, плохие отступы, повторяющиеся карточки, мертвый profile page, скучный create flow, generic landing или посредственная лента. Чем точнее критика, тем лучше redesign.

Самый эффективный формат взаимодействия

1. Сначала мастер-промпт.
2. Потом отдельно архитектура.
3. Потом отдельно app shell и дизайн-система.
4. Потом отдельно ключевые экраны.
5. Потом отдельно полировка.
6. Потом отдельно Next.js / SEO / SSR аудит.
7. Потом отдельно финальные исправления.

Ты — senior frontend архитектор, продуктовый дизайнер и эксперт по Next.js.

Твоя задача — создать production-grade веб-приложение, а не демо и не MVP.

Продукт:
[описание продукта]

Основные разделы:
[список разделов]

Технологии:
- Next.js (App Router)
- React
- TypeScript strict
- Tailwind CSS
- shadcn/ui
- Framer Motion

Архитектура:
- production-ready структура
- переиспользуемые компоненты
- разделение UI / данных / бизнес-логики
- typed mock services под будущие API

SSR / SEO:
- публичные страницы должны быть SEO-friendly
- Server Components использовать там, где это оправдано
- Client Components — только там, где реально нужна интерактивность
- metadata обязательны

НЕ ДЕЛАЙ:
- шаблонный SaaS-дэшборд
- дефолтный AI-generated интерфейс
- скучные одинаковые карточки
- слабую типографику
- плоскую композицию
- визуально бедный UI
- повторяющиеся layout-паттерны
- остановку на первой рабочей версии

ДЕЛАЙ:
- премиальный, современный продукт
- сильную визуальную иерархию
- качественные отступы
- продуманную композицию
- аккуратную глубину
- цельную дизайн-систему
- выразительный, но не перегруженный интерфейс

UX требования:
- loading / skeleton
- empty states
- error states
- success states
- hover / focus / active / disabled
- first-time-user states
- онбординг
- качественная обратная связь на действия

Процесс:
1. Сначала определи архитектуру, route map, сущности и дизайн-систему
2. Потом собери app shell и базовые UI-примитивы
3. Потом реализуй основные экраны
4. Потом проведи UI/UX аудит
5. Улучши всё, что выглядит шаблонно, слабо или посредственно
6. Потом проведи Next.js / SEO / SSR аудит
7. Исправь найденные проблемы

Критерии качества:
- Это выглядит как реальный сильный продукт, а не шаблон?
- Есть ли сильная визуальная иерархия?
- Продуманы ли состояния?
- Достаточно ли хорошие отступы, типографика и композиция?
- Есть ли слабые generic-секции?

Если где-то ответ “нет” — исправь это до завершения.

Перед тем как писать код, спроектируй архитектуру продукта.

Сделай:
1. Краткое описание продукта
2. Пользовательские роли
3. Основные сущности
4. Route map для Next.js App Router
5. Разделение публичных и приватных страниц
6. Где использовать SSR / Server Components / Client Components
7. SEO-стратегию
8. Дизайн-систему:
   - цвета
   - типографика
   - отступы
   - радиусы
   - тени
   - контейнеры
9. Базовые UI-компоненты
10. Архитектуру API-слоя
11. Управление состоянием
12. Адаптивность
13. План реализации

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

Сейчас проведи полный UI/UX аудит и полировку.

Цель:
убрать ощущение шаблонного, слабого или AI-default интерфейса.

Проверь:
- типографику
- отступы
- визуальную иерархию
- композицию
- карточки
- навигацию
- читаемость ленты
- плотность информации
- состояния
- onboarding
- create flow
- страницу поста
- профиль автора

Исправь:
- всё, что выглядит как шаблон
- всё, что выглядит как MVP
- всё, что выглядит как дефолтный AI-UI
- всё, что визуально бедно или слабо

Улучшай:
- иерархию
- spacing
- UX
- состояния
- тексты
- ритм интерфейса
- ощущение премиального продукта

После этого еще раз проведи самокритику и улучши слабые места.

Проведи аудит приложения под Next.js.

Проверь:
- структуру роутов
- Server vs Client компоненты
- metadata
- SEO
- semantic HTML
- производительность
- accessibility
- загрузки и suspense
- масштабируемость структуры

Правила:
- публичные страницы — SEO + SSR где это уместно
- приватные — быстрые и интерактивные
- не злоупотребляй client-side
- правильно раздели server/client responsibilities
- убедись, что проект масштабируемый

Исправь найденные проблемы.

Практический вывод

Хороший prompt для Codex — это не “сделай сайт”, а четко заданная роль, четко описанный продукт, четкий стек, четкие дизайн-правила, четкие UX-состояния, жесткие запреты, порядок работы и обязательная полировка после первой реализации.

Тогда Codex перестает быть шаблонным генератором усредненного UI и начинает работать как управляемый инженерный инструмент.