Подходы к разработке

С агентом работают по-разному: от короткого запроса до строгого процесса. Чем крупнее задача и выше цена ошибки, тем больше пользы от структуры. ## Короткий запрос Мелкую понятную правку (опечатка, строка лога, переименование) достаточно просто описать словами. Это быстро, но результат трудно повторить, и на большой задаче так полагаться не стоит. ## Изучение, план, реализация Незнакомый или большой код: сначала агент разбирается и предлагает план, ты его проверяешь, и только потом начинаются правки. Так меньше риск, что агент решит не ту задачу. Подробнее в [Лучших практиках](/code/best-practices/). ## Spec-Driven Development (SDD) Для крупной или ответственной работы источником правды делают не переписку с агентом, а спецификацию. Запрос одноразовый, а спецификация остаётся и не теряется при смене сессий. Что в неё входит: намерение (зачем это нужно), границы (что делаем, а что нет), критерии приёмки (когда считать готовым), крайние случаи и принятые в проекте соглашения. Порядок работы: 1. Дай агенту себя расспросить (инструмент `AskUser`) и сохрани итог в `SPEC.md`. 2. Выполняй задачу в новой сессии: агент опирается на спецификацию, а не на обрывки переписки. 3. Держи критерии приёмки через [`/goal`](/code/goal/), чтобы агент не остановился раньше времени. 4. Проверяй результат по спецификации, а не только по диффу: решена ли нужная задача и учтены ли крайние случаи. Подход оправдан на многофайловых и многосервисных изменениях, повторяющихся задачах и там, где нужен аудит. Для мелкой правки или прототипа он избыточен. Начинай с одной задачи, а не переводи на процесс весь проект сразу. Разворачивать процесс вручную не обязательно: есть открытые наборы, которые задают его командами агента. Например, [GitHub Spec Kit](https://github.com/github/spec-kit) ведёт от требований к реализации через команды `/speckit.specify`, `/speckit.plan`, `/speckit.tasks`, `/speckit.implement` и работает с разными агентами. Waibee Code читает команды и навыки в формате Claude Code, поэтому подобные наборы подключаются как обычные [навыки и команды](/code/skills/). ## Test-Driven Development (TDD) Сначала пишется тест, который падает и фиксирует нужное поведение, а затем агент доводит его до зелёного. Тест выступает критерием приёмки: «сделай так, чтобы этот тест проходил, а остальные не сломались». Хорошо сочетается со спецификацией, в которой тесты и есть часть критериев приёмки. ## Автор и проверяющий (Writer/Reviewer) Один агент пишет код, другой в чистом контексте его проверяет и возвращает замечания. Второй взгляд ценен тем, что не привязан к готовому решению. Удобно вести в двух чатах или поручать проверку субагенту. ## Автономный прогон с проверкой Если есть надёжная проверка (тесты, сборка, линтер), сделай её условием через `/goal` и дай агенту работать до зелёного результата, а сам оцени итог. Чем дольше агент работает без тебя, тем важнее независимая проверка, прежде чем считать задачу законченной. ## Autoresearch Частный случай автономного прогона: проверка возвращает не «прошло или нет», а число. Тогда агент крутит цикл сам: гипотеза, правка, замер, оставить или откатить. Подходит для скорости, размера, точности и всего, что меряется скриптом. Правила цикла и защита метрики в разделе [Autoresearch](/code/autoresearch/). ## Что остаётся на тебе Любой из подходов выше перекладывает на агента написание кода, но не ответственность за результат. Постановка, выбор подхода и проверка остаются твоими, см. [Роль разработчика](/code/validation/).

С агентом работают по-разному: от короткого запроса до строгого процесса. Чем крупнее задача и выше цена ошибки, тем больше пользы от структуры.

Короткий запрос

Мелкую понятную правку (опечатка, строка лога, переименование) достаточно просто описать словами. Это быстро, но результат трудно повторить, и на большой задаче так полагаться не стоит.

Изучение, план, реализация

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

Spec-Driven Development (SDD)

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

Что в неё входит: намерение (зачем это нужно), границы (что делаем, а что нет), критерии приёмки (когда считать готовым), крайние случаи и принятые в проекте соглашения.

Порядок работы:

Дай агенту себя расспросить (инструмент AskUser) и сохрани итог в SPEC.md.
Выполняй задачу в новой сессии: агент опирается на спецификацию, а не на обрывки переписки.
Держи критерии приёмки через /goal, чтобы агент не остановился раньше времени.
Проверяй результат по спецификации, а не только по диффу: решена ли нужная задача и учтены ли крайние случаи.

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

Разворачивать процесс вручную не обязательно: есть открытые наборы, которые задают его командами агента. Например, GitHub Spec Kit ведёт от требований к реализации через команды /speckit.specify, /speckit.plan, /speckit.tasks, /speckit.implement и работает с разными агентами. Waibee Code читает команды и навыки в формате Claude Code, поэтому подобные наборы подключаются как обычные навыки и команды.

Test-Driven Development (TDD)

Сначала пишется тест, который падает и фиксирует нужное поведение, а затем агент доводит его до зелёного. Тест выступает критерием приёмки: «сделай так, чтобы этот тест проходил, а остальные не сломались». Хорошо сочетается со спецификацией, в которой тесты и есть часть критериев приёмки.

Автор и проверяющий (Writer/Reviewer)

Один агент пишет код, другой в чистом контексте его проверяет и возвращает замечания. Второй взгляд ценен тем, что не привязан к готовому решению. Удобно вести в двух чатах или поручать проверку субагенту.

Автономный прогон с проверкой

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

Autoresearch

Частный случай автономного прогона: проверка возвращает не «прошло или нет», а число. Тогда агент крутит цикл сам: гипотеза, правка, замер, оставить или откатить. Подходит для скорости, размера, точности и всего, что меряется скриптом. Правила цикла и защита метрики в разделе Autoresearch.

Что остаётся на тебе

Любой из подходов выше перекладывает на агента написание кода, но не ответственность за результат. Постановка, выбор подхода и проверка остаются твоими, см. Роль разработчика.