Мы уже выяснили, что код стал дешёвым расходником, а слепое доверие нейросетям быстро разрушает сложные системы из-за локальной оптимизации и срезания важных архитектурных слоев.
Теперь встает главный вопрос, который сегодня не дает спать тысячам разработчиков по всему миру:
«Если ИИ пишет код быстрее меня, находит библиотеки за миллисекунды и закрывает рутинные таски пачками — в чем вообще заключается моя работа как инженера?»
Ответ прост, но для многих болезнен: ваша ценность больше не в скорости набора символов и не в знании наизусть методов стандартной библиотеки.
Ваша работа — быть гарантом целостности системы. Быть тем, кто не дает набору разрозненных скриптов превратиться в гниющую свалку.
Ниже — инженерный фреймворк, к которому мы с коллегами пришли после сотен часов практической работы с автономными coding-агентами в реальном проде.
Паттерн «Skeleton + Pluggable Modules» (Каркас и сменные блоки)
Главная ошибка при работе с ИИ — пустить агента в свободное плавание по всему проекту со словами: «Сделай нам модуль биллинга».
Через полчаса вы получите монстра из 20 файлов, где логика перемешана с контроллерами, запросы к базе размазаны по хэндлерам, а ошибки глушатся пустыми блоками catch.
Чтобы ИИ работал безопасно, система должна строиться по принципу нерушимого скелета и одноразовых мышц:
┌────────────────────────────────────────┐
│ АРХИТЕКТОР (ЧЕЛОВЕК) │
│ Инварианты, Схемы данных, Контракты │
└───────────────────┬────────────────────┘
│ проектирует
▼
┌────────────────────────────────────────┐
│ SKELETON (КАРКАС) │
│ Auth Context │ Event Bus │ DB Schemas │
└─────┬────────────────────────────┬─────┘
│ │
изолированный │ │ изолированный
контракт ▼ ▼ контракт
┌───────────────────────────┐ ┌───────────────────────────┐
│ PLUGGABLE MODULE A │ │ PLUGGABLE MODULE B │
│ (Сгенерирован AI) │ │ (Сгенерирован AI) │
│ Быстро пишется / │ │ При деградации — │
│ Легко удаляется целиком │ │ перегенерируется с нуля │
└───────────────────────────┘ └───────────────────────────┘-
Человек проектирует Каркас (Skeleton):
- Единая точка валидации входных данных (например, схемы Zod / Pydantic).
- Границы транзакций и контекст пользователя (User/Tenant context).
- Шина событий и строгие протоколы межмодульного общения.
- Централизованный аудит и обработка ошибок.
-
ИИ наполняет Сменные Модули (Pluggable Modules):
- Каждый модуль заперт в жесткие границы своего контракта. Он не имеет прямого доступа к чужим таблицам базы данных или чужому состоянию.
- Вся логика модуля — локальна.
В чём фундаментальная сила этого подхода?
Если через полгода выяснится, что модуль написан неидеально или требования бизнеса изменились на 180 градусов, вы не тратите недели на рефакторинг спагетти-кода. Вы просто удаляете папку модуля целиком и просите агента перегенерировать его с нуля по обновленному контракту. На это уходит 15 минут.
Смерть Pull Request и рождение DESIGN.md
Классический процесс Code Review окончательно изжил себя.
Вычитывать вручную PR на 3 000 строк от агента — это чистое лицемерие. Человеческое внимание рассеивается уже на третьем файле. Разработчик ставит механический LGTM («Looks good to me»), молясь, чтобы тесты поймали критические баги.
Сальваторе Санфилиппо в своем эссе предложил куда более жизнеспособную альтернативу: артефакт DESIGN.md.
Перед тем как агент напишет хотя бы одну строчку кода, вы с моделью составляете документ спецификации архитектуры. Это не бюрократическое ТЗ на 50 страниц, а компактный манифест инженерных решений (на 1–2 страницы), включающий:
- Инварианты системы (Что НЕ МОЖЕТ произойти ни при каких условиях):
Например: «Баланс пользователя не может стать отрицательным ни при каких сетевых сбоях; списание средств и начисление бонусов происходят строго в одной транзакции». - Структуры данных и жизненный цикл (State Machine):
Четкие состояния сущности:Draft → Pending → Paid → Fulfilled. Никаких переходов в обход машины состояний. - Границы сбоев (Failure Modes):
Что происходит, если внешний платежный шлюз не ответил за 2 секунды? Что происходит при дублирующем вебхуке? (Идемпотентность). - Критерии доказательства качества (Acceptance Invariants):
Какие именно стресс-тесты и негативные сценарии обязан пройти сгенерированный код.
Когда DESIGN.md утвержден архитектором — написание кода становится тривиальной технической процедурой. А на ревью вы смотрите не на синтаксический сахар, а на соответствие реализации зафиксированным инвариантам.
Практический инструмент:
Чтобы не проектировать каркас и шаблоны спецификаций с нуля под каждый репозиторий, я выложил готовый открытый стартер: AVP-Dev / agent-starter-kit на GitHub. В нём собраны базовые архитектурные рельсы, шаблоныDESIGN.md, правила для coding-агентов и примеры изоляции модулей, которые можно сразу форкать и брать в реальную работу.
Матрица делегирования: Что отдавать ИИ, а что держать руками
Чтобы не скатиться ни в параноидальный микроменеджмент, ни в безответственный «вайб-кодинг», я использую в работе жесткую матрицу разделения ответственности:
| Уровень задачи | Кому доверять | Что входит в скоуп |
|---|---|---|
| 1. Полное делегирование (100% AI) | ИИ-агент | Чистые функции без сайд-эффектов, DTO-конвертеры, юнит-тесты пограничных условий, верстка UI-компонентов по дизайн-системе, парсеры и скрипты миграции данных. |
| 2. Контрактное делегирование (50 / 50) | Человек проектирует контракт → AI реализует | CRUD-эндпоинты, интеграции со сторонними API, фоновые воркеры очередей, логика генерации отчетов. Человек проверяет только контракты и поведение на сбоях. |
| 3. Нулевое делегирование (Только человек) | Архитектор | Модель владения данными (Data Ownership), финансовые транзакции, модель разграничения прав (RBAC/ABAC), протоколы согласованности в распределенных системах, архитектура безопасности. |
Если вы отдаете пункты из третьей категории на откуп автогенерации — вы больше не инженер. Вы просто пассажир в машине, у которой отказали тормоза.
Главный вывод: Настоящая роль инженера
Индустрия программного обеспечения проходит через болезненный, но неизбежный этап взросления.
На протяжении сорока лет мы романтизировали сам процесс набора кода. Мы спорили о пробелах и табах, мерялись знанием редких конструкций компилятора и гордились тем, сколько часов потратили на отладку глупой опечатки.
Теперь эта эпоха закончилась.
ИИ может быть потрясающим, феноменально быстрым и неутомимым программистом. Но он никогда не станет владельцем результата.
- ИИ не несет ответственности перед бизнесом, когда в Черную Пятницу база данных ложится под наплывом покупателей.
- ИИ не сидит на ночном созвоне с инцидент-менеджерами, когда обнаруживается утечка пользовательских данных.
- ИИ не видит общую картину через год и два года развития компании.
За систему всегда отвечает человек.
И чем больше кода вокруг нас способна генерировать машина, тем выше ценится инженер, который способен подняться над синтаксисом, увидеть архитектурный каркас и сказать:
«Этот код мы выкидываем. Мы построим систему иначе».
Серия статей об инженерном мышлении в эпоху AI:
- Код стал дешёвым. Инженерное мышление — нет
- AI любит прямые дороги: почему локальная оптимизация рушит сложные системы
- Архитектор будущего: от построчного ревью к Design Review (эта статья)
