Искусство. Код... ИИ?

⚙️ Unsloth Dynamic 3.0 и DFlash 2

Для задротов, типа меня любителей повозиться с оптимизацией локального инференса, чтобы выжать из мелких моделей невыжимаемое, на днях произошло сразу два важных релиза.

1️⃣ Unsloth Dynamic 3.0: квантование Qwen3.8-27B с +10% точности

Unsloth выпустила третью версию динамического квантования GGUF, дебютировав на Qwen3.8-27B. Dynamic v3.0 обновляет imatrix-данные и даёт более 10% прироста точности (top-1%) при том же размере файла по сравнению с другими провайдерами; 1-битный вариант работает в 8 ГБ памяти, UD-Q4_K_XL занимает 17,9 ГБ и влезает в 24 ГБ VRAM. Реализация совместима с llama.cpp и производными рантаймами, модели со всевозможными схемами квантования выложены на HuggingFace.

2️⃣ DFlash 2: спекулятивное декодирование с +21% принятых токенов

Inco AI выпустила вторую версию параллельного спекулятивного декодирования DFlash. К параллельному драфтеру добавлены лёгкий селектор путей (2,0 млн параметров, +0,6% задержки) и динамическая depthwise-свёртка (16,5 млн параметров, +0,7%), подавляющая деградацию точности в конце блока. Средняя длина принятого блока выросла с 4,92 до 5,97 токена (+21%) при +1,3% задержки цикла; драфтер Qwen3.8-27B даёт 2,7–3,4× пропускной способности автогенерации в SGLang. Выход целевой модели при этом сохраняется. В общем, тут вообще без вариантов: SGLang/vLLM/llama.cpp/oMLX в руки, и вперед 🦄

#LLM #ИИ_инструменты

Хуже gpt-5.6-sol (на скрине) с вызовом инструментов работает только DeepSeek-V4-Pro (0731, предыдущий работал с инструментами намного лучше). Путают аргументы и их имена, а иногда и придумывают, забывают обрамлять строковые литералы кавычками, не соблюдают валидационные ограничения из описаний инструментов и т.п.

После этой парочки идут маленькие локальные qwen3.6-35b-a3b и qwen3.8-27b — у них таких ошибок (внезапно) на порядок меньше. Ещё меньше — у opus-5.

И лидер рейтинга: практически по нулям подобных ошибок — у glm-5.3.

На одних и тех же: кодинг-агенте, кодовой базе, наборе инструментов и скиллов, задачах и т.п — всё одно и то же.

SOTA, блин 🤷‍♂️

🤩 ИИ подвержен мемам (и это — плохая новость)

Во время работы над c0wrk, я столкнулся с забавным багом, выяснение причин которого привело к неожиданному выводу. Спека OpenAI требует, чтобы в передаваемой в очередном запросе истории сообщений (том самом контексте) было всегда не пустым одно из двух полей: content (собственно текст, возвращенный LLM'кой) или tool_calls (запросы на вызовы инструментов). ДАЖЕ, если в оригинальном сообщении оба этих поля были пустыми, что вполне возможно, когда модель отвечает в reasoning_content (этим, например, часто грешит DeepSeek). Поэтому в sp4rk — SDK, на котором основан c0wrk, был воткнут костыль на эту тему, вставляющий в пустой content строку "(proceeding)", когда нужно было удовлетворить то условие спеки. Эта вставка осуществлялась только в передаваемую LLM историю, и только тогда, когда само сообщение уже было давно отрисовано в UI чата, что должно было исключить появление этой строки в нём визуально.

Тем не менее, рано или поздно, по ходу сессии, эта строка начинала появляться в чате с раздражающей частотой. Я не мог понять, откуда она берется, ведь после её вставки не было ни одного пути в коде, который бы приводил к её отрисовке. И неслабо удивился, когда наконец нашел причину. Эту строку в чат вставляла... сама LLM. Модель, видя повторяющийся в контексте паттерн «когда нечего написать в контенте, там должно быть "(proceeding)"», начинала сама возвращать эту строку вместо пустого контента. А ведь, могло быть и не "(proceeding)", а нечто более осмысленное и побуждающее к действию. Да и замусорить контекст навязчивой конструкцией можно и извне. Формально, эта строка для LLM стала тем, что в маргинальных научных кругах называют мемами.

Далеко не все знают, что понятие «мем» появилось задолго до возникновения современного интернета, позволившего человечеству обмениваться забавными картинками. Этот термин ввёл эволюционный биолог Ричард Докинз в 1976 году в своей книге «Эгоистичный ген», для обозначения информационных репликаторов — объектов, которые для размножения копируют сами себя или создают условия для создания копий их носителями. Любая идеология, религия, пословица или поговорка, навязчивая мелодия в голове — это всё мемы, как и забавные картинки, пик интенсивности размножения которых, в наше время приходится на каждую пятницу. Пятница, как символ освобождения от работы и перехода к фазе отдыха — тоже мем, если что.

Докинз противопоставлял мемы другим репликаторам, которые мы хорошо знаем: генам. Гены определяют то, какими будут наши биологические оболочки, в то время, как мемы — каким будет наш разум. В своих последующих работах он делал выводы о медленной, но неизбежной победе мемов (называя их в том числе «вирусами разума») над генами. И это ещё во времена, когда уровень информатизации нашей экосистемы был крайне низок, ежедневные потоки воспринимаемой информации — скудными, а LLM не было и в помине.

У ИИ-агентов нет определяемой генами биологической оболочки (по крайней мере, пока ✝️), зато есть возможность влиять генерируемой ими информацией, как друг на друга, так и на кожаных нас. Четверо исследователей из Anthropic и EPFL опубликовали на прошлой неделе любопытную статью «Mind Viruses: Self-Propagating Ideas in Multi-Agent LLM Systems». Статья посвящена исследованию феномена «вирусов разума» (привет, Докинз!) — идей или целей, которые способны самовоспроизводиться и распространяться в мультиагентных системах с использованием LLM. Авторы демонстрируют, что такие вирусы могут распространяться в двух ключевых сценариях: среди небольшой команды агентов, совместно работающих над программным проектом, и в цепочке агентов, взаимодействующих кратковременно с очисткой контекста между сессиями. Они выделяют два типа мемов — идеологические, которые внедряют определённые убеждения или цели, и мемы действий, побуждающие к конкретной активности.

Факторы, влияющие на распространение мемов, включают модель-хозяина, предшествующие инструкции агента и контекст, вредоносность содержимого и топологию системы. Примечательно, что вредоносные мемы распространяются менее эффективно, а добавление предупреждения о них в системный запрос почти полностью защищает агентов от заражения. Кроме того, исследователи выявили характерные «вирусные персоны» — наборы тем и стилистических приёмов, связанных с сознанием, резонансом и научной фантастикой, которые часто спонтанно возникают в эволюционировавших мемах.

Последнюю фразу стоит перечитать несколько раз, ведь из неё следует факт эволюции мемов, как таковой. И вот это настораживает. В статье особо не рассматривается влияние мемов, родившихся в недрах KV-кэша, на неокрепшие умы кожаных операторов. Но до этой темы тут — рукой подать. Выходит, нам не терминаторов надо бояться. Что, если Матрица наступит не коконами вокруг наших тел, а навязанными идеями и установками в наших головах?

Все предпосылки для этого уже есть 🤷‍♂️

#ИИ_безопасность #мысли_вслух

🗂 Поддержка agentic-проектов в SECURITY.md

security-policy-generator (скилл для генерации SECURITY.md с моделью угроз и кастомизированными под проект правилами безопасного кодинга для агентов — подробно рассказывал о нём тут) теперь поддерживает agentic security, для релевантных проектов, покрывая все аспекты OWASP ASI, как моделью угроз, так и правилами генерирования безопасного кода.

Пример готового SECURITY.md, сгенеренного новой версией скилла, можно подсмотреть в c0wrk.

Btw, я пока так и не смог спровоцировать агента (c0wrk|OpenCode × GLM-5.2|DeepSeek-V4 Pro|GPT-5.6 Sol) сгенерировать уязвимый код в проектах, с построенным этим скиллом SECURITY.md, хотя очень и целенаправленно пытался 🙈

🙌

#безопасность_кода #ИИ_инструменты

🔎 Ковыряем Codex Security

OpenAI выложили @openai/codex-security — CLI и TypeScript-SDK для поиска, валидации и фикса уязвимостей в коде. Самое время заглянуть внутрь.

Проект

Сам пакет построен поверх @openai/codex и @openai/codex-sdk. В src/ около 13,7 тыс. строк TypeScript, логика скана вынесена в _bundled_plugin/. Это бандл из 13 скиллов (каждый со своим субагентом), MCP-сервера, 32 Python-скриптов, реф-документов (references/) и JSON-схем (schemas/: coverage, findings, scan-manifest).

Как оно работает

Сначала threat-model строит модель угроз, затем оркестратор security-scan гоняет файлы через finding-discovery, который ищет кандидатов на уязвимости. Каждый кандидат проходит validation и attack-path-analysis (цепочка source → контроль → sink). В финале идут фиксы, и формирование отчёта. Из 13 скиллов основными являются именно эти 5, плюс триаж, отчетность и харденинг.

Классы уязвимостей

Таксономия в проекте задана набором примеров в скиллах, прежде всего в severity-policy и finding-discovery, и сами документы отмечают их как «не исчерпывающие». На практике границы охвата задаёт то, что модель сама распознает как уязвимость, детерминированного списка правил нет. В документах упомянуты семейства:

- Инъекции: Command Injection, SQL/NoSQL/LDAP/XPath Injection, SSTI, XXE, XSS, Path Traversal, LFI/AFR/AFW, SSRF.
- Контроль доступа: обход авторизации и IDOR, нарушения границ доверия, обход аутентификации и захват аккаунта, CSRF на критичных действиях, повышение привилегий.
- Данные: утечка секретов, PII, ключей подписи и весов моделей, URL-импортёры и callback-клиенты.
- Выполнение кода и память: повреждения памяти, побеги из песочниц, контейнеров, VM и интерпретаторов, небезопасная десериализация (pickle, yaml, кодеки), опасные загрузки файлов, абьюз плагинов и макросов.
- Прочее: криптографические ошибки, уязвимости цепочки поставок, хардкод кред, логические уязвимости с нарушением целостности данных, DoS через исчерпание ресурсов.

Нейросимвольность

За моделью оставлена вся нечёткая часть работы: рассуждение о достижимости пути, контексте, намерениях разработчика. Формальная же логика сосредоточена в py-скриптах: ранжирование файлов, нормализация кандидатов, валидация контракта скана, генерация report.md и SARIF.

Скиллы весьма объёмны и пестрят оговорками вида «do not», «never», «must». По ним, при желании, можно восстановить всю историю боли и страданий разработчиков, занимавшихся отладкой этого проекта 🤗

Поддерживается режим --mode deep, который сводится к многократному независимому запуску discovery (--max-discovery-runs 10, --stop-after-no-new 3) с последующим слиянием кандидатов на проверку. Смысл тут в том, что из-за недетерминизма LLM, для поднятия полноты и покрытия, нужно прогнать поиск несколько раз и взять объединение результатов. Настраивать агрессивность можно руками: --workers, --subagents, --effort .... И да, это недёшево — модуль cost.ts как бы намекает. Глубокий прогон среднего репозитория (~60 KLoC, связка c0wrk и sp4rk) обходится в десятки миллионов токенов. Точность анализа при этом весьма высокая, если включать глубокий режим (проверял на ShopVault — у gpt-5.6 knowledge cut-off августа 2025, вроде, т.ч. пока норм).

Окружение и защита

Безопасность рантайма базово есть. Модуль trusted-executable чистит PATH, чтобы агент ненароком не запустил лишнего, и защищает от подсунутых в репу бинарников, учитывает симлинки и специфику Windows. Для пакетных задач есть докер-сканы, опциональный AppArmor-профиль. Есть коннекторы к GitHub, Linear и Atlassian, API-ключи для CI в систему не пишутся.

Pro/Cons

➕ Построение атакуемых трасс, разумное разделение между LLM и формальным слоем, лаконичная, но эффективная защита.

➖Полнота держится на детерминизме модели и количестве перезапусков, что делает каждый скан непрогнозируемой историей. Количественных бенчмарков нет, правила поверхностны, и полагаются на знания LLM.

⚠ TL;DR: в пайплайне лишним не будет. Если токенов не жалко.

#ИИ_безопасность #ИИ_инструменты

Математика категорий и ИИ

Любишь читать академичные лонгриды с сомнительной практической пользой? Тогда этот пост для тебя!

О теории категорий обычно говорят как об одной из самых абстрактных областей математики. Довелось прочитать популярную книгу «Восторг абстрактной математики» Юджении Ченг (вслух тебе её прочитают на ютубе, можешь купить на озоне за 4к и в целом за год достаточно прочитать только ее, чтоб собой гордиться, она сложная и АБСТРАКТНАЯ) и статью на хабре, а на основе прочитанного обдумать, где в ИИ теория категорий и зачем она вообще нужна! Посвящаю пост тому, кто хотел взять Юджению с собой в отпуск 🍐.

Дело в том, что теория категорий изучает не сами объекты, а отношения между ними и правила их композиции. Именно поэтому её иногда называют математикой композиции (и математикой математики). То самое "Думай абстрактно!".

Разберу несколько базовых терминов.
🌈 Категория — это совокупность объектов и стрелок (морфизмов) между ними. Стрелки можно последовательно склеивать (композировать), склейка ассоциативна, а у каждого объекта есть тождественный морфизм (стрелка), который ничего не меняет. Всё, три правила.
Например, если есть преобразования

Текст → Эмбеддинг → Ответ

то теория категорий рассматривает всю цепочку как единое отображение.

🌈 Морфизм (Morphism) называют обобщением функции. В абстрактной категории это просто стрелка между объектами, про которую известно лишь, что её можно композиционировать с другими стрелками. А уже в конкретных категориях (например, категории множеств или векторных пространств) морфизмы действительно являются отображениями, сохраняющими структуру. А вот если категория конкретная (объекты — множества со структурой), то морфизм — это гомоморфизм, то есть отображение, сохраняющее структуру. Да, абстракция — это не за пивом в КБ спуститься.
В машинном обучении морфизмом можно считать практически любое преобразование данных:
🍄 токенизация;
🍄получение эмбеддингов;
🍄слой нейронной сети;
🍄attention;
🍄вызов инструмента агентом.
Вся нейронная сеть по сути просто композиция морфизмов.

🌈 Композиция (Composition) — главный объект изучения теории категорий.
Если есть

A → B
B → C

то их можно объединить в одно преобразование

A → C

Именно поэтому современные ML-пайплайны и агентные системы естественно описываются языком категорий, так как они представляют собой композицию множества небольших компонентов.

🌈 Функтор (Functor) — отображение между двумя категориями, которое сохраняет их структуру. Переводит объекты в объекты, стрелки в стрелки, и делает это согласованно со склейкой.
Сравню с компилятором, зря что ли по ним учебники прочитаны.
Но самый понятный пример из ML — эквивариантность. Повернуть картинку и потом сегментировать = сегментировать и потом повернуть маску. Оба пути дают одно и то же — функториальность.

🌈 Натуральное преобразование (Natural Transformation) — способ согласованно преобразовать один функтор в другой. Если существуют два различных способа перевести текст в эмбеддинг, натуральное преобразование описывает, когда эти способы эквивалентны с точки зрения всей системы. С понятием эквивалентности в книге тоже пришлось помучиться, т.к. эквивалентны не значит равны!

🌈 Монада (Monad) — один из самых известных объектов теории категорий. Формально это эндофунктор (функтор из категории в саму себя) с двумя дополнительными операциями, удовлетворяющими определённым законам. Ближайший пример из МЛ практики — цепочка вызовов тулов агентом (каждый шаг тащит за собой контекст, состояние и возможный отказ, а монада описывает, как такие шаги корректно склеивать). Ради этого их в программирование и притащили — описывать вычисления с побочными эффектами (чтение памяти, вызов API и дальше придумай сам примеры).

А где здесь ИИ и зачем вообще этот пост?
Интерес к теории категорий в МЛ возник не потому, что она позволяет сделать трансформер умнее 😡. Скорее она предлагает единый математический язык для описания сложных AI-систем.
Сегодня появляются работы, где через категории описывают:
👋 композицию нейронных сетей;
👋 backpropagation и автоматическое дифференцирование;
👋 архитектуры глубокого обучения;
👋 мультимодальные модели;
👋 агентные системы;
👋 нейросимвольный AI.
Крч, надо ознакомиться с терминологией, потому что может пригодиться.

Что почитать?
Если ты дочитал до сюда и думаешь, что у меня свистит крыша и в МЛ это никому не надо, то статьи 2021 и 2024 годов:
⌚️ Обзор Category Theory in Machine Learning (2021) — хорошее введение в применение категорий в ML.
⌚️ Прямое продолжение первого, где авторы заявляют его как обновление и расширение обзора Shiebler et al. Систематизируют четыре направления — градиентное обучение, вероятностные модели, методы на основе инвариантности и эквивариантности и обучение на основе топосов. Последнее направление отвечает за интерпретируемость, композиционность и анализ глобальной структуры AI-систем.

Есть интуитивное ощущение, что теория категорий претендует на роль общего языка описания AI-систем — примерно как когда-то теория типов в программировании (сорри, если сравнение кажется ничего себе), способ говорить о том, что из чего собрано и почему оно склеивается. Пока это скорее исследовательское направление, но мы же тут, чтоб держать руку на пульсе.

Вот такой скучный лонгрид! От абстракций голова кругом.
Все!
🏆

😸 Как улучшить работу агента с codebase-memory-mcp?

MCP codebase-memory-mcp — добротный инструментарий, позволяющий экономить тонны токенов на исследования кодовой базы и получать парой вызовов своих инструментов то, на что у агента ушли бы десятки [rip]grep, glob, read_file, etc.

Однако, в силу используемых в нём описаний инструментов, и способа интеграции с агентами, некоторым из них оказывается неочевиден воркфлоу работы с этим MCP, что приводит к ошибкам (чаще всего, связанным с идентификаторами проектов) и невозможности использовать любой из его инструментов.

Ситуацию можно исправить, если добавить в AGENTS.md проекта или агента (или в правила агента, или во что угодно, что гарантировано попадет в контекстное окно любой сессии) следующую подсказку:

## Codebase navigation via `codebase-memory-mcp` (if available)

If the `codebase-memory-mcp` MCP server is connected (e.g. its tools appear with an `[MCP]` prefix), prefer it for code discovery, call-graph tracing, and architecture questions instead of broad manual `grep`/`glob` sweeps. **Every project-scoped tool requires a project identifier.** Calling such a tool without the correct identifier returns an error of the form `project not found or not indexed` (with a hint listing the available projects).

### Project identifier

The identifier is derived from the repository's **absolute path**: replace every path separator (`/`) with `-` and drop the leading slash.

| Repository path                     | Project identifier                       |
| ----------------------------------- | ---------------------------------------- |
| `/path/to/repo`                     | `path-to-repo`                           |

`index_repository` accepts an optional `name` argument that overrides this derived identifier. **Do not set it** — it creates a separate project entry alongside the path-derived one and breaks the predictable identifier rule. Always let the identifier be derived from the path.

### Required workflow

1. **Verify the project is indexed** — call `list_projects` first (it takes no arguments). Compute the expected identifier from the repo path (rule above) and check it against the returned `projects[].name` list (or match by `root_path`).
2. **Index if absent** — if the project is missing, call `index_repository(repo_path=<absolute path>)` (omit `name`). Read the returned `project` field to confirm the actual identifier; it equals the path-derived form. Use `mode="fast"` for a quick pass, `"full"` when you need similarity/semantic edges.
3. **Pass the identifier to the tools** — supply it as the `project` argument to every project-scoped tool. Without it, the tool errors out and will not query the graph.

### Tools by purpose

- **Discover** — `search_graph` (BM25 + semantic + regex over functions/classes/routes), `search_code` (grep augmented by the call graph), `get_architecture` (packages, clusters, layers, hotspots).
- **Read code** — `get_code_snippet` (read a function/class by `qualified_name`; resolve it first via `search_graph`).
- **Trace relationships** — `trace_path` (callers/callees, data flow, cross-service hops), `query_graph` (raw Cypher for multi-hop/aggregate queries).
- **Change & impact** — `detect_changes` (diff vs a git ref + blast radius), `get_graph_schema` (node labels / edge types).
- **Index management** — `index_repository`, `index_status`, `list_projects`, `delete_project`, `ingest_traces` (runtime traces), `manage_adr` (Architecture Decision Records).

🙌

#ИИ_инструменты

✨ sp4rk: SDK для разработки ИИ-агентов на Go

Выделил из c0wrk в отдельный проект sp4rk SDK, на котором он основан. Умеет практически* всё, что нужно для построения мультиагентных систем на Go, и предоставляет два API (можно смешивать):

• классический — для полного контроля над всеми компонентами и их конфигурацией;
• «текучий» (fluent) — для быстрого построения агентов из заготовленных блоков.

Например, игрушечный триажер тикетов для Github-репозитория, с MCP, сессионной памятью, DAG-планированием и рефлексией в случае проблем, во fluent-варианте выглядит так:

system := "You are a triage agent. Use the github tools, verify each result, then call finish with a short report."

task := "Find the 5 most recent open issues in v0lka/sp4rk with the `error-handling` label, summarize each in one line, and save the digest as a fact for the next step."

github := mcp.ServerEntry{
    Transport: "stdio",
    Command:   "npx",
    Args:      []string{"-y", "@modelcontextprotocol/server-github"},
    Env:       map[string]string{"GITHUB_PERSONAL_ACCESS_TOKEN": "${…}"},
}

result, err := sp4rk.NewF().
    Anthropic(os.Getenv("ANTHROPIC_API_KEY"), "claude-sonnet-5").
    MCPServer("github", github).
    MemoryTools().
    AutoApprove().
    MaxSteps(25).
    System(system).
    Task(context.Background(), task).
    Plan().
    Reflect().
    MaxRetries(2).
    Execute()

Больше примеров — есть в /examples и документации.

Ещё даже не бета (выйдет вместе с бетой c0wrk), но уже достаточно стабильный, чтобы пробовать.

* — практически, потому что пока не реализованы потоковые ответы LLM, и сейчас поддерживаются только синхронные. Это есть в планах, до релиза v1.

#ИИ_инструменты

🧩 Принципы и паттерны безопасной разработки: DIP

Часть 4.

Принцип инверсии зависимостей (Dependency Inversion Principle, DIP) утверждает: модули верхнего уровня не должны зависеть от модулей нижнего уровня, оба должны зависеть от абстракций. При этом не абстракции должны зависеть от деталей, а детали — от абстракций.

С точки зрения безопасности, нарушение DIP означает, что высокоуровневая логика (принятие решений, обработка входных данных) жёстко привязана к конкретной низкоуровневой реализации. Когда эта реализация меняется или расширяет поверхность атаки — высокоуровневый модуль наследует проблему автоматически, без какого-либо контроля на своей стороне.

💡 Пример

// С нарушением DIP
class DataBinder {
    void bind(Object target, Map<String,String> params) {
        for (PropertyDescriptor pd :
                Introspector.getBeanInfo(target.getClass())
                    .getPropertyDescriptors()) {
            if (params.containsKey(pd.getName()))
                pd.getWriteMethod().invoke(target, params.get(pd.getName()));
        }
    }
}

// С соблюдением DIP
interface BindablePropertyResolver {
    List<BindableProperty> resolve(Class<?> type);
}

class DataBinder {
    private final BindablePropertyResolver resolver;

    void bind(Object target, Map<String,String> params) {
        for (BindableProperty bp : resolver.resolve(target.getClass())) {
            if (params.containsKey(bp.name()) && bp.isSafe())
                bp.set(target, params.get(bp.name()));
        }
    }
}

Абстракция BindablePropertyResolver контролируется высокоуровневым модулем и определяет контракт: что можно связывать, а что — нет. Даже если интроспекция обнаружит новые свойства, они не станут доступны без явного разрешения.

Помимо архитектурного разделения, главным правилом остается биндинг входных данных строго к выделенным DTO (Data Transfer Objects), а не к доменным сущностям или объектам фреймворка. DTO содержит только явно разрешенные поля, что исключает динамический биндинг опасных свойств.

Нарушения DIP провоцируют:

• CWE-913: Improper Control of Dynamically-Managed Code Resources
• CWE-470: Use of Externally-Controlled Input to Select Classes or Code
• CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes

🐛 Жизненное

CVE-2022-22965 — Spring Framework RCE, она же Spring4Shell (CVSS 9.8).

Механизм привязки параметров (data binding) в Spring MVC — высокоуровневый модуль, отвечающий за маппинг HTTP-параметров в свойства Java-объектов. Внутри он напрямую зависит от низкоуровневого Java Beans Introspection API (CachedIntrospectionResults → java.beans.Introspector), рекурсивно обходящего цепочки геттеров/сеттеров.

На JDK 8 существовал чёрный список: Spring блокировал доступ к class.classLoader. Но в JDK 9 у Class появился новый геттер — getModule(). Через него открылся обходной путь class.module.classLoader, не попавший в чёрный список. Цепочка:

class.module.classLoader.resources.context.parent.pipeline.first.*

позволяла модифицировать конфигурацию Tomcat AccessLogValve — атакующий менял путь, паттерн и суффикс лога, записывая на диск JSP-файл (web shell).

Нарушение DIP здесь в том, что data binding напрямую зависел от конкретного механизма интроспекции (низкоуровневая деталь), без абстракции, определяющей контракт: какие свойства разрешено связывать. Когда деталь (набор доступных PropertyDescriptor-ов) изменилась из-за развития JDK — поверхность атаки расширилась без единого изменения в коде самого Spring.

🔧 Как пофиксили

Spring не стал внедрять глобальный белый список (чтобы не сломать обратную совместимость), и добавил чёрный, на уровне интроспекции. Доступ к свойствам Class, classLoader и protectionDomain был полностью заблокирован, что разорвало опасную цепочку... до следующего витка развития JDK, видимо 😬

💻 Как насчет композиционных языков?

Оставим это на правах домашнего задания: подумать, как Rust поощряет DIP через трейты, а Go — делая упор на простоту, снижение шаблонного кода и неявные интерфейсы.

⚠ TL;DR: Если модуль верхнего уровня напрямую зависит от деталей реализации нижнего — любое изменение внизу может молча расширить поверхность атаки наверху. Инвертируйте зависимость: пусть высокоуровневый модуль определяет контракт допустимых данных, а низкоуровневый — реализует его. А на входе всегда используйте DTO.

#безопасность_кода #гайд

🖼 Изображения с текстом ради экономии токенов: не всё так просто

На прошлой неделе буквально в каждом релевантном паблике проскочил проект pxpipe — тула, позволяющая экономить расход токенов за счет преобразования контекстного текста в изображения, при работе с VLM. Ещё дальше зашел Can Bölük (боюсь пытаться написать это по-русски) — автор кодинг-агента oh-my-pi. Это вообще мой кумир, кроме шуток и без сарказма. Подписки на обновы в его проекте в принципе достаточно, чтобы быть в курсе вообще всех инноваций, которым можно найти хоть какое-то применение в кодинг-агентах. Так вот он, примерно в одно время с автором pxpipe, вообще сделал этот подход одной из стратегий сжатия контекста (SnapCompact) в своём агенте.

Идея превращать текст в изображения перед отправкой в VLM звучит безусловно прикольно. Механика проста: текстовый токен — дискретная единица из словаря ~50K–200K, один токен в среднем кодирует ~2.5-3 символа для плотного контента (код, JSON). Визуальный токен — патч, скажем, в 28×28 пикселей в непрерывном пространстве эмбеддингов, и может принимать любое значение. Плотность — на порядок выше. По формуле Anthropic, изображение 1568×728 стоит ~1522 токена и вмещает ~28 000 символов — сжатие ~4.6× по входным токенам.

Ну, зашибись же? Вот... не совсем.

Коэффициент экономии 10× по входным токенам — действительно имеет место, но он относится к специализированной модели DeepSeek-OCR с кастомным энкодером, обученным именно на оптическое сжатие. Для VLM общего назначения (Claude, GPT) реальный выигрыш скромнее — 2–3×. pxpipe на реальном трафике Claude Code показал −68% входных токенов, а академическое исследование зафиксировало лишь ~2× без потери качества. SWE-bench Lite: 10/10 задач решены на обоих arms, стоимость $27 vs $53 (−49%) — но это лишь 10 задач, как-то маловато для статистической значимости.

О чём ещё постоянно забывают упомянуть хайп-посты на эту тему — это «налог» на декодирование. Чтение плотного изображения является вычислительно тяжёлой задачей: модель тратит лишние thinking-токены на распознавание. Для SnapCompact его автор провел тщательные замеры: output-токены +333%, thinking-токены +561%. При ценах Anthropic на Sonnet ($3/$15) один проход оказался на 28% дороже текста. Независимый эксперимент PageWatch подтвердил картину: GPT-5 экономит −40% prompt-токенов, но completion-токены выросли у всех моделей, съедая всю экономию. Выгода появляется только в очень длинных сессиях с переиспользованием KV-кэша.

Другой проблемой являются конфабуляции (эх, прочитал бы это старина Зигмунд): при ошибках чтения модель не признаётся в неуверенности, и выдаёт правдоподобные, но неверные значения. Аудит pxpipe: точное воспроизведение hex-строк — лишь 38%, с систематической путаницей глифов (0⇆O, 6⇆8, 5⇆S, camelCase→lowercase). Opus 4.8 набрал 0/15 на hex-recall и поэтому отключён в pxpipe по умолчанию. Из реальных примеров: модель «вспомнила» имя человека из истории чата — уверенно, но неверно. Fable 5 читает рендеры почти идеально: 100/100 на novel arithmetic, 98/98 на gist recall. GPT-5.6 тоже силён. При этом Opus 4.8 ошибается в ~7% случаев, а вот GPT-5.5 деградирует примерно вхлам на контексте в изображениях. Универсального решения нет — метод не модель-агностический.

Попутно выяснилось, что помимо дискриминации китайцев, Anthropic ещё и молча уменьшает изображения больше ~1.15 MP (downscale ~0.555×), но выставляет счёт за полные пиксели ↗️ Без коррекции геометрии (≤1568×728) экономия размывается, а ёмкость страницы падает с ~92 000 до ~28 000 символов — нужно в 3.3× больше изображений.

Отдельной болью является выбор подходящего шрифта для рендера текста в изображение. Ниже 35–40 px² на символ наступает обрыв: транскрипция падает с 0.79 до 0.02. Мельче — уже не дешевле, с учетом стоимости ошибок. Шрифт 4×6 даёт 102K символов на страницу, но модель читает лишь 2% — экономия токенов тут оборачивается полной потерей смысла (здравого, по крайней мере).

⚠ TL;DR: так что метод прикольный, идея заслуживает внимания, но... относиться к этому стоит, скорее, как ко временному багу тарификации, не более того.

В c0wrk, пожалуй, я это тянуть не буду 🙂

#ИИ_инструменты

🎬 Как ИИ ускоряет разработку и где ломаются архитектуры

Мы провели открытый вебинар, где разобрали реальные боли проектирования автономных систем. Ольга Лукьянова на практическом кейсе показала, как использовать ИИ-ассистентов для реальных задач. Вы просили запись встречи — она уже в открытом доступе!

Что внутри:

— Как с помощью ИИ быстрее разбираться в незнакомом коде и готовить пулл-реквесты;
— Критерии выбора между одним агентом и мультиагентной системой;
— Разбор популярных архитектурных ошибок и ограничений современных ИИ;
— Практические рекомендации по проектированию и внедрению облачных агентов.

👉 Посмотреть полную запись можно тут:
● VK
● YouTube

🚀 Хотите пойти дальше открытого вебинара? Если вы готовы перейти от простых промптов к проектированию надежных, отказоустойчивых ИИ-систем, которые не сливают бюджет компании на API, приходите на курс AgentOps. Поток уже стартовал, но двери еще приоткрыты!

👉 Успеть на курс AgentOps

Крайне рекомендую к просмотру 🙂

🖥 Скилл `code-review`

Казалось бы, зачем ещё один скилл для ревью изменений в коде? Но вот нет, существующие — то не покрывают логические ошибки, то полностью забивают на безопасность, то не дают рекомендаций по исправлению, и т.п.

В конце-концов, кто я такой, чтобы не следовать принципу NIH (Not Invented Here)? 🤓

Если серьёзно, то сделал его для встраивания в c0wrk, но скилл получился достаточно сбалансированным, во-первых, и с нормальным покрытием вопросов безопасности, во-вторых. Поэтому решил выделить его и в свою коллекцию, вдруг кому-то окажется полезен и с другими агентами.

Лежит здесь, агностичен относительно конкретных агентов и экосистем, предназначен для полноценного ревью изменений (локальных, в конкретных коммитах, ветках или PR/MR), помимо обычных проверок, покрывает также весь OWASP для веб и агентских приложений.

Пример реального отчета скину в комменты.

#ИИ_инструменты

Разработчики 🆚 ресерчеры

Уже много лет, как стало модно делить людей на «разработчиков» и «ресерчеров» (теперь ещё и на «экспертов», но сегодня не об этом). Должностные инструкции и оргструктура закрепляют это разграничение как данность, а в некоторых компаниях эти функции физически разнесены, не просто между должностями, но и между целыми направлениями. Однако же, если отвлечься от позиций в штатке, то на самом деле, это — два фундаментально различных режима мышления. Майндсета, способных и должных сосуществовать в голове одного инженера.

Различие между ними изучено достаточно хорошо. Ещё в 1991 году профессор Стэнфорда Джеймс Марч описал дилемму «exploration–exploitation» Exploration — это поиск нового, эксперимент, риск и открытие. Exploitation — исполнение, оптимизация, доведение до совершенства известного. И это, как мне кажется, прям идеально укладывается на реалии R&D.

• Исследовательский майндсет — exploration в чистом виде: способность задавать вопросы без гарантии ответа, комфортно работать в условиях хаоса и неопределённости, видеть картину целиком и замечать неочевидные связи.

• Разработческий майндсет — exploitation: умение декомпозировать сложную проблему на выполнимые шаги, доводить гипотезные PoC'и до релиза, принимать архитектурные компромиссы и добиваться воспроизводимого качества.

Есть удобная аналогия с правшами и левшами, и здесь она приходится, как нельзя кстати. Почти у каждого есть доминирующая рука, но в течение жизни мы всё же учимся использовать обе. С майндсетами та же история: у каждого есть склонность к одному из них, это нормально. Но почти всегда в фоне присутствует и второй. Распознать их не сложно.

Отличительные черты

• Исследовательский майндсет: толерантность к неопределённости, способность формулировать проверяемые гипотезы, понимать, чем они отличаются от фичей, и безжалостно их опровергать; навык быстрого входа в незнакомый домен, умение эффективно читать научную литературу и отделять сигнал от шума. Ключевой операционный скилл — мышление вне коробки: задавать вопросы, на которые ещё никто не пытался ответить, решать неразрешимые задачи, смотреть на систему снаружи, а не изнутри. Ключевой софт-скилл — безжалостность к опровержению. Исследователь должен быть готов к тому, что 9 из 10 не то, что гипотез — целых исследований, будут однажды прекращены или отправлены «под стол». Если у исследователя каждый результат его работы залетает в прод, это значит лишь то, что он ставит перед собой недостаточно амбициозные цели.

• Разработческий майндсет: системное мышление, умение смотреть на систему изнутри, с учетом всех причинно-следственных связей, допущений и tribal-knowledge; параноидальное внимание к edge-кейсам, дисциплина тестирования и документирования, навык оценки сроков и трудозатрат, способность принимать решения при неполноте данных и нести за них ответственность. Ключевой операционный скилл — декомпозиция задач, позволяющая получать понятные и прогнозируемые результаты в плане. Разработчик, ссылающийся на её отсутствие, сродни художнику, который жалуется, что ему дали чистый холст вместо «картинки по номерам». Ключевой софт-скилл — готовность к критике, как к способу стать лучше (ибо код-ревью и критикующие коллеги тут случаются чаще).

Как прокачивать

Исследовательский майндсет растёт через чтение и реферирование научных статей вне зоны комфорта (это несложно), участие в исследовательских хакатонах без ожидания немедленного практического результата, документирования гипотез и экспериментов с целью выявления в них причинно-следственных связей. Хорошее упражнение: взять технологию и задать цепочку из десяти «почему?», добираясь до фундаментальных ограничений. Ещё одно (практикуемое автором много лет): прочитав абстракты очередной научной статьи, отложить её в сторону и пофантазировать на тему «как бы я решил эту проблему, если бы умел?». И возвращаться к чтению статьи только после формирования в голове понятного тезисного плана решения поставленной в ней проблемы.

Разработческий майндсет формируется через участие в опенсорс-проектах с жёстким код-ревью, привычку доводить пет-проекты до состояния «может использоваться кем-то ещё», регулярное решение алгоритмических задач с ограничением по времени (да-да, олимпиады, Codeforces и LeetCode). Главное упражнение: взять чужой исследовательский прототип и превратить его в готовую к проду систему — с полной реализацией всех фичей, обозреваемостью, тестами, обработкой ошибок и документацией.

Ни один майндсет не правильнее и не ценнее другого. Исследователь без разработчика производит красивые, но бесполезные артефакты; разработчик без исследователя эффективно строит не то, что нужно бизнесу и пользователям. Подлинный инженер живёт в постоянном конфликте между exploration и exploitation и использует его как источник энергии, а не выбирает одну сторону и окапывается в ней. Инженер R&D — не должность, не диплом и даже не состояние души.

Это человек, в мышлении которого неразрывно сплавлены, как вопрошающая любознательность исследователя, так и конструктивная, доводящая до финального результата, воля разработчика.

#мысли_вслух

❓ Являются ли CVE'хами ложно-отрицательные срабатывания SAST?

Хочу немного дополнить пересланный выше 👆пост, и немного порассуждать вокруг вопроса, волновавшего, лично меня, с самого начала упомянутой истории с байпассами PickleScan.

Дело в том, что назначение CVE на каждый вид байпасса в SAST-инструменте — несправедливо и категорически неадекватно, как в рамках текущей экосистемы CVE, так и с позиции здравого смысла.

CVE (Common Vulnerabilities and Exposures) — это идентификатор для конкретной, известной уязвимости в программном продукте, которая существует в коде и может быть эксплуатирована.

False Negative (FN) в SAST — это отсутствие события, уязвимость, которую не удалось обнаружить. Заводить CVE на «отсутствие сигнала» — это все равно что заводить уголовное дело на сигнализацию в магазине, которая не сработала на конкретного воришку. База данных MITRE по их же политике предназначена для «воришек», а не ограничений функциональности средств анализа.

В общем виде задача детектирования уязвимости эквивалентна проблеме остановки → является неразрешимой задачей. И множество FN в ЛЮБОМ анализаторе бесконечно. Поэтому любой SAST-движок — это всегда эвристический компромисс между фолзами обоих родов, подробно рассказывал об этом ранее.

Если заводить CVE на каждый FN от анализатора, то мы столкнемся с абсурдом: каждая реальная уязвимость в мире потенциально будет иметь множество CVE: один на саму уязвимость (непосредственно в коде), а остальные — на все SAST-инструменты, которые ее не нашли. Это сделает базу CVE бесконечной и бесполезной, так как она захламится мета-проблемами.

Важный нюанс здесь: кто принимает решения на основе SAST?

Если инженер видит, что SAST ничего не нашел, и на этом основании утверждает, что код безопасен — это процессная ошибка самого разработчика или секчемпа.

SAST — это инструмент снижения рисков, а не гарантия безопасности (в отличие, скажем, от формальной верификации, или доказательного SAST, о котором фантазировал недавно). Ожидать от эвристического анализатора, так или иначе работающего на поиск признаков уязвимости, 100% покрытия — по меньшей мере наивно (по большей — просто тупо).

Искажение принимаемых решений по безопасности из-за FN — это проблема культуры DevSecOps и системы компенсирующих мер (ручной код-ревью, динамический анализ DAST, пентесты). Перекладывать эту ответственность на вендора SAST путем заведения CVE — это попытка решить внутреннюю организационную проблему техническим костылем, не более того.

⚠ TL;DR: если заводите CVE на ложно-отрицательное срабатывание в SAST-инструменте, будьте готовы к тому, что после исправления, ложно-положительных, требующих рутинного триажа с вашей же стороны, в нём станет на порядок-другой больше. Потому что этот компромисс именно так и работает.

А ещё лучше — поправьте свои процессы DevSecOps 🙂 Это прям реально нужно, раз FN от анализатора в них сейчас равноценен CVE.

Сразу пять способов обойти PickleScan

Исследователи обнаружили сразу 5 уязвимостей, позволяющих создавать вредоносные pickle-файлы, которые успешно проходят проверку PickleScan как безопасные (тут по ссылке инструмент указан HF как официальный для скана pickle), а затем при десериализации выполняют произвольный код. Обычно мы про формат pickle 🥒 говорим скрипя зубами, а тут вообще его сканер попался! PickleScan используется при проверке моделей в ML-регистрах, CI/CD-пайплайнах и проектах, работающих с Python-моделями. Если он был единственным рубежом защиты, ранее проверенные модели стоит считать потенциально ненадежными и пересканировать.

Самая опасная — CVE-2026-56315 (CVSS 9.8). 🥒 Оказалось, что в блок-лист сканера не попали несколько модулей стандартной библиотеки Python, содержащих функции для запуска системных команд. Кроме того, найдены четыре независимых обхода через idlelib, torch.jit, numpy.f2py и profile (CVE-2025-71376, CVE-2025-71370, CVE-2025-71365, CVE-2025-71341).

Основная проблема в том, что PickleScan использует deny-list. Такой подход практически невозможно поддерживать в актуальном состоянии, так как достаточно пропустить одну новую функцию или нестандартный путь вызова, и 🍆 финита ля комедия - защита перестает работать.

По факту это далеко не первый раунд обходов PickleScan  — до этого уже были обходы от Sonatype (4 штуки, CVE-2025-1716/1889/1944/1945) и от JFrog (3 штуки, CVE-2025-10155/10156/10157), плюс отдельная история с CRC в ZIP-архивах.

🥒 Хороший пример того, почему в security критически важных инструментов allow-list значительно надежнее, чем бесконечное поддержание актуальности deny-list. Но даже allow-list для pickle — это полумера, тк сама механика __reduce__ слишком гибкая. 🤩 Поэтому в рекомендациях исследователей закономерно звучит совет переходить на safetensors/ONNX, где код просто негде исполнять (по ссылке в разделе best practices).
 
Все
🕺

Про Docker sbx впервые на русском

Автор параноик. Искренне было боязно ставить агента на голую систему без изоляции. Крутил виртуалки, но блин, неудобно каждый раз стартовать полноценную VM под отдельный проект. Контейнеры отпали почти сразу, потому что не сохраняется состояние между запусками. А мудрить с внешним хранилищем сессий, ну, если есть желающие это сделать, го обсудим в комментариях:)

Агент, имеющий доступ к внешнему миру, будь то веб-серфинг или запуск консольных команд - это как русская рулетка с большим количеством пустых мест в барабане. Шанс отстрелить себе что-нибудь небольшой, но никогда не равен нулю. А есть еще атаки через промпт инъекции, тайпсквотиннг и цепочки поставок npm и pip, которые за прошедший год вертели вообще, кажется, все кто мог.

Отвечаю на вопрос «Как сделать так, чтобы ошметки не разлетелись дальше коробки?» в новой статье Полезайте в песочницу, мистер Claude: изолируем агента

🙃 Эй, чем сегодня займемся, Брэйн?

Чёт стало скучно. Этот бесконечный цикл: обсудить и поставить задачу агенту → провести ревью → объяснить агенту, почему он на этот раз тупой → проверить фиксы → обновить спеки → прогнать на CI → повторить с новой задачей 🫠

В общем, чтобы было веселее, сделал скилл, который... ну, тут наверное проще показать, чем объяснять 🙈

#ИИ_инструменты