Комментарии 7
Можно ли продемонстрировать на конкретном примере, как Agent Orchestrator применяется в профессиональной деятельности? Существуют ли уже примеры практического использования подобных инструментов? Пока не ясно, как, например, запустить десять агентов, чтобы они работали одновременно, и как человек может контролировать их деятельность."Они сами всё сделали" и будет магией меня пока не удовлетворяет.
Я бы начал с оригинального кейса авторов Agent Orchestrator.
https://composio.dev/blog/the-self-improving-ai-system-that-built-itself
Там интереснее смотреть не на громкие цифры, а на сам процесс: как агентам раздавали отдельные задачи, как их работа проходила через pull request и CI, как ошибки и замечания возвращались обратно агенту и где всё-таки подключался человек.
Но честно: по-настоящему наглядных примеров с подробным разбором реальной профессиональной работы - от постановки задачи до итогового результата - мне пока не встречалось. Думаю, такие инструменты вообще сложно понять со стороны: нужно самому попробовать хотя бы двух-трёх агентов на настоящем проекте. Тогда становится видно, где действительно появляется эффективность, где возникают новые узкие места и для каких задач параллельная работа имеет смысл.
Позволю себе супер делитантский вопрос. Какая практическая польза от всего этого?
Не подумайте, что я ничего в этом не смыслю. Просто реально не понятно. Если мы тут можем писать программы за пару дней, то где найти столько потребностей в автоматизации? Разве условные бухгалтеры бегают и кричат, что у них миллион фич в бэклоге, которые тормознутые люди никак не могут сделать?
Мне кажется, вопрос стоит перевернуть: не где найти столько потребностей в автоматизации, а что произойдёт, когда разработка ускорится в десятки раз.
Мы приближаемся к ситуации, когда проекты, занимавшие годы, будут делаться за недели, а огромное количество привычных программ и SaaS-сервисов потеряет смысл. Особенно показателен здесь замысел Macrohard: Маск хочет не просто создать ещё одного помощника для программиста, а воспроизвести работу целой софтверной компании силами ИИ. Одни агенты будут писать и проверять код, другие - пользоваться программами через экран, мышь и клавиатуру, как это делает человек. По сути, речь идёт о полностью машинном производстве софта.
Даже если именно Macrohard не выстрелит, направление уже обозначено. Следующий шаг - исчезновение программ как постоянных продуктов. Вместо покупки CRM, редактора или бухгалтерской системы агент будет за минуты собирать одноразовое приложение под конкретного человека и конкретную задачу. Возможно, потеряют актуальность и современные языки программирования: зачем агентам код, удобный для чтения человеком, если можно создать низкоуровневый язык, оптимальный исключительно для машин?
В этом смысле описанные в статье диспетчерские - не решение проблемы бухгалтерского бэклога. Это первые примитивные панели управления производственной системой, масштаб и практическое назначение которой мы пока едва успеваем осознать.
не где найти столько потребностей в автоматизации, а что произойдёт, когда разработка ускорится в десятки раз.
Так проблема то не в скорости, проблема в формировании ТЗ промта. Раньше программист сидел и месяц тратил на код, попутно задавая вопросы про логику и внося корректировки и матерясь на "о! мы тут подумали и решили", теперь придется тратить 3 дня на промт и еще 27 дней на дебаг логики. По сути ничего не изменилось - "каждое следующее поколение программистов говорит на языке более высокого уровня" ну вот assembler->c->c++(python)--(мы тут)-->native lang.
Так что скорость это конечно хорошо, но не является необходимым и достаточным условием
Пока что моя работа увеличилась в 10х раз, а когнитивная нагрузка кипит. сэСпасибо всегда интересно быть в курсе. Огромное спасибо что потратил время и собрал информацию.

Армия в терминале