This media is not supported in your browser
VIEW IN TELEGRAM
мы в будущем, ребят (kurbox.ru - ваш умный курятник)
сверстан при помощи ChatGPT, допилен и задеплоен с помощью Cursor, разбирается с кучей непонятных интерфейсов Comet
сверстан при помощи ChatGPT, допилен и задеплоен с помощью Cursor, разбирается с кучей непонятных интерфейсов Comet
колхозный ИИ
Video
Всем привет! Чтобы получить похожий результат, когда агенты просто выполняют свою работу без лишней суеты, крайне рекомендую материал про 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-сабмодули, симлинки, копирование по расписанию) и управляйте контекстом командами уровня «прочитай правила про …» — на практике это делает агента заметно более автономным.
### Короткий вывод
Делайте самым простым способом, который у вас работает сейчас. Пока ИИ не делает всё «под ключ», главная ценность — спроектировать структуру правил. «Самый эффективный способ» устареет быстрее, чем его признают стандартом.
🔗 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-сабмодули, симлинки, копирование по расписанию) и управляйте контекстом командами уровня «прочитай правила про …» — на практике это делает агента заметно более автономным.
### Короткий вывод
Делайте самым простым способом, который у вас работает сейчас. Пока ИИ не делает всё «под ключ», главная ценность — спроектировать структуру правил. «Самый эффективный способ» устареет быстрее, чем его признают стандартом.
VK
Методология PCAM: Превращаем AI-агентов из рабов в партнеров
Введение
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