AI: Подходы

Plan and Act

Агенты часто совершают ошибки и «теряются», когда пытаются одновременно продумывать логику и писать код для комплексных многошаговых задач.
Поэтому процесс разработки разделяется на две фазы:
    Plan Mode:
  • ИИ-агент переводится в режим «только для чтения».
  • Исследует кодовую базу, анализирует контекст, выявляет возможные пограничные случаи и обсуждает с разработчиком архитектурную стратегию.
  • Отсутствие возможности вносить изменения защищает код от импульсивных, ошибочных решений ИИ и фокусирует процесс исключительно на планировании.
    Act / Build / Code Mode :
  • Сохраняя весь контекст и договоренности из фазы планирования, ИИ применяет свои инструменты строго по утвержденной стратегии.
flowchart LR
Plan --> Act --> Plan

Для мелких правок — только Act Mode.
Для средних задач — цикл Plan → Act.
Для крупных архитектурных изменений — глубокое планирование с детальным обсуждением.
1 минута на планирование и написание тех спеки экономит 10 минут на отладку.
Пример:  Cline  и прочие современные агенты.


Test-Driven Development (TDD)

В сочетании с AI-агентами создает мощный  ♻️цикл обратной связи .
TDD обеспечивает структуру и дисциплину, а агенты — скорость.
graph LR
Start((Начало)) --> NewTest[Написать провальный тест]
style NewTest fill:#ff9999,stroke:#333,stroke-width:2px
NewTest --> RunRed{Запуск теста: Провал?}
RunRed -- Нет --> NewTest
RunRed -- Да --> WriteCode[Написать минимальный код]
style WriteCode fill:#99ff99,stroke:#333,stroke-width:2px
WriteCode --> RunGreen{Запуск теста: Успех?}
RunGreen -- Нет --> WriteCode
RunGreen -- Да --> Refactor[Рефакторинг]
style Refactor fill:#99ccff,stroke:#333,stroke-width:2px
Refactor --> RunFinal{Тесты проходят?}
RunFinal -- Нет --> Refactor
RunFinal -- Да --> NewTest

Достоинства:
  • Точные промпты: Тест выступает промптом, который фокусирует ИИ на конкретном поведении, значительно снижая риск галлюцинаций.
  • Предотвращение "подгонки" тестов: для сломанного кода агент напишет сломанный успешный тест.
  • Защита от регрессий: ИИ легко может сломать существующий функционал, но набор тестов фиксирует поведение и позволяет безопасно и быстро итерировать.

Проблемы:
  • ИИ-агенты по умолчанию не любят работать короткими итерациями Red-Green-Refactoring.
  • Обычные текстовые промпты с просьбой "использовать TDD" часто игнорируются.
  • Агенты не умеют ещё достаточно хорошо и качественно писать тесты до логики.
  • Для генерации тестов требуется детализированная спецификация.

Стратегии реализации:
    Изоляция контекста:
  • Агента помещают в изолированную директорию, где он генерирует только спецификации тестов.
  • Допуск к коду только после утверждения тестов человеком.
    Ручное ревью тестов:
  • Человек должен проверить и скорректировать сгенерированные тесты.
  • Написание кода только после подтверждения корректности логики.
    Автоматизированный контроль:
  • Блок написания кода без предварительно созданных тестов.
  •  Хуки  или  TDD guard .
    Специализированные воркфлоу:
  • Процесс разбивается на шаги для узкоспециализированных субагентов с жёсткими ограниченями.


Spec Driven Development

Spec-Driven Development (SDD) — это подход, где спецификации (а не код) становятся главным источником истины.
SDD предоставляет ИИ конкретные контракты, превращая спецификацию в "высокоуровневый язык программирования", а генерацию кода в процесс его компиляции.

Уровни:
    Spec-first: Спецификация пишется для направления начальной ИИ-разработки, но в дальнейшем может не поддерживаться.
    Spec-anchored: Спецификация поддерживается вместе с кодом. Любые изменения в поведении требуют синхронного обновления спецификации и кода, что часто проверяется автоматическими тестами.

Воркфлоу SDD:
graph LR
Start([Задача]) --> Step1
subgraph Фаза 1: Спецификация
Step1[Specify <br/> Описание ЧТО нужно построить]
Rev1{Ревью человеком}
Step1 --> Rev1
end

subgraph Фаза 2: Планирование
Step2[Plan <br/> Описание КАК строить: стек, архитектура]
Rev2{Ревью человеком}
Rev1 -->|Утверждено| Step2
Rev1 -.->|Доработка| Step1
Step2 --> Rev2
end

subgraph Фаза 3: Декомпозиция
Step3[Tasks <br/> ИИ разбивает план на мелкие шаги]
Rev2 -->|Утверждено| Step3
Rev2 -.->|Доработка| Step2
end

subgraph Фаза 4: Реализация и Валидация
Step4[Implement <br/> ИИ пишет код по каждой задаче]
Step5[Validate <br/> Проверка тестами и человеком]
Step3 --> Step4
Step4 --> Step5
Rev3{Поведение <br/> соответствует?}
Step5 --> Rev3
Rev3 -->|Нет| Fix[Обновление Спецификации / Плана]
Fix -.-> Step1
end

Rev3 -->|Да| Finish([Готовый и задокументированный функционал])
Specify: Описание того, что нужно построить (поведение, пользовательский путь, бизнес-правила), без деталей реализации.
Plan: Описание того, как это реализовать (архитектура, стек, ограничения).
Tasks: ИИ разбивает план на мелкие изолированные задачи для пошаговой реализации.
Implement: Агент пишет код для каждой задачи.
Человек выступает в роли валидатора, проверяя узконаправленные изменения.

Примеры:  Github Spec-Kit ,  OpenSpec ,  Kiro ,  Qoder  и другие современные решения.


Spec as Source

В этой парадигме спецификация является единственным артефактом, с которым напрямую работает человек, а роль классического написания кода полностью делегируется ИИ.

Принципы:
graph LR
subgraph Зона ответственности Человека
Spec[📄 Спецификация <br/> Единственный источник истины]
end

subgraph Зона ответственности ИИ
GenProcess((Генерация))
Code[💻 Исходный код <br/> // GENERATED FROM SPEC - DO NOT EDIT]
end

Spec -->|Отправляется агенту| GenProcess
GenProcess -->|Создает или полностью переписывает| Code
NeedChange{Нужно изменить <br/>поведение или <br/>исправить баг?}
Code --> NeedChange
NeedChange -->|Ручные правки ЗАПРЕЩЕНЫ| Spec
NeedChange -->|Все работает корректно| Prod([Продакшен])
classDef human fill:#d4edda,stroke:#28a745,stroke-width:2px;
classDef ai fill:#cce5ff,stroke:#004085,stroke-width:2px;
classDef warning fill:#fff3cd,stroke:#856404,stroke-width:2px;
class Spec human;
class GenProcess,Code ai;
class NeedChange warning;
  • Запрет на ручное редактирование кода:
  • Код полностью генерируется из спецификации.
  • Если в поведении нужно что-то изменить, разработчик вносит изменения в текст спецификации и перегенерирует код.
  • Устранение рассинхронизации:
  • Поскольку ручные правки кода исключены, спецификация и исполняемый код всегда идеально соответствуют друг другу.
  • Эволюция Model-Driven Development:
  • Разработчики больше не скованы жесткими языками моделирования (такими как UML) и сложными генераторами кода.

Проблемы:
  • Недетерминированность LLM-моделей.
  • Нужно писать спецификации максимально однозначно.
  • Необходимо использовать инструменты автоматизированного тестирования для верификации контрактов.



SGR

Подробнее: 📑AI: SGR