Данные должны быть нормализованы т.е. не должны дублироваться. Если у вас уже все это есть в требованиях, тасках и комментах, и вы параллельно ведете требования для агентов - это плохая затея, т.к. они очень быстро разойдутся, у вас будет два варианта требований и какой правильный уже никто никогда не узнает. Возможно ваша идея - это сделать агента, который после каждого коммита пересобирает "витрину данных знаний о проекте для разработчика". Тем самым ускоряет работу агентов не заставляя их каждый раз залезать в десять мест. Например это может быть md файл или несоклько, куда агент собирает изо всех перечисленных источников (ТЗ, таски, коммиты, комменты и т.д.) данные и мэпит их на код скажем с точностью до метода. Фантазирую, но как вариант: в md файле вы храните списокм название файа с исходниками, название класса, метода - под ним собранная информация. Если мы планируем что с кодом будет работать агент, его не будут раздражать полотна комментов, можно наверное и просто в комменты это все запихнуть.
Я думаю ваш когнишн лээр оф лонг терм проджект мемори если его немного потереть, оказывается старыми добрыми хорошими практиками кодирования и спеками. Есть какой-нибудь https://google.github.io/styleguide/ . В подобных местах написано, что надо комментировать, а что не надо. Например хитрая логика, неочевидные решения и т.д. должна быть описана в коментах. Скорее всего ваш агент и так их пишет (у вас же не дурно воспитанный агент?). Баги и новые фичи обычно на больших проектах описаны в тасках, хорошая практика ссылаться на них при коммите, если у вас нет тасков - в указать полностью в комменте к коммиту. Общие знания проекта живут в требованиях, описании архитектуры (кстати никаких проблем их хранить в гите). Т.е. на вид вы изобретаете хороший такой пяти колёсный велосипед. Хотя концепция, что все это видно сразу одновременно в виде такого готового микроконтекста для агента прямо из куска кода мне нравится.
Вы не могли бы раскрыть вашу мысль чуть глубже? Пока напоминает подход пацанов с района, которые мне по пути в школу в начале девяностых объясняли почему мне будет полезно подстричься. Но я не подстригся.
Уважаемая публика, внимание! Только сегодня, удивительный аттракцион: на ваших глазах зумеры изобретают проектную документацию! Простите, если что. На самом деле мысль мне кажется полезная, но почему бы просто не хранить и не обновлять требования в каком-то плюс-минус классическом виде?
Скорее все, что как агент работает ест токены, клод код тоже их ест вполне активно. Наши разработчики вроде не жаловались, что Spec Kit как-то принципиально прожорливее
Пока нет, в текущей версии все живет в одном документе. То что вы описываете - разумный шаг в сторону систем управления требованиями, даже необходимый для больших систем. Тут возможна и интеграция с какими-то внешними системами и вариант собственной разработки. В идеальной картине будущего поддержка изменений с обратной связью: т.е. вы начали работать с таском, нашли проблему, поменяли что-то в юзер-сориз у вас автоматом пересобрались все верхнеуровневые требования, проверерились на согласованность и переопубликовались. Туда идем, но пока мы полностью закрываем задачи связанные с документами на ранних стадиях - собрать требования, помочь владельцам продукта понять чего они собственно хотят и как это может выглядеть, собрать прототип, помочь оценить трудозатраты. Приложение на 30 - 50 экранов для стартапа или идея новой фичи в большом энтерпрайзе - наш текущий идеальный клиент, тут будет наибольший эффект.
Да, с шаблонами работаем, мы сейчас в основном используем свои шаблоны Vision & Scope – на основе PMBoK и нашего проектного опыта. Но это можно кастомизировать, недавно меняли шаблон под запрос заказчика, добавляли секцию с CJM. ГОСТы и т.д. – вполне можно. В планах вообще любые кастомные шаблоны документов.
Структура документа - тут как будто бы все уже изложено в методологиях, PMBoK, BABok, ISO, ГОСТы, - это скорее туда, конкретно наш документ, если он интересен можем показать на демо.
С декомпозицией система справляется вполне неплохо, в этом ее смысл и заключается) Каждый раздел в несколько проходов заполняется промптами на основе расшифровки интервью клиента, документов, знаний самой модели. При необходимости дополняется и финально аппрувится живым аналитиком.
Трассировка, нумерация требований частично автоматизирована, т.е. некоторые требования мы умеем разбивать на атомарные, нумеровать и автоматически проставлять связи, но пока полностью все документы насквозь это не покрывает. Совсем строго, как это делается в авиационных или медицинских стандартах с матрицей трассировки – пока только вручную, но все равно это быстрее чем вообще все делать руками. Это, кстати, очень перспективный (на мой взгляд) вопрос, в плане автоматической поддержки изменений в требованиях.
Разбивка на фичи и задачи, приоритезация – это пока все за человеком. Но в целом в эту сторону тоже уже смотрим.
Если интересно – можем вам провести демо, или даже пилот обсудить, это хороший способ увидеть скорость и качество.
В Калифорнии есть закон запрещающий соглашения о неконкуренции, то есть работодатели не могут препятствовать сотрудникам переходить в компании-конкуренты. Иногда работодателям это нравится, иногда нет)
https://news.ycombinator.com/item?id=44573195 вот, кстати, еще ветка в форуме где в хвост и в гриву комментируют данную статью - объективность, ругают OpenAI за низкое внимание к безопасности, отсутствие тех писателей, культуру снизу вверх = отсутствие нормального управления и т.д. Это уже для тех кому надо совсем глубоко копать)
Про "цикл отладки" - я думаю тут речь о том, что Devinу в теории можно просто отдать багу из таск трекера, а все остальное он сделает сам (ну в идеале, пока совсем не всегда делает, конечно). Может быть можно в .cursorrules прописать подход как вы написали "статический анализ и автотесты" и оно заработает. Единственное что, думаю чтобы нормально заработало нужна будет рассуждающияя модель на шаге продумывания архитектуры решения и тестов. Т.е. :
Прочитал задачку, отдал ее подумать в o1/o3/R1
Получил план решения и что проверяют тесты - преедал его в Claude
Claude Написал код, проганл тесты, вернул в o1 на проверку
Не исключено, что уже довольно скоро сможет. Попытки таких агентов сделать уже есть (Devin, SWE Agent, Amazon Q и т.д.), пока еще не очень работает, но кажется что уже вот-вот может поменяться
https://github.com/orneryd/Mimir
M.I.M.I.R - Multi-agent Intelligent Memory & Insight Repository
AI-Powered Memory Bank + Task Management Orchestration with Knowledge Graphs
Данные должны быть нормализованы т.е. не должны дублироваться. Если у вас уже все это есть в требованиях, тасках и комментах, и вы параллельно ведете требования для агентов - это плохая затея, т.к. они очень быстро разойдутся, у вас будет два варианта требований и какой правильный уже никто никогда не узнает. Возможно ваша идея - это сделать агента, который после каждого коммита пересобирает "витрину данных знаний о проекте для разработчика". Тем самым ускоряет работу агентов не заставляя их каждый раз залезать в десять мест. Например это может быть md файл или несоклько, куда агент собирает изо всех перечисленных источников (ТЗ, таски, коммиты, комменты и т.д.) данные и мэпит их на код скажем с точностью до метода. Фантазирую, но как вариант: в md файле вы храните списокм название файа с исходниками, название класса, метода - под ним собранная информация. Если мы планируем что с кодом будет работать агент, его не будут раздражать полотна комментов, можно наверное и просто в комменты это все запихнуть.
Очень интересно, а вы какие требования пишите? Спеки - это уже системный анализ? План и таски - это для разработчиков план и таски?
Я думаю ваш когнишн лээр оф лонг терм проджект мемори если его немного потереть, оказывается старыми добрыми хорошими практиками кодирования и спеками. Есть какой-нибудь https://google.github.io/styleguide/ . В подобных местах написано, что надо комментировать, а что не надо. Например хитрая логика, неочевидные решения и т.д. должна быть описана в коментах. Скорее всего ваш агент и так их пишет (у вас же не дурно воспитанный агент?). Баги и новые фичи обычно на больших проектах описаны в тасках, хорошая практика ссылаться на них при коммите, если у вас нет тасков - в указать полностью в комменте к коммиту. Общие знания проекта живут в требованиях, описании архитектуры (кстати никаких проблем их хранить в гите). Т.е. на вид вы изобретаете хороший такой пяти колёсный велосипед. Хотя концепция, что все это видно сразу одновременно в виде такого готового микроконтекста для агента прямо из куска кода мне нравится.
Спасибо, я полностью согласен с этой мыслью. Я вроде бы ровно это же и написал)
Вы не могли бы раскрыть вашу мысль чуть глубже? Пока напоминает подход пацанов с района, которые мне по пути в школу в начале девяностых объясняли почему мне будет полезно подстричься. Но я не подстригся.
Уважаемая публика, внимание! Только сегодня, удивительный аттракцион: на ваших глазах зумеры изобретают проектную документацию! Простите, если что. На самом деле мысль мне кажется полезная, но почему бы просто не хранить и не обновлять требования в каком-то плюс-минус классическом виде?
Скорее все, что как агент работает ест токены, клод код тоже их ест вполне активно. Наши разработчики вроде не жаловались, что Spec Kit как-то принципиально прожорливее
Этот проект тоже форк чего-то, что уже было, в AgentSessions не вижу как минимум версии под Windows и поддержки Cursor, фичи попозже посмотрим
Пока нет, в текущей версии все живет в одном документе. То что вы описываете - разумный шаг в сторону систем управления требованиями, даже необходимый для больших систем. Тут возможна и интеграция с какими-то внешними системами и вариант собственной разработки. В идеальной картине будущего поддержка изменений с обратной связью: т.е. вы начали работать с таском, нашли проблему, поменяли что-то в юзер-сориз у вас автоматом пересобрались все верхнеуровневые требования, проверерились на согласованность и переопубликовались. Туда идем, но пока мы полностью закрываем задачи связанные с документами на ранних стадиях - собрать требования, помочь владельцам продукта понять чего они собственно хотят и как это может выглядеть, собрать прототип, помочь оценить трудозатраты. Приложение на 30 - 50 экранов для стартапа или идея новой фичи в большом энтерпрайзе - наш текущий идеальный клиент, тут будет наибольший эффект.
Спасибо, хорошие вопросы! Отвечу по порядку.
Да, с шаблонами работаем, мы сейчас в основном используем свои шаблоны Vision & Scope – на основе PMBoK и нашего проектного опыта. Но это можно кастомизировать, недавно меняли шаблон под запрос заказчика, добавляли секцию с CJM. ГОСТы и т.д. – вполне можно. В планах вообще любые кастомные шаблоны документов.
Структура документа - тут как будто бы все уже изложено в методологиях, PMBoK, BABok, ISO, ГОСТы, - это скорее туда, конкретно наш документ, если он интересен можем показать на демо.
С декомпозицией система справляется вполне неплохо, в этом ее смысл и заключается) Каждый раздел в несколько проходов заполняется промптами на основе расшифровки интервью клиента, документов, знаний самой модели. При необходимости дополняется и финально аппрувится живым аналитиком.
Трассировка, нумерация требований частично автоматизирована, т.е. некоторые требования мы умеем разбивать на атомарные, нумеровать и автоматически проставлять связи, но пока полностью все документы насквозь это не покрывает. Совсем строго, как это делается в авиационных или медицинских стандартах с матрицей трассировки – пока только вручную, но все равно это быстрее чем вообще все делать руками. Это, кстати, очень перспективный (на мой взгляд) вопрос, в плане автоматической поддержки изменений в требованиях.
Разбивка на фичи и задачи, приоритезация – это пока все за человеком. Но в целом в эту сторону тоже уже смотрим.
Если интересно – можем вам провести демо, или даже пилот обсудить, это хороший способ увидеть скорость и качество.
А почему вы считаете, что статья булшит? В ней не хватает какой-то информации?
В Калифорнии есть закон запрещающий соглашения о неконкуренции, то есть работодатели не могут препятствовать сотрудникам переходить в компании-конкуренты. Иногда работодателям это нравится, иногда нет)
https://news.ycombinator.com/item?id=44573195 вот, кстати, еще ветка в форуме где в хвост и в гриву комментируют данную статью - объективность, ругают OpenAI за низкое внимание к безопасности, отсутствие тех писателей, культуру снизу вверх = отсутствие нормального управления и т.д. Это уже для тех кому надо совсем глубоко копать)
Про "цикл отладки" - я думаю тут речь о том, что Devinу в теории можно просто отдать багу из таск трекера, а все остальное он сделает сам (ну в идеале, пока совсем не всегда делает, конечно). Может быть можно в .cursorrules прописать подход как вы написали "статический анализ и автотесты" и оно заработает. Единственное что, думаю чтобы нормально заработало нужна будет рассуждающияя модель на шаге продумывания архитектуры решения и тестов. Т.е. :
Прочитал задачку, отдал ее подумать в o1/o3/R1
Получил план решения и что проверяют тесты - преедал его в Claude
Claude Написал код, проганл тесты, вернул в o1 на проверку
и так по кругу, пока проблема не решена.
Получается в подписку Cursor за $20 как бы входит подписка на Claude $18
Спасибо, с примерами с YOLO супер!
Автор собственно пишет, что т.к. windsurf и cursor в основе своей vs code, то плагины к ним тоже подходят, и cline на них прекрасно работает тоже
Не исключено, что уже довольно скоро сможет. Попытки таких агентов сделать уже есть (Devin, SWE Agent, Amazon Q и т.д.), пока еще не очень работает, но кажется что уже вот-вот может поменяться
sudo -u Владимир Владимирович Post_на_Habr
Все верно подмечено, Владимир Владимирович не заводил себе аккаунт на Хабре, запостили от его имени