Комментарии 8
Кто-то влипил минус посчитав, что статья от нейросети. Согласен, что в эпоху, когда декларация о независимости считается ии сгенерированнной все выглядит, как генерация ии.
Статью писал сам, т.к. если попросить ИИ презентовать продукт, он не сможет выделить ключевые фичи и четко донести основные идеи (по крайней мере, таков мой опыт). На всякий случай прикладываю ссылку на промежуточный черновик, для сомневающихся 😂
https://drive.google.com/file/d/1fegs8S-JtFn-V1qEvFeH-oKwxbBKqq_W/view?usp=sharing
P.S. гифки отрисовывал клод (в Slightly Parallel под это специальный эндпоинт есть), чтобы делать объснения страниц, но я ему так же говорил что и куда снимать. Иногда покадрово.
Прикольно, но когда есть t3code, не уверен что нужно) Т.е. я понимаю зачем нужны фичи ваши, но по факту много из них решается просто вопросом агенту.
Спасибо за комментарий! К сожалению, T3 Code не пользовался, но посмотрел их GitHub и пару видео.
Мне кажется, у продуктов разные акценты: T3 Code, это интерфейс управления установленными кодинговыми агентами, с тредами и worktrees.
А Slightly Parallel больше ориентирован именно на управление задачами через канбан-доску (что достаточно удобно, особенно если использовать вид swimlanes, чтобы не терять задачи / идеи). Но я здесь исхожу из того, что система организована так, что там есть human in the loop.
Т.е. Slightly Parallel ориентирован именно на мультипроектную разработку.
Идеальный пример - это когда человек делает сразу несколько проектов, и каждый ветвится ещё внутри, т. е. нужно сделать сайт, доделать приложение, написать статью, проверить ASO и т. д. и т. п. При таком количестве задач, как мне кажется, достаточно легко потеряться, и Slightly Parallel должен помогать.
Из ярких отличий - в SP задача отделена от чата, т.е. её можно записать заранее (#task, доска, swimlanes), а чат и агент привяжутся к ней, когда работа начнётся. В Т3, как я понял нельзя положить задачи, которые ещё не начаты (идеи, бэклог, «потом»), т.к. треда без разговора нет.
+ судя по редми, эти два инструмента возможно использовать вместе, т.к. т3 требует установленного клод кода, значит хуки будут писать.
По мне, так очень крутая вещь получилась. Сам хотел что-то подобное разработать. Огромное спасибо за инструмент и статью! Сразу бросается, что была проделана колоссальная исследовательская работа, в т.ч. UI, UX. Не говоря уже о коде.
У меня вопросы к Вам.
Если я параллельно разведу агентов на разработку разных подзадач, чтобы они сделали материнскую задачу быстрее, система осилит эти задачи?
Есть ли синхронизация md файлов спецификации?
Почему именно Python? Вижу, инструмент был написан на нём.
Спасибо большое! Очень приятно :)
Если я параллельно разведу агентов на разработку разных подзадач, чтобы они сделали материнскую задачу быстрее, система осилит эти задачи?
Вот тут, наверное, зависит от сценария использования. Если можете, то опишите подробней.
Что сейчас умеет: если несколько агентов работают параллельно в одной папке, то для SP это не проблема, но если работа агентов конфликтует, то это может стать проблемой. Полноценной поддержки git worktrees пока нет, планирую добавить её в версии 1.1.
Если инструмент (например, Claude Code) сам запускает сабагентов, то, в целом, всё ок: (сейчас логика такая: мониторится время работы, файлы и т.д. сабагентов, которые были запущены основным агентом, но чаты с ними в историю не пишутся, т. к. человек общается с основным агентом).
Есть ли синхронизация md-файлов спецификации?
Распространение инструкций (вижена, правил и т. д.) в AGENTS.md и обновление установленных скиллов есть, но произвольный spec.md SP не синхронизирует. (если нужно, то можно подумать, как добавить)
Почему именно Python? Вижу, инструмент был написан на нём.
Там TypeScript для фронта и Python для бэка. Можно было бы целиком на TypeScript, но в этом случае вместо Python потребовался бы Node (для запуска / либо бинарники компилировать). Я предположил, что Python есть практически на любой машине, в то время как Node есть не у всех (и там прикол с виндой, вроде не очень приятно устанавливать). => т.к. прога для максимально широкого круга юзеров, то Python.
Классная штука ! а не думали в сторону подключения к web чатам ? ( я такую же себе сделал, но с гораздо меньшим функционалом ), но приляпал туда еще oauth claude/chatgpt, так что стало возможным в чате что-то обсужлать, а потом чат создает таску, которую уже видят агенты в терминале, или артифакты, неважно. советую добавить, если еще нет. ))
а..еще, - переменые окружения ( на менер gitlab ci Variables ) у вас есть ?
- а, и тулы для работы с gitlab/gitub ? удобно, когла агент сам мониторит pipeline-ы
(свой тут не буду рекламировать ))
Спасибо за коммент!) Добавил это в туду 😂
1) Про OAuth Claude/ChatGPT — не думал про это, т. к. вся серьёзная работа у меня обычно идёт через терминал (наверное, из-за привычки + потому что всё удобно сразу сохранять в репо, т. е. даже если я делаю какой-то предварительный ресерч по проекту и обсуждаю, то, скорее всего, буду делать это через терминал), но идея очень хорошая, постараюсь добавить в ближайшее время. (Сейчас план развития примерно такой (текущая версия v0.3): добраться до версии 1.0 (для этого планирую оттестить всё на живых машинах + внедрить ещё несколько фичей по существующему функционалу + разобрать отзывы / баги первых пользователей); если смогу, то добавлю коннектор в версии 1.0, если нет, то в 1.1.)
2) Переменные окружения (на манер GitLab CI Variables) у вас есть?
На текущий момент нет, но тоже добавил в планы.
3) Тулы для работы с GitLab/GitHub? Удобно, когда агент сам мониторит пайплайны.
Агенты уже умеют работать с существующими инструментами, и мне кажется, что здесь нет смысла пилить что-то своё, т. к. уже есть инструменты CLI: gh для GitHub (gh run watch, gh pr checks, gh run view --log-failed) и glab для GitLab. Claude Code и Codex могут ими пользоваться, если CLI установлены и авторизованы + есть MCP-серверы GitHub и GitLab. Так что, как я вижу, агенту уже есть чем мониторить пайплайны (собственно, при разработке Slightly Parallel они и мониторили :))
Единственное, может, стоит сделать встроенный скилл типа «после пуша дождись CI и разбери падение», но, опять же, мне он кажется избыточным.
Единственное, может, стоит сделать встроенный скилл типа «после пуша дождись CI и разбери падение», но, опять же, мне он кажется избыточным.
вооот ! у меня именно для этого, сам деплой то срабатывает по триггеру ессно, а вот потом агент уже начинает смотреть, чо там с джобой, и вытаскивает лог, если упало ))
Ну, по поводу OAuth, кстате, может Вам и не нужно, просто моя штука ( ладно, не штука, - "Marrow" назавается ) она в первую очередь расчитана на коллаборацию, ребята подрубаются каждый со своим аккаунтом, и фронтер могжет написать бэку "Исправь такую-то мутацию", создается таск с aseegnee для другого юзера, и он рад. а у Вас насколько я понял, акцент на много агентов, а не на много пользователей )
Кстате, еще из полезного, обьединяте таски в milestones ? тоже удобноею ( стрелочкой отметил )
а вообще смешно, у нас с Вами очень похожие почти интерфейсы ))) ну а что...вайбкодинг такой один вайб на всех )))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сделал open-source дашборд Slightly Parallel для мультипроектной разработки с агентами