В классических системах требование было статичным документом, и его декомпозиция (разбить Б на С и Д) стоила колоссальных ручных усилий по перелинковке. В Work Graph требование — это исполняемый узел графа. Поэтому его рефакторинг стоит ровно столько же, сколько рефакторинг функции в коде (Extract Method): новые узлы автоматически наследуют контекст и трассировку родителя, делая эволюцию модели дешёвой и безопасной.
По неочевидным связям, которые "повышают стоимость", мы используем динамический анализ топологии AI-агентом и Compliance Gate. Если изменение одного узла создаёт семантический конфликт с другим, сборка просто падает. Так нечёткость и несовершенство модели перестают быть невидимым техдолгом, который всплывает сюрпризом в проде, и превращаются в явный "linting error", который автоматически создаёт задачу в бэклоге на доработку.
В этом и есть главная ценность. Недооценённый информационный слой (связь между требованием, графом и кодом) становится таким же тестируемым и управляемым активом системы, как и сама бизнес-логика.
Спецификации на типах в классическом стеке кажется утопией. Мы обходим это, вынося верификацию за пределы языка, в собственный слой. А код получает ровно ту типизацию, которую язык поддерживает из коробки.
У нас уровень выше — формализуем не данные, а логику и намерения. Мы строим не контракты на данные, а контракты на исполнение правил.
ODCS описывает контракты на данные: их схему, качество, свежесть. Это про то, как данные должны выглядеть, чтобы ИИ мог им доверять.
Work Graph описывает контракты на поведение: что система должна делать, какие у этого есть предусловия и постусловия, как проверить результат. Это про то, как ИИ должен действовать, а не только что читать.
Согласен, нейрослоп в продакшене — зло. Но переписать руками — это как раз та самая операционная энтропия, от которой мы пытаемся избавиться.
Мы сейчас двигаемся в сторону, когда нейросеть в нашей системе вообще не генерирует код. Она генерирует только формальное описание логики (контракты).
Валидатор математически проверяет граф на полноту, отсутствие тупиков и соответствие типам. Если проверка пройдена, детерминированный компилятор превращает этот граф в чистый, типизированный код.
Нейросеть здесь выступает не как программист, а как переводчик с человеческого языка на строгий протокол. А код уже пишет машина, которая не умеет срать, потому что следует жёстким, верифицируемым правилам. По итогу у нас должен получиться протокол надежности для ИИ.
Согласен. Idris2 — отличный инструмент для верифицируемого кода, но он требует, чтобы разработчик мыслил на уровне типов.
Зависимые типы — это мощнейший инструмент, и если мы говорим о доказательстве того, что код строго соответствует спецификации, то Idris2 или Coq/Lean вне конкуренции.
Но здесь кроется нюанс, который мы и пытаемся закрыть: Idris2 доказывает корректность реализации, но не спасает от ошибок в самой спецификации. Если бизнес-аналитик или ИИ забыл описать в спецификации обработку ошибки сети или edge-case, Idris просто безупречно скомпилирует эту неполную логику. Он докажет, что код непротиворечив, но система всё равно упадет в продакшене.
Поэтому мы не пытаемся соревноваться с Idris2 в математических доказательствах — это нереально для сложных систем без команды математиков.
Мы делаем прагматичную верификацию на уровне модели. Наш валидатор проверяет не "истинность теоремы", а структурную целостность графа намерений:
Все ли узлы достижимы? (Нет ли мертвого кода) Покрыты ли все условия? (Нет ли забытых else) Сходятся ли типы данных между узлами? (Не передаем ли мы строку туда, где ждем число) Нет ли логических тупиков и циклов?
Это не "доказательство корректности программы" в академическом смысле. Это детектирование очевидных архитектурных и логических дыр до того, как они превратятся в код.
Idris2 гарантирует, что вы правильно построили стену по чертежу. А Work Graph гарантирует, что на самом чертеже не забыли нарисовать дверь, прежде чем вы вообще начнете класть кирпичи. И то, и другое нужно, но это разные слои ответственности.
Следующий шаг Work Graph — стать генеративным Low-Code. Overengineering становится просто невозможным: если решение можно собрать из существующих кирпичиков — ИИ обязан использовать их, а не изобретать велосипед.
Сложность появляется только тогда, когда она действительно оправдана и чтобы создать что-то новое, ИИ должен пройти процесс: написать контракт, тесты и пройти валидацию, которая математически проверяет связность и минимальность.
20 лет назад аналитики вручную связывали требования с кодом. Матрица устаревала быстрее, чем её обновляли. Дорого, скучно, бессмысленно.
Сейчас ИИ генерирует код из формализованных требований. Трассировка создаётся автоматически как побочный продукт. Ноль ручного труда.
Rational RequisitePro требовал дополнительной работы для поддержки трассировки. Work Graph делает трассировку "условно бесплатной" — она возникает сама по себе.
Это как разница между ручным вводом данных в Excel и автоматической синхронизацией через API. Одно и то же по сути, но разная экономика усилий.
Доработайте workgraph.ru под интерфейсы, чтобы схемки не в фигджеме рисовать, а в WG сам агент это делал и получится спека для UX/UI, с информационным слоем и историей. Храните информацию не в силах, а в графе. Когда проект связан, агенту проще в нем ориентироваться.
Если коротко, то Work Graph пытается решить фундаментальную проблему AI-разработки: разрыв между намерением человека и исполнением машины.
Paperclip управляет агентами как сотрудниками, но не проверяет качество их работы.
Work Graph создаёт слой смысла (BVC-атом), связывает его с кодом, а затем может автоматически верифицировать, что код действительно реализует задуманный смысл.
Это делает Work Graph не просто трекером задач и не просто оркестратором, а инструментом формальной верификации соответствия кода намерению. И граф здесь — это не только связи между задачами, но и связи между атомами смысла (BVC) и конкретными строками кода.
У меня прямо вот каких-то знаний в проекте обычно нет, кроме как архитектуры и истории принятия решений. И под свой флоу я создал продукт Work Graph и выложил в оупенсорс. Для соло и пет-проектов очень удобно.
Юзер флоу такой: В архитектуру добавляем домены (верхний уровень архитектуры). Далее: Анализ вопроса > Выбор решения > Создание эпика/задач > Выполнение > Тестирование > Сохранение
Получился навигатор для AI-разработки.
Как будет время, напишу статью, пока руки не дошли.
250 т/с это у компоузер 2.0 ?, сейчас 2,5 вышел, и еще 2,5 Fast, он намного быстрее я игрался локально с qwen3,6-27b, и даже карту поменял на 3090Ti 24gb, но с контекстом 240 тыс скорость 2-3 т/с, чтобы не вылетало в память, нужно контекст 60 тыс ставить, тогда 10 т/с. Но после 250, а сейчас и все 1500+ т/с — эти игры быстро надоели.
Прочитал статью и комментарии — очень откликается то, что вы описываете про смешивание уровней и «мёртвые» артефакты, которые нельзя проверить сценарием.
Это BVC (Базис · Вектор · Цель) — формат атомов, специально спроектированный под работу AI-агентов. Не Excel, не ERD, не Mermaid, а именно машиночитаемый формат с жёсткой структурой.
Что там есть:
1. Типизированные профили атомов. Каждый атом имеет profile: charter, charter_section, work_item, plan, prompt_rule, trace. Это решает проблему смешивания уровней — модель не может перепутать «что есть» с «что делается» и «зачем», потому что структура атома жёсткая: Basis (контекст) → Vector (действие) → Goal (цель) + Labels (метаданные).
2. Встроенные проверки — checks. Прямо в атом можно записать массив сценариев проверки. То есть то самое «пока результат нельзя проверить сценарием, это не проектный артефакт» — вшито в формат.
3. Машиночитаемые доказательства — structuredEvidence. Массив с типами (command, test, file, change, decision, worker-run, manual-review, blocker) и статусами (succeeded, failed, pending, skipped, blocked). Это закрывает вопрос trace-связей и оснований для приёмки, который вы поднимали в ответе ASenchenko.
4. Профиль trace — отдельный тип атома для трассировки. Связывает артефакты с доказательствами.
Пример того, как выглядит ваш «резерв товара» в BVC:
#ПроцессРезервации<[
Базис:
- заказ на резервирование товара
Вектор:
- создать резерв на складе
Цель:
- гарантировать наличие товара для клиента
Метки:
profile: work_item
trace.status: pending
Проверки:
- товар существует в номенклатуре
- количество на складе >= заказанного
- статус заказа = "подтверждён"
Доказательства:
- тип: test
статус: succeeded
задача: test-reservation-001
резюме: "Проверка остатков пройдена"
]>
Что это меняет по сравнению с Excel-ядром:
Не нужно поддерживать связанные таблицы — вся предметная логика в типизированных .bvc файлах
Каждый артефакт самодостаточен: содержит и смысл, и проверки, и доказательства
LLM работает с жёсткой структурой, а не восстанавливает предметку заново
Проверка сценарием — не надстройка, а часть формата
Что остаётся за скобками BVC: BVC описывает один атом. Для бизнес-процессов нужна надстройка — граф атомов с последовательностями, ветвлениями и альтернативными маршрутами. Мы это решаем через Work Graph (граф атомов в .bvc файлах), но это уже следующий слой.
Если интересно — посмотрите спецификацию, она небольшая. Мне самому было бы полезно услышать профессиональную критику от человека, который реально мучает LLM на проектных задачах, а не просто теоретизирует.
Что могу сказать: я второй месяц собираю автономного агента на локальных LLM, в которого можно закинуть идею, а он сам бы её исследовал, расписал, согласовал, разбил на задачи и реализовал. На текущий момент Qwen 3.6-27b для агентских задач — самая продвинутая из доступных для моей 3090Ti локально. Но это всё ещё далеко от качества облачных решений типа Composer 2.0.
Хочу дополнить резюме автора своим наблюдением: одного Reviewer Agent недостаточно.
Без жесткой архитектуры это превращается в бесконечный цикл «отклонение → переделка → отклонение», который никогда не закончится, пока не иссякнет контекст или терпение.
В базе нужна действительно большая модель (уровня Kimi-k2,6), способная удерживать весь контекст проекта, плюс обязательное дообучение (LoRA) под специфические инструменты среды.
Нужен не просто Reviewer, а комплексная система оркестрации, включающая:
Детерминированный роутинг сценариев: Четкое разделение на роли (Архитектор, Инженер, Тестировщик, Дебаггер и тд), где каждая роль имеет свои права доступа к инструментам и лимиты итераций.
Верификатор как внешний арбитр: Механизм, который не доверяет словам модели, а самостоятельно запускает тесты/линтеры и принимает решение о статусе задачи (done/blocked) только на основе объективных доказательств (DoD).
Safety Kernel и Loop Guards: Жесткие ограничители, которые прерывают цикл после N неудачных попыток и автоматически эскалируют задачу на человека или меняют стратегию (например, переход от «попытки исправить» к «перепланированию»).
Память проекта в виде артефактов: Хранение контекста не в чате, а в версионируемых файлах, чтобы агент мог обращаться к истории решений, а не галлюцинировать заново.
Стратегии сжатия контекста: Автоматическое архивирование старых частей диалога в краткие резюме для освобождения места под текущую работу без потери смысла.
Контур самообучения: Автоматическое извлечение регрессионных кейсов из неудачных попыток для обновления базы знаний системы.
Сквозная индексация: Единое промежуточное представление и граф зависимостей, связывающие код, тесты, требования и правила в единую сеть. Это позволяет агенту видеть влияние изменений (если я поменяю эту функцию, какие тесты и модули затронуты?) и поддерживать трассируемость от бизнес-цели до конкретной строки кода.
Управление блокировками и конкурентным доступом: Механизм блокировки файлов и ресурсов, предотвращающий конфликты записи при параллельном выполнении задач разными ролями.
Бюджетирование и лимиты ресурсов: Контроль расхода токенов, времени GPU и стоимости операций в реальном времени с автоматической остановкой при превышении лимитов.
Мета-тестирование поведения агента: Набор адверсарных тестов специально для проверки устойчивости самой системы оркестрации к сбоям и галлюцинациям.
Объяснимость решений: Визуализация цепочки рассуждений и причин принятия решений прямо в UI (почему агент выбрал именно этот файл?).
Реакция на внешние события: Возможность автоматически создавать задачи в при внешних триггерах (падение CI, пуш в репозиторий).
Версионирование промптов и конфигураций: Хранение версий системных промптов и правил ролей в Git для возможности отката поведения агента при деградации качества.
Я тоже навайбкодил за месяц проектик, но не рвусь бежать и писать про это статьи. В чем смысл поста, не понятно. Описанный процесс вообще не похож на тот, который выработался у меня. Все лимиты этих умных гипермоделей я потратил в первую неделю, толку от них никакого, пишут кучу не того что нужно. $200 в плане ультра улетели и оставшиеся 3 недели я дописывал на компоузере 1.5, который судя по всему безлимитный, так как по графику затрат он показывал в районе $800 под конец месяца, то есть далеко за пределами самого тарифа. За этот месяц я собрал дизайн систему с компонентами на дизайн токенах. Интегрировал сторонние сервисы по геокодированию, поисковым подсказкам, отображению карт. Выстроил флоу заказчика и исполнителя. Админку для управления контентом и настройкой. Всякие там адаптеры для платежных провайдеров, цели для метрики и тому подобное. MVP еще не закончен, но если интересно, лежит тут мастерклик.рф
В классических системах требование было статичным документом, и его декомпозиция (разбить Б на С и Д) стоила колоссальных ручных усилий по перелинковке. В Work Graph требование — это исполняемый узел графа. Поэтому его рефакторинг стоит ровно столько же, сколько рефакторинг функции в коде (Extract Method): новые узлы автоматически наследуют контекст и трассировку родителя, делая эволюцию модели дешёвой и безопасной.
По неочевидным связям, которые "повышают стоимость", мы используем динамический анализ топологии AI-агентом и Compliance Gate. Если изменение одного узла создаёт семантический конфликт с другим, сборка просто падает. Так нечёткость и несовершенство модели перестают быть невидимым техдолгом, который всплывает сюрпризом в проде, и превращаются в явный "linting error", который автоматически создаёт задачу в бэклоге на доработку.
В этом и есть главная ценность. Недооценённый информационный слой (связь между требованием, графом и кодом) становится таким же тестируемым и управляемым активом системы, как и сама бизнес-логика.
Спецификации на типах в классическом стеке кажется утопией. Мы обходим это, вынося верификацию за пределы языка, в собственный слой. А код получает ровно ту типизацию, которую язык поддерживает из коробки.
У нас уровень выше — формализуем не данные, а логику и намерения.
Мы строим не контракты на данные, а контракты на исполнение правил.
ODCS описывает контракты на данные: их схему, качество, свежесть. Это про то, как данные должны выглядеть, чтобы ИИ мог им доверять.
Work Graph описывает контракты на поведение: что система должна делать, какие у этого есть предусловия и постусловия, как проверить результат. Это про то, как ИИ должен действовать, а не только что читать.
Интересный проект. Похоже, вы строите язык, где корректность встроена в конструкцию, а не добавляется сверху.
Есть параллель с WG, но мы действуем в другом порядке.
Work Graph гарантирует: спецификация корректна по структуре до того, как написан код.
Orthon гарантирует: код корректно написан по спецификации.
Согласен, нейрослоп в продакшене — зло. Но переписать руками — это как раз та самая операционная энтропия, от которой мы пытаемся избавиться.
Мы сейчас двигаемся в сторону, когда нейросеть в нашей системе вообще не генерирует код. Она генерирует только формальное описание логики (контракты).
Валидатор математически проверяет граф на полноту, отсутствие тупиков и соответствие типам. Если проверка пройдена, детерминированный компилятор превращает этот граф в чистый, типизированный код.
Нейросеть здесь выступает не как программист, а как переводчик с человеческого языка на строгий протокол. А код уже пишет машина, которая не умеет срать, потому что следует жёстким, верифицируемым правилам. По итогу у нас должен получиться протокол надежности для ИИ.
Согласен. Idris2 — отличный инструмент для верифицируемого кода, но он требует, чтобы разработчик мыслил на уровне типов.
Зависимые типы — это мощнейший инструмент, и если мы говорим о доказательстве того, что код строго соответствует спецификации, то Idris2 или Coq/Lean вне конкуренции.
Но здесь кроется нюанс, который мы и пытаемся закрыть: Idris2 доказывает корректность реализации, но не спасает от ошибок в самой спецификации. Если бизнес-аналитик или ИИ забыл описать в спецификации обработку ошибки сети или edge-case, Idris просто безупречно скомпилирует эту неполную логику. Он докажет, что код непротиворечив, но система всё равно упадет в продакшене.
Поэтому мы не пытаемся соревноваться с Idris2 в математических доказательствах — это нереально для сложных систем без команды математиков.
Мы делаем прагматичную верификацию на уровне модели. Наш валидатор проверяет не "истинность теоремы", а структурную целостность графа намерений:
Все ли узлы достижимы? (Нет ли мертвого кода)
Покрыты ли все условия? (Нет ли забытых
else)Сходятся ли типы данных между узлами? (Не передаем ли мы строку туда, где ждем число)
Нет ли логических тупиков и циклов?
Это не "доказательство корректности программы" в академическом смысле. Это детектирование очевидных архитектурных и логических дыр до того, как они превратятся в код.
Idris2 гарантирует, что вы правильно построили стену по чертежу. А Work Graph гарантирует, что на самом чертеже не забыли нарисовать дверь, прежде чем вы вообще начнете класть кирпичи. И то, и другое нужно, но это разные слои ответственности.
Следующий шаг Work Graph — стать генеративным Low-Code. Overengineering становится просто невозможным: если решение можно собрать из существующих кирпичиков — ИИ обязан использовать их, а не изобретать велосипед.
Сложность появляется только тогда, когда она действительно оправдана и чтобы создать что-то новое, ИИ должен пройти процесс: написать контракт, тесты и пройти валидацию, которая математически проверяет связность и минимальность.
20 лет назад аналитики вручную связывали требования с кодом. Матрица устаревала быстрее, чем её обновляли. Дорого, скучно, бессмысленно.
Сейчас ИИ генерирует код из формализованных требований. Трассировка создаётся автоматически как побочный продукт. Ноль ручного труда.
Rational RequisitePro требовал дополнительной работы для поддержки трассировки. Work Graph делает трассировку "условно бесплатной" — она возникает сама по себе.
Это как разница между ручным вводом данных в Excel и автоматической синхронизацией через API. Одно и то же по сути, но разная экономика усилий.
Доработайте workgraph.ru под интерфейсы, чтобы схемки не в фигджеме рисовать, а в WG сам агент это делал и получится спека для UX/UI, с информационным слоем и историей. Храните информацию не в силах, а в графе. Когда проект связан, агенту проще в нем ориентироваться.
да — длинные тире (alt+0151) я всегда сам пишу, а аналитические разборы отдаю нейронке
Если коротко, то Work Graph пытается решить фундаментальную проблему AI-разработки: разрыв между намерением человека и исполнением машины.
Paperclip управляет агентами как сотрудниками, но не проверяет качество их работы.
Work Graph создаёт слой смысла (BVC-атом), связывает его с кодом, а затем может автоматически верифицировать, что код действительно реализует задуманный смысл.
Это делает Work Graph не просто трекером задач и не просто оркестратором, а инструментом формальной верификации соответствия кода намерению. И граф здесь — это не только связи между задачами, но и связи между атомами смысла (BVC) и конкретными строками кода.
У меня прямо вот каких-то знаний в проекте обычно нет, кроме как архитектуры и истории принятия решений. И под свой флоу я создал продукт Work Graph и выложил в оупенсорс. Для соло и пет-проектов очень удобно.
Юзер флоу такой: В архитектуру добавляем домены (верхний уровень архитектуры).
Далее: Анализ вопроса > Выбор решения > Создание эпика/задач > Выполнение > Тестирование > Сохранение
Получился навигатор для AI-разработки.
Как будет время, напишу статью, пока руки не дошли.
250 т/с это у компоузер 2.0 ?, сейчас 2,5 вышел, и еще 2,5 Fast, он намного быстрее
я игрался локально с qwen3,6-27b, и даже карту поменял на 3090Ti 24gb, но с контекстом 240 тыс скорость 2-3 т/с, чтобы не вылетало в память, нужно контекст 60 тыс ставить, тогда 10 т/с. Но после 250, а сейчас и все 1500+ т/с — эти игры быстро надоели.
Какой оркестратор используете, в какой среде?
Когда наиграетесь, просто купите подписку на курсор за $200 и получите 1500 т/с, а может и больше.
Прочитал статью и комментарии — очень откликается то, что вы описываете про смешивание уровней и «мёртвые» артефакты, которые нельзя проверить сценарием.
Хочу показать одну штуку, которая, как мне кажется, закрывает ровно вашу боль: https://github.com/bvc-lang/spec
Это BVC (Базис · Вектор · Цель) — формат атомов, специально спроектированный под работу AI-агентов. Не Excel, не ERD, не Mermaid, а именно машиночитаемый формат с жёсткой структурой.
Что там есть:
1. Типизированные профили атомов. Каждый атом имеет
profile:charter,charter_section,work_item,plan,prompt_rule,trace. Это решает проблему смешивания уровней — модель не может перепутать «что есть» с «что делается» и «зачем», потому что структура атома жёсткая: Basis (контекст) → Vector (действие) → Goal (цель) + Labels (метаданные).2. Встроенные проверки —
checks. Прямо в атом можно записать массив сценариев проверки. То есть то самое «пока результат нельзя проверить сценарием, это не проектный артефакт» — вшито в формат.3. Машиночитаемые доказательства —
structuredEvidence. Массив с типами (command,test,file,change,decision,worker-run,manual-review,blocker) и статусами (succeeded,failed,pending,skipped,blocked). Это закрывает вопрос trace-связей и оснований для приёмки, который вы поднимали в ответе ASenchenko.4. Профиль
trace— отдельный тип атома для трассировки. Связывает артефакты с доказательствами.Пример того, как выглядит ваш «резерв товара» в BVC:
Что это меняет по сравнению с Excel-ядром:
Не нужно поддерживать связанные таблицы — вся предметная логика в типизированных
.bvcфайлахКаждый артефакт самодостаточен: содержит и смысл, и проверки, и доказательства
LLM работает с жёсткой структурой, а не восстанавливает предметку заново
Проверка сценарием — не надстройка, а часть формата
Что остаётся за скобками BVC: BVC описывает один атом. Для бизнес-процессов нужна надстройка — граф атомов с последовательностями, ветвлениями и альтернативными маршрутами. Мы это решаем через Work Graph (граф атомов в
.bvcфайлах), но это уже следующий слой.Если интересно — посмотрите спецификацию, она небольшая. Мне самому было бы полезно услышать профессиональную критику от человека, который реально мучает LLM на проектных задачах, а не просто теоретизирует.
Мне 9b весь код запорола, на более сложных задачах. Qwen3.6-27b себя показывает лучше чем 35b. Но это все равно рядом не стояло с облачными моделями.
так это уже давно, просто некоторые просят шифроваться стилем написания и не бросаются в глаза, как эти пункты.
Что могу сказать: я второй месяц собираю автономного агента на локальных LLM, в которого можно закинуть идею, а он сам бы её исследовал, расписал, согласовал, разбил на задачи и реализовал. На текущий момент Qwen 3.6-27b для агентских задач — самая продвинутая из доступных для моей 3090Ti локально. Но это всё ещё далеко от качества облачных решений типа Composer 2.0.
Хочу дополнить резюме автора своим наблюдением: одного Reviewer Agent недостаточно.
Без жесткой архитектуры это превращается в бесконечный цикл «отклонение → переделка → отклонение», который никогда не закончится, пока не иссякнет контекст или терпение.
В базе нужна действительно большая модель (уровня Kimi-k2,6), способная удерживать весь контекст проекта, плюс обязательное дообучение (LoRA) под специфические инструменты среды.
Нужен не просто Reviewer, а комплексная система оркестрации, включающая:
Детерминированный роутинг сценариев: Четкое разделение на роли (Архитектор, Инженер, Тестировщик, Дебаггер и тд), где каждая роль имеет свои права доступа к инструментам и лимиты итераций.
Верификатор как внешний арбитр: Механизм, который не доверяет словам модели, а самостоятельно запускает тесты/линтеры и принимает решение о статусе задачи (
done/blocked) только на основе объективных доказательств (DoD).Safety Kernel и Loop Guards: Жесткие ограничители, которые прерывают цикл после N неудачных попыток и автоматически эскалируют задачу на человека или меняют стратегию (например, переход от «попытки исправить» к «перепланированию»).
Память проекта в виде артефактов: Хранение контекста не в чате, а в версионируемых файлах, чтобы агент мог обращаться к истории решений, а не галлюцинировать заново.
Стратегии сжатия контекста: Автоматическое архивирование старых частей диалога в краткие резюме для освобождения места под текущую работу без потери смысла.
Контур самообучения: Автоматическое извлечение регрессионных кейсов из неудачных попыток для обновления базы знаний системы.
Сквозная индексация: Единое промежуточное представление и граф зависимостей, связывающие код, тесты, требования и правила в единую сеть. Это позволяет агенту видеть влияние изменений (если я поменяю эту функцию, какие тесты и модули затронуты?) и поддерживать трассируемость от бизнес-цели до конкретной строки кода.
Управление блокировками и конкурентным доступом: Механизм блокировки файлов и ресурсов, предотвращающий конфликты записи при параллельном выполнении задач разными ролями.
Бюджетирование и лимиты ресурсов: Контроль расхода токенов, времени GPU и стоимости операций в реальном времени с автоматической остановкой при превышении лимитов.
Мета-тестирование поведения агента: Набор адверсарных тестов специально для проверки устойчивости самой системы оркестрации к сбоям и галлюцинациям.
Объяснимость решений: Визуализация цепочки рассуждений и причин принятия решений прямо в UI (почему агент выбрал именно этот файл?).
Реакция на внешние события: Возможность автоматически создавать задачи в при внешних триггерах (падение CI, пуш в репозиторий).
Версионирование промптов и конфигураций: Хранение версий системных промптов и правил ролей в Git для возможности отката поведения агента при деградации качества.
Ну и там много чего еще...
Я тоже навайбкодил за месяц проектик, но не рвусь бежать и писать про это статьи. В чем смысл поста, не понятно. Описанный процесс вообще не похож на тот, который выработался у меня. Все лимиты этих умных гипермоделей я потратил в первую неделю, толку от них никакого, пишут кучу не того что нужно. $200 в плане ультра улетели и оставшиеся 3 недели я дописывал на компоузере 1.5, который судя по всему безлимитный, так как по графику затрат он показывал в районе $800 под конец месяца, то есть далеко за пределами самого тарифа. За этот месяц я собрал дизайн систему с компонентами на дизайн токенах. Интегрировал сторонние сервисы по геокодированию, поисковым подсказкам, отображению карт. Выстроил флоу заказчика и исполнителя. Админку для управления контентом и настройкой. Всякие там адаптеры для платежных провайдеров, цели для метрики и тому подобное. MVP еще не закончен, но если интересно, лежит тут мастерклик.рф
Flash, который сейчас Adobe Animate поддерживает публикацию в html5.