Следуя советам Никиты @buckwheat_thoughts прокачал гиперпараметры обучения модели ruGPT3XL-8k, оказалось все мои прошлые попытки не маскировали инпут, а большой LR и прочие параметры приводили к оверфиту, теперь прогресс идёт намного стабильнее. Однако, это привело к увеличению времени обучения со 100 часов до 240, но лучше дольше чем неправильно.
(не пугаемся высокому train loss, из-за fsdp тренер пишет кривые числа, делим их на 32)
Помимо этого благодаря советам Александра @dealerAI смог ускорить процесс в почти 4 раза запустив обучение через FSDP (скрипт train_rugpt3xl_fsdp.py), все видеокарты загружены на максимум, время обучения снизилось с 240 часов до 42-46.
Плюс разобрался с тем как сделать "весёлые картинки", для этого внутри контейнера поставил и поднял tensorboard, и настроил тренер чтобы он писал логи куда надо.
Вот каждый раз убеждаюсь, что самый лучший способ научиться чему-то новому это заявить публично какую-то спорную мысль, а потом мотать на ус советы более умных товарищей.
(не пугаемся высокому train loss, из-за fsdp тренер пишет кривые числа, делим их на 32)
Помимо этого благодаря советам Александра @dealerAI смог ускорить процесс в почти 4 раза запустив обучение через FSDP (скрипт train_rugpt3xl_fsdp.py), все видеокарты загружены на максимум, время обучения снизилось с 240 часов до 42-46.
Плюс разобрался с тем как сделать "весёлые картинки", для этого внутри контейнера поставил и поднял tensorboard, и настроил тренер чтобы он писал логи куда надо.
Вот каждый раз убеждаюсь, что самый лучший способ научиться чему-то новому это заявить публично какую-то спорную мысль, а потом мотать на ус советы более умных товарищей.
👍20❤6🤝3🔥2
Forwarded from Валера Ковальский
Ребят в CodeDash появился лидерборд!
Зачем?
1) Интересно узнать на сколько вы отличаетесь от других вайбкодеров
2) Можно найти друзей по цэху и написать им через github
3) Можно поискать что же за проекты пилит автор если он их выкладывает в open-source
4) Можно поискать и хантить себе вайберов если вы поняли о чем я =)
5) Просто по фану измерить примерно сколько у вас всм запросов на фоне других вайберов
В общем качайте новую версию
Синхронизируйте Github и регистрируйтесь в лидерборде!
Зачем?
1) Интересно узнать на сколько вы отличаетесь от других вайбкодеров
2) Можно найти друзей по цэху и написать им через github
3) Можно поискать что же за проекты пилит автор если он их выкладывает в open-source
4) Можно поискать и хантить себе вайберов если вы поняли о чем я =)
5) Просто по фану измерить примерно сколько у вас в
В общем качайте новую версию
codedash update && codedash restart
Синхронизируйте Github и регистрируйтесь в лидерборде!
👍9🔥4💩2🤡2❤1🤝1💊1
Pavel Zloi
Следуя советам Никиты @buckwheat_thoughts прокачал гиперпараметры обучения модели ruGPT3XL-8k, оказалось все мои прошлые попытки не маскировали инпут, а большой LR и прочие параметры приводили к оверфиту, теперь прогресс идёт намного стабильнее. Однако, это…
Обучение ruGPT3XL-8k на ризонинг и агентных датасетах продолжается и судя по eval_loss на 500 шаге тренировка прошла свой предел точности, дальше походу начался оверфит.
Чепоинты эти я уже скопировал в отдельную папку, они нарезаны на шарды из-за особенностей FSDP, но сшить их не проблема, если eval_loss и дальше будет ухудшаться то стопорну тренировку и выкачу 500й чекпоинт.
Единственный нюанс который мне кажется странным в том, что eval/mean_token_accuracy даже на 550 продолжает улучшаться, хотя по логике не должен, но подожду до 650го шага, если там eval_loss сильно пойдёт вверх то на mean_token_accuracy смотреть смысла не будет.
Чепоинты эти я уже скопировал в отдельную папку, они нарезаны на шарды из-за особенностей FSDP, но сшить их не проблема, если eval_loss и дальше будет ухудшаться то стопорну тренировку и выкачу 500й чекпоинт.
Единственный нюанс который мне кажется странным в том, что eval/mean_token_accuracy даже на 550 продолжает улучшаться, хотя по логике не должен, но подожду до 650го шага, если там eval_loss сильно пойдёт вверх то на mean_token_accuracy смотреть смысла не будет.
🔥11👍4❤2🥱1
Вайб-дизайн Starterkit
18 марта 2026 года Google выкатили стандарт DESIGN.md (прототип которого они тизерили ещё в мае 25го года), если кратко, то это такой хитрый markdown-файл для переноса и импорта общих правил оформления дизайна между проектами и инструментами.
Поддержка данного стандарта уже начала расползаться по агентному стеку, у Google есть отдельный репозиторий stitch-skills, где прямо указана совместимость со Stitch MCP и агентами вроде Gemini CLI, Claude Code и Cursor, параллельно с этим вокруг формата уже вырос внешний зоопарк инструментов и гайдов, например designmd.app отдельно пишет про сценарии для Claude Code, Cursor, Kiro, Windsurf и Cline.
DESIGN.md это AGENTS.md, только для UI
Когда мы обсуждали вайбкодерский starterkit для агентов, речь в основном шла про то, как агент должен выполнять работу кодом.
Какие команды запускать.
Какой архитектуры придерживаться.
Какие практики в проекте обязательны.
Чего делать нельзя, а что можно.
В какой последовательности.
То есть AGENTS.md, CLAUDE.md, Cursor Rules и прочие файлы такого рода обычно отвечают на вопрос "как агент должен делать код?".
А вот DESIGN.md отвечает уже на более абстрактный вопрос - "как агент должен делать интерфейс приложения?".
Что внутри DESIGN.md
В официальной идее Google и в уже появившихся примерах вокруг формата почти всегда повторяется один и тот же каркас:
- общее описание визуального характера продукта
- цветовая палитра и роли цветов
- правила типографики
- отступы и layout-принципы
- оформление базовых компонентов
- ограничения и анти-паттерны
Я ещё добавляю всякие хекс коды, размеры отступов, названия CSS фреймворков и тому подобные моменты, плюс в Cursor это хорошо ложится в общий свод правил .cursor/rules/ (можно например создать подпапку design), так как один общий файл для описания стиля всего со временем будет перегружен.
Простейший пример
Вот совсем примитивный DESIGN.md, которого уже достаточно, чтобы агент не улетел в рандом, взял его из официальной доки на сайте Stitch:
На вид ничего необычного, те же правила, вид сбоку, но для агента это уже огромный шаг от "сделай красиво" к "вот конкретный визуальный стандарт, в рамках которого нужно работать".
Послесловие
Уже есть реп awesome-design-md, в нём собрана хорошая обновляемая подборочка материалов на эту тему, надеюсь она вам тоже пригодится.
18 марта 2026 года Google выкатили стандарт DESIGN.md (прототип которого они тизерили ещё в мае 25го года), если кратко, то это такой хитрый markdown-файл для переноса и импорта общих правил оформления дизайна между проектами и инструментами.
Поддержка данного стандарта уже начала расползаться по агентному стеку, у Google есть отдельный репозиторий stitch-skills, где прямо указана совместимость со Stitch MCP и агентами вроде Gemini CLI, Claude Code и Cursor, параллельно с этим вокруг формата уже вырос внешний зоопарк инструментов и гайдов, например designmd.app отдельно пишет про сценарии для Claude Code, Cursor, Kiro, Windsurf и Cline.
DESIGN.md это AGENTS.md, только для UI
Когда мы обсуждали вайбкодерский starterkit для агентов, речь в основном шла про то, как агент должен выполнять работу кодом.
Какие команды запускать.
Какой архитектуры придерживаться.
Какие практики в проекте обязательны.
Чего делать нельзя, а что можно.
В какой последовательности.
То есть AGENTS.md, CLAUDE.md, Cursor Rules и прочие файлы такого рода обычно отвечают на вопрос "как агент должен делать код?".
А вот DESIGN.md отвечает уже на более абстрактный вопрос - "как агент должен делать интерфейс приложения?".
Что внутри DESIGN.md
В официальной идее Google и в уже появившихся примерах вокруг формата почти всегда повторяется один и тот же каркас:
- общее описание визуального характера продукта
- цветовая палитра и роли цветов
- правила типографики
- отступы и layout-принципы
- оформление базовых компонентов
- ограничения и анти-паттерны
Я ещё добавляю всякие хекс коды, размеры отступов, названия CSS фреймворков и тому подобные моменты, плюс в Cursor это хорошо ложится в общий свод правил .cursor/rules/ (можно например создать подпапку design), так как один общий файл для описания стиля всего со временем будет перегружен.
Простейший пример
Вот совсем примитивный DESIGN.md, которого уже достаточно, чтобы агент не улетел в рандом, взял его из официальной доки на сайте Stitch:
# Design System
## Overview
Calm, minimal interface for a SaaS dashboard.
High information density, but without visual noise.
The UI should feel professional, neutral, and slightly premium.
## Colors
- Primary (#2563EB) - primary actions, links, active states
- Surface (#FFFFFF) - main cards and panels
- Background (#F8FAFC) - app background
- Text Primary (#0F172A) - main text
- Text Secondary (#475569) - secondary text
- Border (#E2E8F0) - separators and input borders
- Danger (#DC2626) - destructive actions and errors
## Typography
- Headings - Inter, semibold
- Body - Inter, regular, 14px to 16px
- Small text - Inter, regular, 12px to 13px
- Use tight, readable hierarchy without oversized headings
## Spacing
- Use 8px spacing scale
- Cards should have generous inner padding
- Avoid cramped layouts, but keep density suitable for dashboards
## Components
- Buttons - medium rounding, filled primary for main CTA
- Inputs - light background, 1px border, no heavy shadows
- Cards - subtle border, soft shadow, clean flat surfaces
- Modals - centered, compact, clear action hierarchy
## Do's
- Keep layouts clean and structured
- Use primary color sparingly
- Prefer subtle contrast over aggressive accenting
## Don'ts
- Do not mix multiple accent colors
- Do not use glassmorphism
- Do not use oversized radii
- Do not make the UI look playful
На вид ничего необычного, те же правила, вид сбоку, но для агента это уже огромный шаг от "сделай красиво" к "вот конкретный визуальный стандарт, в рамках которого нужно работать".
Послесловие
Уже есть реп awesome-design-md, в нём собрана хорошая обновляемая подборочка материалов на эту тему, надеюсь она вам тоже пригодится.
🔥16👍9❤7
huggingface.co
evilfreelancer/ruGPT3XL-8k-v1-thinking · Hugging Face
We’re on a journey to advance and democratize artificial intelligence through open source and open science.
Ну чтож, обучение модели закончилось на 963 шаге, по предварительным тестам модель уловила шаблон выполнения ризонинга и даже частично логику работы с тулами, но забыла как говорить на русском языке и стала очень быстро уходить в галлюцинации и repetition loop, тут скрипт тестов, вот тут можно посмотреть отчёты, а тут будут веса адаптера.
Эксперимент судя по всему не удался, но зато получилось собрать набор скриптов и кучу шишек набить. вероятно основная причина неудачи в том что у меня был очень кривой пайплайн обучения и надо над ним больше времени провести, плюс модель маленькая и заточена под небольшой контекст и любые мои попытки контекст увеличить сводят модель с ума, или я как-то неправильно через chat_template составил датасет обучения.
В любом случае ещё попробую потестировать ранние адаптеры, может быть там будет результат получше.
UPD. Ну а пока проект ставлю на паузу, хочется заняться чем-нибудь другим, была ещё идея сделать дистил толстушки GigaChat на ruGPT3XL, но это уже как-нибудь потом.
Эксперимент судя по всему не удался, но зато получилось собрать набор скриптов и кучу шишек набить. вероятно основная причина неудачи в том что у меня был очень кривой пайплайн обучения и надо над ним больше времени провести, плюс модель маленькая и заточена под небольшой контекст и любые мои попытки контекст увеличить сводят модель с ума, или я как-то неправильно через chat_template составил датасет обучения.
В любом случае ещё попробую потестировать ранние адаптеры, может быть там будет результат получше.
UPD. Ну а пока проект ставлю на паузу, хочется заняться чем-нибудь другим, была ещё идея сделать дистил толстушки GigaChat на ruGPT3XL, но это уже как-нибудь потом.
🔥22👍10👏7
Утром тесты, вечером код
Продолжаю делать заметки на полях о тонкостях работы с кодовыми агентами.
Почему я так много внимания уделяю методологиям BDD и TDD, и всегда пишу, что тесты важны и что кодовому агенту тесты стоит генерировать перед кодом?
Дело в том, что из-за особенностей механизма внимания большие языковые модели (LLM) лучше "помнят" информацию, которая находится в контексте ближе к тому, о чём идёт речь прямо сейчас, и "забывает" то, что было в самом начале диалога.
Поэтому в кейсе типа "сначала код, потом тесты", если агент написал какой-то кривой или нерабочий код, он с большей вероятностью будет пытаться подогнать тесты под этот кривой код, нежели пытаться исправить его, потому как уже мог запамятовать о чём там была речь. На тесты обычно нужно совсем мало контекста, и пока контекст модельки ещё "свежий" и не успел ещё слишком переполниться моделька концентрирует своё внимание на нём, а если писать тесты после кода и, например, преодолеть пару суммаризацией, моделька уже может забыть, что она делала и как. Поэтому прогонка тестов после генерации кода позволяет нам заставить агента исправлять кривой код до тех пор пока тесты не пройдут.
Плюс важный нюанс, вся эта пляска вокруг спецификации, документации и тестов перед началом генерации - это своего рода "рефлексия" модели, которая более точно настраивает её на нужный результат, потому что если модели сразу доверить писать код, она проявляет слишком много фантазии, а если предоставить спецификации и тесты, то полёт её фантазии намного точнее концентрируется на решении конкретной проблемы.
Вы можете проверить эту концепцию на нескольких разных моделях, обычно запросы выглядят так:
Но если вы скажете модели перед реализацией фичи что-то типа:
Результат, который получается у агента через разные модели, будет очень похожим, чем когда мы просто описываем фичу.
Агенту важно объяснить не только "что надо делать", но ещё и "как надо делать", тогда и результат будет стабильным и предсказуемым.
Продолжаю делать заметки на полях о тонкостях работы с кодовыми агентами.
Почему я так много внимания уделяю методологиям BDD и TDD, и всегда пишу, что тесты важны и что кодовому агенту тесты стоит генерировать перед кодом?
Дело в том, что из-за особенностей механизма внимания большие языковые модели (LLM) лучше "помнят" информацию, которая находится в контексте ближе к тому, о чём идёт речь прямо сейчас, и "забывает" то, что было в самом начале диалога.
Поэтому в кейсе типа "сначала код, потом тесты", если агент написал какой-то кривой или нерабочий код, он с большей вероятностью будет пытаться подогнать тесты под этот кривой код, нежели пытаться исправить его, потому как уже мог запамятовать о чём там была речь. На тесты обычно нужно совсем мало контекста, и пока контекст модельки ещё "свежий" и не успел ещё слишком переполниться моделька концентрирует своё внимание на нём, а если писать тесты после кода и, например, преодолеть пару суммаризацией, моделька уже может забыть, что она делала и как. Поэтому прогонка тестов после генерации кода позволяет нам заставить агента исправлять кривой код до тех пор пока тесты не пройдут.
Плюс важный нюанс, вся эта пляска вокруг спецификации, документации и тестов перед началом генерации - это своего рода "рефлексия" модели, которая более точно настраивает её на нужный результат, потому что если модели сразу доверить писать код, она проявляет слишком много фантазии, а если предоставить спецификации и тесты, то полёт её фантазии намного точнее концентрируется на решении конкретной проблемы.
Вы можете проверить эту концепцию на нескольких разных моделях, обычно запросы выглядят так:
<спецификации фичи>
Но если вы скажете модели перед реализацией фичи что-то типа:
изучи код, документацию и тесты, потом напиши тесты новой фичи, убедись что они падают, потом напиши код фичи, потом убедись что тесты проходят, потом проверь все остальные тесты
<спецификации фичи>
Результат, который получается у агента через разные модели, будет очень похожим, чем когда мы просто описываем фичу.
Агенту важно объяснить не только "что надо делать", но ещё и "как надо делать", тогда и результат будет стабильным и предсказуемым.
1🔥23👍8❤6❤🔥1
Pavel Zloi pinned «Когда поднимут цены на ИИ Недавно мне пришлось оказаться на одной лекции, имен называть не буду, но общий настрой выступления можно описать так - человеку показали Claude Code, после чего он искренне поверил, что теперь "бизнесом можно управлять через ИИ"…»
Скилов много, оркестрации мало
Последнее время только и слышу у себя в информационном пузыре разговоры про skills. Сделайте skill на ревью, skill на деплой, skill на парсинг, skill на тесты, skill на документацию. Идея в целом годная, под небольшую задачу пилим небольшой skill с понятным триггером, коротким
Но чем дольше смотришь на такие системы, тем сильнее ощущение, что разговор про skills застрял на уровне отдельных кирпичиков, тогда как сама проблема уже давно находится этажом выше. В реальной работе задача почти никогда не равна одному skill. Нормальный инженерный процесс это сначала собрать контекст, потом выбрать режим работы, потом проверить спецификацию, потом написать или обновить тесты, потом сделать код, потом прогнать валидацию, потом на ошибке уйти в запасной сценарий, а иногда ещё и поднять второго агента на узкий участок.
Ну или чем Гейтс не шутит, собрать рой агентиков для решения одной большой задачи, а дальше каждому актору раздать небольшие задачки и спокойно идти спать/гулять/дебоширить.
И вот в этот момент становится видно, что сам по себе skill уже не является конечной сущностью. Он становится всего лишь одной операцией внутри более крупного маршрута. Отдельный skill умеет сделать шаг. Но бизнес-ценность появляется не в момент, когда агент умеет шаг, а в момент, когда он надёжно проходит всю цепочку шагов до проверенного результата.
Мы можем решать эту задачу разными путями, мой любимый - большие и подробные спецификации, плюс щепотка тестов.
Но как по мне так подход "одна задача - один skill" уже либо устарел, либо вот-вот упрётся в потолок, и не потому, что skills плохие и не нужны, скорее наоборот, хорошие skills очень нужны. Но центр тяжести смещается. Важен уже не только сам skill, а то, кто, когда и при каких условиях его вызывает.
По сути это не один большой skill, который пытается вместить в себя всё, а коллекция маленьких skills со скриптами, шаблонами, reference-файлами и жёстко очерченными границами ответственности. Один skill собирает контекст. Другой читает спецификации. Третий пишет тесты. Четвёртый запускает проверки. Пятый делает ревью результата. Шестой оформляет итог.
А сверху лежит ещё один слой (тот самый оркестратор), где явно описано, в какой последовательности всё это вызывать, какие параметры передавать дальше, что считать успехом, где делать паузу для подтверждения, и какой fallback включать, если один из шагов не сработал.
Эта история как по мне отлично ложится на рой агентов и позволяет делать сложные многоступенчатые задачи (само собой разделённые на небольшие атомарные этапы) при этом не терять контекст и обходить самое главное ограничение модели связанное с механизмами внимания моделей.
И вот такой подход, как мне кажется, намного ближе к будущему агентных систем, чем бесконечное наращивание папки со skills. Skill сам по себе никуда не исчезает. Просто он перестаёт быть главной сущностью. Skill становится модулем. А главной сущностью становится оркестрация.
Последнее время только и слышу у себя в информационном пузыре разговоры про skills. Сделайте skill на ревью, skill на деплой, skill на парсинг, skill на тесты, skill на документацию. Идея в целом годная, под небольшую задачу пилим небольшой skill с понятным триггером, коротким
SKILL.md, парой reference-файлов и скриптами, такая постановка задачи действительно помогает агенту меньше фантазировать и чаще попадать в нужный флоу. Особенно когда такой skill вырос не из абстракции, а из реальной боевой задачи, реальных фейлов и реальных исправлений, типа вот я сижу пилякаю какую-нибудь штукенцию и хочу на будущее её автоматизировать.Но чем дольше смотришь на такие системы, тем сильнее ощущение, что разговор про skills застрял на уровне отдельных кирпичиков, тогда как сама проблема уже давно находится этажом выше. В реальной работе задача почти никогда не равна одному skill. Нормальный инженерный процесс это сначала собрать контекст, потом выбрать режим работы, потом проверить спецификацию, потом написать или обновить тесты, потом сделать код, потом прогнать валидацию, потом на ошибке уйти в запасной сценарий, а иногда ещё и поднять второго агента на узкий участок.
Ну или чем Гейтс не шутит, собрать рой агентиков для решения одной большой задачи, а дальше каждому актору раздать небольшие задачки и спокойно идти спать/гулять/дебоширить.
И вот в этот момент становится видно, что сам по себе skill уже не является конечной сущностью. Он становится всего лишь одной операцией внутри более крупного маршрута. Отдельный skill умеет сделать шаг. Но бизнес-ценность появляется не в момент, когда агент умеет шаг, а в момент, когда он надёжно проходит всю цепочку шагов до проверенного результата.
Мы можем решать эту задачу разными путями, мой любимый - большие и подробные спецификации, плюс щепотка тестов.
Но как по мне так подход "одна задача - один skill" уже либо устарел, либо вот-вот упрётся в потолок, и не потому, что skills плохие и не нужны, скорее наоборот, хорошие skills очень нужны. Но центр тяжести смещается. Важен уже не только сам skill, а то, кто, когда и при каких условиях его вызывает.
Отсюда и появляется более интересная конструкция, которую я бы назвал скил-оркестратором или если хотите каскад скилов, по аналогии с каскадом классификаторов.
По сути это не один большой skill, который пытается вместить в себя всё, а коллекция маленьких skills со скриптами, шаблонами, reference-файлами и жёстко очерченными границами ответственности. Один skill собирает контекст. Другой читает спецификации. Третий пишет тесты. Четвёртый запускает проверки. Пятый делает ревью результата. Шестой оформляет итог.
А сверху лежит ещё один слой (тот самый оркестратор), где явно описано, в какой последовательности всё это вызывать, какие параметры передавать дальше, что считать успехом, где делать паузу для подтверждения, и какой fallback включать, если один из шагов не сработал.
Эта история как по мне отлично ложится на рой агентов и позволяет делать сложные многоступенчатые задачи (само собой разделённые на небольшие атомарные этапы) при этом не терять контекст и обходить самое главное ограничение модели связанное с механизмами внимания моделей.
И вот такой подход, как мне кажется, намного ближе к будущему агентных систем, чем бесконечное наращивание папки со skills. Skill сам по себе никуда не исчезает. Просто он перестаёт быть главной сущностью. Skill становится модулем. А главной сущностью становится оркестрация.
👍20❤6💯6🥴1
Forwarded from Тимур Хахалев про AI Coding
CLI Creator Skill
Тут ребятки из openai вчера релизнули новый curated skill — CLI Creator
Skill уже добавлен в Codex App
Он позволяет создать cli + skill для вашей рутины из имеющихся: API docs, OpenAPI JSON, SDK docs, curl examples, browser app, existing internal script, article, or working shell history.
Звучит потрясающе!
Я уже пошёл и проверил на себе. У меня был skill, который ходил в мой сервис по api (через curl + api key) и доставал read only инфу.
Сейчас попросил gpt создать cli версию этого инструмента.
Мы с ним обсудили то, как это будет выглядеть, добавили апдейтов (skill немного отставал) и с помощью моего planact реализовали задачу за 1.5 часа. Всё работает прекрасно!
Напоминаю, что главная идея такой связки cli+skill состоит в том, чтобы дать вашему кодинговому агенту доступ к вашему любимому сервису.
Юзкейс может быть, к примеру, такой: "Ок, агент, сколько пользователей у нас сегодня зарегистрировалось с параметром %PARAM%?". Агент подтягивает этот созданный skill, далее использует CLI, идёт в ваш сервис, тянет инфу и отвечает на ваш вопрос.
Так что если у вас есть какие-то процессы, которые можно так упаковать, то 100% рекомендую это сделать!
Кстати, этот skill является продолжением идеи Валеры и Паши — openapi-to-cli, инструмент который генерирует cli из вашего openapi. Кому актуально — тоже рекомендую!
#aicoding@the_ai_architect
Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь!
Тут ребятки из openai вчера релизнули новый curated skill — CLI Creator
Skill уже добавлен в Codex App
Он позволяет создать cli + skill для вашей рутины из имеющихся: API docs, OpenAPI JSON, SDK docs, curl examples, browser app, existing internal script, article, or working shell history.
Звучит потрясающе!
Я уже пошёл и проверил на себе. У меня был skill, который ходил в мой сервис по api (через curl + api key) и доставал read only инфу.
Сейчас попросил gpt создать cli версию этого инструмента.
Мы с ним обсудили то, как это будет выглядеть, добавили апдейтов (skill немного отставал) и с помощью моего planact реализовали задачу за 1.5 часа. Всё работает прекрасно!
Напоминаю, что главная идея такой связки cli+skill состоит в том, чтобы дать вашему кодинговому агенту доступ к вашему любимому сервису.
Юзкейс может быть, к примеру, такой: "Ок, агент, сколько пользователей у нас сегодня зарегистрировалось с параметром %PARAM%?". Агент подтягивает этот созданный skill, далее использует CLI, идёт в ваш сервис, тянет инфу и отвечает на ваш вопрос.
Так что если у вас есть какие-то процессы, которые можно так упаковать, то 100% рекомендую это сделать!
Кстати, этот skill является продолжением идеи Валеры и Паши — openapi-to-cli, инструмент который генерирует cli из вашего openapi. Кому актуально — тоже рекомендую!
#aicoding@the_ai_architect
Лайк, репост,
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10👍5❤3
Сегодня день горячий на релизы, так что я с самого утра наблюдаю за схваткой двух больших домов: адептус клод кодус и хранителями кодекса, хихикаю и дальше пишу курсору и кими что надо будет сгенерировать пока я ужинаю.
Кстати, напоминаю ещё раз про мой недавний пост про поднятие цен на модельки, если вы думаете, что стало очень дорого, то успокойтесь, будет ещё дороже.
Кстати, напоминаю ещё раз про мой недавний пост про поднятие цен на модельки, если вы думаете, что стало очень дорого, то успокойтесь, будет ещё дороже.
😁15🔥5🤝2
Про AiConf
Вчера пробежал первый полумарафон в этом году, обычно бегаю такие большие расстояния когда надо сосредоточиться на какой-то задаче или выступлении, попрогонять в голове спич ну и так далее, эдакая тренировка слеш репетиция слеш медитация.
А всё потому что 20го числа я выступаю на конференции AiConf 2026 (к чему готовился всю последнюю неделю) с докладом в жанре мастер-класс про SGR Agent Core, планирую рассказать про наш фреймворк, как его ставить, запускать, как на нём писать своих агентов и под конец в какую сторону фреймворк будет развиваться.
В общем заходите на огонёк, до связи.
Вчера пробежал первый полумарафон в этом году, обычно бегаю такие большие расстояния когда надо сосредоточиться на какой-то задаче или выступлении, попрогонять в голове спич ну и так далее, эдакая тренировка слеш репетиция слеш медитация.
А всё потому что 20го числа я выступаю на конференции AiConf 2026 (к чему готовился всю последнюю неделю) с докладом в жанре мастер-класс про SGR Agent Core, планирую рассказать про наш фреймворк, как его ставить, запускать, как на нём писать своих агентов и под конец в какую сторону фреймворк будет развиваться.
В общем заходите на огонёк, до связи.
1🔥22👍14
GitHub
GitHub - EvilFreelancer/rpa-skills: Agent skills collection, includes RPA workflow and Logika (Chelpanov formal logic)
Agent skills collection, includes RPA workflow and Logika (Chelpanov formal logic) - EvilFreelancer/rpa-skills
RPA Skills
По мотивам своих же заметок про вайбкодинг и набора промптов в репозитории cursor-vibe-prompts я оформил это как отдельные скилы для агентов, чтобы не пересказывать каждый раз длинный текст в чат.
- /rpa-init - скилл прогрева контекста по репозиторию, просит агента изучить код, прочесть доки, и код тестов, затем выполнить установку dev-окружения, прогнать тесты, написать короткий отчёт о проекте.
- /rpa-gen-rules - скилл который позволяет собрать или обновить правила для агента, внутри скилла лежат примеры под Cursor и под Claude Code, правила генерятся по методу слоёного пирога (чтобы агент сначала писал логику первого уровня, у которой нет зависимостей, потом второго и так далее), плюс правила описывают разработку по паттерну BDD.
- /rpa-feat - скилл добавления новой фичи строго по BDD, пишет план, генерит тесты, выполняет тесты (red), пишет код, гоняет тесты (green), гоняет все остальные тесты, актуализирует документацию и примеры, плюс выполняет линтер под конец.
- /rpa-bugfix - скилл исправлениия бага, сначала пишет тест на воспроизведение бага, потом фикс, потом полный прогон всех тестов и короткий отчёт о проделанной работе.
Скилы /rpa-init и /rpa-gen-rules работают сами по себе, ничего дополнительного писать не потребуется, а вот для /rpa-feat и /rpa-bugfix нужно передать на вход информацию о том что надо сделать, например текст из issue написать, иначе они не смогут правильно работать.
Репозиторий со скиллами:
https://github.com/EvilFreelancer/rpa-skills
По мотивам своих же заметок про вайбкодинг и набора промптов в репозитории cursor-vibe-prompts я оформил это как отдельные скилы для агентов, чтобы не пересказывать каждый раз длинный текст в чат.
- /rpa-init - скилл прогрева контекста по репозиторию, просит агента изучить код, прочесть доки, и код тестов, затем выполнить установку dev-окружения, прогнать тесты, написать короткий отчёт о проекте.
- /rpa-gen-rules - скилл который позволяет собрать или обновить правила для агента, внутри скилла лежат примеры под Cursor и под Claude Code, правила генерятся по методу слоёного пирога (чтобы агент сначала писал логику первого уровня, у которой нет зависимостей, потом второго и так далее), плюс правила описывают разработку по паттерну BDD.
- /rpa-feat - скилл добавления новой фичи строго по BDD, пишет план, генерит тесты, выполняет тесты (red), пишет код, гоняет тесты (green), гоняет все остальные тесты, актуализирует документацию и примеры, плюс выполняет линтер под конец.
- /rpa-bugfix - скилл исправлениия бага, сначала пишет тест на воспроизведение бага, потом фикс, потом полный прогон всех тестов и короткий отчёт о проделанной работе.
Скилы /rpa-init и /rpa-gen-rules работают сами по себе, ничего дополнительного писать не потребуется, а вот для /rpa-feat и /rpa-bugfix нужно передать на вход информацию о том что надо сделать, например текст из issue написать, иначе они не смогут правильно работать.
Репозиторий со скиллами:
https://github.com/EvilFreelancer/rpa-skills
👍25🤝2
Pavel Zloi
Про AiConf Вчера пробежал первый полумарафон в этом году, обычно бегаю такие большие расстояния когда надо сосредоточиться на какой-то задаче или выступлении, попрогонять в голове спич ну и так далее, эдакая тренировка слеш репетиция слеш медитация. А всё…
Отстрелялся, выступать с докладом было весело, из занятных ситуаций которые произошли: оказалось что через вайфай не работает загрузка пакетов через pip, так что пришлось надеяться на воображение слушателей и мой навык комментирования кода, который я приобрел еще во времена когда стримил.
Были вопросы про сравнение проекта с OpenClaw, вопросы про настройки vllm (и required в частности), про внутреннюю логику работы тулов, ещё спрашивали советы вкатывальщикам в тему агентов и много каких ещё интересных вопросов.
Видеозапись велась, мне даже микрофон беспроводной дали, поэтому вполне возможно что выложу запись.
На будущее сделал себе кучу заметок, ну и понял что ничего в таких выступлениях страшного нет, буду выступать на конференциях про нейросети короче, мне понравилось.
Сейчас двигаю домой, после доклада какое-то резкое ощущение усталости появилось, максимум что хочется после доклада это покемарить, занятно все это.
Короче такой вот веселый денек был.
Были вопросы про сравнение проекта с OpenClaw, вопросы про настройки vllm (и required в частности), про внутреннюю логику работы тулов, ещё спрашивали советы вкатывальщикам в тему агентов и много каких ещё интересных вопросов.
Видеозапись велась, мне даже микрофон беспроводной дали, поэтому вполне возможно что выложу запись.
На будущее сделал себе кучу заметок, ну и понял что ничего в таких выступлениях страшного нет, буду выступать на конференциях про нейросети короче, мне понравилось.
Сейчас двигаю домой, после доклада какое-то резкое ощущение усталости появилось, максимум что хочется после доклада это покемарить, занятно все это.
Короче такой вот веселый денек был.
2🔥38❤10🏆6👍1
Forwarded from Dealer.AI
Ещё раз про новые роли AI-команд, надеюсь последний 🇨🇩 .
В последнее время люди приходят к DS просят, сделать MCP. Люди, дорогие, эт не задача AI engineer, Data scientist. Это задача или разработки, или новой роли AI разработчик. А чтобы вы не забывали про роли, вот вам небольшой тлдр по AI-native профессиям со стороны ИИ.
И кстати, перестаньте мучать CDTO/CTO/CIO вопросами развития ИИ в вашей компании. Их задача проникновение ИИ инструментов в их область деятельности (разработка, процессы, инфра, поддержка и тп). А за развитие ИИ отвечает Head of AI/VP of AI/Chief AI Officer
Все, вечером будет про Kimi-K2.6
В последнее время люди приходят к DS просят, сделать MCP. Люди, дорогие, эт не задача AI engineer, Data scientist. Это задача или разработки, или новой роли AI разработчик. А чтобы вы не забывали про роли, вот вам небольшой тлдр по AI-native профессиям со стороны ИИ.
И кстати, перестаньте мучать CDTO/CTO/CIO вопросами развития ИИ в вашей компании. Их задача проникновение ИИ инструментов в их область деятельности (разработка, процессы, инфра, поддержка и тп). А за развитие ИИ отвечает Head of AI/VP of AI/Chief AI Officer
Please open Telegram to view this post
VIEW IN TELEGRAM
😁8👌6❤2👍1💯1
Forwarded from AI да парень! / Sergei Notevskii
#300tps
Бабушкины рецепты
Сегодня наш LLMOps (Серёга, привет!) показал новый интерфейс рецептов vLLM.
На первый взгляд просто удобный конструктор: выбираешь модель, железо, параметры - получаешь готовый vllm serve.
Но мне кажется важнее не UI и даже не JSON API.
Важнее сама попытка вынести то «как правильно запустить конкретную
модель на конкретном железе» в отдельный воспроизводимый
артефакт. Потому что обычно это знание живёт где угодно:
в model card, в README, в issue, в PR, в Discord, в голове
инженера который «уже поднимал Qwen на H200 и помнит где грабли».
Что конкретно появилось.
Раньше рецепты были md файлами
в подразделе доки - свободный текст, каждый автор писал как
удобно. Сейчас YAML-схема со строгими полями (hardware_configs,
flags, throughput_vs_latency), валидация и формула VRAM при
билде, JSON API, ну и конечно селектор на странице модели.
Живой пример скорости: сегодня релизнулся DeepSeek V4, PR
поддержки в vllm (#40760) ещё мержится - а рецепт для V4-Pro
уже на сайте, верифицирован на 8×H200, с готовыми флагами вроде --tool-call-parser deepseek_v4.
Раньше при выходе модели такое собирали бы неделю по чатам и issue.
По сути мы чуть продвинулись на пути от набора шаманских команд к набору версионируемых рецептов.
Бабушкины рецепты
Сегодня наш LLMOps (Серёга, привет!) показал новый интерфейс рецептов vLLM.
На первый взгляд просто удобный конструктор: выбираешь модель, железо, параметры - получаешь готовый vllm serve.
Но мне кажется важнее не UI и даже не JSON API.
Важнее сама попытка вынести то «как правильно запустить конкретную
модель на конкретном железе» в отдельный воспроизводимый
артефакт. Потому что обычно это знание живёт где угодно:
в model card, в README, в issue, в PR, в Discord, в голове
инженера который «уже поднимал Qwen на H200 и помнит где грабли».
Что конкретно появилось.
Раньше рецепты были md файлами
в подразделе доки - свободный текст, каждый автор писал как
удобно. Сейчас YAML-схема со строгими полями (hardware_configs,
flags, throughput_vs_latency), валидация и формула VRAM при
билде, JSON API, ну и конечно селектор на странице модели.
Живой пример скорости: сегодня релизнулся DeepSeek V4, PR
поддержки в vllm (#40760) ещё мержится - а рецепт для V4-Pro
уже на сайте, верифицирован на 8×H200, с готовыми флагами вроде --tool-call-parser deepseek_v4.
Раньше при выходе модели такое собирали бы неделю по чатам и issue.
По сути мы чуть продвинулись на пути от набора шаманских команд к набору версионируемых рецептов.
👍19🔥13❤5
Вайбкодинг для DevOps
Размышлял намедни о порядке в своем зоопарке серверов. Моя самая главная и рутинная проблема - развертывание десятков контейнеров на разных машинах, их автоматическое обновление и поддержка. На docker swarm у меня аллергия, ansible не годится, потому что эти скрипты неустойчивы к изменениям, и их тоже надо сопровождать. Вдоволь наигравшись с *Claw и прочими Harness и агентами, составил для себя что-то типа правил администрирования серверов через агентов. Делал всё по мотивам поста про вайбкодинг документации (ведь настройки серверов в формате эдакой вики тоже суть документация) и другого поста про создание каскадного скила.
Создаю папку с директориями, каждая директория названа как хостнейм машины. В каждой директории находится README файл с описанием того, как подключиться к серверу, что этот сервер делает, какие у него есть особенные настройки, задачи по расписанию. Короче, все, на что имеет смысл обратить внимание.
В корне проекта глобальный AGENTS, в нём описываю как и куда подключаться, что делать и так далее.
Помимо этого, в этих директориях я решил хранить папки, дублирующие структуру домашней папки пользователя. А в них у меня всякие разные docker-compose.yaml, настройки env, конечно же README с описанием чего и как делать и так далее, получается что-то типа этого:
По итогу получается, что настройки моих серверов хранятся локально у меня и копия на сервере git. Файлы для стейтфул приложений (типа логов того же langfuse) лежат при этом на той машине, на которой это приложение запущено. Плюс секреты и конфиги там же, так как в репу я коммичу только примеры.
Кстати, знающие люди, наверное, заметят, что это напоминает систему контроля конфигураций NixOS, а кто-то скажет, что это скорее ansible. Обои будут правы ;) т.к. я вдохновлялся всеми указанными проектами. Но мое решение чуть более универсальное и, в отличие от NixOS, не привязывается к конкретной ОС, а в отличие от ansible агент работает недетерминированно и может справиться с любой операционкой и любой задачей, что я ему поручу.
То есть по сути в такой схеме каждый сервер становится уникальным саб-скилом, доступным через мета-скил.
Размышлял намедни о порядке в своем зоопарке серверов. Моя самая главная и рутинная проблема - развертывание десятков контейнеров на разных машинах, их автоматическое обновление и поддержка. На docker swarm у меня аллергия, ansible не годится, потому что эти скрипты неустойчивы к изменениям, и их тоже надо сопровождать. Вдоволь наигравшись с *Claw и прочими Harness и агентами, составил для себя что-то типа правил администрирования серверов через агентов. Делал всё по мотивам поста про вайбкодинг документации (ведь настройки серверов в формате эдакой вики тоже суть документация) и другого поста про создание каскадного скила.
Создаю папку с директориями, каждая директория названа как хостнейм машины. В каждой директории находится README файл с описанием того, как подключиться к серверу, что этот сервер делает, какие у него есть особенные настройки, задачи по расписанию. Короче, все, на что имеет смысл обратить внимание.
В корне проекта глобальный AGENTS, в нём описываю как и куда подключаться, что делать и так далее.
Помимо этого, в этих директориях я решил хранить папки, дублирующие структуру домашней папки пользователя. А в них у меня всякие разные docker-compose.yaml, настройки env, конечно же README с описанием чего и как делать и так далее, получается что-то типа этого:
servers/
README.md
AGENTS.md
lb01/
README.md
containers/
docker-langfuse/
docker-compose.yaml
README.md
...
gpu02/
README.md
containers/
docker-tei/
docker-compose.yml
gpu03/
README.md
nas01/
README.md
...
По итогу получается, что настройки моих серверов хранятся локально у меня и копия на сервере git. Файлы для стейтфул приложений (типа логов того же langfuse) лежат при этом на той машине, на которой это приложение запущено. Плюс секреты и конфиги там же, так как в репу я коммичу только примеры.
Кстати, знающие люди, наверное, заметят, что это напоминает систему контроля конфигураций NixOS, а кто-то скажет, что это скорее ansible. Обои будут правы ;) т.к. я вдохновлялся всеми указанными проектами. Но мое решение чуть более универсальное и, в отличие от NixOS, не привязывается к конкретной ОС, а в отличие от ansible агент работает недетерминированно и может справиться с любой операционкой и любой задачей, что я ему поручу.
То есть по сути в такой схеме каждый сервер становится уникальным саб-скилом, доступным через мета-скил.
❤10🔥8💯3👍1🤣1👻1🫡1
Pavel Zloi
Вайб-дизайн Starterkit 18 марта 2026 года Google выкатили стандарт DESIGN.md (прототип которого они тизерили ещё в мае 25го года), если кратко, то это такой хитрый markdown-файл для переноса и импорта общих правил оформления дизайна между проектами и инструментами.…
В продолжение темы с дизайном через агентов, намедни состоялся релиз проекта OpenDesign, это открытая альтернатива Claude Design без вендорлока на модели Antropic.
Заявлена поддержка многих кодовых агентов, включая опенкод, а это значит можно будет задействовать on-prem модели, что очень хорошо, так как у меня как-раз стоит копытом бьет qwen 3.6 35b на паре 4090.
Короче план чем заняться в праздничные дни финализирован.
Заявлена поддержка многих кодовых агентов, включая опенкод, а это значит можно будет задействовать on-prem модели, что очень хорошо, так как у меня как-раз стоит копытом бьет qwen 3.6 35b на паре 4090.
Короче план чем заняться в праздничные дни финализирован.
GitHub
GitHub - nexu-io/open-design: 🎨 Local-first, open-source alternative to Anthropic's Claude Design. ⚡ 19 Skills · ✨ 71 brand-grade…
🎨 Local-first, open-source alternative to Anthropic's Claude Design. ⚡ 19 Skills · ✨ 71 brand-grade Design Systems 🖼 Generate web · desktop · mobile prototypes · slides · images · videos · ...
🔥9❤7