Да, всё так. Каждая новая сессия запускается в новом контекстном окне и ничего не знает о предыдущих сессиях. Но есть механизмы наделения агента памятью, о них в статье написал (не обо всех), более широкую информацию можно посмотреть в документации claude code: https://code.claude.com/docs/en/memory.
Это моё личное недоверие к LLM и желание ограничить её влияние на инфраструктуру. Имею ввиду доступы на редактирование чего-либо дальше, чем файлы на моём компьютере (в том числе write операции в удаленную систему контроля версий).
Сложилось у меня такое отношение после ряда увиденных мной аварий, виновником которых были ошибки LLM :(
Расскажу небольшую историю про конкретно git. У нас в компании есть корпоративный GitLab. Одним прекрасным днём я вижу сообщение, что меня тегнули в каком-то PR’е и, зайдя в него, обнаруживаю, что тегнули в нем еще кучу других людей, не относящихся к изменениям (потом выяснилось, что так решил кодинговый агент). Ажиотаж в том PR’е образовался такой, что это повлекло проблемы с доступностью GitLab. Было смешно и страшно одновременно!
Возможно моя позиция - это паранойя.. Также не отрицаю, что когда-нибудь LLM вполне могут вернуть моё доверие!
Спасибо за комментарий! Хорошее замечание про цвет, зеленый действительно может в заблуждение вводить, учтём!
Про systematic-debugging: на первом этапе размышлений происходит исследование проблемы и поиск корневой причины (читаются stack trace’ы, проверяются последние изменения и т.д.). Следующий этап - это про поиск решения: анализ похожих (но работающих корректно) паттернов в проекте. Потом уже тестируем гипотезы «причина + решение» и реализуем. Согласен, что в статье очень куцо описал процесс и формулировка вызывает вопросы.
Спасибо за комментарий! Да! Именно такую идею и хотелось донести в статье: пока у нас не появился индустриальный стандарт, выбираем то, что удобно. И частенько нам удобен наш велик:)
А я хотел рассказал, как мой фреймворк хорошие идеи и принципы реализует. Возможно это поможет кому-то своё решение написать, адаптированное конкретно под его задачи.
Да, всё так, реализация функционала через TDD. Задача разбивается на кусочки, перед написанием каждого пишутся тесты на него, и только после - сама реализация.
Разведка действительно может быть полезна на какой-то не самой тривиальной задаче. Классная идея, подумаю над добавлением! Если научить агента на этом этапе еще по корпоративной системе контроля версий побегать - вообще пушка будет :)
Да, хук понадежнее будет, согласен. У меня на моделях Антропиков работает пока неплохо. Надо бы на чем-то послабее потестировать мне и доработать.
Согласен про линтер, но вот новый функционал например он не опишет. Так что тут, думаю, самое правильное - и линтер, и LLM, и делать это почаще!
В интернете сейчас каждый встречный поперечный форсит свой фреймворк для работы с агентскими системами. Зачастую они переусложнены.
Когда первый раз начал делать задачу с superpowers, я еще даже ничего не понял, а он там уже коммитить, пушить что-то пошел. Я подумал, ну всё, следующим шагом видимо в прод сам покатит, "классная" штука.
Разобравшись, понимаешь что все эти gtd, specчетотам строятся на нескольких скиллах, а остальное часто специфичная обвязка. Так что жирно плюсую автору, как всегда учим базу, а потом уже фреймворки!
Спасибо за статью! А чем на ваш взгляд лучше MCP для таких интеграций, чем написать skill, в который зашить работу с api того же Финам?
Да, всё так. Каждая новая сессия запускается в новом контекстном окне и ничего не знает о предыдущих сессиях. Но есть механизмы наделения агента памятью, о них в статье написал (не обо всех), более широкую информацию можно посмотреть в документации claude code: https://code.claude.com/docs/en/memory.
Это моё личное недоверие к LLM и желание ограничить её влияние на инфраструктуру. Имею ввиду доступы на редактирование чего-либо дальше, чем файлы на моём компьютере (в том числе write операции в удаленную систему контроля версий).
Сложилось у меня такое отношение после ряда увиденных мной аварий, виновником которых были ошибки LLM :(
Расскажу небольшую историю про конкретно git. У нас в компании есть корпоративный GitLab. Одним прекрасным днём я вижу сообщение, что меня тегнули в каком-то PR’е и, зайдя в него, обнаруживаю, что тегнули в нем еще кучу других людей, не относящихся к изменениям (потом выяснилось, что так решил кодинговый агент). Ажиотаж в том PR’е образовался такой, что это повлекло проблемы с доступностью GitLab. Было смешно и страшно одновременно!
Возможно моя позиция - это паранойя.. Также не отрицаю, что когда-нибудь LLM вполне могут вернуть моё доверие!
Спасибо за комментарий! Хорошее замечание про цвет, зеленый действительно может в заблуждение вводить, учтём!
Про systematic-debugging: на первом этапе размышлений происходит исследование проблемы и поиск корневой причины (читаются stack trace’ы, проверяются последние изменения и т.д.). Следующий этап - это про поиск решения: анализ похожих (но работающих корректно) паттернов в проекте. Потом уже тестируем гипотезы «причина + решение» и реализуем. Согласен, что в статье очень куцо описал процесс и формулировка вызывает вопросы.
Спасибо за комментарий! Про субагентов согласен, в версии фреймворка, которую использую я, они напилены на тесты, ревью и т.д.
В vibe-skills репозиторий намеренно не стал добавлять, чтобы сохранить его максимально простым в изучении. Этот поинт в статье подсветил.
Спасибо за комментарий! Да! Именно такую идею и хотелось донести в статье: пока у нас не появился индустриальный стандарт, выбираем то, что удобно. И частенько нам удобен наш велик:)
А я хотел рассказал, как мой фреймворк хорошие идеи и принципы реализует. Возможно это поможет кому-то своё решение написать, адаптированное конкретно под его задачи.
Да, всё так, реализация функционала через TDD. Задача разбивается на кусочки, перед написанием каждого пишутся тесты на него, и только после - сама реализация.
Спасибо большое за комментарий!
Разведка действительно может быть полезна на какой-то не самой тривиальной задаче. Классная идея, подумаю над добавлением! Если научить агента на этом этапе еще по корпоративной системе контроля версий побегать - вообще пушка будет :)
Да, хук понадежнее будет, согласен. У меня на моделях Антропиков работает пока неплохо. Надо бы на чем-то послабее потестировать мне и доработать.
Согласен про линтер, но вот новый функционал например он не опишет. Так что тут, думаю, самое правильное - и линтер, и LLM, и делать это почаще!
Когда первый раз начал делать задачу с superpowers, я еще даже ничего не понял, а он там уже коммитить, пушить что-то пошел. Я подумал, ну всё, следующим шагом видимо в прод сам покатит, "классная" штука.
Разобравшись, понимаешь что все эти gtd, specчетотам строятся на нескольких скиллах, а остальное часто специфичная обвязка. Так что жирно плюсую автору, как всегда учим базу, а потом уже фреймворки!