Прочитал в фейсбуке у Церена отличный текст про то, что работа с агентами сводится к роли руководителя в концентрированном виде.
Церен это в целом и так знал и понимал, вопрос сейчас в том, что эта мысль уже начала раскатываться публично, "принимается" обществом и занимает свое место на столе.
Агентность еще не развернулась в том многообразии форм и протяженностей новых поверхностей для приложения трудовых усилий (surfaces, как называет это Карпатый), но вектор крепкий и не меняется -- быть руководителем это не вариант, а единственная роль, навыки которой лежат вне опыта инженеров, программистов, классических чайка-менеджеров из систем "свой -- чужой" и т.д.
Агент это вообще классное слово, это новая бигдата, машинлернинг и что там у нас было -- это максимально зонтичный термин. Это указатель, куда я вот с тобой сейчас говорю, в себе несущий неизвестные говорящему и слушателю смыслы и предметы. Это наполняется как корзинка, в моменте, и чем только можно.
Не только из поста Церена, но и много от кого уже в сети вы слышите, что оказывается важно:
- Контекст проекта держать самому, а между агентами РАЗДЕЛЯТЬ ТРУД порционально.
- Разделять труд необходимо так, чтобы его можно было потом СОБРАТЬ (Слоган моего доклада на highload 2018 года).
- Если ты не понимаешь, как ты примешь работу (получишь и применишь себе для чего тебе это было надо в твоем ОБЩЕМ КОНТЕКСТЕ), -- ты не можешь поставить задачу агенту, потому что нет задачи.
- ...
Идея витала в воздухе, поясняю я это от заказа к заказу, и тут такое -- легалайз. Каждая новая сессия вашей работы с ИИ -- это онбординг во всех смыслах этого слова максимально исполнительного, но неинформированного сотрудника.
Как ему передать так контекст, чтобы он не лопнул и не перегрузился (ТРИЗ-противоречие -- чем больше контекста, тем хуже работа любой llm, вплоть до шизы), при этом чтобы была необходимая достаточность понимания в рамках чего и что происходит и что собственно требуется сделать.
Да, еще поставить задачу надо так, чтобы не решать задачу за агента, а дать ему пространство, чтобы именно он сам чудо-мозгом нашуршал результат.
Вот это задача, которая стоит перед соло-руководителями, -- это именно уровень ПРИНЯТИЯ РЕШЕНИЙ, а не уровень ИСПОЛНЕНИЯ.
Руководитель -- это роль. А для выполнения своей роли ему нужен главный скилл. И этот скилл -- это архитектурное проектирование.
Плод деятельности руковожения является разделенный труд, который можно собрать в общий результат.
Как выглядит этот разделенный труд -- это не тикет-таблица, нет. Он может быть разделен без фамилий, с профессиями. Это тот самый контекст, который содержит все, что нужно, но не содержит ничего, что не нужно, и удерживает всю картинку, -- это архитектура.
Таким образом нужно иметь архитектуру под ключ (файл), давать ее агенту и сделать из этого что угодно -- да, именно так это и получается.
То, что вы даете доступ к папке с вашим проектом, -- это уже субстрат реализации. Где-то мельком вы прописали что-то подобное на архитектурный указатель, но архитектура -- это не обрывки мыслей и идей, это крепкое, согласованное, непротиворечивое ядро концентрированного смысла, произведенного ГОЛОВОЙ.
С любым LLM и армией агентов вы повышаете когнитивную нагрузку на узел принятия решений -- на себя. Если вы отдаете принятие решений машине -- вы слетаете с роли и дрейфуете как чайка на льдине.
Ничего путного кроме поделок не получается ровно по одной простой причине -- отсутствие Архитектуры вообще как объекта внимания и как отдельного продукта.
Который потребляют все ваши агенты -- люди, и машины.
Интересное заключается в том, что часто в разработке под архитектурой любят называть все, как устроено. То есть структуру, модульную разбивку, решения реализации.
Нет, это не архитектура, а проваливание в субстрат -- формы проявления архитектуры.
Пример -- одна и та же архитектура позволяет реализовать систему в любой форме: прием заявок вы можете делать по телефону, оплату принимать банками варенья, но при этом узел приема и обслуживания лида у вас есть.
Архитектура -- и есть тот ключик.