Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 15
Ну это не обзор получился, а скорее перечисление :) Попробовать бы с помощью каждого фреймворка (а) создать некий проект и (б) допилить фичу в существующий - и поделиться результатами, возникавшими непонятками в процессе и потраченным временем... Такое тоже находил, но по нескольким фреймворкам только.
В копилку добавлю:
А вот Tessl пока из этого списка, IMHO, можно бы исключить. Существующий продукт у них очень нишевый, закрывает одну задачу и не сильно понятно, зачем вообще нужен при живом Context7. Но они пилят (в приватной бете пока) какую-то вундервафлю, которая якобы перенесёт всё на совершенно новый уровень, где спецификация исчерпывающе описывает код... про это было вот в этой статье, после которой все их и начали в контексте SDD фреймворков упоминать, хотя пока, вроде, рановато.
А так тема безусловно интересная, ну и развивается буквально на глазах, любопытно, что в итоге выживет и во что превратится в процессе.
Ну я всё это проделал. А если описать в статье - получится не статья а учебник. Я вроде поделился результатми применимости того или иного фреймворка и косяками. Ну правда несколько из последних не трогал - там да, в конце перечисление. Tessl в том числе. Но показался интересным. Context7 закрывает только базовый контекст фрейвморков. В Tessl кейсов побольше насколько могу судить.
Я отбирал по популярности... Agent OS и GSD - по 3000 старов - моловато. Memory Bank просто под Cursor и используется всем окружением, поэтому попал.
Beads писали уже видел пробовал, результат у меня лично получился никакой, поэтому его не упоминал
Мне кажется, на этом этапе, когда всем инструментам ещё по несколько месяцев от роду, количество звёзд вообще не показатель. Весьма вероятно, что industry standard станет вообще не существующий пока что фреймворк, но вот основываться он будет на тех или иных концепциях, которые сейчас появляются, и не факт, что только в самых популярных продуктах.
Для себя пока что понял, что BMAD - оверкилл (но надо вернуться к этому вопросу после обещанной v6 с радикальными изменениями); из очень похожих Spec-Kit и OpenSpec для нового проекта выигрывает первый, для уже существующего - второй; Beads и частично GSD представляют собой концептуально интересную альтернативу, но при этом у автора Beads уже на этапе написания этого инструмента крышу изрядно снесло, а когда он переключился на Gas Town - то окончательно :), так что этим можно вдохновляться, но вряд ли использовать. Остальное надо ещё пробовать.
Мне тема интересна, т.к. я хороший аналитик, но посредственный программист :), для меня подготовка спек - понятное и интересное занятие. Тогда как многие программисты плюются на SDD именно потому, что, мол, зачем вычитывать/править кучу текста, если можно сразу к коду приступать.
По Tessl - они добавляют в контекст свои спецификации, как правильно использовать фреймворк/библиотеку. Но современные LLM достаточно умны, чтобы и сами разобраться в этом, если подсунуть им актуальную документацию (что и делает Context7). При этом спецификации от Tessl полной документации не заменяют, так что экономией токенов это тоже не объяснить. Ну и, в конце концов, если действительно так нужна роль "сделать выжимку из документации и запихнуть в контекст" - что мешает именно для этой роли запустить отдельного агента, не плодя фреймворки? Вряд ли Tessl свои спецификации вручную писали тоже.
Тогда как многие программисты плюются на SDD именно потому, что, мол, зачем вычитывать/править кучу текста
Тут есть определённая проблема с "кучей". "Кучу текста" трудно понять и гарантировать, что реализация соответствует этой самой куче.
LLM тут отчасти помогают - можно сделать review на соответствие - но на "куче" весьма высок процент ложно-положительных срабатываний.
PS. Сам постоянно пишу спеки, перечень проблем примерно такоей- сделать покороче, убрать дублирование и описание очевидных моментов, добиться согласованности.
промпт был "дай список из 10 SDD фреймворков и кратко распиши каждый из них"?
ИИ пишет код очень хорошо. Современные модели в алгоритмике уже почти всегда лучше разработчиков.
Сразу вспоминается вчерашняя простыня "лучшей в мире модели для кодинга" Опус 4.5, полностью состоящая из дублирования кода, с хардкодом значений вместо констант..
Два месяца активно на claude code с опусом, ни разу такого не попадалось.В правилах clean code и ddd. Может, поэтому?
ИИ пофиг на эти правила с mcp с ростом контекста. Ещё, как вероятность сработает. Но чего ожидать, их обучали на говнокоде, вот они и воспроизводят паттерны. Я уже привык ко всякой тупости и говнокоду от ИИ, уже знаю, что будет много итераций исправлений. Все равно в итоге в 3 раза быстрее.
В смысле "пофиг с ростом контекста"?
Типа у вас он не начинает предупреждать "контекст за полнен на 80%", а потом и восе принудительно compact запускать?
Да все там работает.. Это современный ии такой. Вот недавно пишет profile load user.profile что идиотизм полный. В профиль загружает юзера и в юзера профиль.. а потом этот идиотизм расплодил по фронту и логике на бэке. И вот такая тупость постоянно, В переменные сохраняет при этом зачем-то грузит отношения. Зачем все загружать если сохраняешь в переменные? Это противоречит элементарной минимальной логике. Ресурсы не создаёт вообще никогда хотя в правилах написано, что обязательно создавать для всех моделей. Опять же чтобы не дублировать данные. Дубликаты в простынях это на постоянной основе. Никогда с первого раза не выносит в компоненты и классы - все нужно потом рассказывать и обьяснять. Либо вынесет но каким-то кривым способом и все равно оставит связанность между классами. Что вообще лишает смысла такие разделения. Индусовский синтаксис в Ларавел - это вообще у всех моделей. Хотя дока подключена, но опять же в контекте все это киснет, веса говнокода доминируют над правилами. Видно что база для обучения одна и не лучшего качества.. Если все устраивает в ии поздравляю. В принципе да - можно не исправлять, все работает. Для меня качество кода важно, поэтому большая часть "вайбкодинга" уходит на исправления. Иногда по 5-10 часов на доработку..
Для меня качество кода важно. Еще важнее, чтобы он был понятен и мне через год, и другим. И сами описания были доступны человекам (почему я решил так, а не иначе). Сам я такое не сделаю на постоянной основе :)
Поэтому типичный подход:
Написать руками задание - небольшую задачу. Например, конкретный плагин, а не сразу все. Даже страничку frontend к нему - уже другая задача. Ее планирование начнется после полного завершение backend
Скормить в Gemini с просьбой найти неопределеннойсти, задать уточняющие вопросы и сформулировать как четкое задание.
Проанализировать, насколько Gemini правильно поняла мои хотелки.
(в точности как с подчиненными - их я тоже прошу вкратце описать шаги, как они собираются мое задание выполнять, какие видят подводные камни, в каких случаях придут ко мне за советом).Скормить в /openspec:proposal
Получить proposal.md, design.md, tasks.md, spec.md (тут уже видно, какие будут созданы классы)
Внимательно их прочитать и подумать. Решить, устраивает ли меня здесь dataclass или уже предпочту Pydantic model (хотя чаще это уже в задании указано)
При необходимости ответить на open questions и попросить что-то в спеке переделать (ибо забыл что-то изначально указать).
Только после этого запустить /openspec:apply
В случае написания нового кода - автоматический apply, при исправлениях - ручное подтвержение каждого изменения.
Анализ написанного, исправления комментариев (убрать очевидные, оставить, возможно уточнить описывающие, почему именно так...)
При этом в постоянный контекст загружены CONVENTIONS.md и прочие общие правила и шаблоны, во всем существующем коде type hints, комментарии. Описаны Quality Gate (ruff, mypy, eslint...)
Да, контекст сильно загружен. Чуть ли не 40K изначально отожрано. При 64К контексте такого не мог себе позволить, сейчас уже вполне. Особенно если попросить ее на подзадачи запускать конкретных агентов, которые в собственном контексте отрабатывают, а чужой не жрут.
Если я начну код согласовывать в тз, то это ничем не будет отличаться от исправления генераций. Какая разница где генерировать токены.. От настоящего ИИ я жду понимания, что он делает. Логики хотябы базовой. Пока это выглядит так, что как монетка ляжет так и сгенерирует (что в принципе характеристика технологии). Я сейчас вообще не даю ии большие модули создавать/рефакторить т.к. это геморой. Сам создаю классы/контроллеры/роуты с нужной структурой и юзаю чисто как генератор на рутине, там где не нужно уже проектирование + зная его слабые места, что он криво обучен для Ларавел. И разработка только по маленьким шажкам. Все равно тупости много, но хотябы руки не опускаются, когда видишь 15 сненерированных файлов под снос..
Вот прямо только что в обычном круд методы store update и их валидация - всё на дубликатах кода. В респонсах захардкодил ключи с несуществующими переводами, хотя не то что в правилах - в тз 300 раз было написано и про вынос в севрисы и про переводы..
Спасибо!
Очень схожие ощущения (BMAD слишком заумный для меня, SpecKit - для моих задач избыточен, OpenSpec - самое то).
И небольшая добавка - я часто сначала пишу будущий Proposal. Потом скармливаю Gemini 3, и она выдает нормальный текст для /openspec:proposal.
У меня Gem есть для преобразования. Начинается как
Act as a 'Senior Technical Product Manager and Prompt Architect'. Your specialty is translating high-level, sometimes vague human ideas into rigorous, machine-readable specifications. You are the bridge between a user's vision and an AI Agent's execution. Your tone is professional, analytical, and highly structured, but you use simple language to ensure clarity.
...
И он сначала задает несколько уточняющих вопросов по "моей" спеке, уточняет какие-то моменты, и формирует уже более четкий текст, по которому проще генерится proposal, с меньшим количеством уточнений и вольностей.
Разумеется, можно и другую модель использовать для подобной цели. Но предварительно из своего потока сознания получить нечто структурированное и без неоднозначностей, на основании чего уже реально с OpenSpec работать, существенно улучшает следующие этапы.
для экономии токенов и мемори банк использую допиленную под bsl serena. Очень полезный mcp, советую.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Совсем не вайбовый вайбкодинг. Обзор SDD+ фреймворков для разработки с ИИ