learn-se · Урок 4 · ~15 минут

Спека как делегирование: писать ТЗ быстро

Твоя боль: одно предложение разрослось в страницу, и это долго. Решение — не писать спеку руками. Пиши её вместе с агентом, а сам будь редактором.

Сначала — зачем вообще спека (а не одно предложение)

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

Твоё решение в спеке	Что выйдет из одного предложения
форма только в окно `check-in-weekday`	форма доступна всегда — гейтинг исчез
день назначают клиент и тренер (LWW)	расписания нет вообще
офлайн-очередь, eventual consistency	online-only — в зале без сети потеряется

Одно предложение → generic-версия. Спека → твоя версия. Ценность спеки пропорциональна тому, насколько твой замысел отклоняется от дефолта модели. Для тупого CRUD спека — overkill (см. «когда вредно», урок 1); для фичи с продуктовым суждением спека — то место, где твой продукт существует.

Петля: автор → редактор

Ключ к скорости — сменить роль. Распознавать пробелы в готовом тексте легче, чем сочинять с нуля (ты сам это доказал на дрилле: чужие ошибки видел, свои в момент письма — нет).

Рабочая петля

1. Пишешь одно предложение.
2. Просишь агента: «разверни в спеку-черновик: Given/When/Then, перечисли edge cases и открытые вопросы, ничего не реализуй».
3. Ты — редактор: принимаешь / режешь / решаешь открытые вопросы.
4. Отдаёшь отредактированную спеку в работу.

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

Дисциплина редактора

Отвечать на вопросы черновика мало. Хороший редактор делает четыре вещи (все — из нашего разбора чек-инов):

Сверяй, не только отвечай. Твоё решение может отменять раннюю строку. «Форма видна всю неделю» переписало «форма только в свой день» — редактор обязан пойти и поправить ту строку, а не оставить противоречие.

Лови несогласованность. «Оповещать при смене дня, но молчать при правке самого чек-ина» — решение спорило само с собой. Редактор ищет, где две части спеки не бьются.

Дели: продукт — тебе, реализацию — агенту. «4 фото» решаешь ты; «лимит размера, форматы» — агент. Проводи границу сознательно (урок 1).

«Инфра есть» ≠ бесплатно. Пуш-напоминание удешевлено тем, что пуши уже в проекте — но втянутая фича волочёт свои edge cases (когда стрелять, не задваивать, кому не слать). Дешевле — не значит даром.

Живой пример: чек-ины setlog

Так это выглядело у тебя. Из предложения «клиент раз в неделю шлёт тренеру чек-ин (вес, фото, комментарий), тренер видит» агент развернул черновик с 5 edge cases и 6 открытыми вопросами. Ты закрыл их шестью строками решений:

Вопрос черновика	Твоё решение (редактор)
кто главный: клиент или тренер?	last-writer-wins + оповестить другую сторону
пропустил день — можно позже?	окно: до следующего дня отправки
обязательные поля?	минимум одно из трёх
правка/удаление?	в том же окне (+ оповещение тренеру)
сколько фото?	4; размер/форматы — агенту
scope-out?	пуш втянуть в scope, остальное — нет

Страница с дырами превратилась в шесть решений и один осознанный открытый вопрос. Автор — модель, суждение — твоё. Вот так миссия ощущается в бою.

И новый рычаг в копилку: last-writer-wins (LWW) — при конфликте побеждает тот, кто записал последним. Безопасен на одиночном скаляре (день недели), опасен на богатых данных (два правят документ → потерянные правки). Глоссарий.

Проверь себя

1. В чём главная ценность петли делегирования?

Суть — смена роли. Черновик выкатывает edge cases и вопросы, а ты применяешь суждение к готовому. Суждение никуда не девается — оно становится твоей основной работой.

2. Когда петля (и спека вообще) — overkill?

Если твой замысел = дефолт модели, спека ничего не добавляет (урок 1, «когда вредно»). Ценность спеки ∝ отклонению от дефолта.

3. Редактор решает «форма видна всю неделю», но в черновике строка «форма только в свой день». Что делать?

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

Упражнение — прогони петлю сам

Возьми новое предложение (из твоего бэклога): «Хочу, чтобы тренер назначал упражнение с диапазоном повторов и целевым RPE, а клиент видел это при выполнении.»

Попроси меня (в сессии) развернуть его в спеку-черновик с edge cases и вопросами.
Стань редактором: ответь на открытые вопросы, вычеркни лишнее, сверь нет ли противоречий.
Принеси решения — разберу твоё суждение, не формулировки.

Бонус — глаз редактора. В черновике ниже спрятано одно противоречие. Найди до того, как раскроешь.

Черновик (фрагмент)

— Given упражнение назначено с RPE, when клиент открыл его, then виден целевой RPE.
— Given клиент офлайн, when открывает назначение, then RPE не показывается, пока нет сети.
— Критерий: клиент видит целевой RPE при выполнении, в том числе в офлайне (данные закешированы).

Показать противоречие

Разбор

Вторая строка поведения говорит «офлайн → RPE не виден», а критерий приёмки требует «RPE виден в офлайне». Спека спорит сама с собой — агент не сможет удовлетворить оба. Редактор решает: кешируем назначение и показываем в офлайне (убрать вторую строку), либо честно прячем (убрать «в офлайне» из критерия). Одно из двух, но не оба.

Что читать

Willison: «попроси LLM написать план, итерируй по нему, потом реализуй» — это ровно петля делегирования, только для спеки, а не для кода. Anthropic best practices: plan mode = черновик до реализации.

Устал писать спеку руками — не пиши. Скажи мне «разверни в черновик», и включается петля. Я твой преподаватель и твой соавтор черновиков.

Источники: Willison — Using LLMs for code · Anthropic — Claude Code best practices