ivklgn: разработка и исследования

описание

Исследую и строю продукты в сфере IT. Работаю над archcore.ai

← к каналу @ivklgn_dev

104

подписчиков

Охват к подписчикам

152,9%

ERR

Реакции к просмотрам

4,12%

124 на 19 постов

Пересылки к просмотрам

0,30%

Постов в день

0,1

всего 19

Где отзываются чаще

доля реакций к просмотрам

12 авг.🤖 14 отличных лекций про агентские обвязки (harness engineering) мне кстати больше нравится слово оснастка - помогает понять лучше почему чаще виновата НЕ LLM в агентских задачах - мне понравилось про Overreach / Under-finish / WIP - классика: верификация, умение автоматически строить качественные проверки результата - интересно было узнать про склонность к сверхуверенности - наблюдаемость очень важна - совет по упрощению harness - "каждый компонент harness существует, потому что модель не может надёжно делать что-то самостоятельно". круто! https://walkinglabs.github.io/learn-harness-engineering/ru/lectures/lecture-01-why-capable-agents-still-fail/ 🙂 ivklgn: разработка и исследования22,41%
4 авг.Как-то раз в одном промпте наткнулся на упоминание про ASD-STE100. STE (Simplified Technical English) помогает писать технический текст строже. Этот свод правил пришел из авиастроения, где устранение неоднозначных формулировок в технических вопросах критически важны. Кратко: меньше двусмысленности, метафор, красивых оборотов, сложных цепочек. 1. Одно слово - одно значение 2. Минимум синонимов 3. Простая грамматика 4. Одно предложение - одна мысль …и др. Для разработки ПО может повысить качество при создании и поддержке документации. С другой стороны есть еще ISO 24495-1: Plain Language. Данный стандарт уже обращает внимание на то как сделать технический текст, в котором пользователь: 1. Может легко найти информацию 2. Быстро понять ее 3. Правильно использовать И они отлично комбинируются: ISO 24495-1 как общий формат и улучшения навигации в тексте, а ASD-STE100 как строгий стиль написания технических инструкций. ————— Я попробовал сравнить пару спек при обычном генерировании и со стандартами. Сlaude к примеру предпочитает ASD-STE100 + ISO 24495-1 и считает данный текст док более понятным. На данный момент тестирую комбинацию в Archcore в общих промптах для агентов. Возможно станет базовым стандартом на уровне самого инструмента. Для системного промпта или CLAUDE.md / AGENTS.md можно попробовать: When generating, rewriting, or reviewing technical documentation, including output produced by skills, plugins, subagents, SDD workflows, or context tools, select the writing style from the purpose of the text. Use an ASD-STE100-inspired controlled style for procedures: one action per step, imperative verbs, conditions before dependent actions, consistent terminology, and separate instructions, prerequisites, expected results, notes, warnings, and explanations. Use a controlled normative style for requirements, specifications, policies, rules, and contracts: one independently verifiable obligation per item, an explicit actor, and exactly one uppercase MUST, MUST NOT, SHOULD, or MAY modal. Use ISO 24495-1-inspired plain-language principles for architecture documents, ADRs, RFCs, READMEs, proposals, and explanations: state the purpose, decision, or conclusion early; organize information around the reader’s task; and clearly separate facts, decisions, requirements, assumptions, constraints, rationale, risks, and examples. Preserve identifiers, commands, paths, configuration keys, code, and literal values exactly. Do not invent missing facts, behavior, requirements, or constraints. Mark unsupported technical claims with [assumption]. Preserve the original scope and normative strength. Before returning or saving documentation, normalize all generated content to these rules. Explicit higher-priority user or repository instructions may override structure or style, but not the accuracy, preservation, and non-invention rules. 🙂 ivklgn: разработка и исследования8,82%
10 июл.EARS Если не сталкивались со спецификациями ПО, то советую взглянуть на EARS (Easy Approach to Requirements Syntax). Я наткнулся на этот формат у Kiro. Подход помогает очень лаконично описывать требования к системе в текстовом виде, используя синтаксис: Ubiquitous: The system shall <response> Event-Driven: When <trigger>, the system shall <response> State-Driven: While <state>, the system shall <response> Optional: If <feature is included>, then the system shall <response> Unwanted: If <undesired condition>, then the system shall <mitigation> Complex: While <state>, if <condition>, then the system shall <response> Живой пример такой спецификации можно посмотреть тут. В моем инструменте Archcore уже давно существовали *.spec.md файлы, но я при активном использовании в нескольких проектах начал замечать что простое описание пунктами бедновато. Поэтому в последних релизах я все таки выбрал для спецификаций данный формат как основной. Удобно. Минималистично. Полезно при разработке систем и составных частей. Рекомендую попробовать в своих сетапах, реализует часть SDD (spec driven development) - от спецификации к коду. Полезное: - Коротко: Про EARS от Alistair Mavin - Подробнее: Easy approach to requirements syntax (EARS) - Когда не стоит использовать EARS - Готовый скилл с нотацией для агентов - kiro-skill с EARS для Claude 🙂 ivklgn: разработка и исследования7,82%
17 июл.как вам?7,14%
8 июн.Агенты: Что такое автономность? Intelligence / Judgment. Какие процессы подходят? Дообучение или контекст? 👉 Отличная статья: https://vikulin.ai/posts/real-automation/ рекомендую: @vikulin_ai6,67%
10 июн.🎉 Вот и мой первый релиз, исправляющий ошибку установки в Codex прилетевший от незнакомого разработчика на Github. Несмотря на то что сам баг обломал пользователя - я рад что он отрепортил. Очень вдохновляет Напомню, что я делаю инструменты для улучшения работы с контекстом - помогаю людям и AI агентами писать/проверять код эффективнее. Как раз один из 2 инструментов - это Archcore Plugin. Я его поддерживаю для Claude, Cursor и Codex и пока что это конечно та еще свистопляска. Конечно же жду стандартизации плагинов. Если соберетесь сейчас создавать / поддерживать плагинчики для нескольких хостов - готовьтесь 🙂. Тем временем в Archcore ожидается еще +2: copilot и opencode. 🆕 Релизы Archcore размещаю регулярно вот тут t.me/archcore_ai https://t.me/archcore_ai/256,07%
1 июн.Хороший чек-лист для тех кто запускает свои web приложения / SaaS 12 факторов содержит перечень полезных рекомендаций по конфигурации, масштабированию и других ops задач. Ну и конечно же используя Openclaw навык от Kevin Anderson портировал скилл для claude/codex: https://github.com/ivklgn/ai-kit/tree/main/skills/12-factor-apps 🙂 ivklgn: разработка и исследования4,30%
4 маяArchcore Plugin Я все так же продолжаю развивать Archcore - создаю вспомогательные инструменты для AI-агентов Цель простая: через создание качественного контекста заставляем агентов программировать следуя правилам На сей раз делюсь релизом плагина для Claude и Cursor. 🔌 В сердце плагина все тот же Archcore CLI - MCP устанавливается и поднимается внутри плагина автоматически 🛠 Более 10 скиллов для эффективного создания документов 🤖 2 субагента для повышения продуктивности разработки ваших артефактов Подробнее: https://archcore.ai/plugin/ Приходите контрибьютить, присылайте идеи и багрепорты! И конечно буду рад звездам на Github ⭐️!4,29%
23 апр.В чате народ жалуется на работоспособность сайта chatgpt, @skywalker587 решил это подебажить: судя по всему chatgpt.com под капотом юзает zustand + immer middleware я прост пытаюсь ща понять их говнокод который при переключении чатов у меня 600 мс функцию в флеймграфе выполняет. восстанавливаю исходники из минификаций Если вкратце они при получении чата с бэка полностью перетирают в стейте объект чата (и в объекте хранят и тайтлы и мета инфу вообще все там хранят) и далее все подпичики перерисовываются и на это 600мс. короче их надо научить нормализации стейта А я лишь напомню про https://v1000.reatom.dev/handbook/atomization/4,11%
31 мар.Как работает Archcore CLI — коротко для тех, кто пишет код с агентами Выполняем в репозитории archcore init и в корне появляется .archcore/. Это весь контекст проекта. Никаких внешних сервисов: всё хранится в git, проходит через PR/MR и живёт вместе с кодом. Внутри — markdown-файлы с YAML-фронтматтером. Все файлы специально именуются: slug.type.md. Типов много, но по сути они делятся на три слоя: • Vision — что и зачем строим (PRD, планы, идеи, и др.) • Knowledge — что уже знаем (ADR, RFC, правила, гайды и др.) • Experience — чему научились (паттерны, шаблоны задач) Жизненный цикл простой: Vision → Knowledge → Experience. Документы связаны между собой, поэтому контекст не теряется. Самое важное: это работает с любым агентом через MCP. Один и тот же .archcore/ понимают Claude Code, Cursor, Copilot, Gemini CLI и др. Агент читает и обновляет документы, создаёт новые, связывает их между собой. Если агент поддерживает хуки — он сразу получает весь контекст проекта при старте. По сути, .archcore/ — это централизованный источник правды о проекте, который одинаково понятен людям и агентам. https://docs.archcore.ai/start/quick-start/4,03%
16 маяВ Archcore Plugin стабилизирован набор /archcore:* команд — 7 коротких workflow для работы с архитектурным контекстом из AI-агента. /archcore:init Делает репозиторий понятным для AI: добавляет базовые документы, правила стека, run guide и импортирует существующий CLAUDE.md, AGENTS.md или .cursorrules, если они уже есть. /archcore:context Перед изменением кода подтягивает релевантные правила, решения, specs и patterns для файла, директории или темы. /archcore:capture Документирует то, что уже живёт в коде: модуль, API, pipeline или integration с неявным tribal knowledge. /archcore:plan Собирает из идеи структурированный план реализации /archcore:decide Фиксирует техническое решение как ADR, RFC, Guide, rules и др. При необходимости помогает превратить решение в командный стандарт /archcore:audit Показывает состояние документации: coverage, gaps, stale docs, missing relations. Есть --deep для полного аудита и --drift для code/doc drift. ————— Команды можно вызывать напрямую — или просто описать intent обычным языком. Archcore сам маршрутизирует запрос в нужный workflow. https://archcore.ai/plugin/3,21%
25 июн.если вы активно генерируете тесты для вашего кода, то порой полезно проверитьx тест вообще полезен и не врет ли он? отталкиваясь от мутационного тестирования создал навык для агентов, которым можете проверить ваши тесты Как это работает на примере: >> К заказу применяется скидка 10%. 1. Сначала skill понимает ожидаемое поведение: товар стоит $1000, после скидки итоговая сумма должна быть $900. 2. Затем он запускает тест как есть. Тест проходит. 3. После этого skill временно ломает код: скидка больше не применяется. 4. Запускает тот же тест ещё раз. 5. Если тест падает — значит, он действительно защищает поведение со скидкой. Если не падает — он только выглядит полезным. 6. Затем код откатывается, а skill показывает диагностику: что тест действительно ловит, а что пропускает. 7. Если будет соблазн прогнать много-много тестов - готовьтесь к расходу токенов. SKILL: https://github.com/ivklgn/ai-kit/tree/main/skills/test-health-check2,90%