Сперва начал писать развернутый ответ. Но к сожалению понял, что полемика в таком формате комментариев избыточна. Простите :)
Спасибо за замечания и Ваши размышления. Некоторые действительно по делу. Некоторые (как например SVN) - наследие старого проекта, которое мы знаем, но сейчас не является первостепенным. Но некоторые избыточны и основаны на предположениях о нашем проекте. Как то например, из выбора того же SVN сделан необоснованный вывод, что серьёзный рефакторинг у нас не в чести. Это не так: недавно буквально распилили модуль с 30к строк, который рос годами на участки по 5к и соответствующие классы. Многое остаётся за пределами этой статьи - она лишь про конвейер Автопилота.
Идею "что считать сделаным" принял на вооружение, усилив промты и цели агентов. Спасибо.
Честно, мне приятно такое детальное внимание к теме. Значит, наверное, наш опыт оказался полезен хотя бы чтоб поднять тему. :) Пойду почитаю Ваш опыт. Многие советы про анализаторы выглядят хорошо. Спасибо.
Человеческого контроля каждого изменения нет. В том то и прелесть. При таких масштабах разработки затраты на человеческий контроль несопоставимы с затратами на ИИ. Стало быть контроль кода и дрейфа состоит примерно из этих частей: а) Ревьюер (он указан на схеме). Простая подчистка "хвостов", мертвого кода и прочих мелочей сразу после создания кода б) При написании кода Клод "консультируется" с Кодексом получая его ревью на отдельные вопросы или в целом на код, который написала. Там уже вопросы решаются не только поверхностные, но и архитектурные. В промтах много требований соблюдать консистентность проекта, не плодить излишний код, не наслаивать. Но конечно бывает. Поэтому чистка идет дальше в) Аудит. На этом этапе самый строгий контроль кода и архитектуры г) Архитектурный дрейф контролируется "вручную" инженером естественно при помощи ИИ агента по фактическим диффам - это позволяет сосредоточить анализ именно на измененных участках, не распыляясь по всему проекту. Найденную проблему можно не ждать самому, а создать ишью по результатам анализа - Решала выполнит сам. д) По дрейфу наверное самое важное. Архитектурные развилки обязаны эскалироваться к лиду еще на этапе анализа кода. Автомат не возьмется за работу если видит важную архитектурную развилку
Нет, статических анализаторов не добавляли. На практике видно, что ИИ агенты справляются с этой задачей лучше. Несколько уровней контроля кода, которые перечислил выше, справляются с задачей. Статический анализатор думается мне уходит в прошлое. Но его функция конечно остается. Просто выполняется качественнее.
Контекст агента а) Каждый субагент - отдельный контекст со своими промтами б) Между агентами нужные данные передаются через папку ишью - там нужные логи, выводы, скриншоты, скачанная фикстура и прочее в) Стоимость каждого субагента контролируется в долларах и в токенах. Есть лимиты. г) Ктстаи по промтам. Важный инсайт (вроде очевидный, но не сразу доходит) - нельзя идти путем создания промтов по типу указаний, строгих правил. Агент достаточно умный, но исполнительный. И чем строже правила, тем боьльше они зажимают его и превращают в обычный олдскульный алгоритм. Промты нужно писать в формате манифеста, рекомендаций, и полученного ранее опыта. Строгие указания только на важные моменты: например безопасность д) На каждом инстансе весь процесс работы ведет отдельный агент. Даже если на компе все агенты запускаются скриптом и летят в автомате, здесь запущего интерактивное окно Клода (или Кодекс), который следит за процессом, "тушит пожар", отписывается в общий чат и прочее. А "марафон" задач например вообще бежит на таком агенте без скрипта автоматического выбора задач. Последовательности и важность задач, которые мы берем решает ИИ агент. И с ним непосредственно есть перепика с человеком. В общем это такой домовой на каждом компе :) к которому я всегда могу зайти и спросить как дела, что делается, как прошла ночь и так далее. Конечно же этот агент имеет "бесконечный" продолжающийся автосаммари контекст
Сейчас у нас строгое разделение ролей. Иначе можно зарыться. "Решала" не дописывает себе "ручки", но если он понимает, что ему не хватает инфраструктуры, он делает infra feedback, откладывает решение ишью. Разбор фидбэка (отдельный агент) выполняет анализ и доработку ифнраструктуры по жалобам обобщенно и системно. Потом решение повторяется уже с новой измененной инфраструктурой. Так мы отделяем роли. Разбиратель фидбэка (Доработница :) знает как работать с инфраструктурой и имеет системное "мышление" (промты). У Решалы своя задача - решить ишью на той инфраструктуре, что имеем. При необходимости запросить изменения. Так мы исключаем зацикливание в самодоработки. И самое главное обеспечиваем системный взгляд на инфраструктуру, а не костыльную подгонку "ручек" под конкретный случай
Вот я хочу делать не просто Модератора, а Директора. Которого будут еще слушаться и исполнять. И еще. Сейчас чат они читают по своему усмотрению каждый. Обычно как начинают или заканчивают какую-то работу. Поэтому срочного "исполнения приказа" в таком варианте нет. Я собираюсь пилить чтоб сообщения о Директора попадали моментально в контекст агентов кому они назначены. В этом есть некоторая потребность уже. Ну к примеру нужно срочно стопнуть разработку и не коммитить никому. Сейчас такое не сработает если отправить. Все прочитают это в разное время.
К сожалению без фильтрации по ишьюсам оно выглядит мягко говоря запутанно. Там просто поток сообщений одовременно от разных машин по разным задачам. Обычно сообщения большие, подробные. Я специально запоминал и выбирал интересные случаи которые мне понравились. А еще там обезличены номера заявок, убраны пути, названия машин и прочее. Так что сорри, сейчас больше ничего нет - не готовил. Но может есть смысл сделать отдельный выпуск про внутреннее общение ИИ.. хм.. прикольная идея. если матерьяла насобираю ;)
Information
Rating
1,242-nd
Location
Тюмень, Тюменская обл. и Ханты-Мансийский АО, Россия
Registered
Activity
Specialization
Архитектор программного обеспечения, ML разработчик
Сперва начал писать развернутый ответ. Но к сожалению понял, что полемика в таком формате комментариев избыточна. Простите :)
Спасибо за замечания и Ваши размышления. Некоторые действительно по делу. Некоторые (как например SVN) - наследие старого проекта, которое мы знаем, но сейчас не является первостепенным. Но некоторые избыточны и основаны на предположениях о нашем проекте. Как то например, из выбора того же SVN сделан необоснованный вывод, что серьёзный рефакторинг у нас не в чести. Это не так: недавно буквально распилили модуль с 30к строк, который рос годами на участки по 5к и соответствующие классы. Многое остаётся за пределами этой статьи - она лишь про конвейер Автопилота.
Идею "что считать сделаным" принял на вооружение, усилив промты и цели агентов. Спасибо.
Честно, мне приятно такое детальное внимание к теме. Значит, наверное, наш опыт оказался полезен хотя бы чтоб поднять тему. :) Пойду почитаю Ваш опыт. Многие советы про анализаторы выглядят хорошо. Спасибо.
Человеческого контроля каждого изменения нет. В том то и прелесть. При таких масштабах разработки затраты на человеческий контроль несопоставимы с затратами на ИИ. Стало быть контроль кода и дрейфа состоит примерно из этих частей:
а) Ревьюер (он указан на схеме). Простая подчистка "хвостов", мертвого кода и прочих мелочей сразу после создания кода
б) При написании кода Клод "консультируется" с Кодексом получая его ревью на отдельные вопросы или в целом на код, который написала. Там уже вопросы решаются не только поверхностные, но и архитектурные. В промтах много требований соблюдать консистентность проекта, не плодить излишний код, не наслаивать. Но конечно бывает. Поэтому чистка идет дальше
в) Аудит. На этом этапе самый строгий контроль кода и архитектуры
г) Архитектурный дрейф контролируется "вручную" инженером естественно при помощи ИИ агента по фактическим диффам - это позволяет сосредоточить анализ именно на измененных участках, не распыляясь по всему проекту. Найденную проблему можно не ждать самому, а создать ишью по результатам анализа - Решала выполнит сам.
д) По дрейфу наверное самое важное. Архитектурные развилки обязаны эскалироваться к лиду еще на этапе анализа кода. Автомат не возьмется за работу если видит важную архитектурную развилку
Нет, статических анализаторов не добавляли. На практике видно, что ИИ агенты справляются с этой задачей лучше. Несколько уровней контроля кода, которые перечислил выше, справляются с задачей. Статический анализатор думается мне уходит в прошлое. Но его функция конечно остается. Просто выполняется качественнее.
Контекст агента
а) Каждый субагент - отдельный контекст со своими промтами
б) Между агентами нужные данные передаются через папку ишью - там нужные логи, выводы, скриншоты, скачанная фикстура и прочее
в) Стоимость каждого субагента контролируется в долларах и в токенах. Есть лимиты.
г) Ктстаи по промтам. Важный инсайт (вроде очевидный, но не сразу доходит) - нельзя идти путем создания промтов по типу указаний, строгих правил. Агент достаточно умный, но исполнительный. И чем строже правила, тем боьльше они зажимают его и превращают в обычный олдскульный алгоритм. Промты нужно писать в формате манифеста, рекомендаций, и полученного ранее опыта. Строгие указания только на важные моменты: например безопасность
д) На каждом инстансе весь процесс работы ведет отдельный агент. Даже если на компе все агенты запускаются скриптом и летят в автомате, здесь запущего интерактивное окно Клода (или Кодекс), который следит за процессом, "тушит пожар", отписывается в общий чат и прочее. А "марафон" задач например вообще бежит на таком агенте без скрипта автоматического выбора задач. Последовательности и важность задач, которые мы берем решает ИИ агент. И с ним непосредственно есть перепика с человеком. В общем это такой домовой на каждом компе :) к которому я всегда могу зайти и спросить как дела, что делается, как прошла ночь и так далее. Конечно же этот агент имеет "бесконечный" продолжающийся автосаммари контекст
Сейчас у нас строгое разделение ролей. Иначе можно зарыться. "Решала" не дописывает себе "ручки", но если он понимает, что ему не хватает инфраструктуры, он делает infra feedback, откладывает решение ишью. Разбор фидбэка (отдельный агент) выполняет анализ и доработку ифнраструктуры по жалобам обобщенно и системно. Потом решение повторяется уже с новой измененной инфраструктурой. Так мы отделяем роли. Разбиратель фидбэка (Доработница :) знает как работать с инфраструктурой и имеет системное "мышление" (промты). У Решалы своя задача - решить ишью на той инфраструктуре, что имеем. При необходимости запросить изменения. Так мы исключаем зацикливание в самодоработки. И самое главное обеспечиваем системный взгляд на инфраструктуру, а не костыльную подгонку "ручек" под конкретный случай
Вернули 2007 ;)
Но вообще наши задачи выполняет. Это не редкость в давнишних проектах.
Вот я хочу делать не просто Модератора, а Директора. Которого будут еще слушаться и исполнять. И еще. Сейчас чат они читают по своему усмотрению каждый. Обычно как начинают или заканчивают какую-то работу. Поэтому срочного "исполнения приказа" в таком варианте нет. Я собираюсь пилить чтоб сообщения о Директора попадали моментально в контекст агентов кому они назначены. В этом есть некоторая потребность уже. Ну к примеру нужно срочно стопнуть разработку и не коммитить никому. Сейчас такое не сработает если отправить. Все прочитают это в разное время.
К сожалению без фильтрации по ишьюсам оно выглядит мягко говоря запутанно. Там просто поток сообщений одовременно от разных машин по разным задачам. Обычно сообщения большие, подробные. Я специально запоминал и выбирал интересные случаи которые мне понравились. А еще там обезличены номера заявок, убраны пути, названия машин и прочее. Так что сорри, сейчас больше ничего нет - не готовил. Но может есть смысл сделать отдельный выпуск про внутреннее общение ИИ.. хм.. прикольная идея. если матерьяла насобираю ;)