мы в будущем, ребят (kurbox.ru - ваш умный курятник)

сверстан при помощи ChatGPT, допилен и задеплоен с помощью Cursor, разбирается с кучей непонятных интерфейсов Comet

Всем привет! Чтобы получить похожий результат, когда агенты просто выполняют свою работу без лишней суеты, крайне рекомендую материал про GRACE — он помогает превратить хаос ИИ-вайб-кодинга в стабильный и воспроизводимый процесс. Ниже мои дополнения и практические приёмы.

🔗 https://vk.com/@turboplanner-metodologiya-pcam-prevraschaem-ai-agentov-iz-rabov-v-partner

— Если не использовать инструменты IDE, отлично работает подход «правила в том же XML». Дальше просто говорю модели: *«прочитай правила»* — и всё.
— После каждого решённого «грабля» прошу ИИ зафиксировать решение в контракте/документации/XML. Потом достаточно *«прочитай доку»* — и модель вспоминает, как себя вести. Иначе любое сжатие контекста обнуляет память агента.
— Многократные проверки обязательны. Мало сгенерировать data-flow — прошу модель несколько раз «проверить архитектуру/искать ошибки», пока она не начнёт придираться к мелочам. В этот момент результат действительно «сходится».

### Что добавляю к GRACE

* StateMachine.xml — описывать сложные системы как автоматы состояний и переходов:

1. упрощает абстрактные тесты;
2. синхронизирует backend/frontend/whatever в одной точке.
* protobuf — удобная фиксация API-контрактов.

### Организация правил и агентов

— Ничто не мешает использовать одних агентов другими (даже внутри Cursor).
— Удобно завести отдельный репозиторий под правила каждого проекта.
— Личный инсайт: код — это текст и он вторичен. Первичны правила, имена и структура проекта. Это тоже можно оптимизировать агентом. Пишите наборы правил (наследование/инклюды), подключайте как удобно (git-сабмодули, симлинки, копирование по расписанию) и управляйте контекстом командами уровня «прочитай правила про …» — на практике это делает агента заметно более автономным.

### Короткий вывод

Делайте самым простым способом, который у вас работает сейчас. Пока ИИ не делает всё «под ключ», главная ценность — спроектировать структуру правил. «Самый эффективный способ» устареет быстрее, чем его признают стандартом.

Желаю всем совершенных проектов! :)

Отзыв от разработчика с 10+ стажем после мастер-класса со мной. Прошли полный путь от простой идеи до прототипа.

В процессе вайб-разработки можно выделить три этапа, на каждом из которых можно упереться в пределы организации разработки, из-за чего возникнет хаос.

Первый этап самый простой: мы пишем промпт из разряда "сделай мне такой-то сервис". Код генерируется, мы наваливаем ещё фичей, все идет хорошо, ИИ нам отвечает что все отлично и все сделано. На данном этапе оно может работать, а может и не работать, это не так важно. Допустим все работает и мы идем дальше.

В нашем гипотетическом приложении появляется дополнительный модуль, например фронтенд (если мы делали бекенд) и наоборот. Мы переходим ко второму этапу, где все начинает разваливаться. Основная проблема тут в отсутствии эффективных методов тестирования, так и правил разработки. Нейроесть кряхтит-пердит, но пытается собрать проект в кучу (генерируя кучу версий, упрощая тесты и функциональность). Параллельно она ещё пишет, что все готово и сделано, так что начинает бесить и вызывать желание написать в интернет, что вайб-кодинг это херня. Если вдруг нам удалось на этом этапе стабилизировать приложение, мы вытираем пот и говорим себе, что не нейросети нас ещё не заменят (пока).

На этом этапе нам нужно отступить на шаг назад и полностью переработать нашу документацию. Все должно быть отражено в тексте: функциональные требования, контракты в коде, структуры состояний/экранов/whatever. Только когда мы оформили это в XML у нас появляется возможность использовать рефлекцию ИИ над самой структурой приложения. А добавив правила, мы позволяем агенту самому исправлять ошибки в архитектуры и поставлять стабильное качество.

Это третий этап (ничто не мешает вам сразу начать с него). На данном этапе вы как разработчик следите только за правилами агента, так и за документацией. Код становится не важен и его можно редуцировать (во многих аспектах) до парсера XML. Здесь мы работаем только с требованиями (различных уровней), сам код можно уже не смотреть, потому что постоянный поток рефлексии (даже слегка галлюцинирующий) поверх жесткой структуры приводит к стабильным результатам.

🚀 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

🎯 Разработка через спецификации: 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

AgentOS: стандартизация работы с AI-агентами в разработке

Современные кодовые агенты часто не учитывают ваши стандарты, архитектуру и специфику продукта, что приводит к потерям времени и регулярным исправлениям. AgentOS помогает структурировать взаимодействие с AI‑ассистентами и устранить эти проблемы.

Ключевые особенности AgentOS:

- Три уровня контекста:
- Стандарты (стек, стиль кода, правила) задаются один раз и применяются во всех проектах.
- Продуктовый контекст — миссия и дорожная карта проекта, сценарии использования.
- Технические спецификации — подробные планы по каждой фиче, включая задачи, техническое описание и ограничения.

- Процесс внедрения:
- Базовая установка позволяет создать системную папку стандартов; для каждого нового проекта эти стандарты автоматически копируются.
- Возможно использование нескольких типов проектов с индивидуальными наборами стандартов.
- Шаги установки и настройки описаны в документации проекта.

- Взаимодействие с агентами:
- Вся информация представлена в виде структурированных файлов, понятных для AI‑агентов.
- Операции (планирование, создание спецификаций, задач, их исполнение) доступны через команды в Claude Code и Cursor.
- Поддерживается работа с ветками через встроенные Git-команды.

- Командная работа:
- Все разработчики и AI-ассистенты используют единые стандарты и спецификации — кодовая база становится последовательной.
- Новые сотрудники быстро адаптируются к процессу за счёт унификации инструкций.

AgentOS повышает прозрачность процесса, снижает количество ручной корректировки и ускоряет переход от спецификации к реализации.

#AIразработка #Стандарты #DevWorkflow #Спецификации #ProductOps
https://www.youtube.com/watch?v=4PlVnrliN3Q