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

[Dhwtj]

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

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

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

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

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

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

[nomhoi]

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

Проектирование систем в эпоху ИИ: Контракты 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).

Итог

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

[Dhwtj]

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

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