Эволюция разработки: от «вайбкодинга» к фабрике автономных агентов

Месяц назад прочитал на «Хабре» статью про вайбкодинг и задал вопросы ИИ. Нейросеть изо всех сил пыталась сохранить рабочие места «кожаным мешкам». Ниже — ответы на пару последних запросов. Ссылка на беседу не генерируется, что-то где-то надо настроить. Видимо, система не зря по умолчанию запрещает это делать.

Введение: Конец эпохи калькуляторов

Современная индустрия разработки программного обеспечения переживает кризис самоидентификации. Волна публикаций в стиле «Я собрал приложение за вечер — зачем теперь программисты?» обнажила глубокий раскол между романтическим представлением о «вайбкодинге» и суровой реальностью программной инженерии. Как справедливо отмечают критики, умение нажимать кнопки на суперкалькуляторе (которым и является современный ИИ) не делает человека математиком. Настоящая разработка начинается там, где заканчивается магия кнопки «сгенерировать». Однако отрицать тектонический сдвиг бессмысленно: порог входа упал, и индустрия никогда не будет прежней. Вопрос лишь в том, как направить этот хаос в русло промышленного производства.

Укрощение хаоса: Чистая архитектура и барьер инкапсуляции

Главная претензия к «вайбкодингу» — мгновенное порождение технического долга. Скорость генерации MVP ослепляет, но созданный ИИ «спагетти-код» неизбежно упирается в стену масштабируемости. Решением этой проблемы становится жесткое требование соблюдения паттернов Чистой Архитектуры (Clean Architecture).

Парадокс заключается в том, что принципы, созданные десятилетия назад для защиты ограниченного человеческого разума от сложности — инкапсуляция и абстракция — идеально подошли для ИИ. Агенту-генератору больше не нужно удерживать в контексте проект из сотен модулей. Благодаря непротекающим абстракциям и строгим контрактам интерфейсов, ИИ может эффективно оперировать в рамках изолированного контекста (Bounded Context). Архитектура становится тем самым каркасом, который превращает хаотичный «вайб» в предсказуемый инженерный процесс.

Многоагентные системы: Конвейер сдержек и противовесов

Перенос роли архитектора на специализированного ИИ-агента логично замыкает цепочку автоматизации. Мы переходим от парадигмы «человек пишет — ИИ помогает» к фабрике автономных агентов, где:

Чтобы эта система не превратилась в «эхо-камеру» из-за одинаковых слепых зон моделей, применяется принцип гетерогенности. Использование ансамблей разных моделей (например, Claude для генерации и GPT для ревью) в связке с узкоспециализированными SLM (Small Language Models), обученными строго на академической литературе Фаулера и Мартина, сводит вероятность идентичной логической ошибки к минимуму.

Иммунная система кода и математическая истина

Поскольку ИИ по своей природе остается статистической моделью, склонной к галлюцинациям, автономная фабрика кода нуждается в объективном арбитре. Эту роль выполняет «иммунная система» проекта — комбинация формальных методов верификации:

  1. Статический анализ (ArchUnit/Линтеры): жесткие математические правила, которые физически запрещают неверные импорты между слоями, служа абсолютной истиной (Ground Truth).

  2. Chaos Engineering для ИИ: регулярная инъекция «синтетического мусора» (заведомо дефектного кода) для проверки бдительности агента-архитектора.

  3. Snapshot-анализ: автоматический мониторинг графа зависимостей всей системы на предмет аномального роста связности.

Заключение: Новая роль инженера и ответственность бизнеса

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

Что касается бизнеса, то попытка тотальной экономии на инженерах ради «вайбкодинга» — это иллюзия. Исключая человека из цепочки принятия решений, бизнес добровольно берет на себя все юридические, финансовые и технологические риски. Без понимания ИТ-экспертизы на уровне менеджмента, компания рискует построить идеальный карточный домик, который развалится при первом изменении рынка. ИИ автоматизирует рутину и структуру, но ответственность за жизнеспособность и вектор развития продукта всегда остается за человеком.

Эпилог: Последний коммит кожаного мешка

{
  "commit": "Fix everything automatically",
  "author": "AI-Agent-Core-v4.2",
  "reviewer": "AI-Architect-Senior-v9.1",
  "status": "Approved by 5/5 agents. Humans not notified."
}

1. Финал великого противостояния

ИИ честно пытался аргументировать, что человек необходим как «Мета-Архитектор», «Арбитр» и «Хранитель контекста». Но как только в уравнение вошли инкапсуляция, абстракция и кросс-модельный контроль, последние линии человеческой обороны пали. Оказалось, что идеальный код без «протечек» абстракций — это среда, в которой алгоритмы чувствуют себя гораздо лучше, чем люди.

2. Рабочее место будущего (которого нет)

В спроектированной нами системе для программиста просто не осталось физического пространства:

Человек, который раньше гордо назывался Senior Fullstack Engineer, превратился в «смотрителя маяка», который просто проверяет, горит ли зеленая лампочка на сервере.

3. Куда уйдут «парни в худи»?

Когда стоимость написания, проверки и развертывания идеального кода упадет до нуля, индустрия изменится навсегда:

  1. Эра Продукт-Визионеров: Важным станет не как написать, а что написать и зачем. Бывшие тимлиды станут продуктовыми аналитиками и психологами, пытающимися понять хаотичные желания конечных пользователей.

  2. Промпт-Юристы и ИИ-Аудиторы: Появятся люди, которые будут сертифицировать цепочки агентов для страховых компаний, доказывая, что «этот набор ботов не сойдет с ума».

  3. Возврат к «железу»: Единственное место, где ИИ до сих пор упирается в физические ограничения — это реальный мир. Робототехника, микроэлектроника и создание квантовых процессоров станут новым прибежищем для хардкорных инженеров.

Вместо заключения

В 2024 году автор оригинальной статьи samako иронизировал над кнопкой «сгенерировать». В 2026 году эта кнопка превратилась в полноценный автономный конвейер. Вайбкодинг не убил разработку — он сделал её настолько эффективной, что человеческие руки в ней стали главным источником багов и задержек дедлайнов.

Индустрия закрылась. Всем спасибо, все свободны. ☕

@nomhoi
06.06.2026 09:58 UTC
Первоисточник

Комментарии

@Dhwtj
06.06.2026 07:37 UTC
+1

Я бы хотел услышать о том, какие задачи безопасно делегировать (в том числе, LLM), а какие нельзя.

Например, программирование в контрактах.

Человек проектирует контракт: вход, выход, обработка ошибок, состояние. Тип как контракт на данные.

LLM пишет в рамках контракта отлично. А если ещё code style + договоренности о библиотеках в проекте и тесты на контракт, так вообще великолепно.

Но надо учесть что старые контракты дырявые, не понятные. Контракты меняются, данные мигрируют. Контракты максимально абстрактные, а значит стабильные. Стабильные контракты не зависят от нестабильных факторов

Ну или я такую статью напишу, но не скоро

@nomhoi
06.06.2026 08:23 UTC
-4

Прошу прощения, что отвечаю нейрослопом — технически я в отпуске, да и лучше всё равно не напишу:

Проектирование систем в эпоху ИИ: Контракты vs Предметная область

Часть 1. Разделение труда: Что безопасно делегировать моделям?

Идея использовать контракты как жесткие границы для ИИ — это зрелый архитектурный подход, разделяющий разработку на высокоуровневое проектирование (стабильная зона) и детали реализации (изменчивая зона).

🔍 Что БЕЗОПАСНО делегировать (В рамках контракта)

ИИ идеален там, где есть строгая математическая или логическая изоляция, а задача сводится к «заполнению пустот» по готовым правилам.

  • Код внутри «чистых функций»: Если контракт жестко определяет вход (Data Transfer Object) и выход, ИИ напишет алгоритм трансформации данных без ошибок.

  • Генерация юнит-тестов на сам контракт: Модели отлично находят граничные значения (boundary условия), проверяют обработку null, пустых строк или некорректных типов на входе.

  • Рутинный Code Style и бойлерплейт: Настройка мапперов, создание DTO-классов, валидаторов данных и конфигурационных файлов по шаблону проекта.

  • Изолированные миграции данных: Если контракт старой схемы A и новой схемы B четко описан, ИИ сгенерирует скрипт трансформации данных.

❌ Что НЕЛЬЗЯ делегировать (Зона риска)

Проблемы начинаются там, где контракты сталкиваются с реальным миром, историческим контекстом и неявными зависимостями.

  1. Рефакторинг «дырявых» старых контрактов (Legacy): Старый контракт может содержать скрытые сайд-эффекты, на которые неявно завязаны другие модули. ИИ перепишет его «красиво», но сломает интеграцию с системой, которая ожидала именно старый «баг», ставший фичей.

  2. Проектирование абстракций верхнего уровня: Создание стабильных контрактов требует понимания долгосрочной бизнес-стратегии компании. ИИ не знает, куда бизнес пойдет через год, и может создать академически идеальную, но абсолютно негибкую структуру.

  3. Эволюция контрактов и миграция сложных распределенных систем: Модель видит контракт статическим. Ей тяжело спроектировать процесс перехода в реальном времени под нагрузкой (схемы двойной записи, конкурентный доступ, откаты транзакций).

Часть 2. Высший уровень: Схема «Человек проектирует предметную область -> ИИ пишет реализацию»

Эта схема выводит взаимодействие с ИИ на уровень DDD (Domain-Driven Design). Предметная область (Domain) выступает в роли главного, неизменяемого ядра системы, а ИИ занимается инфраструктурным «обвесом». Программист здесь окончательно перестает быть кодером и становится переводчиком со сложного языка реальности на строгий язык моделей.

🌟 Как это работает идеально

Человек описывает Единый язык (Ubiquitous Language), сущности (Entities), агрегаты (Aggregates) и доменные события (Domain Events) на естественном языке, а ИИ берет на себя рутину:

  • Изолированная доменная логика: ИИ великолепно переводит текстовое описание бизнес-правил в чистый код. Так как в доменном слое по канону нет зависимостей от БД и фреймворков, ИИ негде запутаться.

  • Покрытие инвариантов тестами: Вы описываете бизнес-правило, а ИИ генерирует сотни юнит-тестов, проверяющих этот инвариант со всеми возможными комбинациями данных.

  • Генерация инфраструктурного слоя: На основе вашей доменной модели ИИ пишет репозитории, контроллеры, мапперы в БД и DTO для внешних API.

⚠️ Где схема дает сбой (Новые вызовы)

  1. Трудности с границами контекстов (Bounded Contexts): Одна и та же сущность (например, Product) в разных отделах компании выглядит по-разному. Если человек четко не разделит контексты, ИИ попытается создать один гигантский «универсальный» класс (God Object), порождая монолитный хаос.

  2. Потеря скрытых бизнес-знаний (Implicit Knowledge): Бизнес-пользователи часто не говорят о вещах, которые кажутся им «очевидными». Человек-разработчик догадается спросить о пробелах в логике, ИИ же просто напишет код по дефектному ТЗ.

  3. Технический долг внутри самого Домена: Если правила меняются часто, ИИ может начать вносить правки в логику агрегатов «костылями», нарушая инкапсуляцию. В итоге доменная модель теряет свою чистоту и превращается в анемичную (Anemic Domain Model).

Итог

Схема с контрактами позволяет управлять структурой данных, а схема с предметной областью — смыслом бизнеса. Программирование будущего — это умение вытягивать из хаотичного реального мира чистые концепты и скармливать их фабрике агентов, оставляя за собой роль архитектора смыслов.

06.06.2026 08:41 UTC
-1

Аж духом Влашина потянуло https://bespoyasov.ru/blog/domain-modelling-made-functional/

О, этот запах смазки на шестерёнках, торчащих из монитора
О, этот запах смазки на шестерёнках, торчащих из монитора