[начало выше]
Во втором варианте человек сначала проектирует среду создания: спецификацию, архитектурные правила, тесты, доступные инструменты, контекст, ограничения по ресурсам и условия остановки. Те же ИИ-агенты, возможно даже с тем же оркестратором, создают систему внутри этой среды. Человек вмешивается, когда правила среды не удерживают нужный результат или оказываются неполными.
А потом начать портить обоим вариантам жизнь: увеличивать объём системы, добавлять неизвестные заранее требования, менять условия в процессе, заменять модель или одного из агентов. Измерять затраты человека на настройку и дальнейшие вмешательства, количество прямых исправлений, объём перепроектирования, нарушения правил, стоимость и время создания системы.
На маленькой задаче поэлементное управление вполне может победить: среду ещё нужно построить, а её стоимость не успеет окупиться. Но с ростом системы и числа изменений ситуация может поменяться. Если точка пересечения не обнаружится, значит гипотеза не работает на доступном масштабе или неверна вообще.
Да, в полном виде эксперимент получается дорогим. Если сравнивать несколько способов разработки, разные уровни сложности, неожиданные изменения и проводить повторные прогоны, это уже небольшая исследовательская программа, а не один эксперимент.
Можно начать с дешёвого пилота: одна небольшая, но не игрушечная система с детерминированными приёмочными тестами. Сначала её создают через обычное ручное управление кодом с ИИ-агентом, затем ту же задачу решает среда из нескольких агентов, ограниченных общими правилами и проверками. После первой реализации в требования вносится одно заранее не раскрытое изменение.
Сравнивать стоит:
🛑 затраты человека на управление;
🛑 стоимость токенов и общее время;
🛑 количество ручных вмешательств;
🛑 нарушения архитектурных ограничений;
🛑 прохождение функциональных тестов;
🛑 объём переделок после изменения требований.
Важно отдельно учитывать стоимость создания среды и стоимость каждого следующего изменения. На одной задаче средовой подход почти наверняка окажется дороже из-за стартовых затрат. Его гипотетическое преимущество должно проявляться не в первой реализации, а в том, как быстро растут затраты при повторных изменениях и усложнении системы.
Такой пилот не докажет, что точка экономической эффективности обязательно существует. Он проверит более скромные гипотезы: может ли среда вообще самостоятельно создавать детерминированную систему, уменьшается ли ручное управление и сохраняются ли заданные ограничения при изменении требований. Уже по его результатам можно решать, оправдан ли большой эксперимент. 🤚
Получается, книга о доказательной архитектуре и архитектурных гипотезах и средовой подход всё же пересеклись в одной точке: эту гипотезу тоже придётся проверять об практику. Пока она опирается на интуицию, аналогии и уже существующие практики вокруг SDD, обвязки (harness'а), архитектурных тестов и формальных правил.
Получается, что описанный эксперимент — ещё один кейс в копилку практики применения описанных в книге подходов 📒
И, кажется, я уже знаю какие части в себя будет включать моя следующая книга 🙂
I. Проектирование среды создания детерминированной системы
II. Проектирование среды, в которой работает система
III. Проектирование среды создания среды
🧸
Во втором варианте человек сначала проектирует среду создания: спецификацию, архитектурные правила, тесты, доступные инструменты, контекст, ограничения по ресурсам и условия остановки. Те же ИИ-агенты, возможно даже с тем же оркестратором, создают систему внутри этой среды. Человек вмешивается, когда правила среды не удерживают нужный результат или оказываются неполными.
А потом начать портить обоим вариантам жизнь: увеличивать объём системы, добавлять неизвестные заранее требования, менять условия в процессе, заменять модель или одного из агентов. Измерять затраты человека на настройку и дальнейшие вмешательства, количество прямых исправлений, объём перепроектирования, нарушения правил, стоимость и время создания системы.
На маленькой задаче поэлементное управление вполне может победить: среду ещё нужно построить, а её стоимость не успеет окупиться. Но с ростом системы и числа изменений ситуация может поменяться. Если точка пересечения не обнаружится, значит гипотеза не работает на доступном масштабе или неверна вообще.
Да, в полном виде эксперимент получается дорогим. Если сравнивать несколько способов разработки, разные уровни сложности, неожиданные изменения и проводить повторные прогоны, это уже небольшая исследовательская программа, а не один эксперимент.
Можно начать с дешёвого пилота: одна небольшая, но не игрушечная система с детерминированными приёмочными тестами. Сначала её создают через обычное ручное управление кодом с ИИ-агентом, затем ту же задачу решает среда из нескольких агентов, ограниченных общими правилами и проверками. После первой реализации в требования вносится одно заранее не раскрытое изменение.
Сравнивать стоит:
🛑 затраты человека на управление;
🛑 стоимость токенов и общее время;
🛑 количество ручных вмешательств;
🛑 нарушения архитектурных ограничений;
🛑 прохождение функциональных тестов;
🛑 объём переделок после изменения требований.
Важно отдельно учитывать стоимость создания среды и стоимость каждого следующего изменения. На одной задаче средовой подход почти наверняка окажется дороже из-за стартовых затрат. Его гипотетическое преимущество должно проявляться не в первой реализации, а в том, как быстро растут затраты при повторных изменениях и усложнении системы.
Такой пилот не докажет, что точка экономической эффективности обязательно существует. Он проверит более скромные гипотезы: может ли среда вообще самостоятельно создавать детерминированную систему, уменьшается ли ручное управление и сохраняются ли заданные ограничения при изменении требований. Уже по его результатам можно решать, оправдан ли большой эксперимент. 🤚
Получается, книга о доказательной архитектуре и архитектурных гипотезах и средовой подход всё же пересеклись в одной точке: эту гипотезу тоже придётся проверять об практику. Пока она опирается на интуицию, аналогии и уже существующие практики вокруг SDD, обвязки (harness'а), архитектурных тестов и формальных правил.
Получается, что описанный эксперимент — ещё один кейс в копилку практики применения описанных в книге подходов 📒
И, кажется, я уже знаю какие части в себя будет включать моя следующая книга 🙂
I. Проектирование среды создания детерминированной системы
II. Проектирование среды, в которой работает система
III. Проектирование среды создания среды
🧸