ИИ в проектировании и архитектуре: как устроен GoRunWithAI

ИИ в проектировании и архитектуре: как устроен GoRunWithAI

Серия «Разработка с ИИ: полный цикл», часть 2. Платформа GoRunWithAI.

Архитектура — это принятие решений в условиях неопределённости. У каждого решения есть цена, и узнаёте вы её обычно через полгода. ИИ не принимает архитектурные решения за вас — но он радикально удешевляет их проработку и критику. В GoRunWithAI я проверил это на себе: все ключевые решения прошли через ИИ-оппонента, и часть из них изменилась до того, как за них заплатила реальность.

Кейс: четыре решения, которые определили проект

Решение 1. Модульный монолит вместо микросервисов

Соблазн «сразу микросервисы» для конвейера новостей велик: отдельный сервис для RSS, отдельный для LLM, очередь между ними. ИИ-оппонент с моим контекстом («один разработчик, VPS 2 vCPU / 2 ГБ, бюджет ~1200 ₽/мес») вынес вердикт: микросервисы здесь — это плата за чужую архитектурную мечту. Модульный монолит FastAPI с чёткими границами (api, services, tasks, models) даёт 90% дисциплины за 10% стоимости. Триггер пересмотра записан явно: «выносим в отдельные сервисы, когда появится второй разработчик или нагрузка упрётся в один процесс».

Решение 2. DeepSeek как LLM-провайдер

Критерии были простыми: цена за 1K токенов, качество русского языка, OpenAI-совместимый API (чтобы замена провайдера стоила день, а не месяц). DeepSeek победил по совокупности; fallback-сценарий — YandexGPT/GigaChat — записан, но пока не понадобился. Учёт стоимости вызовов зашит в систему с первого дня: каждый LLM-вызов пишет логи (токены, стоимость, latency) — из них же выросла «Открытая кухня».

Решение 3. Конвейер как пайплайн с приоритетами

RSS-источники (A: 15 мин, B: 1 час, C: сутки)
   → нормализованная дедупликация
   → скоринг релевантности (вес источника + ключевые слова − штрафы за мусор)
   → LLM-пересказ
   → аппрув (порог 0.7) → очередь кросспостинга → Telegram (до 7 в день)

Каждое звено — отдельный модуль с тестами. Приоритеты A/B/C — компромисс между свежестью и стоимостью опроса: важные источники каждые 15 минут, прочие — раз в сутки. ИИ помог с проектированием скоринга: списки «сигнальных» и «мусорных» слов собраны и откалиброваны в диалоге.

Решение 4. Отложенная публикация через планировщик

Статьи живут в репозитории как Markdown с frontmatter, импортируются черновиками, а даты публикации назначает планировщик по периодичности из админки (шаг 7 дней, час публикации). Это решение родилось из ИИ-критики требований (статья 1) и определило архитектуру: PublishSchedule (синглтон), фоновая задача публикации каждую минуту, автоназначение дат каждые 5 минут.

Сценарии, которые сработали в проекте

ADR без боли. Ключевые решения оформлены как короткие записи «что решили, почему, что отвергли, триггер пересмотра» — включая отвергнутые варианты. Через месяц такой документ дороже кода: он отвечает на вопрос «почему не сделали очевидное?».

Диаграммы как код. Карта конвейера нарисована в текстовой нотации и живёт в репозитории рядом с кодом — при изменениях обновляется тем же агентом.

Контракты до кода. Форматы контента (frontmatter статей, схема анонса) зафиксированы до разработки — и фронтенд, и конвейер пишутся под них.

Где ИИ-критика уберегла от переделки

• Отвергнуто: отдельный сервис для LLM-пересказов с очередью. Для текущего масштаба — лишняя инфраструктура; вернуться можно триггером из решения 1.
• Отвергнуто: генерация картинок для каждого поста. Удорожание конвейера без доказанной пользы; вернёмся, если цифры канала попросят.
• Принято после критики: published_at как отдельное поле с планировщиком (а не дата в файле) — именно это решение дважды спасло расписание серии при переносах.

Границы: что ИИ в архитектуре делает плохо

• Не знает вашу организацию. Модель проектирует для абстрактной команды. Мой главный архитектурный фактор — «разработчик один» — пришлось вписать в контекст явно, иначе рекомендации летели мимо.
• Оптимистичен в оценках. «Это легко масштабируется» — типичная галлюцинация. Просите расчёты: «прикинь стоимость опроса 20 источников каждые 15 минут на таких-то тарифах».
• Не чувствует цену сложности. Kubernetes для проекта одного человека — реальная рекомендация из коробки. Размер команды и операционный бюджет в контексте меняют всё.

Артефакты этапа

1. Архитектурная схема конвейера (в репозитории, рядом с кодом).
2. Записи решений с триггерами пересмотра.
3. Контракты форматов контента (frontmatter, анонсы).
4. Правила проекта (стек, соглашения, запреты) — главный мостик к этапу разработки.

Метрики этапа

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

Практический минимум для старта

1. Заведите папку с записями решений и оформите через ИИ первые три.
2. Создайте правила проекта (стек, соглашения, запреты, команды сборки и тестов).
3. Перед следующим архитектурным решением прогоните схему через «скептический ревью»-промпт и запишите риски.
4. Переведите диаграммы в текстовую нотацию и положите в репозиторий.

💬 Обсудим? Ведёте ли вы записи архитектурных решений — и если нет, что мешает? Какое решение вам пришлось переделывать дороже всего? Напишите в комментариях или в [Telegram-канале GoRunWithAI]. Архитектура самой платформы GoRunWithAI построена по этим принципам — с живыми метриками на дашборде открытой кухни.

Следующая статья: «Часть 3. Разработка: как я собрал конвейер за лето».