Почему проект разваливается на третьей правке и что такое Spec Coding

2026-06-29

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

Коротко, если нет времени

Первый заход даёт восторг, третий — тупик: правка формы ломает меню, починка меню ломает блок из второго захода.

Причина структурная: у проекта нет описания, есть только история просьб. Модель каждый раз достраивает контекст заново.

Spec Coding — другой порядок работы: сначала описание, потом код, и правки идут в описание, а не в код.

Описание — не техническое задание на сорок страниц, а шесть пунктов, которые задают проект.

Особенно это важно, когда код пишете не вы: программист держит проект в голове и помнит, почему сделано так, — у вас этой памяти нет, её заменяет описание.

Описание одновременно является техническим заданием для заказчика — то есть работа не удваивается.

Шаблоны сайтов устроены ровно по этому принципу: 343 промпта, в среднем около 10 000 знаков, самые проработанные — до 75 000.

Первый день восторг, третий — тупик

Знакомая кривая для всех, кто пробовал собирать что-то с нейросетью.

Первый заход. Описали идею, получили работающую страницу. За вечер. Восторг.

Второй. Попросили добавить блок — добавила, всё работает. Ещё восторг.

Третий. Попросили поменять форму — поменяла, но перестало работать меню. Чините меню — ломается блок из второго захода.

Пятый. Вы уже не помните, что там было изначально, модель тоже. Проще начать заново.

И многие начинают заново — по третьему разу.

Причина не в том, что модель тупеет. Причина в том, что у проекта нет описания, а есть только история просьб.

Почему правки ломают проект

Разберём механику, потому что без неё непонятно, что чинить.

Модель не помнит ваш проект. Она видит то, что вы ей показали в этом разговоре. Всё, что решалось раньше и осталось у вас в голове, для неё не существует.

Каждая просьба — новая задача без контекста. Вы говорите «поменяй форму», модель меняет форму. Она не знает, что три захода назад вы договорились, что данные из формы идут в определённое место в определённом виде. Она это переделает, потому что ей никто не сказал.

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

Это не проблема конкретной модели и не проблема плохих промптов. Это структурная проблема работы «по просьбам».

Что такое Spec Coding

Другой порядок работы. Одно слово вместо всего объяснения: сначала описание, потом сборка.

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

Разница выглядит так.

Работа по просьбам: просьба → результат → правка → результат → правка → хаос.

Работа по описанию: описание → сборка → изменение в описании → пересборка нужной части.

Ключевое во второй схеме: правится не проект, а его описание. Проект приводится в соответствие. Поэтому изменения не накапливаются как слой заплаток — они всегда согласованы с одним источником.

Что входит в описание

Не техническое задание на сорок страниц. Достаточно шести пунктов.

Что это и для кого. Одна-две фразы. Кому это нужно и какую задачу решает. Без этого модель делает «вообще», а не «для этого».

Экраны и что на них. Перечень страниц или состояний с содержимым каждого.

Что происходит при действиях. Нажали кнопку — что случилось. Отправили форму — куда упало. Ввели неверные данные — что показалось.

Где хранятся данные. Что должно сохраниться, а что живёт только в сессии.

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

Что уже работает и трогать нельзя. Список готового. Именно он спасает от того, что третья правка ломает вторую.

Как Spec Coding работает на практике

Шаг 1. Опишите до первого запроса. Шесть пунктов выше. Двадцать минут работы — и они окупятся на второй же правке.

Если формулировать трудно, попросите модель составить описание по вашей идее: вы описываете задачу словами, получаете структурированный документ, дальше правите его. Править готовое быстрее, чем писать с нуля.

Шаг 2. Собирайте по описанию. Отдавайте документ целиком, а не пересказ.

Шаг 3. Меняйте описание, а не проект. Понадобилось новое — сначала внесите в документ, потом просите изменение со ссылкой на обновлённый текст.

Шаг 4. Держите список неприкосновенного. Каждая просьба о правке заканчивается фразой, что именно менять нельзя. Это одна строка, и она предотвращает большую часть поломок.

Шаг 5. Проверяйте после каждой правки не только новое. Проверять надо и то, что работало раньше. Пять минут против часа разбирательств.

Почему это особенно важно, когда код пишете не вы

Программист, который писал руками, держит проект в голове: он помнит, почему сделано так, и не сломает это случайно.

Вы этого не помните, потому что не писали. И модель не помнит, потому что не хранит.

Описание заменяет то, чего нет ни у вас, ни у неё, — общую память проекта.

Отсюда неочевидный вывод: чем меньше вы разбираетесь в коде, тем важнее для вас описание. Оно не для модели, оно для вас.

Что это даёт в работе с заказчиком

Описание — это и есть техническое задание. Тот же документ показывается клиенту до начала: вот что получится. Согласовали — собрали.

Оно закрывает бесконечные правки. «Устранение замечаний до полного удовлетворения заказчика» — формулировка, из-за которой исполнители работают месяцами бесплатно. Замечания принимаются в пределах согласованного описания, всё остальное — отдельная работа за отдельные деньги.

Оно защищает при передаче. Проект с описанием передаётся другому человеку. Проект без описания — не передаётся никак, и это ваша же проблема, когда захотите передать.

И оно обосновывает цену. Заказчик, который видит документ из шести разделов, спорит с позициями, а не с итоговой суммой.

Что для Spec Coding есть на платформе

Шаблоны сайтов — 343 промпта, и они устроены ровно по этому принципу. Каждая карточка не «сделай лендинг», а полное ТЗ: структура, типографика, цвета, поведение анимации при наведении и прокрутке. В среднем около 10 000 знаков, самые проработанные — до 75 000.

То есть описание уже написано за вас, и написано тем, кто знает, что туда должно входить. Превью видно до запуска.

Промпты не привязаны к конкретному сервису: вставляются в любую среду, которая умеет писать код. Тариф Plus.

Скиллы для Claude Code — более 10 000. Скилл это цепочка агентов, где задача разбита на части и каждая передаётся дальше, — та же логика, что и Spec Coding, только внутри одного инструмента. Каталог открыт всем, файлы с Basic.

Ассистенты категории «Инженеры» — с Basic. Помогут составить описание по вашей идее.

Регистрация бесплатная и открывает три дня доступа к Basic целиком.

С чего начать сегодня

Одно действие. Возьмите проект, который у вас разваливается, и напишите по нему шесть пунктов задним числом. Особенно последний: что уже работает и трогать нельзя.

Двадцать минут. Дальше следующую правку просите со ссылкой на этот документ и с явным списком неприкосновенного.

Обычно после этого проект перестаёт ломаться сразу — не потому, что модель стала умнее, а потому, что у неё наконец появилось то, чего не было: описание того, что она чинит.

Почему описание работает: механика каскадов

Spec Coding — частный случай общего принципа, и в курсе «Базовый промптинг» он разобран отдельно.

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

Зачем это нужно — формулировка из урока: каждый отдельный запрос точечно сфокусирован, модель не распыляется и решает конкретный подвопрос. Вы контролируете каждый шаг, проверяете промежуточные ответы и направляете дальше.

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

Итог, который объясняет всю статью: вы ведёте нейросеть по чёткому плану, как сценарист. Описание проекта — это и есть такой план, только записанный один раз и переиспользуемый.

Курс «Базовый промптинг» (урок «Каскадные промпты») — тариф Basic.

Где учат писать спеку до кода

Экспресс-курс «Claude: от первой подсказки до собственной библиотеки мега-способностей», тариф Creator и выше ($9) — восемь тегов мега-промпта: роль, цель, задача, структура ответа, ограничения, критерии успеха. Это и есть спека, только для модели. Формулировка из курса: понял структуру один раз — перестал искать удачные промпты в чатах, потому что собираешь свои за пять минут.

Экспресс-курс «Бюро персональных ИИ», тариф Creator и выше ($9) — проектирование до сборки.

Экспресс-курс по Gemini («Google Gemini + команда из 12 Gems…», $9, Creator и выше) даёт ту же рамку иначе: роль, контекст, обзор задачи, пошаговые инструкции, ограничения, критерии успеха. Шесть блоков заполняются под задачу — на выходе промышленный промпт.

Готовые ТЗ как образец объёма. Раздел Шаблоны сайтов, тариф Plus — промпты в среднем около 10 000 знаков, самые проработанные до 75 000. Это полная спецификация на несколько десятков страниц. Полезно открыть один и посмотреть, что в нём описано: обычно там есть всё, о чём вы вспомните на третьей правке.

Ассистенты, тариф Basic: Prompting Assistant, GPT Prompt Master, Архитектор ботов.

Скиллы, где спека встроена в процесс

Статья объясняет, почему проект рассыпается. Эти инструменты не дают начать писать код, пока спека не согласована. Все они продвинутые скиллы: Creator+, либо $9 разово, либо 1 000 XP.

Спецификация перед написанием кода — четыре фазы с воротами: описать, спланировать, разбить на задачи, реализовать. Каждая требует явного одобрения. Для крупных задач есть нулевая фаза — проверка, не сидит ли внутри одного запроса несколько независимых кусков
Spec Kit — разработка по спецификации с ИИ — открытый набор процессов и команд /speckit-*: сначала фиксируется, что и зачем строится, затем план, задачи и реализация
Разработка через спецификации — семь этапов от обсуждения до архива, с требованиями в формате «должно» и критериями в структуре «дано — когда — тогда»
Техническая спецификация — шесть обязательных разделов, и главный из них последний: условия готовности как исполняемые команды с ожидаемым результатом. Не «работает», а конкретная проверка
Фиксация критериев приёмки — замораживает определение готовности до начала работы. Любая попытка переписать требования по ходу становится видна в истории изменений
Разбивка на подзадачи — вертикальными срезами: каждый кусок даёт работающий результат, а не половину функции. Контрольные точки каждые две-три задачи
Пошаговый план разработки — цель, границы, что делать не будем, риски, список файлов. Раздел «не будем» здесь важнее остальных
Анализ влияния изменений — прямо про третью правку из заголовка: что ещё затронет это изменение

Что забрать без установки чего-либо. Формат из четвёртого пункта: условие готовности должно быть командой, которую можно выполнить, а не фразой «должно работать». Разночтения возникают ровно там, где готовность описана словами.

Что взять на платформе под эту задачу

Базовый промптинг — курс, в нём урок «Каскадные промпты»; тариф Basic.
VIBE CODING — курс: от идеи к чёткому техническому заданию и сборке приложения; тариф Creator.
Spec Kit — разработка по спецификации с ИИ — скилл; продвинутый (Creator+, $9 или 1 000 XP).
Спецификация перед написанием кода — скилл; продвинутый (Creator+, $9 или 1 000 XP).
Prompting Assistant — ассистент: создание и оптимизация промптов; с Basic.
Шаблоны сайтов — 343 полных ТЗ-промпта; тариф Plus.

Что почитать дальше

Архитектура приложения как здание — чтобы правки шли по адресу.

Промпт на 30 000 знаков — как выглядит настоящее описание.

От прототипа к продукту — что добавлять после того, как стабилизировалось.

Скиллы для Claude Code — цепочки вместо одной просьбы.

Claude Code + NotebookLM — где держать исследование, которое не влезает в контекст.