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

2026-06-29

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

---

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

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

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

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

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

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

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

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

Почему так происходит

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

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

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

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

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

Что такое Spec Coding

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как это работает на практике

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что для этого есть на платформе

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

Блок 3 — тариф Basic.

---

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

[Архитектура приложения как здание](/blog/app-architecture-as-building) — чтобы правки шли по адресу.

[Промпт на 30 000 знаков](/blog/prompt-30000-characters) — как выглядит настоящее описание.

[От прототипа к продукту](/blog/prototype-to-product) — что добавлять после того, как стабилизировалось.

[Скиллы для Claude Code](/blog/claude-code-skills-guide) — цепочки вместо одной просьбы.