# 22. AI-native архитектор

Как использовать AI как рабочий инструмент архитектора: exploration, design critique, docs, testing, риски hallucination и quality gates.

- **Author:** Фёдор Чищин
- **Level:** advanced
- **Reading time:** ~25 минут чтения
- **Published:** 2026-05-23
- **Source:** https://fedorthinks.com/ru/learn/software-architect-22-ai-native

---

## 1. Главная идея

AI полезен как усилитель reasoning, но опасен как источник непроверенной уверенности.

### AI хорошо расширяет пространство вариантов

> Ассистент может быстро принести десять карт маршрута. Но водитель всё равно отвечает за выбор дороги.

Архитектор может использовать AI для генерации alternatives, чеклистов рисков, черновиков ADR, сравнения trade-offs, тестовых сценариев, угроз security и вопросов для review. Это ускоряет подготовку.

Но AI не знает весь контекст системы, может галлюцинировать API, недооценивать operational cost и звучать уверенно там, где нужны данные. Поэтому результат должен проходить через verification: codebase, docs, metrics, constraints, team knowledge.

### Prompt должен содержать constraints

> Попросить архитектора «сделай дом» бессмысленно. Нужны участок, бюджет, климат, семья, сроки и ограничения.

Для архитектурной работы AI нужно давать контекст: домен, текущую архитектуру, team topology, нагрузку, compliance, ограничения бюджета, цели продукта, существующие решения и критерии успеха.

Без constraints модель часто предлагает generic best practices: микросервисы, Kafka, Kubernetes, event sourcing. Это может быть красиво и вредно.

## 2. Пример и антипример

AI-native работа должна усиливать инженерную дисциплину, а не обходить её.

### Пример: AI как reviewer ADR

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

Команда пишет ADR о переходе на async processing. AI получает контекст, ADR, constraints и список известных incidents. Задача: найти missing risks, unclear assumptions, migration gaps и test scenarios. Архитектор проверяет вывод и добавляет реальные пункты в документ.

Так AI помогает увидеть слепые зоны, но не принимает решение за команду.

### Антипример: принять AI-дизайн без проверки

> Красивый чертёж моста бесполезен, если никто не проверил грунт, нагрузку и материалы.

AI предлагает event sourcing и CQRS для простой CRUD-системы. Команда принимает, потому что объяснение звучит профессионально. Через месяц появляется сложность replay, schema evolution, debugging и обучение команды, но бизнес-ценность не выросла.

AI может ускорить over-engineering, если архитектор не держит критерии качества.

#### Самопроверка

- Какие constraints я дал AI?
- Какие факты нужно проверить в коде или документации?
- Где AI мог предложить generic solution?
- Какие quality gates защищают от непроверенного вывода?

Следующий модуль: [Антипаттерны](./software-architect-23-antipatterns).