Это исследование для тех, кто не писал код руками, но собирается построить полноценное приложение с помощью AI через подход specification-driven development. Оно про одну непонятную штуку, которая съест вам больше всего часов и нервов, если не знать о ней заранее. Читать 20–25 минут.

Привет, Хабр! С вами Василий Рассказов начальник отдела новых ИИ-решений X5 Tech. Сегодня расскажу, почему при разработке приложения с AI-ассистентом сложность часто прячется не там, где её ждёшь. База, логика и API собираются быстро, а интерфейс съедает недели. Разберём, как не провалиться в эту ловушку и построить приложение с помощью AI, даже если вы не пишете код руками.

Зачем это читать

Если вы не разработчик, но решили построить приложение от начала до конца с кодинг-ассистентом (типа Claude Code, Cursor или AWS Kiro) через методологию Specification-driven development (SDD), есть одна особенность современного веба, про которую надо знать заранее. Иначе вы потратите половину бюджета времени и денег там, где вообще не ждали.

Код интерфейса, по которому пользователь кликает, в среднем в 3–10 раз больше и сложнее, чем код сервера, который этот интерфейс обслуживает. Не потому, что разработчики плохо пишут. А потому, что так устроен современный веб.

Если понять это до старта, вы можете:

1. Правильно раскладывать время в плане проекта.

2. Правильно писать спецификации (детальнее на фронт, скупее на бэк).

3. Не удивляться, что AI-ассистент чаще всего ломается именно на интерфейсных задачах.

4. Не обижаться на себя, когда «собрал базу и логику за день, а экран пилю неделю». Это нормально.

Дальше будет длинный разбор с цифрами, таблицами и объяснением, откуда берётся перекос. Как мы сюда пришли: краткая хронология 2021–2026

Чтобы понять, зачем вообще обсуждать соотношение фронт/бэк в 2026 году, короткая контекстная перебивка.

2021. GitHub выпускает Copilot. Это ещё помощник программиста, который дополняет код. Программист остаётся программистом. Работает в связке «я пишу — он подсказывает».

Февраль 2025. Карпати публикует твит о vibe coding. Мир понимает, что уже можно не писать код вообще — просто разговаривать с машиной. Инструменты Cursor, Lovable, Bolt, Replit Agent, v0 становятся массовыми.

Июль 2025. AWS анонсирует Kiro — специальный редактор кода, построенный вокруг идеи spec-driven development. Заявленная цель Kiro — «увести разработчиков от vibe coding к viable code», то есть к работающему продакшн-коду. Kiro опирается на три файла спецификации: requirements.md (требования), design.md (техническая архитектура), tasks.md (пошаговый план).

Сентябрь 2025. GitHub открывает Spec Kit — свой open-source тулкит для SDD. К весне 2026 года он набирает больше 72 000 звёзд на GitHub — это уровень популярности, который для нового инструмента в open-source означает «индустриальный стандарт».

Декабрь 2025. Kiro становится общедоступным (general availability). Martin Fowler публикует разбор трёх основных SDD-инструментов: Kiro, SpecKit, Tessl. Его определение:

Spec-driven development — это когда вы пишете «спецификацию» до кода. Спецификация становится источником истины и для человека, и для AI. Martin Fowler, декабрь 2025

2026. По данным внутренних исследований Anthropic, инженеры используют AI примерно в 60% своей работы. А неразработчики, которые раньше вообще не могли сделать  приложение, теперь строят его за выходные. И чаще всего спотыкаются на одном и том же — на фронтенде.

Про это и речь.

Цифры: насколько фронт реально больше бэка

Соотношение объёма кода — самый прямой способ померить, где живёт основная сложность. Неидеальная метрика, но показательная.

Данные из реальных проектов

Вот что удалось собрать из открытых источников и отчётов команд.

Источники: Reddit, r/webdev, DEV Community — big frontend codebases.

Числа скачут от 4× до 20×, но направление везде одно — фронт перевешивает.

Типичная раскладка для среднего SaaS-проекта

Если взять среднестатистическое B2B-приложение (база, 20–30 экранов, формы, таблицы, роли, авторизация) на стеке Next.js + React на фронте и FastAPI + PostgreSQL на бэке — ожидаемая раскладка выглядит примерно так.

Бэкенд (FastAPI + PostgreSQL):

Фронтенд (Next.js + React):

Соотношение: ≈ 6:1 в пользу фронта.

Цифры — это модельная оценка, а не замер конкретного проекта. Они основаны на медианных значениях, которые я вижу в open-source и тех кейсах, где команды делятся статистикой. Для какого-то проекта будет 4:1, для какого-то 8:1, но 10 000 строк на бэке и 60 000 на фронте — это реалистичный порядок для среднего B2B-SaaS.

Грубая шкала по типам продуктов

Чтобы быстро прикинуть под свой кейс, вот таблица.

Проценты — это доля фронта в общем коде.

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

Откуда берётся этот перекос: анатомия фронтенд-кода

Фронт жирнее потому что бэкенд описывает, что у приложения есть, а фронтенд описывает, как человек этим пользуется. Первое — компактная правда. Второе — бесконечное множество сценариев.

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

1. Комбинаторный взрыв состояний интерфейса

Каждый элемент на экране — это не один «вариант», а набор состояний.

У простой кнопки «Сохранить» минимум 6–8 состояний:

И это только для одной кнопки. Теперь умножьте на 200 компонентов в среднем приложении, и получите сотни тысяч строк кода на одни только состояния.

На бэкенде «сохранить» обычно превращается в одну функцию на 15–40 строк, которая получает данные, проверяет их и кладёт в базу. Один успешный сценарий, несколько типов ошибок — и всё.

2. Количество компонентов

В типичном SaaS-проекте — 300–800 компонентов. В Jira их, по оценкам команд, больше 2 000. В каждом файле 50–300 строк. Это и есть основной пласт фронта.

Бэкенд же живёт в 20–50 эндпоинтах (точек API, к которым обращается фронт) и 20–30 моделях данных. Этого почти всегда хватает, чтобы обслужить всю функциональность таких приложений.

3. Дизайн-система и стили

На фронте живёт отдельный мир — дизайн-система. Это набор общих правил и компонентов, который показывает какого цвета заголовки, какой отступ между карточками, как выглядит состояние «форма отправляется», как ведёт себя приложение на экране 320 пикселей и на экране 2560 пикселей.

У типичного SaaS в дизайн-системе от 500 до 2 000 строк только в токенах (цвета, шрифты, отступы) и до 10 000 строк в базовых компонентах. У бэкенда этого просто нет.

4. Обработка ошибок — видимая глазами

Когда на бэке случается ошибка, программист её пишет одной строкой: raise HTTPException(status_code=404, detail="Not found"). 

Когда та же ошибка прилетает на фронт, начинается аттракцион. Нужно:

• показать пользователю что-то адекватное а не «Error 404» на белом фоне;

• сохранить данные формы, которую он заполнял, чтобы они не потерялись;

• дать ему кнопку «повторить», которая действительно пытается что-то повторить;

• записать инцидент в систему мониторинга, например, Sentry;

• подобрать правильный текст ошибки на нужном языке;

• не показать технические подробности, которые напугают;

• корректно вернуть пользователя в рабочее состояние после ошибки.

Это 50–150 строк на каждый сценарий ошибки, и таких сценариев десятки.

5. Зависимости. Много, правда много

Современный фронт — это не одна библиотека. Это связка из 15–30 пакетов (готовых кусков чужого кода), которые надо подключить, настроить и, подружить друг с другом.

Типичный набор для Next.js-проекта:

• React — базовая библиотека

• React Router или Next.js роутер — для навигации

• React Query или SWR — для общения с сервером

• Zustand или Redux — для управления состоянием

• React Hook Form — для форм

• Zod — для валидации данных

• Tailwind — для стилей

• shadcn/Radix UI — для компонентов

• Framer Motion — для анимаций

• date-fns — для дат

• i18next — для переводов

• Lucide — для иконок

• TanStack Table — для таблиц

• Recharts — для графиков

Каждая такая штука тянет за собой свои подзависимости. В итоге папка node_modules (куда загружаются все пакеты проекта) у среднего Next.js-проекта весит 400–700 мегабайт и содержит 1 000–3 000 пакетов.

На FastAPI-проекте аналогичная папка (.venv) обычно весит 100–200 мегабайт и содержит 30–80 пакетов. Разница больше, чем на порядок.

6. Локализация. Тихий убийца времени

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

В среднем мультиязычном SaaS на локализацию уходит 3 000–10 000 строк JSON-файлов и ещё 1 000–3 000 строк логики на фронте. На бэке — ноль. Сервер не знает, на каком языке читает пользователь. Он отдаёт данные, а переводит их уже фронт.

7. Accessibility. Доступность для всех

Современные требования обязывают делать интерфейсы доступными для людей с ограниченными возможностями. Главный стандарт: WCAG 2.2 (Web Content Accessibility Guidelines), опубликован в октябре 2023 года. Принцип POUR: Perceivable (воспринимаемый), Operable (управляемый), Understandable (понятный), Robust (надёжный).

В Евросоюзе с 2025 года по закону European Accessibility Act почти все цифровые сервисы должны соответствовать WCAG 2.2 Level AA. В США аналогичные требования давно закреплены в ADA и Section 508.

Практически это значит, что каждый интерактивный элемент на фронте должен уметь работать с клавиатуры (без мыши), быть понятным для программ чтения экрана (screen readers), иметь правильный контраст цветов, корректно читать экранными читалками. Это ещё +20–30% кода в компонентах, плюс отдельные aria-атрибуты.

На бэке такого понятия просто нет.

8. Клиентский роутинг и живой интерфейс

На сервере URL — это просто адрес функции. Пришёл запрос на /api/orders → запустилась функция → отдала данные → всё.

На фронте URL — это архитектура. Маршруты бывают вложенными и параллельными, с ленивой загрузкой, с layout-ами, с состояниями загрузки, с обработкой «нет интернета». Плюс живые обновления, когда данные меняются в реальном времени, оптимистичные апдейты (показали пользователю результат до того, как сервер ответил), кэш и его инвалидация, отмена отменённых действий (undo), автосохранение черновиков.

Это ещё один большой слой кода, которого на бэке нет в принципе.

Сводная таблица. Почему фронт раздувается

Сумма этих эффектов как раз и даёт тот самый 3–10-кратный перевес.

Почему AI-ассистент спотыкается именно на фронте

Вторая половина истории, про которую мало кто рассказывает до старта — это AI-ассистенты. Claude, GPT, Gemini и все, кто на них построен, делают на фронте больше ошибок, чем на бэке. Причин три.

Причина 1. Агент работает вслепую

Когда кодинг-ассистент пишет серверный код, он может его сразу проверить: запустить функцию, сравнить результат с ожиданием, прочитать логи. Это текст в текст. Ошибка сразу видна в консоли.

Когда тот же ассистент пишет интерфейс, он видит только HTML-разметку и CSS. Он не видит, как это отрисовалось в браузере. Кнопка может обрезаться, текст выходить за границы, модальное окно перекрывать меню, но ассистент об этом не знает, пока ему не расскажут.

Этот эффект разработчики называют «coding blind» — код вслепую. Видео с демонстрацией (например, «Claude Code + Playwright MCP = Perfect UI Every Time», август 2025) хорошо показывает типовой кейс. AI пишет страницу, она выглядит нормально в коде, но в реальном браузере текст обрезается и модалки накладываются друг на друга. Без механизма «посмотреть глазами» агент эти проблемы не ловит.

Причина 2. Решение — Playwright MCP, но про него надо знать

На эту проблему индустрия отреагировала инструментом под названием Playwright MCP:

• Playwright — это инструмент для программного управления браузером. С его помощью можно открывать страницы, кликать по кнопкам, делать скриншоты.

• MCP (Model Context Protocol) — протокол, который позволяет AI-ассистенту подключать внешние инструменты.

Связка Playwright + MCP даёт AI возможность открыть страницу, потыкать на ней, сделать скриншот, прочитать ошибки из консоли браузера и самостоятельно заметить, то что сломалось. Без этого агент пишет код, вы его запускаете, а он не работает. Вы объясняете словами, агент гадает. И так раз десять.

Debbie O’Brien из Microsoft формулирует это так:

«MCP-сервер может делать то, что раньше делал ты сам, будучи ручным тестировщиком».

Именно поэтому, если вы строите фронт через AI-ассистента, настраивать Playwright MCP стоит буквально в первый день. Без него каждая UI-правка становится в 3–5 раз длиннее из-за циклов «не то».

Причина 3. LLM любят скучные интерфейсы

Есть ещё одна проблема, которую нашли исследователи. Большие языковые модели, когда им говорят «сделай красивый UI», сваливаются на усреднённые, консервативные паттерны, такие как одинаковые карточки, одинаковые шапки, одинаковые кнопки. Это зафиксировано в академических работах.

Плюс text-only модели (те, которые работают только с текстом, а не с изображениями) плохо понимают пространственные отношения: где что расположено, что на что накладывается и что перекрывается. Это следствие того, что они обучены на тексте, а не на картинках.

Прикладной смысл такой. На бэке AI с первой попытки пишет код, близкий к промышленному уровню,  потому что задача структурная и текстовая. На фронте первая версия обычно выглядит как «студенческий проект 2015 года»: всё работает, но смотреть грустно. Нужны итерации, визуальные референсы, скриншоты, прогоны через Playwright MCP, подключение Figma MCP, отдельные промпты на «сделай посовременнее».

Это и есть вторая половина перекоса по времени. Код на фронте не только больше — он ещё и требует больше циклов с ассистентом, чтобы прийти в приличное состояние.

npm vs pip. Разные весовые категории

Один наглядный штрих, чтобы масштаб разницы стал физически ощутим.

npm — репозиторий пакетов для фронтенда и Node.js-бэкендов. Это общий склад, откуда фронтовые проекты качают себе готовые куски кода.

pip — аналогичный репозиторий для Python, откуда качают пакеты бэкенд-проекты на FastAPI, Django, Flask.

Вот их цифры:

Источник: State of NPM 2023. Для pip — открытые данные PyPI.

То есть во «фронтовом мире» пакетов в 5,4 раз больше по количеству и в 4.8 раз больше по размеру, чем в «бэковом мире». А средний проект тянет в 30–50 раз больше внешних зависимостей. Это ощутимая разница в размере и сложности.

Когда вы просите AI-ассистента «собрать проект на Next.js», он за пару минут подтягивает десятки мегабайт чужого кода с потенциальными конфликтами версий, breaking changes и уязвимостями. Когда вы просите «собрать бэк на FastAPI», он подтягивает в 30 раз меньше, и пазл обычно собирается чище.

Что всё это значит на практике. Чек-лист, если вы не-программист с SDD и AI-ассистентом

Теперь восемь конкретных вещей, которые окупятся на любом SDD-проекте с AI-ассистентом.

1. Планируйте время 70/30 в пользу фронта

Если вам кажется, что проект займёт 10 дней — закладывайте 7 дней на фронт, 3 на бэк.

2. Пишите спецификации асимметрично

В requirements.md и design.md вашего SDD-проекта бэкенд спокойно описывается короткими блоками «есть такие эндпоинты, такие модели данных, такие права». 2–3 страницы, и их хватит.

А вот UI нужно описывать в разы подробнее. Все состояния по каждому экрану —, все ошибки, все пустые состояния (empty states), все кейсы на мобилке, все анимации и переходы. Kiro и Spec Kit прямо рекомендуют использовать для UI  формат EARS (Easy Approach to Requirements Syntax). Это чёткие шаблоны типа «Когда <событие>, если <условие>, то система должна <поведение>». Для каждого экрана по 10–30 таких строк.

А если есть Figma-макеты, подключайте Figma MCP. Это протокол, который позволяет AI-ассистенту прочитать макет и опереться на него, вместо того чтобы «додумывать» дизайн из воздуха.

3. Подключите Playwright MCP с первого дня

Это, возможно, самый высокий ROI-совет в статье. Без визуальной проверки AI будет крутиться в циклах «не то → исправил → всё равно не то». С Playwright MCP агент сам открывает браузер, делает скриншот, видит проблему и сам её фиксит. В Claude Code это настраивается одной командой.

4. Сначала соберите дизайн-систему, потом экраны

Распространённая ошибка сразу начать собирать экраны, а кнопки, поля и карточки лепить на каждом экране заново. Через 20 экранов у вас будет 20 разных кнопок, у каждой своё поведение и свой цвет. Починить это позже — отдельный ад.

Правильный порядок: сначала общий набор компонентов (design tokens + базовые UI-элементы вроде Button, Input, Card, Modal), а потом уже экраны, собранные из этих кубиков. AI-ассистенты типа Claude и Cursor хорошо понимают паттерн shadcn/ui. Можно прямо в спецификации написать «используй shadcn/ui как основу» и дальше работать через него.

5. Заложите отдельный блок времени на accessibility

Если вы в ЕС, в США или работаете с госсектором, то доступность не опция, а закон. Лучше потратить 2 дня на то, чтобы с самого начала сделать интерфейс клавиатурно-навигабельным и screen-reader-совместимым, чем потом переписывать половину проекта под аудит.

Попросите AI-ассистента делать ревью на соответствие WCAG 2.2 Level AA. Большинство современных моделей с этим справляются, если явно поставить такую задачу.

6. Настройте визуальное тестирование заранее

Регресс-тесты на фронте — отдельная дисциплина. Скриншот-тесты (когда браузер делает снимки страниц и сравнивает с эталонами) ловят до 80% визуальных багов, которые бы пропустил человек. Playwright умеет делать это прямо из коробки.

7. Не пытайтесь сделать всё в одном репозитории

Разделите проект на две части: фронт и бэк. Это даст AI-ассистенту более чёткий контекст и позволит работать над ними независимо. Плюс  упростит передачу проекта профессиональным разработчикам, если они в какой-то момент подключатся.

8. Держите в голове «бюджет сложности» UI

Каждый новый экран прибавляет несколько сотен строк кода, плюс новые состояния, плюс интеграция с API, плюс локализация и accessibility. 20 экранов дают 20 таких пакетов.

Поэтому ещё на фазе планирования, задайте себе вопрос: «этот экран правда нужен, или вам просто так хочется?». Каждый ненужный экран, вычеркнутый из плана, экономит день-два работы. Посмотрите на Linear, Superhuman, Notion, которые беспощадно режут количество UI-элементов. Это их сознательная стратегия, чтобы приложение не расплылось.

Всё это и многое другое я разбираю в своём блоге. Пишу о том, как AI меняет разработку, обучение, автоматизацию и работу компаний: от агентов, GitHub, MCP и Claude Code до корпоративных стратегий, безопасности, рынка труда и обучения взрослых. Если вам близка идея строить продукты через AI, но хочется лучше понимать, что происходит под капотом, заходите.

Что в итоге держать в голове

Если резюмировать всё вышесказанное, перечийте перед стартом каждого SDD-проекта:

Если у вас будет это понимание до старта — вы сэкономите недели. А в худшем случае сохраните сам проект, который без такого понимания обычно застревает где-то на середине, когда «бэк готов, а UI не склеивается».

Материалы, на которых построена статья:

• Martin Fowler — Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl

• AWS Kiro — официальный блог

• InfoQ — Beyond Vibe Coding: Amazon Introduces Kiro, the Spec-Driven Agentic AI IDE (август 2025)

• Microsoft Developer Blog — Diving Into Spec-Driven Development With GitHub Spec Kit (сентябрь 2025)

• Andrej Karpathy — оригинальный твит про vibe coding (февраль 2025)

• Wikipedia — Vibe coding

• Business Insider — The year coding changed forever (декабрь 2025)

• Gartner / Planet Crust — прогноз citizen developers 4:1 к 2025

• Reddit r/webdev — 4.6× больше кода во фронте

• DEV Community — Some things I learnt from working on big frontend codebases

• State of NPM 2023

• WCAG 2.2 — объяснение стандарта

• Playwright MCP + Claude Code — гайд

• Anthropic — 2026 Agentic Coding Trends Report

• ArXiv — The role of LLMs in UI/UX design

• Spec-Driven Development 2025 Guide — dplooy

Также можно прочитать статьи об управляемой разработке с ИИ, интерфейсах и инженерной дисциплине вокруг AI-инструментов:

– От vibe coding к Spec-Driven Development: как приручить скорость ИИ и довести проект до продакшена
– Как я подключил Obsidian к Claude и Codex: домашний сервер, CouchDB, MCP и баг, который съедал заметки