codemonsters.log
الذهاب إلى القناة على Telegram
| Просто рассказываю про | Научно обоснованный подход | Рациональной и качественной разработки софта @maxology
إظهار المزيد580
المشتركون
لا توجد بيانات24 ساعات
لا توجد بيانات7 أيام
+130 أيام
أرشيف المشاركات
ИМба Ин да Хаус💪
Мне бро написал
Сколько у тебя оперативки?
https://github.com/Niko1221/Strata
Niko1221 написал движок под конкретную модель для запуска на наших боярских железяках 125 билионс
Strata runs Qwen3.8-Flash-Next, a 125-billion-parameter
Вот это норм разработка на крестах от Нико (c++ для тех кто в жвм онли мире)
С Лешей обсуждали
Что qwen, deep seek порвут мир ИИ.
Я все не доберусь до kimi.
И разом вспомнили книги Кай-Фу Ли
Что я
предлагаю:
почитаем и обсудим вместе в чате к этому посту?
Что думаешь?
Через месяц можно в кафешке или онлайн потрещать пофилософствовать на тему нового мира + ИИ.
Я начал с красной и потом захватила черная;)
#читаемобсуждаем
Бро мне написал свои положительные впечатления от Qwen3.8-max и напомнил про этот кайф.
В своем эксперименте я попробовал qwen3.8-Max
Скорость и качество работы меня сильно положительно поразили ошеломили и я убежал от терминала ;)
Не удивили, а я афигел.
Пока писал это тут тебе, зародилась идея💡
Кто тестил этого монстра?
Что делал? Как результат?
Инсталлер скиллов прикольный.
In the age of AI art, what can originality look like?🙋
Я выложу видео, 🤓
ты напиши что думаешь об искусстве,
фотографии с ИИ,
если думаешь об этих вселенных.
Напиши свои мысли Про музыку с ИИ, знаю есть энтузиасты любители этих направлений человеческого + ИИ творчества.
https://www.ted.com/talks/eileen_isagon_skyers_in_the_age_of_ai_art_what_can_originality_look_like
+1
Как заметил один из отцов-основателей США, квакер-пацифист Уильям Пенн, если вокруг постоянно дуют сильные ветра, зданию нужен хороший фундамент.
С❤️🔥бираю крепость для домашней LLM.🙋
Вчера выпилил одно отверстие, чтоб встала вторая карта.
Как там твои ИИ исполняет поручения?
Фотография Хельмута Ньютона, великого fashion-фотографа, для американского Vogue 2002.
Читал его автобиографию и считаю его работы яркими высказываниями несмотря на объективизацию
Как ИИ стремительно умнеет
Фантастический мир. Создавать продукты стало невероятно интересно — с опорой на экспертизу и фантазию.
Просто переворачиваются индустрии.
Клипмейкерство, имиджмейкерство, software engineering, создание музыки — всё это становится проще.
И при этом как много будет порождено некомпетентного и поспешного спама!
Мне кажется, всё больше будет цениться ручной труд. Керамика, например.
Что же будет с человеческим крафтом? Или умный ИИ будет делать крафт из человеческих мешков?) (10% вероятность есть)
Смотри, какая красота.
Коммит: Human Gate 1.
Что сделал Харнес?
Оператору нужно принять дизайн и план работ.
Тикеты мне тоже нравятся.
Gate 1:
Проверка плана работ. В ветке содержание работы.
https://github.com/codemonstersteam/pinout-openapi/tree/docs/concept-mechanism-consistency
Изначально была задача:
https://github.com/codemonstersteam/pinout-openapi/blob/docs/concept-mechanism-consistency/TASK.md
Проработка идеи:
https://github.com/codemonstersteam/pinout-openapi/blob/docs/concept-mechanism-consistency/docs/CONCEPT.md
Далее эмуляция и вывод алгоритма, чтобы понять, как это будет работать и будет ли работать:
https://github.com/codemonstersteam/pinout-openapi/blob/docs/concept-mechanism-consistency/sandbox/ALGORITHM.md
Попросил машину провести эксперимент, чтобы убедиться, что идея и процесс рабочие.
#codemonsterslog
Привет!
Подготовил интересные материалы, которые помогут тебе отправиться в невероятное и увлекательное путешествие в разработку AI-агентов.
Сразу бросилась в глаза модульность — прямо как в 70-х рекомендовали отцы-основатели из IBM: головной модуль и подчинённые.
Эта дисциплина прекрасно ложится в проектирование и реализацию с тестами в агентском режиме
Понравилось, что с гардрейлами получилось организовать процесс работы агента и субагентов по заданному алгоритму и держать творческую вариативность в узде.
Одна ответственность,
малый консистентный контекст,
чёткие контракты в сообщениях:
что на вход, что на выход —
с контролем входных и выходных данных.
The anatomy of a skill.
И получается фантастическое изделие из конечных и вариативных автоматов.
Ссылки:
Architecture Patterns and
Implementation Frameworks
A practical guide to building agents
Мех и человеческие проверки:
1. Гардрэйлс (хуки, live-блок) — harness/enforcement/ + чистая логика shared.mjs:
- claude → PreToolUse/PostToolUse хуки; opencode → TS-плагин tool.execute.before/after
- enforce: closed-set роутинг, фронтдор (@gilb первый), Gate #1 (реализатор заблокирован без plan-review.md+gate1.approved), decisions.log
- exit 2 = блок, без участия модели; fail-open на инфра-сбое
2. Валидаторы (DoD-гейты) — 15× validate-*.mjs (plan/tickets/dod/readme/mermaid/slices/constructors/contract-frozen/…); вызывают роли + CI; детерминированно, без LLM
3. Человеческие гейты — маркеры .agent/gates/ (#1 план, #2 мерж, #3 канарейка), ставит оператор
Евалс (eval-run/eval-judge.mjs) — не контроль, а пост-хок оценка прогона (A/B).
Суть: контроль = хук + детерминированный чек, а не проза-инструкция («проза не держит — держит хук»).
GL HF DD
#codemonsterslog
⬆️Разработал инструмент, который реализует четкий конвейер разработки API сервиса на Go или CLI.
Этот инструмент делает то, что мне нужно по требованию, единообразно, четко и правильно, следуя научному подходу, а не просто потому, что так принято в интернете или на GitHub.
Пришла пора писать видосы.
https://github.com/codemonstersteam/rationaldev-ai-sdlc-skills
Результат работы workflow:
https://github.com/codemonstersteam/pinout-openapi/tree/main
Сам harness, я и тестирую, и провел уже сотни тестов на золотой задаче создания сервиса.
Тестил в том числе на glm 5.2, qwen 3.6-2.6b
Важно:
Еще много работы и улучшений
Но процесс предсказуемый с единообразными артефактами
#codemonsterslog
Тестирую workflow по разработке сервиса.
Задачу перед собой поставил такую: хочу, чтобы агент или связка агентов:
1. Прожаривал требования;
2. Отдавал их агенту, и тот по постановке решал задачу согласно прописанному фреймворку и требованиям к архитектуре и качеству.
В результате двух недель экспериментов с golden task workflow подход работает стабильно.
В экспериментах используются GLM 5.2 для проработки плана, архитектуры и нарезки тикетов, а Qwen3.6‑27b — для реализации тикетов.
Вывод:
С вариативными GPT workflow прекрасно работает. Это конвейер где синтетическое творчество варится в дисциплине и четкой последовательности действий.
Я не могу пока раздувать вывод эмоциональным всплеском ;))
2 недели
20+ прогонов
Несколько поздних ночных сессий.
Результат меня удовлетворяет, узнал много нового.
Вывод 2: эксперименты очень важны, экспериментируй и воплощай то, что тебе очень интересно.
#codemonsterslog #ai #agents
+1
Навёл порядок в скилл-харнесе для рационального SDLC с ИИ.
Что сделал:
🔹 Оптимизировал все 18 скиллов — привёл каждый к ≤300 строкам.
Часть со временем разбухла; вырезал дубли и воду, правила свёл к нормативным.
Суть не потерял — гейты, формулы, чеклисты на месте.
🔹 Перевёл на английский. Не из эстетики — по замерам экономит токены (−29% по набору, 63k → 45k).
Английский плотнее в токенайзере, а скилл-нагрузка грузится в каждый вызов роли.
🔹 Заострил роль планировщика — добавил сбор требований. Раньше дизайн стартовал «от одной фразы».
Теперь есть фронт requirements-intake:
бизнес-требование → функциональные требования (use-cases по Кокберну), акторы, интерфейсы, контракт API, карта отказов.
Спрашиваешь харнес «с чего начать?» в пустом проекте — он ведёт именно сюда.
По-моему, вышло достойно.
https://github.com/codemonstersteam/rationaldev-ai-sdlc-skills
Собираю все скиллы в удобный пак
заодно решил проверить какой будет эффект при переводе на английский
тесты показали - эффект будет положительный
#codemonsterslog
🙏Собрал развернутое саммари сессии митапа
🔌 pinout: спроектировали валидатор OpenAPI-контрактов и попутно прокачали свои скиллы разработки
На этой сессии проектировали инструмент, который на pre-merge стадии в CI проверяет, что потребитель REST-сервиса совместим с
прод-контрактом поставщика — сравнением их OpenAPI-спек. Без генерации клиентских либ, без подъёма заглушек: чистая функция
«спека vs спека».
🔗 Экосистема: https://github.com/codemonstersteam/pinout
🔗 Сам валидатор: https://github.com/codemonstersteam/pinout-openapi
Что зацепило больше всего
📐 Системные use case по Коберну.
Оказалось, что fully-dressed use case (акторы, предусловия, основной сценарий, extensions =
режимы отказа, гарантии/exit) — это не «бумажка для галочки», а рабочая спецификация. Структура use case изоморфна Gherkin: Main
Success → happy-тест, каждый Extension → один сценарий отказа. Формула сошлась сама собой: N сценариев = 1 + число extensions.
🗺 C4 как уровни дизайна. Разложили проект по уровням C4 на Mermaid (рендерится прямо в GitHub):
• C1 (контекст экосистемы) — в концепт-репо
• C2 + C3 (контейнер + дерево модулей) — в компоненте
• C4 = тот самый системный use case «как работает программа»
📄 Живой пример: https://github.com/codemonstersteam/pinout-openapi/blob/main/docs/design/contract-validate/c4.md
Главный инсайт — это всё прошивается в систему
Получилась сквозная трассировка:
use case (Cockburn)
→ вертикальный слайс
→ компонентный тест
→ узлы графа контрактов.
1 слайс = 1 внешний вход = 1 use case.
Ничего не выдумывается из кода — каждый компонентный тест выводится из соответствующего extension use case, с двусторонней сверкой (нет extension без теста и нет теста без extension).
Как мы доработали скиллы разработки
По следам сессии внесли правки прямо в процедуры скиллов (не в «когда-нибудь потом»):
✅ documentation — обязательные C4-диаграммы по уровням, системный use case как C4-уровень, таблица сбоев в README, gate:
документация только по скиллу (никакой свободной прозы мимо процедур)
✅ program-design — C4 по уровням, модель ошибок (коды → exit, «деградация видна, не маскируется под успех»), трассировка
UC→слайс→тест, conformance-gate (STOP перед хендоффом)
✅ component-tests — режимы отказа берутся из extensions use case
✅ роль plan-reviewer — асимметричная проверка соответствия дизайна скиллу
Плюс зашили несколько жёстких правил в скилл проектирования:
• Один внешний вход = один Request. Все параметры (включая флаги CLI) собираются в единый Request; флаг — это поле Request, а не
отдельный аргумент или «прокинутый сбоку» io.Writer. Внешний ввод парсится только в адаптере.
• Развилки по флагам — это юниты, а не компонентные тесты. Выбор «куда писать» (--out) и «в каком формате» (--format)
оформляется чистой функцией (resolveDestination, renderReport) и покрывается юнит-тестами. В компонентные сценарии идёт только
режим отказа записи — иначе матрица stdout/файл × json/md раздувает число сценариев.
• Запрет «тестового» второго метода I/O (WriteTo(io.Writer) рядом с боевым Write) — решение выносится в логику, лишний шов не
заводится.
Вывод сессии: use case по Коберну + C4 + вертикальные слайсы — это один связный конвейер, а не три отдельные практики. Когда они
сшиты, дизайн перестаёт расходиться с тестами и кодом by design.
#codemonstersvlog #разработка #архитектура #C4 #UseCase #OpenAPI
+6
🛠 На митапе:
— Спроектировали pinout-openapi (C4: С1 в pinout, C2-C3 — в openapi).
— Обновили README.
— Гульнара помогла с Use Case'ами (Cockburn), документация стала чётче.
⚠️ Выявили риски со сборкой OpenApi и $ref — вынесли в таблицу. Решили не усложнять, сначала проверим в деле.
📌 План: допрограммируем по дизайну, на след. митапе (вторник) протестируем на проекте.
Получилось достойно. Давно собирался затащить c4.
Скиллы доработаны 🧸
👋 Что ещё улучшить? Пишите в комментариях.
Погнали https://telemost.yandex.ru/j/8669013602
🔧 Чем займёмся:
· Продолжим пилить инструменты Pinout — погружаемся глубже.
Спроектируем тулзу pinout-openapi и обсудим концепт.
Посмотрим как харнес поможет спроектировать то, что нужно.
· Живое общение: отвечу на ваши вопросы, обсудим идеи.
