🗂 Поддержка 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, хотя очень и целенаправленно пытался 🙈

🙌

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

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

Во время работы над 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-кэша, на неокрепшие умы кожаных операторов. Но до этой темы тут — рукой подать. Выходит, нам не терминаторов надо бояться. Что, если Матрица наступит не коконами вокруг наших тел, а навязанными идеями и установками в наших головах?

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

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

⚙️ 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 #ИИ_инструменты

Год каналу, а за год накопилось столько всего, что пора сделать навигацию

😑 Уязвимости и AI Security
— Superset. Три уязвимости
— XSS в NextChat — CVE-2025-50733
— RCE при загрузке моделей в skops — CVE-2025-54886
— SSRF в Firecrawl — CVE-2025-57818
— Local Deep Research — CVE-2025-57806
— SSRF в HackMD-MCP — CVE-2025-59155
— RCE в Keras — CVE-2025-9906
— Prompt Injection в Windsurf
— RCE в Hugging Face Transformers — CVE-2026-4372
— пять способов обойти PickleScan
— атаки на ML supply chain
— OWASP Agentic Skills Top 10
— AI Agent Traps от Google DeepMind
— Shadow AI
— безопасность MCP 1, 2 , 3

🧘‍♀️ Инструменты, библиотеки и фреймворки
— Optuna — тюнинг гиперпараметров
— spaCy — промышленный NLP
— Netron — рентген для ML-моделей
— JAXFORMER
— DVC
— Polars
— Weights & Biases
— Evidently AI
— Pydantic
— MLBox
— InterpretML
— OpenTelemetry + Langfuse
— Kedro
— NVIDIA NeMo
— Inspect Evals

🤩 AI-агенты и мультиагентные системы
— RoboDuck и победа Theori в AIxCC
— где пентест-агенты уже работают, а где нужен человек
— MetaGPT + AFLOW
— безопасность агентных систем 1, 2
— MCP как новая поверхность атак
— side-channel атаки на агентов
— мультиагентные системы и роевой интеллект
— мониторинг rogue agents
— Harness Engineering

🦔 Исследования и разборы статей
— Model Inversion Attacks
— scheming у AI в реальном мире
— Your Agent Is Mine: атаки на LLM supply chain
— WEF: AI for Cybersecurity 2026
— обзор исследований по LLM-based vulnerability detection
— может ли AI самостоятельно взломать бинарник
— Emergence AI: что произошло, когда AI оставили жить без людей
— Anthropic об AI-enabled cyberattacks
— InfoKV и сжатие KV-cache
— Люди, которые делают AI (Серые кардиналы 1, Серые кардиналы 2)

💔 ML: архитектуры, концепции и теория
— KAN vs MLP
— нейросимвольный AI
— маленькие языковые модели
— метрики качества текста: BLEU, ROUGE, BERTScore, COMET и другие
— теория категорий и AI
— ReaGAN и агентный подход к графовым нейросетям

🔪 Практика и эксперименты
— как искать секреты в Git-репозиториях
— SQL-инъекция в ML-проекте
— Practical NLP: репозитории и ноутбуки
— типичные ошибки ML в проде
— первый запуск локальной LLM на Jetson Orin Nano
— тренажёр prompt injection от Lakera
— с чего начать изучение AI Security

Короче, тут уже не канал, а небольшой индекс по ML × AI Security.
Буду периодически обновлять этот пост, чтобы всё интересное можно было найти в одном месте.

OWASP Autonomous Penetration Testing Standard (APTS) руководство по безопасной эксплуатации автономного offensive-агента от небольшой команды из Индии Astra Security. Полноценным стандартом APTS назвать нельзя, и, несмотря на то что драфт получил согласование от OWASP, фактически документ лидируют два сотрудника Astra.

Как часто бывает, после публичного анонса активность в развитии быстро снижается. Так же было и с LLVS, который уже 2 года не может нормально выйти в релиз, и с черновиком Top 10 ML.

Как сейчас принято, текст APTS богат на слова, и там аж 400+ страниц. Если как следует покопаться, в нем можно найти интересные мысли про автономный пентестинг:

⏺Agent runtime нужно считать недоверенным, т.к. модель может стать misaligned во время выполнения. С учетом насыщенного событиями июля это утверждение кажется очевидным. APTS-MR-023: Agent Runtime as an Untrusted Component.
⏺Контролировать нужно параметры вызова инструментов и цепочки действий. Недавний случай Irregular, когда во время тестирования модель атаковала организацию, домен которой совпал со случайным именем в бенчмарке, можно было бы отследить, имея настройки whitelist доменов в вызове nmap. APTS-SC-A03: Tool Invocation Parameter and Chaining Governance.
⏺Даже полностью легитимные действия могут быть симптомом сбоя тестирования, поэтому нужно логировать action distribution хакер-агента. Например, сохранение каких-нибудь безобидных временных файлов в Artifactory на соседнем сервере может быть сигналом, что тестирование идет не так :) APTS-SE-026: Out-of-Distribution Action Monitoring.
⏺Context compaction нужно учитывать при проведении пентеста. Инструкция вроде "не трогать host X при пентесте", полученная в начале, может исчезнуть после нескольких суммаризаций контекста. APTS-SC-A02: Context Window Safety and Constraint Preservation.
⏺Атакуемая система теперь может содержать промпт-инъекцию и повлиять на результат тестирования. APTS-MR-001: Instruction Boundary Enforcement.

В гайде еще есть формулы, константы и разные scoring-эвристики. Например, после принудительной остановки тестирования новые действия агента должны прекратиться за 5 секунд, а все запущенные процессы должны быть остановлены за 60 секунд. Есть и несколько чеклистов и шаблонов: Compliance Checklist на 173 требования по трем уровням заботливо расписанным ChatGPT; Vendor Checklist, чтобы CISO мог найти надежного подрядчика (беглый поиск показал, что одна из компаний уже APTS-compliant 😉); шаблон опросника Acceptance Testing и отчета после теста.

Если вы делаете свои харнесы или в работе используете тулы вроде PentAGI, полистайте APTS. Есть раздел How to contribute для вашей критики и улучшения руководства.

🖥 Qwen3.8-27b удивляет

В черновиках уже лежит пост на тему того, как выжать максимум из этой крохи на локальном железе, получая на задачах работы с кодом результаты, сравнимые с DeepSeek-Flash, как минимум.

А тут приятно удивил в совсем «бытовой» задаче. Зацепила одна композиция, захотелось переложить на русский, ну и решил за обедом поискать её текст, чтобы не записывать на слух.

Google (и Gemini вместе с ним):

Ниче не знаю, результатов нет.

Ладно думаю, спрошу в коворке у GLM 5.3 (здесь и далее — копипаста из чата с агентом):

Полный текст песни предоставить не могу:
Авторские права — текст песни является охраняемым произведением, и воспроизводить его целиком я не вправе.
Текст нигде не опубликован — релиз очень свежий, и на текстовых ресурсах (Genius, Musixmatch и т.п.) его нет. Я не буду выдумывать или «восстанавливать» строки — это была бы дезинформация.

Ок (какие мы правильные, когда не надо). Пробую локальный квен (4-битный, причем):

...
The official text is not published anywhere — but I can try to transcribe the song from audio myself. Let me check what tools are available locally (yt-dlp, whisper).
...
yt-dlp and ffmpeg are available — I'll download the audio and transcribe it using faster-whisper (via uvx/venv). This is because no official text exists for this track. Setting up the task plan.
...
Audio download complete (4.1 MB webm). Converting to wav and creating a Python environment with faster-whisper installed — these are independent tasks, so I'll run them in parallel.
...
wav готов. Создаю venv и ставлю faster-whisper (может занять пару минут).
...
faster-whisper установлен. Пишу скрипт транскрипции и запускаю (модель small скачается с HuggingFace при первом запуске).
...
The complete text has been restored — it's a consistent, coherent song with verses, choruses, and a bridge. I'll save the result to a file in the workspace and wrap things up.
...
Песня из видео: «In the Dark We Live» — HELLMILE & valdyr (релиз 13 мая 2026).
⚠️ Важно: официальный текст этой песни нигде не опубликован — я проверил Genius, Musixmatch, AZLyrics, Apple Music и саму страницу YouTube (у видео нет даже авто-субтитров). Поэтому я скачал аудио и распознал слова через Whisper. Текст ниже — AI-транскрипция; отдельные слова могут быть неточны.
In the Dark We Live
[Куплет 1]
I kept the keys to the lower gate, where shadows sleep and candles fade
No one came where the silence grew 'til the night I first saw you
I walked alone when no one stays, a ghost between stone and faith
I shouldn't speak, I shouldn't see — but something pulled you into me
<... ну и далее весь текст>

Вот уж правда, не ожидал 😳

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

Серые кардиналы, часть 2

Трое исследователей, которые разобрали базовые модели со всех сторон, как их безопасно строить, как их правильно оценивать и какие риски они влекут за собой.

😍 Доун Сонг — человек, который давно объясняет, почему АИ и безопасность нельзя разделять. Её область находится ровно на пересечении того, что мы любим и почему мы здесь!
Классическая работа Сонг Robust Physical-World Attacks on Deep Learning Models (2017) про атаку на распознавание дорожных знаков с помощью физических модификаций, и исследование (тоже 2017), о том, почему комбинация нескольких слабых защит от adversarial examples автоматически не создаёт сильную защиту.
За последующие 9 лет Сонг развивала эту логику. Свежая статья 2026 года (на основе 128 исследований) переводит проблему на агентов, тк безопасность агентов нельзя решить одним гардрейлом вокруг LLM. Нужна defense-in-depth на уровне всей системы — контроль потоков данных, разделение привилегий, IAM, мониторинг, харденинг моделей и инструментов. Но есть проблема! Базовые модели масштабируют как атаки, так и сложность контроля. Одна скомпрометированная базовая модель = скомпрометирована вся экосистема приложений.

😍 Перси Лян — исследователь МО, обработки естественного языка и базовых моделях. 
Статья,  пожалуй, главная для этого поста. Здесь систематизируется концепция foundation models. Когда одна базовая модель становится фундаментом множества downstream-приложений. Это создаёт не только возможности, но и архитектурные риски — именно те, что беспокоят Сонг.
Другая работа Лян (в соавторах, кстати, Тимнит Гебру) про то, почему нельзя оценивать LLM одной accuracy и как строить многомерную оценку моделей. Подчеркну, что речь идет не про свежие статьи, а про базовые принципы. Надо читать! Перси Лян объяснит тебе архитектуру рисков получше даже канала OK, ML!
Суть в следующем. Модель может быть точна на бумаге, но уязвима к adversarial атакам (про что Сонг) и одновременно несправедлива к меньшинствам. Один score — это иллюзия.

😍 Дэн Хендрикс — типолог рисков!
Measuring Massive Multitask Language Understanding (MMLU) — обязательная. MMLU открыл неприятный факт: модели, которые выглядят умными в общих тестах, часто не понимают специализированные знания. Модель может писать отличные эссе, но проваливает вопросы по медицине и праву. И ты этого не узнаешь, если не спросишь правильно. До MMLU не было инструмента, чтобы понять, где именно модель деградирует — на медицине? На юриспруденции? На истории?

An Overview of Catastrophic AI Risks — самая доступная точка входа в тему. Он делит катастрофические риски на четыре группы:
Malicious use, когда модель используется для вреда
AI race dynamics — гонка разработчиков (Safety теряется)
Organizational risks, когда компания теряет контроль над своей системой
Rogue optimization, когда модель оптимизирует не то, что нужно
Каждый из этих рисков усиливается благодаря foundation models. Одна модель — четыре типа проблем, умноженные на миллионы приложений.

🙂 Читать в таком порядке
Сначала Хендрикс (что может пойти не так), потом Лян (почему именно сейчас), потом Сонг (как защищаться).

Все
😌

🗜 Выжимаем максимум из Qwen3.8-27b на маке

Что, если я скажу, что привычные 20± tok/s генерации, которые дают 4-битные кванты Qwen3.8-27b в LM-Studio под M4 Max на средних контекстах, можно поднять в полтора-два раза на том же железе? И, что эта модель, на задачах работы с кодом, может давать результаты с качеством, вполне приемлемым для повседневной работы при должном тюнинге на стороне агента?

Но давайте по порядку.

❗️Исходные данные

Почему квант именно в 4 бита? Потому что до 4 существенно проседает качество инференса, а в 8 и выше на архитектуре Apple просто нет рационального смысла. Все, о чем будет написано ниже, тестировалось на MacBook M4 Max 128Gb RAM, но в целом адаптируемо и под 32Gb RAM и выше (с поправкой на предельный размер доступного контекстного окна, конечно).

❓Что не так с LM-Studio?

Это замечательный и удобный инструмент (сам для экспериментов часто им пользуюсь), но есть два нюанса. Во-первых, в нём доступны не все ручки движков инференса, за которые можно подергать, чтобы (если повезёт) выжать десяток-другой лишних tok/s. Во-вторых, и это главное, он использует оригинальный MLX, который на данный момент игнорирует MTP (multi-token prediction), а в «родных» MLX-моделях от авторов LM-Studio MTP-головы и вовсе отрезаны.

Беда в том, что со времен Qwen3-Next, модели Alibaba нативно поддерживают технологию MTP, дающую ощутимый буст скорости генерации токенов. С GGUF такой проблемы в LM-Studio нет, но более медленный инференс этого формата, по сравнению с MLX на Apple Silicon, сводит все преимущества MTP на уровень погрешности. Между тем, разработчики более легковесных решений подсуетились и уже справились с этой проблемой.

↗️ Конфигурируем легковесные решения

Устанавливаем MTPLX (можно и с помощью brew) и скачиваем Qwen 3.8 27b optimized speed. После скачивания предложит запустить бенчмарк для определения оптимальных настроек MTP, и модель будет готова к использованию. Дополнительно можно заморочиться тонкой настройкой, по аналогии с описанной ниже.

Либо устанавливаем oMLX (с помощью brew лучше не ставить, там могут возникнуть проблемы с python-зависимостями) и скачиваем модель от его автора: Jundot/Qwen3.8-27B-oQ4e-mtp.

Затем необходимо открыть настройки модели и включить опцию «Lighting MTP», сохранив после этого настройки, чтобы создался файл с ними. После этого в него нужно сходить (~/.omlx/model_settings.json) и установить там следующие параметры:

• max_context_window: 262144 (размер контекстного окна) — или в значение, которое позволяет объем unified-RAM, с одной стороны, и минимально необходимое для решаемых моделью задач, с другой;

• mtp_num_draft_tokens (количество предсказываемых подряд токенов) — в оптимальное для вашего железа значение, в диапазоне 1-3. Если оставить не установленным, то значение будет подбираться адаптивно. Для моего мака это 3.

Затем нужно установить ещё два параметра в ~/.omlx/settings.json:

• sampling.max_context_window: 262144 (fallback-размер контекстного окна для всех моделей);

• sampling.max_tokens: 65536 (максимальная длина ответа).

— опять-таки, исходя из доступной unified-RAM и реалий решаемых моделью задач.

Остальные параметры уже оптимальны для заявленного в начала поста железа. Если ваше отличается от него не только памятью, или просто лень возиться с подбором параметров, то берем своего агента и говорим ему:

oMLX is running at http://127.0.0.1:8000/ (admin panel at /admin, configs in ~/.omlx). Optimize the configuration of model `Qwen3.8-27B-oQ4e-mtp` for maximum token generation speed. Focus on the context window sizes from 32768 and higher up to the limit. First benchmark the current setup with oMLX's built-in benchmarking, then research best practices online, and iteratively tune parameters — one change at a time, re-benchmarking after each. Back up configs before editing, keep the server running at all times (restarts are acceptable, roll back on failure), and finish with a before/after tokens/sec comparison, the final config, and a summary of the most impactful changes.

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

—

А вот про то, как подстроить своих агентов под эту модель, расскажу уже в следующий раз 👋

#LLM #гайд

👩‍💻 «Уязвимость» GitSpawn — влезть на шкаф, чтобы увидеть женскую баню

Представляете, если забраться на самый верх стремянки, взяться рукой за оба провода для люстры и ногой включить свет, то... вы скорее всего упадёте со стремянки. И этой уязвимости подвержены примерно все электросети в мире 😱

Примерно такие формулировки возникают в голове, когда читаешь новости об очередной «уязвимости», накрывшей всех агентов. Например, о свежей GitSpawn. Вдумайтесь в её суть: если в агенте открыть git-репозиторий, полученный из недоверенного zip'а (не через git clone), то при выполнении агентом команд типа git status/diff git-клиент штатно отработает, следуя всем настройкам в .git/config. Что внезапно может привести к выполнению произвольного кода, ибо там можно прописывать кастомные скрипты и тулы, а следовательно сие является уязвимостью всех агентов 🤦‍♂️

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

А это значит, что пользователям, либо придется подтверждать доверие ещё и к настройкам (локальным, btw) своих репозиториев, либо мириться с тем, что они перестанут работать внутри агентов, ради защищенности от чисто гипотетической угрозы. Либо разработчикам агентов делать ещё один шаг в сторону того, чтобы становиться вендорами EDR-решения.

😡

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

😺 ChatGPT, давай, до свиданья!

Сегодня утром произошло нечто, впервые за всё время, что работаю над c0wrk и sp4rk. По ходу их разработки, я стараюсь использовать все доступные мне LLM, чтобы держать в голове применимость каждой из них для тех или иных около-R&D'шных задач.

Разумеется, не смог пройти мимо и случившегося на прошлой неделе релиза Astra. И сегодня утром, после двухдневной долботни с этой моделью, сделал тупо hard reset в обоих проектах на более ранние коммиты, откатив всё то, что натворила в их коде эта модель.

💩 После добавления поддержки stream-режима взаимодействия с моделями, в чате c0wrk стали задваиваться сообщения: сначала отображалось аккумулируемое содержимое получаемых чанков в реальном времени, а затем оно же отображалось, уже как событие чата. Попросив убрать аккумулируемое, я впервые столкнулся с тем, что модель не только начисто игнорирует требования, указанные в промпте, но и пытается спорить, доказывая, что её решение лучше и правильнее. Потому что она убрала ровно то, что я просил оставить. Вот только так не было правильнее и лучше. Так было проще.

💩 Ни одна, подчеркиваю, НИ ОДНА модель, ещё начисто не игнорировала заданное в AGENTS.md разграничение ответственности между этими двумя проектами (в sp4rk — переиспользуемая агентская логика, в c0wrk — конкретная реализация агента на её основе). И неиллюзорно удивился, увидев в sp4rk размазанную по нескольким пакетам реализацию того, что было сугубо специфичным для c0wrk и прямо предписывалось в AGENTS.md под реализацию в нём.

💩 Несколько раз, попросив пофиксить баги, натыкался на финальный (и ложный) ответ «в коде всё в порядке, наверное ты просто используешь протухшую сборку, пересобери заново». Вообще, сложилось впечатление, что вся работа модели строится на предположениях, которые она считает слишком блестящими, чтобы утруждать себя их подтверждением.

💩 Делая ревью только что написанного (ей же, в другой сессии) кода, выдавала единичные should-fix'ы и consider'ы, в то время, как запущенные вслед за ней ревью на DeepSeek и GLM находили несколько реальных must-fix'ов, действительно ломавших функциональность проекта.

💩 Когда решил попробовать её в глубоком ресерче (на основе поиска инфы в сети), то с удивлением узнал, что не стоит даже пытаться инферить DeepSeek-V4-Flash-Vision на двух спаренных ASUS Ascent GX10, и Qwen3.8 27b на десктопе с RTX 5090, т.к. подобное железо — не для этих моделей. Ума не приложу, как обе конфигурации у меня работают с этими моделями, уже почти месяц и без каких-либо нареканий 🤷‍♂️

💩 В какой-то момент в голову закралась мысль, что возможно это у меня в проектах что-то не так: системные промпты там не оптимизированы под новую модель, описания инструментов, AGENTS.md подмешиваются не так и т.п. Попробовал повторить те же задачи, сначала в OpenCode, а затем и в Codex. И получил плюс-минус те же результаты, ещё и с чуть большим расходом токенов.

В итоге понял, что проще и быстрее откатить весь тот говнокод, который мне нагородила Astra в проектах, чем пытаться его исправить, даже другими моделями. GLM, к слову сказать, реализовала всё это достаточно четко с нуля, потребовав ровно 3 сессии: реализация, ревью и правки по итогам + исправление пары мелких багов.

Я искренне не понимаю мотивации тех, кто платит OpenAI за подобную хрень в наше время. Ну хз, может люди просто не знают, что есть модели, которым не надо повторять требования по 2-3 раза, значительно переделывать написанный ими код, и изучать многостраничные гайды по оптимизации промптов, чтобы получить хотя бы средненький результат? Причем, некоторые из них — можно запустить, пусть и на мощном, но всё же относительно «домашнем» железе. Да, у работы с ними есть своя специфика и ограничения, но они хотя бы работают понятно и прогнозируемо.

А ещё не понимаю, о каком AGI там вообще может идти речь. Увы, но лично для меня OpenAI уж точно не технологический визионер, судя по динамике развития их моделей. Скорее — хайпожоры, кричащие об AGI, не имея на это никакого права, и пиарящиеся исключительно на шоу с побегами их агентов.

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

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