Ну, "всегда" - это сильное утверждение. Мы переживаем краткий момент когда можем еще что то понять и улучшить в том что генерирует LLM.
У меня желание (вайб)кодить пропадает не потому что нейронка что то делает плохо, а потому что через год она будет делать это лучше чем я. В том числе ставить задачи.
Я тоже сначала использовал claude session-to-session communication, но т.к. лимита MAX 20x регулярно не хватает, пришлось подключить GLM как альтернативу, а в ней это API не работает.
Так что сделал надстройку, которая использует для этого недокументированное API claude code и работает с любой моделью.
Вместо "файлов памяти" на FS использую тикеты в трекере который работают как RAG (агент отлично им управляет - ищет дубли, перелинковывает, создает задачи, трекает прогресс)
Самое главное - управлять роем должен не человек а агент, человек принимает только ключевые решения (утверждает или изменяет предложенную агентом реализацию фичи/фикс бага).
Вот мой скилл мастер агента. По моему опыту, решения которые предлагает fable удовлетворительны в 80-90% случаев.
У меня на последнем (экспериментальном) проекте выстроен классический цикл разработки:
CD (трекер задач) TDD (строгая test-driven разработка), CI (сборка и прогон тестов), деплой, smoke тесты, анализ телеметрии - все это экспонировано в утилиты командной строки доступные агенту (MCP сервера мне не нравятся т.к. их неудобно юзать человеку).
Управляет всем агент (мастер), у которого в подчинении пул других агентов (папетов) с которыми он обменивается сообщениями через MCP (его я накостылял)
Роль человека в этом.. Боюсь это говорить, но практика показала что для фронтир моделей человек по больше части не нужен вообще.
/loop 1h изучи логи и заведи баги /loop 1h разай задачи /goal пустой трекер
Ну а касательно вопросов:
> Пытаетесь ли вы менять архитектуру проектов специально под ИИ-агентов?
Архитектура по большей части это свойство проекта а не процесса разработки, главное что бы она была с ним совместима (например, была тестируемой)
> Как дела с многопоточностью, когда используете много агентов одновременно?
Я пришел к тому что интеграция в главную ветку централизована, все остальное делается асинхронно. Агенты прекрасно находят общий язык.
> Нужна ли вообще строгая файловая типизация или это путь к архитектурной бюрократии?
Строить универсальную онтологию гиблое дело, но формализовать ее для конкретного проекта это всегда благо
> И где, на ваш взгляд, проходит граница между разработчиком и оператором ИИ-системы?
On a long enough time line, the survival rate for everyone drops to zero.
Так эту теорему еще 10 лет назад Хоофт доказал (см его cogwheels) но в итоге уперся в проблему с нижней границей гамильтониана которую, к слову, так и не решил. A тут ее просто проскочили.
А Вольфрам и не утверждал, что его постулат относится к линейным системам, у него совершенно другая онтология.
Ну, "всегда" - это сильное утверждение. Мы переживаем краткий момент когда можем еще что то понять и улучшить в том что генерирует LLM.
У меня желание (вайб)кодить пропадает не потому что нейронка что то делает плохо, а потому что через год она будет делать это лучше чем я. В том числе ставить задачи.
Я тоже сначала использовал claude session-to-session communication, но т.к. лимита MAX 20x регулярно не хватает, пришлось подключить GLM как альтернативу, а в ней это API не работает.
Так что сделал надстройку, которая использует для этого недокументированное API claude code и работает с любой моделью.
Вместо "файлов памяти" на FS использую тикеты в трекере который работают как RAG (агент отлично им управляет - ищет дубли, перелинковывает, создает задачи, трекает прогресс)
Самое главное - управлять роем должен не человек а агент, человек принимает только ключевые решения (утверждает или изменяет предложенную агентом реализацию фичи/фикс бага).
Вот мой скилл мастер агента. По моему опыту, решения которые предлагает fable удовлетворительны в 80-90% случаев.
У меня на последнем (экспериментальном) проекте выстроен классический цикл разработки:
CD (трекер задач) TDD (строгая test-driven разработка), CI (сборка и прогон тестов), деплой, smoke тесты, анализ телеметрии - все это экспонировано в утилиты командной строки доступные агенту (MCP сервера мне не нравятся т.к. их неудобно юзать человеку).
Управляет всем агент (мастер), у которого в подчинении пул других агентов (папетов) с которыми он обменивается сообщениями через MCP (его я накостылял)
Роль человека в этом.. Боюсь это говорить, но практика показала что для фронтир моделей человек по больше части не нужен вообще.
/loop 1h изучи логи и заведи баги
/loop 1h разай задачи
/goal пустой трекер
Ну а касательно вопросов:
> Пытаетесь ли вы менять архитектуру проектов специально под ИИ-агентов?
Архитектура по большей части это свойство проекта а не процесса разработки, главное что бы она была с ним совместима (например, была тестируемой)
> Как дела с многопоточностью, когда используете много агентов одновременно?
Я пришел к тому что интеграция в главную ветку централизована, все остальное делается асинхронно. Агенты прекрасно находят общий язык.
> Нужна ли вообще строгая файловая типизация или это путь к архитектурной бюрократии?
Строить универсальную онтологию гиблое дело, но формализовать ее для конкретного проекта это всегда благо
> И где, на ваш взгляд, проходит граница между разработчиком и оператором ИИ-системы?
On a long enough time line, the survival rate for everyone drops to zero.
Так эту теорему еще 10 лет назад Хоофт доказал (см его cogwheels) но в итоге уперся в проблему с нижней границей гамильтониана которую, к слову, так и не решил. A тут ее просто проскочили.
А Вольфрам и не утверждал, что его постулат относится к линейным системам, у него совершенно другая онтология.