Research Insights Space
К каталогу
paper
case-study
conceptual

A Prompt Pattern Sequence Approach to Apply Generative AI in Assisting Software Architecture Decision-making

Разбор подхода к использованию GenAI как co-architect: шесть prompt patterns, их последовательность и практический flow принятия архитектурных решений.

Открыть оригинал

Практика чтения для этого источника ещё не опубликована

Ниже доступен готовый редакционный brief из прежнего каталога. Он даёт контекст, но не засчитывается как lab.

Открыть оригинал

Готовый редакционный разбор

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

Whitepaper

A Prompt Pattern Sequence Approach... (Dec 2024)

Работа о применении prompt patterns для поддержки архитектурных решений.

Перейти на сайт

По серии постов в tg-канале показан практичный взгляд на paper: это не «архитектор на автопилоте», а структурированный способ использовать GenAI как ассистента в цикле подготовки, анализа и принятия решений.

Серия постов

Telegram #3201

Часть 1 обзора: контекст paper, паттерны и общий flow применения.

Перейти на сайт

TL;DR

  • Whitepaper предлагает не «один магический промпт», а последовательность паттернов для подготовки контекста и выбора архитектурного решения.
  • Базовая идея: использовать GenAI как co-pilot для структурированного анализа trade-off, а не как замену архитектора.
  • Главный вклад работы - формализация набора prompt patterns и порядок их применения в реальном decision flow.
  • Подход протестирован на трех кейсах: финтех-портал, retail pharmacy network и cloud CRM для стартапа.

Как в paper описывают паттерны

Базовые атрибуты

  • Name
  • Context
  • Problem
  • Forces
  • Solution
  • Rationale
  • Consequences

Расширенные атрибуты

  • Specializes
  • Statement template
  • Concrete statement example
  • Related patterns
  • Usage example
  • Known uses

Набор prompt patterns

Software architect persona pattern

Фиксирует роль, цели и ограничения архитектора, чтобы ответы LLM были предметными для архитектурных trade-off.

Снижает риск общих ответов и задает границы допустимых предложений.

Template

You are [Persona's Name] in the role [Role]. Your main goal is [Main Goal]. You cannot [Limitations/Constraints].

Architectural project context pattern

Вводит операционные, организационные и финансовые ограничения проекта.

Сдвигает обсуждение из «идеальной архитектуры» в «реализуемую в заданных ресурсах».

Template

Given a development timeline of [Time], a team of [Team Size], and a budget of [Budget], determine if [Architecture Description] is feasible.

Quality attribute question pattern

Заставляет ассистента сначала задавать вопросы про quality attributes, а не сразу предлагать решение.

Улучшает качество входных данных для архитектурного решения и делает допущения явными.

Template

You are [Role] responsible for [Project]. Focus on [Quality Attributes]. Ask clarifying questions and avoid decisions until data is collected.

Technical premises pattern

Требует от LLM явно перечислять факты и обоснования для технических предпосылок.

Снижает влияние галлюцинаций через принудительную верификацию ключевых утверждений.

Template

Given [Context] and [List of Technical Premises], generate facts and justifications, then list verifiable facts at the end.

Uncertain requirement statement pattern

Выносит неопределенные требования в явный анализ рисков и последствий.

Помогает заранее обсуждать гибкость архитектуры под регуляторные и технологические изменения.

Template

In [Project Context], and [Uncertain Aspect], examine repercussions of not addressing uncertainty and propose mitigation directions.

Prompt pattern sequence

Собирает предыдущие паттерны в последовательность шагов для принятия архитектурных решений.

Дает воспроизводимый рабочий процесс вместо набора несвязанных промптов.

Template

Apply patterns in a defined sequence and evaluate outputs before final architectural decisions.

Prompt Pattern Sequence (7 шагов)

Step 1

Define the role and objective of the architect.

Step 2

Apply software architect persona.

Step 3

Evaluate technical premises.

Step 4

Process uncertain requirements.

Step 5

Refine quality attributes via guided questions.

Step 6

Add budget/resource constraints via project context.

Step 7

Evaluate generated results and decide.

Кейсы применения из статьи

Brazilian Financial Bank

Технологический портал банка: фокус на reliability, scalability и ограничениях по ресурсам.

Brazilian Pharmacies Nationwide

Сетевой retail-кейс: баланс масштабируемости, стоимости владения и скорости изменений.

Cloud CRM for Startup

Гипотетический стартап-кейс: быстрый вывод продукта при высокой неопределенности требований.

Сильные стороны и ограничения

Что работает хорошо

  • Структурирует диалог с моделью и уменьшает хаотичность prompt-to-prompt итераций.
  • Формализует этап уточнения требований до архитектурного выбора.
  • Переводит работу с LLM из ad-hoc режима в повторяемый процесс.
  • Хорошо подходит как co-architect слой для senior инженеров и архитекторов.

Где подход ограничен

  • Шаблоны в paper остаются довольно общими и требуют адаптации под конкретный домен.
  • Качество результата все еще критично зависит от полноты исходного контекста проекта.
  • Без внутреннего knowledge base (документация, стандарты, ADR) полезность ответов ограничена.
  • Валидация фактов по technical premises должна выполняться отдельно; это не автоматический guarantee.

Как применить в команде (практический rollout)

  • Собрать минимальный baseline: 1 persona, 1 контекст проекта, 3-5 ключевых quality attributes.
  • Запустить sequence на одном архитектурном вопросе и зафиксировать draft ADR.
  • Провести human review: что полезно, где галлюцинации, какие допущения невалидны.
  • Добавить внутренний контекст (RAG по ADR/стандартам/инцидентам) и повторить цикл.
  • Сформировать командный prompt playbook с versioning и критериями качества результата.

Практический смысл paper в том, что архитектурный диалог с LLM должен быть итеративным и верифицируемым: сначала контекст и вопросы, потом варианты, потом человеческое решение и ADR.

Связанные главы

QA-guided Architecture Re-Design at Google

Системный подход к архитектурным trade-off через quality attributes и моделирование.

Quality Metrics in Software Architecture

Каталог метрик для измерения архитектурных атрибутов и ограничений практики.

Towards AI-Native Software Engineering (SE 3.0)

Следующий шаг после copilots: intent-first и agentic-подходы в разработке.