Ключевые идеи
🔧 Скилы - это SOP для агентов, и они работают надёжнее любых правил
Правила в agents.md агент воспринимает как рекомендации - и периодически их забывает. Скилы зашиты глубже: они подгружаются автоматически, когда агент сталкивается с подходящим контекстом. По сути, это стандартные операционные процедуры (SOP, как в Amazon) для AI - “вот так тут принято делать миграции в базу”, “вот так делаем коммиты”, “вот так анализируем дубликаты”. Разница в качестве выхлопа - радикальная.
🗂️ Модель данных - главный рычаг качества генерации
Без чёткой модели данных агент начинает фантазировать, спеки расходятся, код дрифтит. Когда модель данных определена заранее, агент строит всё вокруг неё - и качество кода вырастает на порядок. Пять минут на описание структуры экономят часы на переделках.
🗺️ Спеки - это карта, а не зеркало кода
OpenSpec разделяет changes (единицы работы, которые архивируются) и capabilities (живые спеки, описывающие, что система умеет). Спеки не обязаны идеально соответствовать коду в каждый момент - eventual consistency между ними нормальна. Главная функция спек - навигация: чтобы в следующий раз, когда агент планирует новую функцию, он нашёл нужный контекст быстрее и точнее.
Ключевые выводы
🎯 Фокус побеждает свободу. One-shotting работает, но жжёт токены и даёт худшее качество. Сфокусированные спеки с ясными целями - consistently outperform.
🚀 Первые 100 метров решают всё. Как при запуске ракеты: если агент побежал не туда в начале, весь прогон бесполезен. Смотри в начале - потом отпускай.
📋 Агенты обожают дубликаты. Нашли 8 почти одинаковых блоков кода в проекте - теперь еженедельный анализ дубликатов обязателен.
📐 “Тут так принято” сильнее правил. В большом проекте существующие паттерны кода влияют на генерацию сильнее, чем любые rules-файлы. Чистый код сейчас предотвращает плохую генерацию потом.
🗑️ Выкинь первый прототип. Переписать проект с нуля, когда уже есть фидбэк от клиентов и понимание архитектуры - одно из лучших решений.
⚡ Дофаминовая петля реальна. 4-5 часов интенсивной работы с параллельными агентами - дневной максимум. Активный отдых (лыжи, без ноутбука) критически важен.
Ресурсы
OpenSpec - начало работы - github.com/Fission-AI/OpenSpec - Документация по OpenSpec: от инициализации проекта до полного lifecycle с proposals, design, specs и tasks.
SDX Project Setup Skill - tessl.io/registry/…/sdx-project - Скилл для автоматического создания проекта из концепта: генерирует все спеки, roadmap и разбивает на параллельные фазы.
SDX Spec Driven Commit Skill - tessl.io/registry/…/sdx-commit - Скилл коммита, который проверяет тесты и валидирует изменения перед фиксацией.
UI/UX Pro Max Skill - ui-ux-pro-max-skill.nextlevelbuilder.io - Скилл для генерации дизайн-систем. Установка: npm install -g uipro-cli, затем uipro init --ai claude.
Стартовые документы для проекта - concept.md, architecture.md, datamodel.md - Примеры документов, с которых начинается проект: концепт, архитектура и модель данных.
Тема DOOM 95 - preview.html - Дизайн-система в стиле DOOM 95, которую сгенерировал агент во время лайв-демо.
Основные моменты
[0:00] 🎯 Как NVIDIA подтвердила наш подход
Перед началом сессии обсудили вчерашний кинот NVIDIA GTC. Главный инсайт: Хуанг показал паттерн “структурная основа + GenAI сверху” - детерминистический фреймворк внизу, генеративный AI наверху. «Это ровно то, что мы делаем с агентами: есть чёткая, детерминистическая вещь, и есть LLM, который поверх неё блуждает». Сам удивился, когда дошёл до того, что агент генерирует Python-скрипты, складывает их и запускает - родилась “фаза компиляции” английского текста в код.
[0:10] 🚀 От 0 до 400K строк: история стартапа на спеках
Finsi - AI движок агентов для маркетинга - в декабре приняли решение переписать весь стартап с нуля. «Смотрим на текущую кодовую базу - она разошлась. Либо причёсывать, либо заново. А давайте заново». За три месяца: 76 спек в 15 категориях, ~400K строк кода. Ключевой момент: Claude 4.5 Opus в ноябре радикально увеличил качество генерации. Фичи, которые раньше были экономически нецелесообразны, стали реальными за пару часов.
[0:18] 💡 Три фактора качественного выхлопа
Цели, фокус, модель данных - и всё. Цели: описывай зачем, а не как. Агент подстраивается, чтобы «сделать тебе хорошо». Фокус: без него ты платишь переделкой. А модель данных - «когда у тебя есть структура данных, качество на порядок выше. Я развлекался - брал спеки из существующего проекта и пересоздавал. Работает фантастически».
[0:25] 🔧 Скилы вместо промтов
«Все любят system prompts - ты такой QA Architect, делай вот это. Мне эстетически не нравится». Скилы - это упакованные промты с workflow внутри. Примеры: схема БД (как делать миграции и запросы), коммит-скилл (проверки перед коммитом), анализ дубликатов. Ключевой инсайт: хорошо написанный скилл подгружается автоматически - не нужно каждый раз объяснять агенту, что делать. «Это SOP из Amazon - standard operating procedure. Тут так принято».
[0:35] 🎮 Дизайн-система в стиле DOOM 95
Зрители в чате выбрали стиль для UI: DOOM 95. Агент создал цветовую палитку - gunmetal, doom-red, doom-blood - и полную дизайн-систему с компонентами. Antigravity сама запустила браузер, проскролила результат и провалидировала UI. «Вот это мне больше всего нравится - Antigravity сама может провалидировать. Раньше это делал ручками, а теперь просто смотришь, как она кликает».
[0:42] ⚡ OpenSpec: как работает lifecycle
Proposal → Design → Specs → Tasks → Apply. Proposal - самое важное: «потраченное время на why экономит очень много потом». Design - трейдоффы. Specs (capabilities) - живые документы, описывающие что система умеет. Tasks - конкретные задачи. Если получилось >50 тасок - вернись и раздроби proposal. Change архивируется, capabilities обновляются. «Как бы, сейчас я не знаю, зачем мы это сделали? Идёшь в архив. За три месяца залезали раза два».
[0:50] 🏗️ Проект Derik: инфра за 11 дней
Один из клиентов присылает 500K имейлов в день - data pipeline сломался. «5-10 ГБ в день, не то чтобы много, но open source тулы сломались». Derik - Rust backend, JS frontend, single binary - за 11 дней, 25K строк кода, 70 API endpoints. «Раньше это было экономически нецелесообразно - я не могу посадить человека на три месяца ради пары маленьких проблем. Сейчас - а почему нет?». И мобильное приложение к нему - за 30 минут через one-shot.
[0:58] 🔀 Параллельные агенты в деле
Живая демонстрация: два агента одновременно - один реализует foundation specs, другой строит data model. Пока оба крутятся, подготовка спек для следующей фазы. «Четыре параллельных агента - мой ментальный предел. После четвёртого мозг закипает». Workflow: запускаешь apply → готовишь следующий батч → повторяешь. За 20% дневного лимита токенов - больше, чем один one-shot за весь лимит.
[1:05] 🔍 Философия code review
«Код перестали активно смотреть давно». Не каждую строку - а только когда грабли вылезают или для предотвращения паттернов. Потому что в большом проекте “тут так принято” работает сильнее любых правил: если агент видит плохой паттерн в существующем коде, он его повторит. Еженедельно: анализ сложности, поиск дубликатов, проверка дрифта. «Нашли 8 мест с почти одинаковым кодом. Вишенка на торте. Теперь анализ дубликатов - каждую неделю».
[1:12] 🧹 Eventual consistency для спек
«Не нужно поддерживать идеальный порядок - позволь лёгкому беспорядку быть, потом упорядочь». Есть скилл проверки дрифта: сравнивает код со спеками, находит расхождения. Раз в неделю - уборка. Иногда что-то делается без спек - ок, задокументируй постфактум. Анекдот: отладочный экран, который Миша сделал для себя, агент нашёл и добавил туда новый функционал Андрея. «Я такой - а я вообще не знал, что этот экран существует. Агент нашёл, улучшил, клиенты пользуются».
[1:20] 🎰 Дофамин и выгорание
«Дофаминовая петля - очень большая боль. Через какое-то время привыкаешь, но отмена после эйфории - фантастически плоха». Совет бывшего босса из Нью-Йорка: «Тут работают активно, поэтому тебе нужно отдыхать активно. Если не будешь - сгоришь за пару месяцев». На выходных - лыжи, ноутбук остаётся дома. Рецепт: 4-5 часов интенсива с агентами, потом переключение на клиентов, налоги, что угодно.
[1:30] 🏁 Итоги и что дальше
Спек workflow можно переопределять - и нужно, под свой контекст. Скилы пишутся за десять минут, с тестами. «Делаете openspec init - он дальше расскажет, что делать. Либо возьмите мой скилл - он вам проект зафигашет». Подписки - ключевой ментальный сдвиг: вместо “надо экономить токены” переходишь в режим «давай попробую, что получится». Мобильное приложение за полчаса? Почему нет. Пока подписки сильно субсидированы - это время нарабатывать скиллы и понимать границы. В следующий раз - brownfield SDD, кооперативная многозадачность и параллельные спеки на одном репо. «Всё, до связи всем. Было очень клёво».
Q&A: Вопросы и ответы
🧭 Стратегические вопросы 🔗
Spec-driven - это универсальный ответ? Есть ли альтернативы?
Скорее, spec-driven - это не универсальный ответ на все вопросы, а способ структурировать разработку и сфокусировать её именно для LLM на разных элементах: целях, архитектуре, модели данных, контрактах.
Подходит ли для legacy?
Для legacy подходит абсолютно так же, как и для новых проектов. OpenSpec себя хорошо показывает и на том, и на другом. Можно наш текущий проект считать legacy - ему уже три месяца 😄
Для legacy я бы не пытался покрыть спеками весь проект сразу. Начинать лучше по небольшим кускам - берёшь тот участок, где сейчас идёт работа, покрываешь его постепенно, оборачиваешь в полноценную спеку. И так по кусочкам - с одним разобрались, пошли дальше.
Есть несколько инструментов для обратного направления - из кода в спеки. spec-gen умеет reverse-engineer’ить спеки из существующего кода. Я также пробовал просто использовать Claude/Opus, чтобы переписать определённый код назад в спек и вытащить ключевые элементы. Работает, как всегда, на 80% нормально.
Есть ли рецепты, как выбрать между SDD / без SDD?
Зависит от размерности задачи. Небольшие фиксы - можно и без спек. Большие или сложные вещи, где явно нужно планирование и дизайн - там спеки начинают приносить ценность.
Для меня ключевая точка - там, где нужно выбрать дизайн и проверить его. Я не хочу, чтобы код сгенерировался автоматически без того, чтобы я посмотрел, как это запланировано. Вот там спеки несут самую большую ценность.
Второй случай - большое изменение по кодовой базе, даже если оно несложное. В спеке записаны все кусочки, и LLM проще по ней навигироваться, чем пытаться сделать всё в one-shot.
Простые изменения можно пропускать без спек. Но мы периодически реверсим спеки после того, как сделали пару изменений и поняли, что “маленький багфикс” оказался не таким маленьким. Просишь агента обновить спеки из кода - и всё снова актуально.
Как выбрать правильный SDD фреймворк?
Выбор фреймворка: я бы выбирал исходя из того, что не мешает вам работать. Когда мы выбирали между SpecKit и OpenSpec, SpecKit выдавал большое количество текста, который не очень хотелось читать - непонятно, как со всем этим жить. OpenSpec был легковесным, простым и понятным. Мы выбрали понятность, может быть, где-то в минус дотошности SpecKit.
У всех spec-фреймворков есть шаблоны и промты. Что мне нравится в OpenSpec - все их можно переопределить и добавить свои. Хочу вместо стандартных четырёх шагов шесть - с архитектурными трейдоффами, с дизайном базы данных, продуманными перед тем, как код будет написан, и с маркетингом релиза для этой фичи - чтобы каждый попал в свой артефакт. Пожалуйста, я получаю это сейчас в OpenSpec.
Фреймворки, которые заставляют проходить по жёсткому workflow, я скорее не возьму - хочется гибкости. Но кому-то, наоборот, будет нравиться, что фреймворк протаскивает по определённым шагам, и это проще, чем граф зависимостей в OpenSpec. Тут кому что.
Есть ли значимые преимущества OpenSpec перед самописным фреймворком? Какая-то промптовая магия?
Промптовой магии нет. Я сейчас считаю, что промптовая магия вообще переоценена.
Важна структура. Важен шаблон, как он разложен. Например, мотивация (why) в спеке - я показывал это на слайдах - помогает агенту итерироваться в сторону того результата, который ты хочешь получить. Без неё всегда заметно хуже.
Важен workflow, важна последовательность элементов. Из proposal генерируется design, из design - спеки. На каждом шаге важно, какой объём информации переходит из одного артефакта в другой, какие элементы получаются из каких. LLM на каждом шаге добавляет контекст сама и пытается додумать на непредоставленных данных. Вся суть в том, чтобы эти моменты расширения не были огромными - чтобы на каждом шажочке она добавляла разумный элемент знаний или assumptions, а не фантазировала на пустом месте.
Для чего нужна мотивация (в proposal)? Что будет, если упустить?
Мотивация отвечает на “ЗАЧЕМ”. Без неё агент не понимает цель и оптимизирует не то, дизайн-решения принимаются без бизнес-контекста, спеки получаются generic. С мотивацией агент знает, что значит “хорошо”, и дизайн-трейдоффы решаются в контексте цели.
Пример: ❌ “Создать dashboard с графиками” → какой то график. С неплохой вероятностью LLM угадает что было нужно (ну или вы и сами не знали и такой ответ подойдёт).
✅ “Пользователю нужно видеть дневную метрику email performance по каждому типу клиентов, чтобы принять решение о следующей рассылке” → конкретный, полезный dashboard.
Мотивация задаёт вектор, куда всё движется. Если этот вектор задан расплывчато или не туда - получите не тот результат. Поэтому я всегда проверяю, в том ли направлении мы собираемся двигаться.
📦 Жизненный цикл спек 🔗
Что делать со спеками, когда фича закончена? В каком виде и как хранить?
В OpenSpec есть чёткое деление: changes (изменения) и specs (сapabilities) (основное описание поведения системы).
Фича закончена, и спека завершена, когда все изменения/таски по ней сделаны. То есть, вот эта единица работы, единица изменения всей системы, может считаться завершенной.
Когда фича готова: выполняем openspec archive --change "feature-x". Change перемещается в openspec/changes/archive/, а delta-спеки мерджатся в основные specs/.
Архив хранит историю для ответа на вопрос “зачем мы это сделали?”. Из боевого опыта: за три месяца работы с 76 спеками залезали в архив ровно два раза. Архив ценен, но не критичен.
Какие есть подходы, чтобы спеки оставались актуальными и не устаревали?
Мы используем подход eventual consistency - спеки не обязаны идеально соответствовать коду в каждый момент. Периодически спеки обновляются и приводятся в соответствие с кодом, чтобы LLM не так сильно путалось.
Пока явной разницы в создании новых спек, когда старые не обновлены, мы не заметили.
Так ли важно архивировать спеки? Если уже есть процесс обновления ТЗ, можно просто считывать дифф?
Архивация полезна, но не критична. Уменьшает потребление контекста - видно в вызове агента, что он не читает заархивированные файлы, а читает только те, которые ещё в работе. Скилы OpenSpec помогают ему это делать.
🏗️ Архитектура и организация спек 🔗
Как выстраивать архитектуру спек в проекте? Нужна ли корневая спека на весь проект?
Корневая спека не нужна, но в разных spec-фреймворках есть понятие конституции или общей концепции проекта - зачем он вообще существует. Она задаёт направление, такое же как мотивация задаёт направление для конкретного изменения. В нашем случае лежит файл concept.md, на который ссылаются корневые правила в agents.md или в конфиге OpenSpec. Просто добавляет деталей, чтобы не повторяться в каждом изменении.
Отдельно есть спека на технический обвяз проекта - создаётся одной из первых, чтобы LLM знала, что вот эти вещи идут сюда, а вот эти - туда. Вместо того чтобы прописывать это в правилах, оно попадает в спеку и становится гайденсом для агента. Видно, когда он создаёт новые вещи - он подсматривает в эту спеку и раскладывает файлы по нужным каталогам.
С какими проблемами сталкивались при росте количества спек?
Проблем именно со спеками при росте их количества явно не было. У нас сейчас уже 80 спек в 15 категориях, и пока даже не понадобилось что-то, что бы разделяло их по категориям - лежат в плоской структуре, влазят в контекст и не забивают его при фазе планирования.
Недавно делали несколько больших изменений, которые проходили через всю кодовую базу. Работает.
Спеки создаются как независимые части, которые можно параллельно запускать?
Да, спеки очень сильно помогают в параллельной разработке, особенно для больших изменений.
Раньше мы делали одну большую спеку на условных 400 задач, и агент её выполнял, перегружаясь. Результат получался плохим.
Сейчас вместо одной большой будет 5-6 спецификаций на разные кусочки. Если по proposal видно, что изменение будет большим, или по таскам видно, что их слишком много - просим сделать разбивку. Получается 4-5 штук, которые можно запустить в параллель: например, четыре разных экрана, или клиентский модуль + админский модуль + расчётный модуль.
Вещи, которые не пересекаются друг с другом по функционалу, разбиваются на параллельные кусочки - и всей дружной толпой делают за двадцать минут вместо нескольких часов подряд.
🟤 Brownfield проекты 🔗
Как заводить спеки в brownfield проекте?
Я бы начал с определённого модуля, где спеки можно ввести и начать смотреть, как они работают. Вместо того чтобы пытаться покрыть весь проект - взять определённую зону, желательно не самую критичную, и добавить спецификации.
Можно через spec-gen сгенерировать спеки для уже имеющегося кода. Отсмотреть их глазами, понять, где пошло не так. Сделать новые изменения со спеками, опять посмотреть, где разваливаются вещи. Подтюнить, посмотреть, не хватает ли скиллов.
На второй-третьей итерации будет понятно, насколько это работает в конкретном кусочке и чего не хватает, чтобы LLM давал качественный результат. По большому счёту параметр, для которого оптимизируете - помочь LLM в этой части кода делать результат лучше со спеками, чем без них, и делать более аккуратный предсказуемый результат.
Как выглядел флоу переписки существующего проекта на спеки?
Мы в этой части, возможно, не самый лучший пример для подражания. Взяли уже написанный код, сгенерировали из него концепт и конституцию, выделили несколько критичных элементов, для которых сгенерировали отдельные спеки. Спеки были не для всего проекта, а для расчётных частей и критичных вещей.
Потом просто пересоздали проект с нуля. Перегенерировать с Opus весь проект, который делали предыдущий год - на это ушло несколько дней и очень адекватное количество токенов. Тогда мы ещё не платили за подписки.
Был один элемент с определённым типом расчётов, который стоял отдельно и потом рефакторился, чтобы войти в общую кодовую базу. Для него были написаны тесты, которые сравнивали вывод старого и нового. Агенты гоняли эти тесты в параллель - сравнивали, фиксили, сравнивали, фиксили - и пришли к качественному результату.
Единственный момент: тот же фокус на Opus 4.5 показывал средненькие результаты, приходилось дорабатывать руками. Opus 4.6 уже давал качественный результат без ручного вмешательства.
⚙️ Рабочий процесс и модели 🔗
Имеет ли смысл делать спеку сложной моделью (Opus), а исполнение отдавать быстрой (Flash)?
Мы изначально использовали быструю модель для экономии токенов. Я очень любил Composer v1, потому что он работал быстро и достаточно качественно.
Но Opus, который работает дольше, даёт на порядок лучший результат и требует меньше итераций переделывания и подгонки.
Поэтому вместо того чтобы использовать быструю модель, мы научились работать с несколькими агентами параллельно - чтобы не сидеть и ждать 10-15 минут, пока один завершит работу.
Есть ли стандартные тесты для оценки качества новых моделей?
Есть тесты от OpenHands, в которых тестируют качество моделей по скорости, стоимости и качеству - включая open source модели и последние разработки Anthropic. Можно посмотреть их отчёт. Как бы там ни было, Opus сильно выигрывает.
Фронт и бэк лежат в одной репе? Пропала необходимость делить?
Да, необходимость делить пропала. Но надо понимать, что у нас бэкенд - это BFF (backend for frontend), то есть часть бизнес-логики, которая забирает данные из базы, интегрируется с другими системами и отдаёт это клиентской части.
Там, где нужно, есть отдельные процессы - например, агенты или перекачка данных. Это отдельные deployments, которые работают сами по себе.
Я бы смотрел больше на домены и разделял по ним. Думаю, через пару месяцев мы придём к тому, что разделим один большой frontend + backend на отдельную клиентскую часть, отдельную админскую, отдельную customer success часть. Возможно, клиентскую часть тоже поделим на большие элементы - там, где будет явно видно, что модели начинают сильно путаться и не могут внести адекватные изменения.
Пока они с одной спеки делают изменения между админкой, клиентской частью и всем остальным - смысла делить нет.
🔧 Инструменты и экосистема 🔗
В чём разница tessl.io от маркетплейса скилов типа skillsmp.com?
SkillsMP - это каталог с 87K+ скилами, собранными из GitHub. Загрузил, скачал, установил. Tessl - платформа, которая помимо маркетплейса делает evals. Для меня это самая большая ценность: Tessl отвечает на вопрос “добавляет ли мой скил реальную ценность?” - запускает агента с ним и без него и сравнивает результат. Часто ответ - не добавляет. Скил может выглядеть отлично на бумаге и ничего не менять в поведении агента. Без evals вы верите, что скил работает.
Насколько workflow кастомизирован относительно OpenSpec? Сколько пришлось допиливать?
Значительно. Поверх допилены: drift detection, duplicate finder, complexity checker, convention checker, проект-специфичные скилы (DB migrations, API endpoints). Workflow кастомизируется по необходимости. Скил пишется за 10 минут. OpenSpec позволяет кастомизировать и schema (pipeline артефактов) - можно переименовать команды, добавить свои шаги, создать custom профили.
Видите ли и проверяете ли альтернативы для OpenSpec?
Периодически мониторим, что выходит, пробуем разные вещи. Пока я честно не верю в концепцию полностью автономных агентов, которым даёшь маленький элемент и они всё сделали - мы их между собой называем “токен-сжигалками”. Результат они дают, но он может быть очень неточным, и его всё равно приходится переделывать.
Основная мысль, которая проходила через кучу ответов - поправка на старте очень сильно помогает попасть туда, куда нужно. У меня было много примеров, когда агенты проектировали явно неправильную архитектуру. Смотришь на proposal, смотришь на design и думаешь: так мы не будем делать. Поправить proposal на 50 строк или design на 100 строк намного проще, чем то, что они сделают вокруг 30 файлов в проекте.
Большинство фреймворков сейчас дают примерно одно и то же. Я бы сравнивал под свои процессы - подойдёт ли мне эта штука на ближайшие три-четыре месяца. Смигрироваться с одного на другой будет, скорее всего, так же просто, как написать пару скилов и дать агенту команду перепаковать из одного формата в другой. Такие вещи он делает на ура. Вопрос больше в том, имеет ли это смысл и получим ли мы что-то сверху от того, что уже есть.