Forwarded from AI Projects (Vladimir Ivanov)
Написал статью с формальным описанием методологии GRACE (Graph-RAG Anchored Code Engineering) по автоматической генерации кода ИИ агентами. Думаю, что почитав как генерируются большие приложения с помощью ИИ, многие поймут, почему у многих возникает "технический долг" при работе с ИИ и они не могут создать больше 1го рабочего модуля.
GRACE предназначен для больших приложений, которые на 100% генерируются с помощью ИИ. Методология имеет смысл для кода от 800-1000 строк. Для совсем мелких приложений скорее избыточная, но это больше для средних и крупных Enterprise приложений.
Впервые публично раскрывается технология "семантического каркаса кода", что сейчас закрыта страшными NDA у крупнейших IT-концернов, чтобы обеспечивать им конкурентные преимущества.
Сам по себе методология сильно приземленная на конкретные особенности sparse attention у GPT и специфики работы RAG-агентов по коду как Cursor. Для распределенного внимания семантический каркас позволяет ИИ легко манипулировать даже 20.000 строк кода в одном контексте sparse attention, а для RAG агентов позволяет в 1-3 прыжка оказаться в нужном блоке кода и сразу же собрать контекст как его править.
GRACE отлаживался несколько месяцев на более чем 200 специалистах на моих обучениях, в итоговую версию вошло только то, что реально эффективно работает. Сам GRACE совместим с моей методологией создания агентов PCAM, но не требует PCAM обязательно, т.к. это скорее технология генерации большого кода и способность ИИ контролировать без "технических долгов" как у новичков в ИИ генерации кода.
В рамках поста не все тезисы могу описать, фреймворк на деле методически довольно крупный. По факту что-то вроде RUP для AI-эпохи получается постепенно. Поэтому рекомендую почитать статью, скорее отдельные элементы методологии буду раскрывать отдельными публикациями. Сами по себе GRACE и PCAM поддерживают моими курсами обучения и готовыми учебно-боевыми примерами решений.
vk.com/@turboplanner-grace-freimvork-sozdaniya-koda-llm-v-bolshih-kontekstah-s-uc
GRACE предназначен для больших приложений, которые на 100% генерируются с помощью ИИ. Методология имеет смысл для кода от 800-1000 строк. Для совсем мелких приложений скорее избыточная, но это больше для средних и крупных Enterprise приложений.
Впервые публично раскрывается технология "семантического каркаса кода", что сейчас закрыта страшными NDA у крупнейших IT-концернов, чтобы обеспечивать им конкурентные преимущества.
Сам по себе методология сильно приземленная на конкретные особенности sparse attention у GPT и специфики работы RAG-агентов по коду как Cursor. Для распределенного внимания семантический каркас позволяет ИИ легко манипулировать даже 20.000 строк кода в одном контексте sparse attention, а для RAG агентов позволяет в 1-3 прыжка оказаться в нужном блоке кода и сразу же собрать контекст как его править.
GRACE отлаживался несколько месяцев на более чем 200 специалистах на моих обучениях, в итоговую версию вошло только то, что реально эффективно работает. Сам GRACE совместим с моей методологией создания агентов PCAM, но не требует PCAM обязательно, т.к. это скорее технология генерации большого кода и способность ИИ контролировать без "технических долгов" как у новичков в ИИ генерации кода.
В рамках поста не все тезисы могу описать, фреймворк на деле методически довольно крупный. По факту что-то вроде RUP для AI-эпохи получается постепенно. Поэтому рекомендую почитать статью, скорее отдельные элементы методологии буду раскрывать отдельными публикациями. Сами по себе GRACE и PCAM поддерживают моими курсами обучения и готовыми учебно-боевыми примерами решений.
vk.com/@turboplanner-grace-freimvork-sozdaniya-koda-llm-v-bolshih-kontekstah-s-uc
VK
GRACE: Фреймворк создания кода LLM в больших контекстах с учетом sparse attention и особенностей RAG-агентов
1. Аннотация
❤1👍1
Пространственно-временной континуум разорвало — у нас сразу два поста и перепутанные ссылки. Но для понимания концепции стоит прочитать обе статьи, а ниже — мои личные дополнения.
https://github.com/KolkhozIO/rulez
Что это такое:
Это коллекция моих правил для Cursor, которые я использую при разработке кода. По сути — две адаптированные версии под разные проекты:
- сложное веб-приложение (backend + frontend + месиво из контейнеров);
- ML-пайплайн с обучением wake-word моделей.
Помимо правил я выложил примеры реальной документации — их можно грузить as-is в свои проекты и «прогонять» ваших AI-агентов, адаптируя под вашу среду.
Чем это НЕ является:
- волшебной пулей, которая всё сделает сама;
- «успешным кейсом внедрения ИИ-агента» (пока рано говорить, что есть универсально успешные подходы);
- финальной версией правил и доков — 30–50% материалов можно урезать/упростить, но это требует времени и тестов.
Чем это МОЖЕТ быть:
- стартовой точкой, если своих (более лучших) идей пока нет;
- набором правил, чтобы заставить агента делать что-то осмысленное без тотальной детализации с вашей стороны;
- инструментом для стабилизации хаоса в проекте.
Как использовать:
1. Подключите репозиторий к своему проекту (как сабмодуль/копию).
2. Загрузите правила и примеры доков в контекст агента.
3. Попросите агента адаптировать правила под ваши процессы/структуру.
4. Зафиксируйте удачные находки обратно в правилах (контрактах/гайде) — «прочитай доку» должно стать рабочей командой.
Важно:
Я много говорил о важности рефлексии: для вашего проекта подобные изменения могут быть избыточны. Смотрите на сигналы и метрики, примеры рефлексии — на скриншотах.
https://github.com/KolkhozIO/rulez
Что это такое:
Это коллекция моих правил для Cursor, которые я использую при разработке кода. По сути — две адаптированные версии под разные проекты:
- сложное веб-приложение (backend + frontend + месиво из контейнеров);
- ML-пайплайн с обучением wake-word моделей.
Помимо правил я выложил примеры реальной документации — их можно грузить as-is в свои проекты и «прогонять» ваших AI-агентов, адаптируя под вашу среду.
Чем это НЕ является:
- волшебной пулей, которая всё сделает сама;
- «успешным кейсом внедрения ИИ-агента» (пока рано говорить, что есть универсально успешные подходы);
- финальной версией правил и доков — 30–50% материалов можно урезать/упростить, но это требует времени и тестов.
Чем это МОЖЕТ быть:
- стартовой точкой, если своих (более лучших) идей пока нет;
- набором правил, чтобы заставить агента делать что-то осмысленное без тотальной детализации с вашей стороны;
- инструментом для стабилизации хаоса в проекте.
Как использовать:
1. Подключите репозиторий к своему проекту (как сабмодуль/копию).
2. Загрузите правила и примеры доков в контекст агента.
3. Попросите агента адаптировать правила под ваши процессы/структуру.
4. Зафиксируйте удачные находки обратно в правилах (контрактах/гайде) — «прочитай доку» должно стать рабочей командой.
Важно:
Я много говорил о важности рефлексии: для вашего проекта подобные изменения могут быть избыточны. Смотрите на сигналы и метрики, примеры рефлексии — на скриншотах.
❤1👍1
Отзыв от разработчика с 10+ стажем после мастер-класса со мной. Прошли полный путь от простой идеи до прототипа.
В процессе вайб-разработки можно выделить три этапа, на каждом из которых можно упереться в пределы организации разработки, из-за чего возникнет хаос.
Первый этап самый простой: мы пишем промпт из разряда "сделай мне такой-то сервис". Код генерируется, мы наваливаем ещё фичей, все идет хорошо, ИИ нам отвечает что все отлично и все сделано. На данном этапе оно может работать, а может и не работать, это не так важно. Допустим все работает и мы идем дальше.
В нашем гипотетическом приложении появляется дополнительный модуль, например фронтенд (если мы делали бекенд) и наоборот. Мы переходим ко второму этапу, где все начинает разваливаться. Основная проблема тут в отсутствии эффективных методов тестирования, так и правил разработки. Нейроесть кряхтит-пердит, но пытается собрать проект в кучу (генерируя кучу версий, упрощая тесты и функциональность). Параллельно она ещё пишет, что все готово и сделано, так что начинает бесить и вызывать желание написать в интернет, что вайб-кодинг это херня. Если вдруг нам удалось на этом этапе стабилизировать приложение, мы вытираем пот и говорим себе, что не нейросети нас ещё не заменят (пока).
На этом этапе нам нужно отступить на шаг назад и полностью переработать нашу документацию. Все должно быть отражено в тексте: функциональные требования, контракты в коде, структуры состояний/экранов/whatever. Только когда мы оформили это в XML у нас появляется возможность использовать рефлекцию ИИ над самой структурой приложения. А добавив правила, мы позволяем агенту самому исправлять ошибки в архитектуры и поставлять стабильное качество.
Это третий этап (ничто не мешает вам сразу начать с него). На данном этапе вы как разработчик следите только за правилами агента, так и за документацией. Код становится не важен и его можно редуцировать (во многих аспектах) до парсера XML. Здесь мы работаем только с требованиями (различных уровней), сам код можно уже не смотреть, потому что постоянный поток рефлексии (даже слегка галлюцинирующий) поверх жесткой структуры приводит к стабильным результатам.
В процессе вайб-разработки можно выделить три этапа, на каждом из которых можно упереться в пределы организации разработки, из-за чего возникнет хаос.
Первый этап самый простой: мы пишем промпт из разряда "сделай мне такой-то сервис". Код генерируется, мы наваливаем ещё фичей, все идет хорошо, ИИ нам отвечает что все отлично и все сделано. На данном этапе оно может работать, а может и не работать, это не так важно. Допустим все работает и мы идем дальше.
В нашем гипотетическом приложении появляется дополнительный модуль, например фронтенд (если мы делали бекенд) и наоборот. Мы переходим ко второму этапу, где все начинает разваливаться. Основная проблема тут в отсутствии эффективных методов тестирования, так и правил разработки. Нейроесть кряхтит-
На этом этапе нам нужно отступить на шаг назад и полностью переработать нашу документацию. Все должно быть отражено в тексте: функциональные требования, контракты в коде, структуры состояний/экранов/whatever. Только когда мы оформили это в XML у нас появляется возможность использовать рефлекцию ИИ над самой структурой приложения. А добавив правила, мы позволяем агенту самому исправлять ошибки в архитектуры и поставлять стабильное качество.
Это третий этап (ничто не мешает вам сразу начать с него). На данном этапе вы как разработчик следите только за правилами агента, так и за документацией. Код становится не важен и его можно редуцировать (во многих аспектах) до парсера XML. Здесь мы работаем только с требованиями (различных уровней), сам код можно уже не смотреть, потому что постоянный поток рефлексии (даже слегка галлюцинирующий) поверх жесткой структуры приводит к стабильным результатам.
🔥1
🚀 Spec-Driven Development: новая эра agentic-разработки
Leon от Zencoder провел мастер-класс по SDD — подходу, который меняет правила игры при работе с AI-агентами.
🎯 Главная идея
Когда AI переходит от conversational режима к agentic (долгие независимые выполнения), ему нужна детальная спецификация — как архитектору нужен план дома, а не просто "построй крыло".
💡 Ключевые инсайты:
Spec ≠ Implementation
Спецификация описывает желаемый UX, а не код. Агент сам выберет подход.
4 фазы разработки:
Specify → Plan → Task → Implement
Каждая фаза — отдельный фокус внимания.
State tracking — must have
Progress.txt + test.json + atomic commits = возможность прерывать и продолжать работу без потери контекста.
Vibe coding vs SDD
Vibe coding = ты присутствуешь каждый prompt. SDD = агент работает часами, пока ты летишь в самолёте ✈️
🔧 Практические советы:
✅ Не смешивай "что есть" с "что должно быть" при написании spec
✅ Используй Spec Kit или spec generation agents
✅ Collaborative planning с агентом — обязателен
✅ TDD не противоречит SDD — это зеркальные подходы
✅ Твои старые janky проекты — уже готовые specs для переписывания!
🎓 Цитата дня:
"Agents do not feel vibes. No spec survives unchanged with contact with your code base — just like no battle plan survives contact with the enemy."
🛠 Упомянутые инструменты:
Zencoder (с repo info agent и steerability)
Spec Kit (GitHub)
Beads (state tracking library)
Claude Sonnet 3.5
📌 Главный takeaway:
Не перекладывай когнитивную работу по продумыванию опыта пользователя на агента. Это твоя ответственность. Агент — мастер реализации, ты — архитектор видения.
https://www.youtube.com/watch?v=mtls8g-uAqY
#SpecDrivenDevelopment #AgenticAI #Zencoder #AIEngineering #SDD
Leon от Zencoder провел мастер-класс по SDD — подходу, который меняет правила игры при работе с AI-агентами.
🎯 Главная идея
Когда AI переходит от conversational режима к agentic (долгие независимые выполнения), ему нужна детальная спецификация — как архитектору нужен план дома, а не просто "построй крыло".
💡 Ключевые инсайты:
Spec ≠ Implementation
Спецификация описывает желаемый UX, а не код. Агент сам выберет подход.
4 фазы разработки:
Specify → Plan → Task → Implement
Каждая фаза — отдельный фокус внимания.
State tracking — must have
Progress.txt + test.json + atomic commits = возможность прерывать и продолжать работу без потери контекста.
Vibe coding vs SDD
Vibe coding = ты присутствуешь каждый prompt. SDD = агент работает часами, пока ты летишь в самолёте ✈️
🔧 Практические советы:
✅ Не смешивай "что есть" с "что должно быть" при написании spec
✅ Используй Spec Kit или spec generation agents
✅ Collaborative planning с агентом — обязателен
✅ TDD не противоречит SDD — это зеркальные подходы
✅ Твои старые janky проекты — уже готовые specs для переписывания!
🎓 Цитата дня:
"Agents do not feel vibes. No spec survives unchanged with contact with your code base — just like no battle plan survives contact with the enemy."
🛠 Упомянутые инструменты:
Zencoder (с repo info agent и steerability)
Spec Kit (GitHub)
Beads (state tracking library)
Claude Sonnet 3.5
📌 Главный takeaway:
Не перекладывай когнитивную работу по продумыванию опыта пользователя на агента. Это твоя ответственность. Агент — мастер реализации, ты — архитектор видения.
https://www.youtube.com/watch?v=mtls8g-uAqY
#SpecDrivenDevelopment #AgenticAI #Zencoder #AIEngineering #SDD
YouTube
Spec-Driven Development: Build Smarter with AI
Most of us started with AI coding agents the same way we search Google: type a vague prompt, hope for magic. That works fine for toy apps — but when it’s time to ship production-grade systems, “vibe-coding” breaks down fast.
In this webinar, we’ll talk more…
In this webinar, we’ll talk more…
👍1
колхозный ИИ
🚀 Spec-Driven Development: новая эра agentic-разработки Leon от Zencoder провел мастер-класс по SDD — подходу, который меняет правила игры при работе с AI-агентами. 🎯 Главная идея Когда AI переходит от conversational режима к agentic (долгие независимые…
🎯 Разработка через спецификации: 3 проблемы, которые игнорируют все инструменты
Brian Castle (создатель Agent OS) объясняет, почему массовые инструменты для разработки через спецификации всё ещё не готовы к реальному миру — и как это исправить.
📊 Контекст индустрии
GitHub запустил Spec Kit. Amazon выпустил Kero. Cursor добавил отслеживание задач. Claude Code имеет режим планирования.
➡️ Индустрия сходится на том, что спецификации — это путь. Но инструменты и процессы всё ещё не устоялись.
***
⚠️ 3 критические проблемы
1️⃣ Отсутствие процесса согласования
❌ Проблема: Инструменты ожидают, что вы придете с готовым запросом
✅ Решение: Нужна фаза генерации идей и стратегического планирования ДО написания спецификации
Подход Agent OS:
- Субагент-исследователь задает уточняющие вопросы
- С разумными предположениями для быстрых ответов (просто "да" или корректировка)
- Дополнительные вопросы после анализа ваших ответов
- Поддержка визуальных референсов (макеты, схемы)
💡 Инсайт: Не перекладывай когнитивную работу по продумыванию пользовательского опыта на агента. Это твоя зона ответственности.
***
2️⃣ Отсутствие контекста о стандартах
❌ Проблема: "Построй React-приложение" — недостаточно
✅ Нужна детализация: технологический стек, стиль кода, библиотеки, паттерны, компоненты, разработка API
Подход Agent OS:
- Определи стандарты кодирования и дизайнерские решения ОДИН РАЗ
- При написании спецификаций и реализации агенты уже имеют эти знания
- Не нужно "переобучать" агента на каждой новой функции
***
3️⃣ Слишком жесткие инструменты
❌ Проблема: Инструменты диктуют процесс разработки
✅ Реальность: Все строят по-разному
- Подход с приоритетом API против подхода с приоритетом интерфейса
- Стартап с 3 соучредителями против корпорации с 30 инженерами
- Разные функции требуют разных субагентов и фаз
Подход Agent OS:
- Адаптируется под ваш процесс через оркестрацию субагентов
- Гибкое делегирование: инженер БД, инженер API, дизайнер интерфейса
- Можно менять процесс на лету между функциями
***
🔄 Рабочий процесс Agent OS
Фаза 1: Исследование и планирование
→ Уточняющие вопросы с предположениями
→ Анализ визуалов (макеты)
→ Документ требований
Фаза 2: Создание спецификации
→ Субагент-писатель создает одностраничник
→ Субагент-верификатор проверяет точность
→ Высокоуровневый технический подход (без излишней детализации)
Фаза 3: Разбиение на задачи
→ Группы задач с родительскими/подзадачами
→ Рекомендации по делегированию субагентам
→ Гибкость для корректировок
***
💎 Где теперь наше мастерство?
> "Вот где теперь происходит наше мастерство. Где мы приносим ценность — это через дизайн, вкус, опыт и понимание того, что нужно нашим клиентам."
Агенты строят код.
Ты — архитектор видения.
Фаза планирования — это где происходит настоящая ценность.
***
🔗 Ресурсы:
- Agent OS — бесплатная открытая система для разработки через спецификации
- Новостная рассылка Builder Briefing — buildermethods.com
- Живые мастер-классы по разработке с приоритетом ИИ
#РазработкаЧерезСпецификации #AgentOS #РазработкаСИИ #ДизайнПродукта
***
*P.S. Если Leon говорил о философии разработки через спецификации, то Brian показывает конкретные инструменты и рабочий процесс. Оба подхода дополняют друг друга.*
https://www.youtube.com/watch?v=3le-v1Pme44
Brian Castle (создатель Agent OS) объясняет, почему массовые инструменты для разработки через спецификации всё ещё не готовы к реальному миру — и как это исправить.
📊 Контекст индустрии
GitHub запустил Spec Kit. Amazon выпустил Kero. Cursor добавил отслеживание задач. Claude Code имеет режим планирования.
➡️ Индустрия сходится на том, что спецификации — это путь. Но инструменты и процессы всё ещё не устоялись.
***
⚠️ 3 критические проблемы
1️⃣ Отсутствие процесса согласования
❌ Проблема: Инструменты ожидают, что вы придете с готовым запросом
✅ Решение: Нужна фаза генерации идей и стратегического планирования ДО написания спецификации
Подход Agent OS:
- Субагент-исследователь задает уточняющие вопросы
- С разумными предположениями для быстрых ответов (просто "да" или корректировка)
- Дополнительные вопросы после анализа ваших ответов
- Поддержка визуальных референсов (макеты, схемы)
💡 Инсайт: Не перекладывай когнитивную работу по продумыванию пользовательского опыта на агента. Это твоя зона ответственности.
***
2️⃣ Отсутствие контекста о стандартах
❌ Проблема: "Построй React-приложение" — недостаточно
✅ Нужна детализация: технологический стек, стиль кода, библиотеки, паттерны, компоненты, разработка API
Подход Agent OS:
- Определи стандарты кодирования и дизайнерские решения ОДИН РАЗ
- При написании спецификаций и реализации агенты уже имеют эти знания
- Не нужно "переобучать" агента на каждой новой функции
***
3️⃣ Слишком жесткие инструменты
❌ Проблема: Инструменты диктуют процесс разработки
✅ Реальность: Все строят по-разному
- Подход с приоритетом API против подхода с приоритетом интерфейса
- Стартап с 3 соучредителями против корпорации с 30 инженерами
- Разные функции требуют разных субагентов и фаз
Подход Agent OS:
- Адаптируется под ваш процесс через оркестрацию субагентов
- Гибкое делегирование: инженер БД, инженер API, дизайнер интерфейса
- Можно менять процесс на лету между функциями
***
🔄 Рабочий процесс Agent OS
Фаза 1: Исследование и планирование
→ Уточняющие вопросы с предположениями
→ Анализ визуалов (макеты)
→ Документ требований
Фаза 2: Создание спецификации
→ Субагент-писатель создает одностраничник
→ Субагент-верификатор проверяет точность
→ Высокоуровневый технический подход (без излишней детализации)
Фаза 3: Разбиение на задачи
→ Группы задач с родительскими/подзадачами
→ Рекомендации по делегированию субагентам
→ Гибкость для корректировок
***
💎 Где теперь наше мастерство?
> "Вот где теперь происходит наше мастерство. Где мы приносим ценность — это через дизайн, вкус, опыт и понимание того, что нужно нашим клиентам."
Агенты строят код.
Ты — архитектор видения.
Фаза планирования — это где происходит настоящая ценность.
***
🔗 Ресурсы:
- Agent OS — бесплатная открытая система для разработки через спецификации
- Новостная рассылка Builder Briefing — buildermethods.com
- Живые мастер-классы по разработке с приоритетом ИИ
#РазработкаЧерезСпецификации #AgentOS #РазработкаСИИ #ДизайнПродукта
***
*P.S. Если Leon говорил о философии разработки через спецификации, то Brian показывает конкретные инструменты и рабочий процесс. Оба подхода дополняют друг друга.*
https://www.youtube.com/watch?v=3le-v1Pme44
YouTube
Spec-Driven Development in the Real World
The industry is converging on spec-driven development as the professional way to build with AI, but most tools are missing 3 critical aspects that make it actually work in the real world. I'll show you what's missing from most tools, plus how I solve these…
AgentOS: стандартизация работы с AI-агентами в разработке
Современные кодовые агенты часто не учитывают ваши стандарты, архитектуру и специфику продукта, что приводит к потерям времени и регулярным исправлениям. AgentOS помогает структурировать взаимодействие с AI‑ассистентами и устранить эти проблемы.
Ключевые особенности AgentOS:
- Три уровня контекста:
- Стандарты (стек, стиль кода, правила) задаются один раз и применяются во всех проектах.
- Продуктовый контекст — миссия и дорожная карта проекта, сценарии использования.
- Технические спецификации — подробные планы по каждой фиче, включая задачи, техническое описание и ограничения.
- Процесс внедрения:
- Базовая установка позволяет создать системную папку стандартов; для каждого нового проекта эти стандарты автоматически копируются.
- Возможно использование нескольких типов проектов с индивидуальными наборами стандартов.
- Шаги установки и настройки описаны в документации проекта.
- Взаимодействие с агентами:
- Вся информация представлена в виде структурированных файлов, понятных для AI‑агентов.
- Операции (планирование, создание спецификаций, задач, их исполнение) доступны через команды в Claude Code и Cursor.
- Поддерживается работа с ветками через встроенные Git-команды.
- Командная работа:
- Все разработчики и AI-ассистенты используют единые стандарты и спецификации — кодовая база становится последовательной.
- Новые сотрудники быстро адаптируются к процессу за счёт унификации инструкций.
AgentOS повышает прозрачность процесса, снижает количество ручной корректировки и ускоряет переход от спецификации к реализации.
#AIразработка #Стандарты #DevWorkflow #Спецификации #ProductOps
https://www.youtube.com/watch?v=4PlVnrliN3Q
Современные кодовые агенты часто не учитывают ваши стандарты, архитектуру и специфику продукта, что приводит к потерям времени и регулярным исправлениям. AgentOS помогает структурировать взаимодействие с AI‑ассистентами и устранить эти проблемы.
Ключевые особенности AgentOS:
- Три уровня контекста:
- Стандарты (стек, стиль кода, правила) задаются один раз и применяются во всех проектах.
- Продуктовый контекст — миссия и дорожная карта проекта, сценарии использования.
- Технические спецификации — подробные планы по каждой фиче, включая задачи, техническое описание и ограничения.
- Процесс внедрения:
- Базовая установка позволяет создать системную папку стандартов; для каждого нового проекта эти стандарты автоматически копируются.
- Возможно использование нескольких типов проектов с индивидуальными наборами стандартов.
- Шаги установки и настройки описаны в документации проекта.
- Взаимодействие с агентами:
- Вся информация представлена в виде структурированных файлов, понятных для AI‑агентов.
- Операции (планирование, создание спецификаций, задач, их исполнение) доступны через команды в Claude Code и Cursor.
- Поддерживается работа с ветками через встроенные Git-команды.
- Командная работа:
- Все разработчики и AI-ассистенты используют единые стандарты и спецификации — кодовая база становится последовательной.
- Новые сотрудники быстро адаптируются к процессу за счёт унификации инструкций.
AgentOS повышает прозрачность процесса, снижает количество ручной корректировки и ускоряет переход от спецификации к реализации.
#AIразработка #Стандарты #DevWorkflow #Спецификации #ProductOps
https://www.youtube.com/watch?v=4PlVnrliN3Q
YouTube
Agent OS: The System for Spec-Driven Development
Update! Agent OS v2 has been released. All new video demo here: https://youtu.be/kApsR0l9Jfw?si=x7IKxRHLIC3DktuT
---
Two months ago, I released Agent OS—a free, open-source system that brings spec-driven development to your coding agents. It teaches agents…
---
Two months ago, I released Agent OS—a free, open-source system that brings spec-driven development to your coding agents. It teaches agents…
колхозный ИИ
AgentOS: стандартизация работы с AI-агентами в разработке Современные кодовые агенты часто не учитывают ваши стандарты, архитектуру и специфику продукта, что приводит к потерям времени и регулярным исправлениям. AgentOS помогает структурировать взаимодействие…
А вот немного критики, хотя скорее уточнения:
🎥 Шаг назад от "спецификаций" — где реальный кайф разработки на AI
На неделе GitHub выпустил свой инструмент Specify — шикарный повод разобраться, нужен ли вообще полный «spec-driven» стиль или проще уйти обратно в vibe coding. Я решил проверить — и построил простое приложение в двух вариантах: "как чувствую" и строго по specs.
Vibe coding когда-то взорвал инфополе: любой мог собрать приложение парой промптов — даже школьницы в X/Twitter. Это реально магия, но быстро стало ясно: без базового понимания — получаешь спагетти-код и ошибки.
Появилась мода на "development по спецификациям": сначала строим схему, по которой агент должен работать. Но маятник ушёл слишком далеко — теперь половина dev-сообщества утопла в .spec-файлах, фреймворках и сотнях МБ сожжённых токенов.
Коротко о Specify/SpecKit (и других, например, BMED, Kero):
- CLI-установка через пару команд.
- Всё уже интегрировано: после /specify — бот просит описать, что строим (фича, приложение, элемент), делает папки и план, потом разбивает задачи по TDD-принципу.
- Очень test-driven философия: проверки, контракты, edge cases, отдельные бранчи — всё для безопасности.
Что реально в итоге:
- Сделать «spec-версию» приложения — 40+ минут, куча токенов, TDD и автоматизация.
- Сделать «vibe-версию» — 3 минуты, красивый фронт, куча фич, быстро подключённая база, user-friendly результат.
- Производство через спецификации по ощущениям слишком зарегламентировано для простого прототипирования, где всё меняется на ходу.
Мой итог после пары лет в AI-dev:
Самое эффективное — гибрид:
1. Базовый ресерч с агентом: обсуждаешь стек, предпочтения, задачи — но не тонешь в 50-страничной спецификации.
2. Сначала мастеришь фронт на фиктивных данных (быстрее тестировать UX).
3. MVP — всегда минимальный. Расширяешь только если зашла идея/решение.
4. Specs и правила — добавляешь только по мере необходимости, не всё сразу.
5. Готовишь задачи/план к следующей фиче отдельным промптом — и в бой.
В общем, "спеки" полезны, но не стоит перегибать. Лёгкое планирование + итеративный подход — гораздо продуктивнее. Кому интересно, в комментариях поделитесь опытом: сами больше к specs или к "как идёт"? Какие используете фреймворки?
***
P.S. Вывод: Не дайте агенту превратить вашу разработку во вторую бюрократию. Немного структуры + много свободы = эффективный AI-dev.
#AICoding #SpecDev #VibeCoding #DevTools #AICommunity
https://www.youtube.com/watch?v=Ij-mZcpTcVM
🎥 Шаг назад от "спецификаций" — где реальный кайф разработки на AI
На неделе GitHub выпустил свой инструмент Specify — шикарный повод разобраться, нужен ли вообще полный «spec-driven» стиль или проще уйти обратно в vibe coding. Я решил проверить — и построил простое приложение в двух вариантах: "как чувствую" и строго по specs.
Vibe coding когда-то взорвал инфополе: любой мог собрать приложение парой промптов — даже школьницы в X/Twitter. Это реально магия, но быстро стало ясно: без базового понимания — получаешь спагетти-код и ошибки.
Появилась мода на "development по спецификациям": сначала строим схему, по которой агент должен работать. Но маятник ушёл слишком далеко — теперь половина dev-сообщества утопла в .spec-файлах, фреймворках и сотнях МБ сожжённых токенов.
Коротко о Specify/SpecKit (и других, например, BMED, Kero):
- CLI-установка через пару команд.
- Всё уже интегрировано: после /specify — бот просит описать, что строим (фича, приложение, элемент), делает папки и план, потом разбивает задачи по TDD-принципу.
- Очень test-driven философия: проверки, контракты, edge cases, отдельные бранчи — всё для безопасности.
Что реально в итоге:
- Сделать «spec-версию» приложения — 40+ минут, куча токенов, TDD и автоматизация.
- Сделать «vibe-версию» — 3 минуты, красивый фронт, куча фич, быстро подключённая база, user-friendly результат.
- Производство через спецификации по ощущениям слишком зарегламентировано для простого прототипирования, где всё меняется на ходу.
Мой итог после пары лет в AI-dev:
Самое эффективное — гибрид:
1. Базовый ресерч с агентом: обсуждаешь стек, предпочтения, задачи — но не тонешь в 50-страничной спецификации.
2. Сначала мастеришь фронт на фиктивных данных (быстрее тестировать UX).
3. MVP — всегда минимальный. Расширяешь только если зашла идея/решение.
4. Specs и правила — добавляешь только по мере необходимости, не всё сразу.
5. Готовишь задачи/план к следующей фиче отдельным промптом — и в бой.
В общем, "спеки" полезны, но не стоит перегибать. Лёгкое планирование + итеративный подход — гораздо продуктивнее. Кому интересно, в комментариях поделитесь опытом: сами больше к specs или к "как идёт"? Какие используете фреймворки?
***
P.S. Вывод: Не дайте агенту превратить вашу разработку во вторую бюрократию. Немного структуры + много свободы = эффективный AI-dev.
#AICoding #SpecDev #VibeCoding #DevTools #AICommunity
https://www.youtube.com/watch?v=Ij-mZcpTcVM
YouTube
Spec Driven Development is Slowing You Down: Here’s a Better Way
Build Apps With AI - Course https://switchdimension.com
Lets checkout Specify Spec Kit from Github, is it any good and what you might be better off doing instead.
Prompts for 3 Experts Approach
https://notes.switchdimension.com/AI-Dev-Project-Setup-Prompts…
Lets checkout Specify Spec Kit from Github, is it any good and what you might be better off doing instead.
Prompts for 3 Experts Approach
https://notes.switchdimension.com/AI-Dev-Project-Setup-Prompts…
Осталась неделя до окончания акции гугла на студенческий AI Pro. Чтобы получить халявный Про аккаунт Gemini вам нужно сделать следующее:
1. Android телефон на котором вы заведете новый аккаунт
2. Прокси США берете на https://px6.me/user/proxy
3. Заходите с прокси на http://goo.gle/freepro и видите то, что на скриншоте
4. Нажимаете получить доступ и переходите на sheerId, ссылку с sheerId вставляете сюда и получаете апрув https://batch.1key.me/
5. В финале попросит привязать зарубежную карту, списывать ничего не будет, главное чтобы карта прошла хоть с нулевым балансом (можно попробовать купить пустую на plati.market)
Пользоваться на gemini.google.com
Пара лайфхаков:
• Сразу удаляйте аккаунт с телефона, гемини не работает с РФ, работайте с гемини все время через прокси (телефон спалит вашу локацию)
• Привязывайте 2FA через гугловый аутентификатор, иначе будет просить привязать мобильный номер
1. Android телефон на котором вы заведете новый аккаунт
2. Прокси США берете на https://px6.me/user/proxy
3. Заходите с прокси на http://goo.gle/freepro и видите то, что на скриншоте
4. Нажимаете получить доступ и переходите на sheerId, ссылку с sheerId вставляете сюда и получаете апрув https://batch.1key.me/
5. В финале попросит привязать зарубежную карту, списывать ничего не будет, главное чтобы карта прошла хоть с нулевым балансом (можно попробовать купить пустую на plati.market)
Пользоваться на gemini.google.com
Пара лайфхаков:
• Сразу удаляйте аккаунт с телефона, гемини не работает с РФ, работайте с гемини все время через прокси (телефон спалит вашу локацию)
• Привязывайте 2FA через гугловый аутентификатор, иначе будет просить привязать мобильный номер
👍2