Как принять 4 проекта в курирование и не свихнуться?

TL;DR

Руководитель дал 4 новых проекта в архитектурный надзор. Держать всё в голове нереально. Изучил индустриальные практики и подготовил процесс приёмки совместно с Claude Code. Выложил в open-source. Буду рад feedback от вас и ваших агентов.

Как всё началось

Руководитель: "Вот тебе 4 проекта - принимай в работу."

Я: "Окей... А что там?"

Руководитель: "Узнаешь."

Контест:

• 4 проекта

• Где-то есть пересечение функциональности (где именно - неясно)

• Команды разные, стек разный, зрелость разная

• Держать всё это в голове - бесмысленно

Немного поглядел - стало понятно: нужен системный подход.

Что я сделал

1. Изучил индустриальные практики

Посмотрел, как это делают:

• Futurice Project Handover Checklist

• TOGAF Architecture Review

• Harvard EA Checklist

• Практики из книг (Software Architecture in Practice, Building Evolutionary Architectures)

2. Собрал процесс приёмки и аудита

Готовил совместно с Claude Code. Не в чистом виде, конечно с моей конфигурацией (на текущий момент это 3882 строк rules, skills and commands). Безусловно, вычитывал и редактировал.

Что получилось:

Процесс приёмки проекта

6 фаз:

1. Инициация (получить вводную, доступы)

2. Kickoff встреча (PM + Tech Lead)

3. Сбор информации (документация, код, мониторинг)

4. Аудит (анализ архитектуры)

5. Решение о приёмке (принят/с оговорками/не принят)

6. Онбординг в надзор (регулярные встречи, точки контроля)

Файлы:

• project-handover-process.md - детальный процесс

• project-handover.md - чеклист (11 секций, 80+ пунктов)

Шаблоны аудита системы

Ручной аудит (12 разделов):

• Структура системы (C4, bounded contexts)

• Взаимодействие сервисов (sync/async, матрица зависимостей)

• Паттерны и антипаттерны

• Observability (метрики, логи, трейсинг, алерты)

• Устойчивость (SPOF, graceful degradation, DR)

• Безопасность

• План улучшений

Автоматическая валидация (215 метрик):

• Coupling и fan-out

• Layer violations

• God classes

• Топологические метрики

Файлы:

• system-audit.md - ручной аудит

• audit.md - отчет автоматической валидации

На следующей неделе начинаю приёмку. Посмотрим как процесс сработает в реальности.

Если эксперимент удастся - расскажу подробнее о результатах, подводных камнях и корректировках процесса.

Вопрос к сообществу

Буду рад feedback от вас и ваших агентов:

1. Процесс: Что лишнее? Чего не хватает?

2. Чеклисты: Какие критичные пункты я упустил?

3. Автоматизация: Используете ли инструменты для валидации архитектуры?

4. Агенты: Если вы используете AI-агентов для аудита - какие задачи им даёте? Как проверяете результаты?

Open-source шаблоны:

• Project Handover - процесс и чеклист приёмки

• System Audit - ручной и автоматический аудит

• Specifications - spec-driven development

• ADR - Architecture Decision Records

С удовольствием улучшу на основе вашего опыта.

UPD: Если интересно как процесс сработал на практике - подписывайтесь, расскажу после завершения приёмки.
Поддержать меня: https://t.me/MikeShogin

AI не заменяет - AI меняет роль

Спор про скорость - ловушка. Правильный вопрос: что стало узким местом?

55% компаний, которые уволили людей из-за AI, теперь жалеют (Orgvue, 2025). Исследование METR показало странное - разработчики думают что с AI работают на 20% быстрее, а объективно на 19% медленнее (METR, июль 2025).

Хинтон говорит что скоро AI будет делать за минуты работу на месяц. CEO AWS называет отказ от найма джуниоров "одной из самых глупых вещей" (MIT Tech Review).

Кто прав? Мой опыт говорит - оба мимо. AI не заменяет и не замедляет. Он меняет распределение труда.

Что отдал AI

Почти всю черновую аналитику:

• Spec drafts - первые версии спецификаций по сырым требованиям

• C4 диаграммы - контейнеры, компоненты, контекст

• Sequence diagrams - потоки взаимодействия

• Поисковые запросы - сбор контекста из документации и кодовой базы

• Тест-кейсы - acceptance criteria по спецификации

Ручное кодирование сократил до точечных мест: интерфейсы, критичные участки, отладка. Всё остальное - через агента.

Звучит как будто всё отдал. Но нет.

Что не отдам

Здоровье. Доктор может использовать AI - это хорошо. Но это должен быть доктор с образованием и опытом. AI как инструмент - да. AI вместо врача - нет.

То же с психологом и коучем. Всё что связано со здоровьем и осознанностью - только к профессионалам.

В коде аналогично: security-критичные участки, интерфейсы с внешними системами, инварианты бизнес-логики - там доля ручной работы и глубокой экспертизы остаётся выше. AI ускорил черновики и сбор вариантов, но ответственность за модель и критерии - на мне.

Про "парадокс продуктивности"

Подозреваю, что люди измеряют "ощущение скорости", а система измеряет "время до принятого PR".

Не согласен с интерпретацией METR.

Раньше: пробуешь 1-2 варианта, выбираешь, идёшь. Натыкаешься на проблемы - третья версия. Четвёртая. Legacy копится.

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

Микро-кейс: фича интеграции с внешним API. Раньше - 3 дня на реализацию, потом 2 дня на переделку когда выяснились edge cases. Сейчас - 1.5 дня, но 40% времени ушло в спецификацию и тест-контракты. Переделок ноль.

Это не замедление. Это сдвиг: меньше "time-to-code", больше "time-to-confident".

Джуниоры: как меняется обучение

CEO AWS: "Как это будет работать через 10 лет, когда никто ничему не научился?"

Согласен. Передача знаний должна быть. С AI можно делать сайты без образования - но индустрия не только про сайты. Есть вещи где нужна математика и computer science.

Но джуниор теперь не "пишет CRUD". Джуниор учится:

• Формулировать требования так, чтобы агент понял

• Писать тест-контракты до реализации

• Дебажить и верифицировать результат

• Понимать, когда AI галлюцинирует

Сдвиг роли

Меньше клавиатурной работы, больше постановки, проверки и ответственности за инварианты.

Раньше - исполнитель. Теперь - проектировщик и валидатор.

Причём само проектирование тоже с AI - общаешься с агентом, раскладываешь задачу, проверяешь результат. Во многих продуктовых задачах ручное написание кода - не главное узкое место. Узкое место - постановка, проверка, интеграция, риски.

Что стало важнее

Системный подход. "Герой-разработчик" и "пожаротушитель" - уходит. Ценятся люди, которые системно решают задачи.

И новый навык: строить свою систему работы с AI.

Это мой актив. Моя интеллектуальная собственность. Я трачу время не только на задачи, но и на эту систему.