На Skills нет, на рабочий процесс которые эти Skills обслуживают — да. Я оставил ссылку на нашу платформу, в ней есть такое понятие как pipelines, они представляют из себя способ декларировать конвейер который агенты должны исполнить и это не просто Skills, это может быть несколько Skills workflow запущенные параллельно или последовательно в разных агентных сессиях, у этого piplelines есть UI интерфейс через который можно регрессировать процесс хоть UI тестами, он так же умеет писать свое состояние и runtime log на файловую систему, что позволяет написать функциональные тесты. Агент может немного по разному задавать вопросы и писать вывод, но якоря и стадии не меняются если Skills - это алгоритм, а не 1000 строк требований и ограничений, половину из которых агент никогда не исполнит. Артефакты между стадиями шаблонезированы и могут быть верифицированы. Да и в целом это конечный автомат который полностью детерменирован. Можно пойти дальше и обрастить процессы метриками, обновлять Skills и смотреть где-нибудь в Grafana, как изменяются метрики процессов и результатов которые мы ожидаем. Поэтому я не вижу смысла в принципе регрессировать сами скиллы, когда можно регрессировать и мониторить процессы которые эти скилы обслуживают.
На мой взгляд, тут гораздо более интересный вопрос в том, что делать если регрессия показала деградацию =) Но это тема отдельной статьи =)
Кто будет писать — не важно, важен принцип. Мы пишем комбинировано, что-то агент (и это большинство), что-то руками, иногда попросить агент дольше и дороже, чем написать руками пару строк в Markdown. Но тут вопрос не в этом, вопрос в том, что если агент напишет за вас Skill насколько вы будете понимать, как он работает и что там вообще написано? Это может показаться неважным если у вас десяток Skills и небольшой проект, но если у вас 100+ Skills, а если 1000+, то уже нужно уметь управлять тем, что они делают, а для этого процесс требует систематизации. Я нашел для себя такой способ и решил поделиться им сейчас потому, что он уже успешно работает и хорошо себя зарекомендовал у нас в команде, вы можете найти свой и поделиться им, мне было бы очень интересно посмотреть на другие решения. Мы все сейчас находимся немного "в творческом поиске" и я не исключаю, что возможно найдется решение лучше.
Все так, поэтому больше хочется quality gates, а не стандарты, но не бессмысленно трешхолды ставить которые душат, а более осмысленно это делать не мешая работе. Сейчас у нас достаточно прикольно получается, трешхолды в CI по рукам ударили в ветке, в агенте скилл запустил, план улучшений посмотрел, сделал небольшой рефкторинг сразу им же, не дал деградации усилиться. Вроде и не сложно, тк метрика по рукам ударила, но есть инструмент который сразу и поправить поможет, но и полезно, не дает на дно упасть. Хочется конечно дальше пойти, это не идеал, скорее просто старт, посмотрим куда приведет.
Спасибо, что не поленились и написали такой развернутый коммент! Когда пишешь первую статью, то вообще не ожидаешь, что кто-то потратит силы и напишет подробный комментарий, да еще и с которым не поспоришь.
Я полностью согласен, что если у тебя опыта вагон и за ним еще целый состав, то в целом проблем нет, сиди себе и пинай агента в спеки пока контекстное окно не закончится. Но я столкнулся с проблемой когда у людей не такая мощная инженерная база, команды в биг техах, как правило, разнородны, многие вообще отрицают новые подходы, да и с точки зрения опыта последнего года у меня были случаи когда пускали людей с агентами в репозиторий в котором идет очень интенсивная разработка и они буквально уничтожали репос агентами за пару месяцев и приходилось полностью откатываться и все переписывать и там было такое состояние проекта, что и strictacode бы не помог уже, а были случаи когда все достаточно гладко шло, потому, что репозиторий небольшой, работает в нем полтора человека и в целом следят за тем, что там агент делает. Но меня сейчас больше занимает вопрос того, как стабилизировать качество и получить контроль за деградацией с учетом того, что в биг техах очень интенсивная разработка, разнородные команды, многим разработчкам очень сложно читать спеки и выхлоп от агента, когда они привыкли уже мыслить трассировкой и держать в голове графовидную структуру взаимодействий, а им тут спеки подсунули, люди ломаются и либо забивают на то, что агент пишет и просто соглашаются и либо идут опять руками писать, и хорошо если второе, а вот если первое, то тут уже метрики могут помочь.
У нас есть фронт на js который полностью навайбкожен и мы работам по алгоритму — сделали несколько фич, запускаем скилл strictacode и делаем план улучшений. И пока ребятам такой подход очень нравится, говорят, что он предлагает достаточно хорошие планы и результат нравится. Возможно вам тоже поможет, попробуйте, будет интересно получить обратную связь ;)
На 100% сказать сложно, но ИИ-ку обычно тянет RP перекос, большинство проектов которые мне доводилось видеть, которые написаны нейронкой, даже если используется какой-нибудь speckit или superpowers, то там обычно этот симптом вылезает. Попробуйте последить за этим показателем, возможно получится если не на 100% задетектить, но хотя бы заподозрить.
А если быть до конца честным, то в целом какая разница пишут нейронками или нет, если проект здоров =)
Если быть до конца честным, то я сам последний раз писал на java лет 15 назад и сейчас мы уже давно не используем его на проектах, kotlin встречается, а вот java нет. А добавлять язык для галочки, не понимая как это в реальной жизни работает просто нет ни времени, ни сил. Но если вы поможете проекту и добавите поддержку java, то мы не будем противиться pull request-у ;)
На Skills нет, на рабочий процесс которые эти Skills обслуживают — да. Я оставил ссылку на нашу платформу, в ней есть такое понятие как pipelines, они представляют из себя способ декларировать конвейер который агенты должны исполнить и это не просто Skills, это может быть несколько Skills workflow запущенные параллельно или последовательно в разных агентных сессиях, у этого piplelines есть UI интерфейс через который можно регрессировать процесс хоть UI тестами, он так же умеет писать свое состояние и runtime log на файловую систему, что позволяет написать функциональные тесты. Агент может немного по разному задавать вопросы и писать вывод, но якоря и стадии не меняются если Skills - это алгоритм, а не 1000 строк требований и ограничений, половину из которых агент никогда не исполнит. Артефакты между стадиями шаблонезированы и могут быть верифицированы. Да и в целом это конечный автомат который полностью детерменирован. Можно пойти дальше и обрастить процессы метриками, обновлять Skills и смотреть где-нибудь в Grafana, как изменяются метрики процессов и результатов которые мы ожидаем. Поэтому я не вижу смысла в принципе регрессировать сами скиллы, когда можно регрессировать и мониторить процессы которые эти скилы обслуживают.
На мой взгляд, тут гораздо более интересный вопрос в том, что делать если регрессия показала деградацию =) Но это тема отдельной статьи =)
Кто будет писать — не важно, важен принцип. Мы пишем комбинировано, что-то агент (и это большинство), что-то руками, иногда попросить агент дольше и дороже, чем написать руками пару строк в Markdown. Но тут вопрос не в этом, вопрос в том, что если агент напишет за вас Skill насколько вы будете понимать, как он работает и что там вообще написано? Это может показаться неважным если у вас десяток Skills и небольшой проект, но если у вас 100+ Skills, а если 1000+, то уже нужно уметь управлять тем, что они делают, а для этого процесс требует систематизации. Я нашел для себя такой способ и решил поделиться им сейчас потому, что он уже успешно работает и хорошо себя зарекомендовал у нас в команде, вы можете найти свой и поделиться им, мне было бы очень интересно посмотреть на другие решения. Мы все сейчас находимся немного "в творческом поиске" и я не исключаю, что возможно найдется решение лучше.
Рад, что статья оказалась вам полезной ;)
Все так, поэтому больше хочется quality gates, а не стандарты, но не бессмысленно трешхолды ставить которые душат, а более осмысленно это делать не мешая работе. Сейчас у нас достаточно прикольно получается, трешхолды в CI по рукам ударили в ветке, в агенте скилл запустил, план улучшений посмотрел, сделал небольшой рефкторинг сразу им же, не дал деградации усилиться. Вроде и не сложно, тк метрика по рукам ударила, но есть инструмент который сразу и поправить поможет, но и полезно, не дает на дно упасть. Хочется конечно дальше пойти, это не идеал, скорее просто старт, посмотрим куда приведет.
Спасибо, что не поленились и написали такой развернутый коммент! Когда пишешь первую статью, то вообще не ожидаешь, что кто-то потратит силы и напишет подробный комментарий, да еще и с которым не поспоришь.
Я полностью согласен, что если у тебя опыта вагон и за ним еще целый состав, то в целом проблем нет, сиди себе и пинай агента в спеки пока контекстное окно не закончится. Но я столкнулся с проблемой когда у людей не такая мощная инженерная база, команды в биг техах, как правило, разнородны, многие вообще отрицают новые подходы, да и с точки зрения опыта последнего года у меня были случаи когда пускали людей с агентами в репозиторий в котором идет очень интенсивная разработка и они буквально уничтожали репос агентами за пару месяцев и приходилось полностью откатываться и все переписывать и там было такое состояние проекта, что и strictacode бы не помог уже, а были случаи когда все достаточно гладко шло, потому, что репозиторий небольшой, работает в нем полтора человека и в целом следят за тем, что там агент делает. Но меня сейчас больше занимает вопрос того, как стабилизировать качество и получить контроль за деградацией с учетом того, что в биг техах очень интенсивная разработка, разнородные команды, многим разработчкам очень сложно читать спеки и выхлоп от агента, когда они привыкли уже мыслить трассировкой и держать в голове графовидную структуру взаимодействий, а им тут спеки подсунули, люди ломаются и либо забивают на то, что агент пишет и просто соглашаются и либо идут опять руками писать, и хорошо если второе, а вот если первое, то тут уже метрики могут помочь.
У нас есть фронт на js который полностью навайбкожен и мы работам по алгоритму — сделали несколько фич, запускаем скилл strictacode и делаем план улучшений. И пока ребятам такой подход очень нравится, говорят, что он предлагает достаточно хорошие планы и результат нравится. Возможно вам тоже поможет, попробуйте, будет интересно получить обратную связь ;)
На 100% сказать сложно, но ИИ-ку обычно тянет RP перекос, большинство проектов которые мне доводилось видеть, которые написаны нейронкой, даже если используется какой-нибудь speckit или superpowers, то там обычно этот симптом вылезает. Попробуйте последить за этим показателем, возможно получится если не на 100% задетектить, но хотя бы заподозрить.
А если быть до конца честным, то в целом какая разница пишут нейронками или нет, если проект здоров =)
Если быть до конца честным, то я сам последний раз писал на java лет 15 назад и сейчас мы уже давно не используем его на проектах, kotlin встречается, а вот java нет. А добавлять язык для галочки, не понимая как это в реальной жизни работает просто нет ни времени, ни сил. Но если вы поможете проекту и добавите поддержку java, то мы не будем противиться pull request-у ;)