Я провел эксперимент с AI для кодинга: создал prod-ready лендинг на Next.js тремя способами, используя разную степень детализации контекста для Claude Code. 1300 строк спецификации дали код на 8/10. Минимум контекста – только 4/10. Но быстрый старт за 11 минут обернулся 3+ часами доработок.
Дальше – результаты трех экспериментов, технический анализ кода и правила выбора подхода.
Зачем этот эксперимент
Постоянно спорят: больше контекста для AI – хорошо или плохо? Одни говорят: "Чем детальнее опишешь, тем лучше". Другие: "Минимум информации – AI разберется сам".
Я решил проверить на практике. Взял реальную задачу – создание лендинга с Claude Code – и сделал его тремя способами:
- Максимальная детализация – 1300 строк спецификации, MCP-сервер, два саб-агента
- Сбалансированный подход – ~100 строк спецификации, без дополнительных инструментов
- Минимализм – только tech-stack и описание проекта
Какой подход даст лучший результат – скорость? качество кода? минимум доработок?
Спойлер: выбор был сложным и неоднозначным, но мой голос пал на первый вариант. А почему – расскажу дальше.
Задача: создание лендинга на Next.js с помощью AI
Что создаю – лендинг о важности подготовки контекста для AI-агентов.
Tech stack:
- Next.js (14 или 15)
- TypeScript
- Tailwind CSS
- shadcn/ui компоненты
- next-themes (светлая/темная тема)
- lucide-react (иконки)
Что должно быть на лендинге:
- 9 секций: Header, Hero, Problem, Solution, Best Practices, Metrics, Examples, CTA, Footer
- Светлая и темная тема с плавными переходами
- Адаптивная верстка (mobile-first)
- Валидация форм
- Hover эффекты и анимации
Критерии оценки:
- Скорость создания первого прототипа – сколько минут от промпта до готового результата
- Соответствие ожиданиям – визуальное качество, работоспособность, детали
- Потенциальные доработки – сколько времени нужно на правки до production-состояния
Дополнительно оцениваю качество кода: архитектуру, типизацию, расширяемость, поддерживаемость. Оценка производится на основе собственного здравого смысла и мнения двух других флагманских моделей, так как я не являюсь экспертом в области фронтэнд-технологий.
Эксперимент 1: Максимальная детализация (1300 строк)
Подход – создал детальную спецификацию на 1300 строк с полным описанием всех секций, компонентов, стилей и требований. Подключил MCP-сервер для работы с контекстом и два специализированных AI-агента: Tailwind Frontend Expert и Frontend-Developer.
Время работы агента: 27 минут
Самый долгий вариант. 30+ минут на спецификацию, остальное – разработка. Но вот что интересно: больше времени на подготовку = меньше правок потом.
Спецификация (1300 строк, у меня было собственное ТЗ, но мне нужно было его растянуть на 1000+ строк. Perplexity с этим мне помогла)
Работа шла по этапам:
- AI-агенты изучили спецификацию
- Tailwind Frontend Expert спроектировал компонентную архитектуру
- Frontend-Developer реализовал код
- MCP-сервер помог с организацией файлов, структурой проекта, получением контекста по компонентам. Каким MCP чаще всего пользуюсь, рассказывал вот тут
Что хорошо:
- Цвета, анимации, последовательность блоков – всё по спецификации
- Код понятный и хорошо структурированный
- Модульная архитектура с разделением на sections/, cards/, forms/, providers/
- Все компоненты переиспользуемые
- Централизация данных в lib/constants.ts (но вынесен не весь текст)
Что не так:
- Выжженные цвета в темной теме (слишком яркие, надо приглушить)
- Блок "Процесс подготовки" не до конца корректно сформирован
- Некоторые анимации слишком активные
Технологии (на момент эксперимента):
- Next.js 15.1.4 + React 19.0.0 (актуальная stable версия)
- Tailwind CSS 3.4.1 (на момент эксперимента; актуальная в 2026: v4.1)
- Radix UI (3 компонента) + shadcn/ui
- next-themes 0.4.6
- lucide-react 0.562.0
Примечание: Эксперименты проведены в январские каникулы 2026 года. На январь 2026 актуальны Next.js 16.1, React 19.2, Tailwind CSS v4.1. Описанные принципы остаются актуальными независимо от версий.
Архитектура веб приложения и качество кода
Качество кода:
- TypeScript Strict Mode: ✅
- Отдельный файл типов (types/index.ts): ✅
- Централизация данных: ✅ (большая часть контента в constants.ts)
- Модульность: ✅ (5 специализированных типов карточек)
- Email валидация: ✅ (regex + детальные сообщения ошибок)
Общая оценка: 8/10
Первый подход выиграл по архитектуре. Модульная структура, централизация данных, специализированные компоненты – проект готов к масштабированию.
Да, разработка дольше в 2 раза. Но доработок минимум – всего 30 минут на цвета и мелкие баги.
Эксперимент 2: Сбалансированный подход (~100 строк)
Подход – сократил спецификацию в 13 раз (до ~100 строк). Оставил только ключевые моменты: tech stack, описание проекта, основные секции и требования к дизайну. Отключил MCP-сервер и дополнительных AI-агентов. Работа напрямую с базовым Claude Code.
Время работы AI-агента: 14 минут
Спецификация: (100 строк)
Работа шла линейно:
- Дал промпт с краткой спецификацией
- Claude Code создал структуру проекта
- Реализовал все секции последовательно
- Добавил темную тему и адаптивность
Что хорошо:
- Визуально зашел даже больше первого
- Темная тема получилась значительно лучше (более сбалансированные цвета)
- Простая и понятная структура
- Хорошая документация (README.md присутствует)
Что не так:
- Нет анимаций при переходе между секциями (есть только притормаживание)
- Ошибки в консоли при первом запуске
- Данные размазаны по компонентам (нет централизации)
- Валидация формы базовая
Технические характеристики
Технологии:
- Next.js 14.2.0 (отстаёт на 2 мажорные версии: 14 → 15 → 16)
- Tailwind CSS 3.4.0
- Radix UI (1 компонент) + shadcn/ui
- next-themes 0.3.0 (старая версия)
- lucide-react 0.344.0
Архитектура:
Качество кода:
- TypeScript Strict Mode: ✅
- Отдельный файл типов: ❌
- Централизация данных: ❌ (данные локально в секциях)
- Модульность: ⚠ (базовый Card из shadcn/ui)
- Email валидация: ✅ (regex)
Общая оценка: 6/10
Второй эксперимент – золотая середина по времени. 14 минут на разработку – неплохо. Визуально результат даже лучше первого.
Но есть нюансы:
- Устаревшие версии библиотек
- Нет централизации данных (сложнее поддерживать)
- Слабее архитектура
Для среднего проекта или быстрого прототипа – отличный вариант. Для production с планами роста – потребуются доработки (1-2 часа).
Эксперимент 3: Минимализм (базовая спецификация)
Подход – минимум информации. Дал только tech stack и краткое описание проекта (2-3 предложения). Без детализации секций, без требований к дизайну, без спецификации компонентов. Claude Code сам решает, как всё делать.
Время: 11 минут
Спецификация: (10 строк)
Самый быстрый из всех экспериментов. Минимум на подготовку (1 минута), максимум на реализацию (10 минут).
Работа была предельно простой:
- Дал минимальный промпт
- Claude Code создал структуру
- Реализовал базовые секции
- Добавил shadcn/ui компоненты со стандартными стилями
Что хорошо:
- Очень быстро (11 минут)
- React 19.0.0 (последняя стабильная мажорная версия на момент эксперимента)
- Структура простая – легко навигироваться
- Работает из коробки
Что не так:
- Результат безвкусный и шаблонный
- Стандартная цветовая тема Shadcn без кастомизации
- Нет анимаций и переходов вообще
- Добавлен лишний блок Pricing – варианты продаж, которых не было в задаче
- Нет кнопок "Связаться", "Купить"
- Обработка ошибок через alert() вместо нормальных уведомлений
- Слабая валидация формы (только HTML5)
Технические характеристики
Технологии:
- Next.js 15.1.4 (актуальная на момент эксперимента; в 2026: v16.1)
- React 19.0.0
- Tailwind CSS 3.4.17 (последняя версия v3; в 2026 актуальна v4.1)
- shadcn/ui (6 компонентов)
- next-themes 0.4.4
- lucide-react 0.468.0
Архитектура:
Качество кода:
- TypeScript Strict Mode: ✅
- Отдельный файл типов: ❌
- Централизация данных: ❌
- Модульность: ❌ (плоская структура)
- Email валидация: ⚠ (только HTML5 required)
Общая оценка: 4/10
Третий эксперимент – самый быстрый, но с наибольшим количеством доработок. 11 минут экономии = 3+ часов на исправления:
- Реорганизация структуры (плоская → модульная)
- Централизация данных
- Замена alert() на нормальные уведомления
- Улучшение валидации форм
- Кастомизация дизайна (убрать шаблонность)
Подходит для быстрых экспериментов и MVP, где визуал и архитектура не критичны. Для production – только после рефакторинга.
Сравнение результатов: кто выиграл?
Эксп. 1 выигрывает с большим отрывом:
- Модульная структура: components/sections/, cards/, forms/
- Централизация данных в lib/constants.ts (один источник правды)
- TypeScript интерфейсы в types/index.ts (переиспользование типов)
- Специализированные компоненты для разных типов контента
Эксп. 2 и 3 используют упрощенную/плоскую структуру. Данные размазаны по компонентам. Нет четкого разделения по типам.
Поддерживаемость
Эксп. 1 проще поддерживать:
- Один источник данных (lib/constants.ts)
- Четкая структура папок
- Специализированные компоненты (легко найти нужный)
Эксп. 2/3 сложнее:
- Данные размазаны по файлам
- Плоская/смешанная структура
- Универсальные компоненты (нужно читать код, чтобы понять логику)
Почему я выбрал вариант 1
Да, на разработку ушло 27 минут (против 11-14 в других). Но доработок нужно всего ~30 минут:
- Исправить цвета в темной теме
- Подправить блок "Процесс подготовки"
- Приглушить некоторые анимации
Итого: 27 + 30 = час до production.
Для сравнения:
- Эксп. 2: 1-2 часа (обновление зависимостей, централизация данных)*
- Эксп. 3: более 3-ех часов (рефакторинг архитектуры, улучшение валидации, дизайн)*
Когда проект живет больше месяца, архитектура становится важнее скорости разработки.
Время на подготовку окупается
30 минут на подготовку детальной спецификации = экономия часов на:
- Правках после первой версии
- Рефакторинге кода
- Добавлении новых фич
- Обновлении контента
* Есть важный момент. Время доработки формировалось из условий, что человек только-только пробует так называемый vibe-кодинг. В умелых руках, что-то поправить в эксперименте 2 или 3 – может занять кратко меньше времени. Особенно если человек обладает экспертизой, насмотренностью и умением писать эффективные prompt-запросы.
Практические выводы: когда использовать какой подход
На основе трех экспериментов я вывел 5 правил, которые помогут выбрать оптимальный баланс между детализацией контекста и результатом.
Этот эксперимент – пример vibe coding в действии: интуитивная разработка с помощью AI для кодинга, где важнее понимание цели, чем написание каждой строки кода вручную.
Правило 1: Выбирайте детализацию по целям проекта
Не существует универсального ответа "больше контекста = лучше". Всё зависит от цели.
MVP / быстрый прототип → Эксп. 3 (Минимализм)
- Подходит для: тестирование идеи, демо, proof of concept
- Ожидание: доработаете потом или выбросите
Production с планами роста → Эксп. 1 (Максимальная детализация)
- Подходит для: коммерческие проекты, долгосрочная поддержка, команда разработчиков
- Ожидание: минимум правок, готов к масштабированию
Средний проект / быстрый запуск → Эксп. 2 (Сбалансированный)
- Подходит для: pet-проекты, внутренние инструменты, средний срок жизни (около месяца)
- Ожидание: умеренные доработки
Правило 2: Инвестируйте время в источники правды
Эксперимент 1 показал мощь централизации. Вместо повторения инструкций в каждом промпте создайте файлы-источники правды:
Что создавать:
- DESIGN_SYSTEM.md – цвета, шрифты, отступы, компоненты
- REFERENCE.md – описание дизайна секций
- CODE_STYLE.md – правила кода, архитектура, паттерны
- API_SPEC.md – спецификация API
Преимущества:
- AI всегда видит актуальную информацию
- Консистентность гарантирована
- Легко обновлять (статичные файлы вместо десятков промптов)
Правило 3: MCP и AI-агенты для сложных проектов
Когда MCP и агенты окупаются:
- Пробуете новые версии библиотек и LLM ещё о ней не знает
- Сложная предметная область
- Интеграция с внешними системами
Что дает MCP:
- Помогает организовать структуру проекта
- Следит за консистентностью
- Предлагает архитектурные решения
- Получение актуального контекста
- Возможности отладки (например через Playwright организовать E2E тестирование)
Когда можно без MCP:
- Быстрые прототипы
- Pet-проекты
- Learning проекты
- Одноразовые скрипты
Правило 4: Баланс между скоростью и качеством
Звучит логично: быстро = экономия времени. Но нет.
Экономия N минут на старте (Эксп. 3 vs Эксп. 1) = потеря N минут на доработках.
Инвестируйте время в подготовку, если проект будет жить дольше недели. Для одноразовых задач – минимализм оправдан.
Правило 5: Новый чат для каждой проблемы
Если с первого промпта не завелось – не пытайтесь чинить в том же чате. Создавайте новый.
Почему это важно:
Когда AI генерирует код с ошибками, контекст "загрязняется". В истории чата остаются:
- Неработающий код
- Ошибки компиляции
- Попытки исправлений
- Ваши комментарии "это не работает"
AI начинает опираться на этот битый контекст и генерирует новые правки поверх сломанного кода.
Правильный workflow при ошибках:
Шаг 1: Зафиксируйте проблему
"AI сгенерировал компонент Hero, но: - Цвета не те (использует #000000 вместо #0a0a0a) - Анимация не работает - TypeScript ругается на типы"
Шаг 2: Откройте НОВЫЙ чат
Шаг 3: Дайте чистый промпт
"Создай компонент Hero по спецификации DESIGN_SYSTEM.md. Требования: - Цвет фона #0a0a0a (из DESIGN_SYSTEM.md) - Fade-in анимация через framer-motion - Строгая типизация TypeScript"
Что это дает:
- AI видит задачу с чистого листа
- Нет битого контекста
- Свежий взгляд на проблему
- Меньше шансов повторить ошибку
Когда можно продолжать в том же чате:
- Мелкие стилистические правки (цвет, отступ)
- Добавление новой независимой фичи
- Рефакторинг работающего кода
Когда нужен новый чат:
- Код не компилируется
- Логика работает неправильно
- После 3-х неудачных попыток исправить
- Ошибки TypeScript/ESLint не уходят
Я уже писал про это – про то, как наш мозг работает как одноядерный процессор, и AI не исключение. Перегруженный контекст = хуже результаты.
Заключение
Три эксперимента показали: больше контекста – не всегда лучше. Минимализм – не всегда быстрее.
Мои рекомендации:
- Для learning / MVP: минимальный контекст (Эксп. 3) – быстро, доработаете потом
- Для серьезных проектов: детальный контекст (Эксп. 1) – дольше старт, но меньше боли потом
- Для баланса: средний контекст (Эксп. 2) – золотая середина
Детализация контекста – это не про "больше или меньше". Это про соответствие целям проекта. Выбирайте подход осознанно, экспериментируйте и находите свой баланс.
Если вы работаете с AI для кодинга или только начинаете использовать Claude Code / Cursor для разработки, этот эксперимент показывает: детализация контекста – не просто техника промпт инжиниринга, а инвестиция в качество архитектуры веб приложения.
А какой подход используете вы? Делитесь в комментариях – интересно узнать ваш опыт с детализацией контекста для AI.