Очень много всего сейчас происходит параллельно... Голова кипит. Из основного творческого — это 2 отдельных почти непересекающихся направления: конечно же, книга «Доказательная архитектура» и средовой подход. Сегодня ночью очередь второго ⚗️
Основная гипотеза перехода от системного к средовому подходу в ИТ у меня сейчас такая: код благодаря ИИ дешевеет; компонентов любой системы (микросервисов, модулей в модульном монолите и т.д.), вероятно, станет больше, а изменения в них ускорятся. Количество потенциальных взаимодействий между ними может расти ещё быстрее. В какой-то момент проектировать каждое взаимодействие вручную станет слишком дорого, и часть работы архитектора переедет на уровень среды: архитектор будет задавать общие законы, настраивать стимулы и механизмы отбора.
Тут есть пробел в рассуждении — «в какой-то момент», а в какой? При каких условиях? Есть наблюдаемый тренд: код дешевеет, компонентов и изменений становится больше. А дальше я делаю скачок к выводу, что средовой подход обязательно окажется выгоднее. Но это пока именно гипотеза, причём гипотеза про будущее.
Знал бы прикуп.. 🃏
Сформулировать гипотезу точнее можно примерно так. При создании небольшой и редко меняющейся системы белковому, скорее всего, дешевле и надёжнее явно контролировать код: самостоятельно или с помощью ИИ-агента. Но по мере роста объёма генерируемого кода, сложности системы и частоты изменений стоимость проверки и перепроектирования каждого элемента может расти быстрее, чем стоимость поддержки среды, в которой ИИ-агенты создают систему по общим правилам. Если эти две кривые где-то пересекутся — там и будет тот самый переход. Если не пересекутся, значит моя гипотеза не работает или мы проверяем её не в том масштабе.
Далее. Я говорю, что для средового подхода нужны наблюдаемость и воспроизводимость. И говорю, что современные харнесы — как раз примеры применения средового подхода. Но разве воспроизводимость не противоречит самой природе LLM?
Если ждать от нейросети одинакового ответа на одинаковый запрос — противоречит. Побитовой воспроизводимости тут может не быть, но и от методологии она не требуется — методология не опускается до уровня супер-конкретных советов. Для LLM и средового подхода можно воспроизвести такой эксперимент: зафиксировать модель, контекст, инструменты и правила, выполнить много прогонов и смотреть на распределение результатов. Траектории создания системы могут различаться, но результат должен оставаться в заданных границах и с приемлемой вероятностью проходить критерии приёмки.
То есть в среде мы не пытаемся предсказать каждое действие каждого ИИ-агента и каждую написанную им строчку. Мы проверяем систему, которая вырастает в результате: выполняет ли она требования, соблюдает ли архитектурные правила и выдерживает ли заданные ограничения.
Теперь хочется конкретизировать и провести эксперимент. 🧪
Взять одну техническую задачу с одинаковыми функциональными и архитектурными критериями. Для чистоты эксперимента можно специально создавать строго детерминированную систему, например с центральным оркестратором бизнес-процесса.
В первом варианте человек поэлементно управляет созданием системы: декомпозирует задачу, задаёт агенту каждый следующий шаг, проверяет решения и явно корректирует код.
[продолжение ниже]
Основная гипотеза перехода от системного к средовому подходу в ИТ у меня сейчас такая: код благодаря ИИ дешевеет; компонентов любой системы (микросервисов, модулей в модульном монолите и т.д.), вероятно, станет больше, а изменения в них ускорятся. Количество потенциальных взаимодействий между ними может расти ещё быстрее. В какой-то момент проектировать каждое взаимодействие вручную станет слишком дорого, и часть работы архитектора переедет на уровень среды: архитектор будет задавать общие законы, настраивать стимулы и механизмы отбора.
Тут есть пробел в рассуждении — «в какой-то момент», а в какой? При каких условиях? Есть наблюдаемый тренд: код дешевеет, компонентов и изменений становится больше. А дальше я делаю скачок к выводу, что средовой подход обязательно окажется выгоднее. Но это пока именно гипотеза, причём гипотеза про будущее.
Знал бы прикуп.. 🃏
В моем предлагаемом средовом подходе есть важная развилка его применения. Можно проектировать
🛑 среду, в которой работает система;
🛑 среду, в которой система создаётся.
Сегодня поговорим о втором — о среде создания системы. На выходе может получиться любая архитектура, в том числе строго детерминированная система с оркестратором в центре.❕
Сформулировать гипотезу точнее можно примерно так. При создании небольшой и редко меняющейся системы белковому, скорее всего, дешевле и надёжнее явно контролировать код: самостоятельно или с помощью ИИ-агента. Но по мере роста объёма генерируемого кода, сложности системы и частоты изменений стоимость проверки и перепроектирования каждого элемента может расти быстрее, чем стоимость поддержки среды, в которой ИИ-агенты создают систему по общим правилам. Если эти две кривые где-то пересекутся — там и будет тот самый переход. Если не пересекутся, значит моя гипотеза не работает или мы проверяем её не в том масштабе.
Далее. Я говорю, что для средового подхода нужны наблюдаемость и воспроизводимость. И говорю, что современные харнесы — как раз примеры применения средового подхода. Но разве воспроизводимость не противоречит самой природе LLM?
Если ждать от нейросети одинакового ответа на одинаковый запрос — противоречит. Побитовой воспроизводимости тут может не быть, но и от методологии она не требуется — методология не опускается до уровня супер-конкретных советов. Для LLM и средового подхода можно воспроизвести такой эксперимент: зафиксировать модель, контекст, инструменты и правила, выполнить много прогонов и смотреть на распределение результатов. Траектории создания системы могут различаться, но результат должен оставаться в заданных границах и с приемлемой вероятностью проходить критерии приёмки.
То есть в среде мы не пытаемся предсказать каждое действие каждого ИИ-агента и каждую написанную им строчку. Мы проверяем систему, которая вырастает в результате: выполняет ли она требования, соблюдает ли архитектурные правила и выдерживает ли заданные ограничения.
Теперь хочется конкретизировать и провести эксперимент. 🧪
Взять одну техническую задачу с одинаковыми функциональными и архитектурными критериями. Для чистоты эксперимента можно специально создавать строго детерминированную систему, например с центральным оркестратором бизнес-процесса.
В первом варианте человек поэлементно управляет созданием системы: декомпозирует задачу, задаёт агенту каждый следующий шаг, проверяет решения и явно корректирует код.
[продолжение ниже]