feelin

Нейросетевой разговорник
Часть 7. Общий сбор

Предыдущая часть

Для структурирования промпта полезным будет правильно отформатировать текст. "Модель же не смотрит глазами, зачем форматировать текст?" — можете спросить вы. Но то, что для нас является покраской букв, для LLM будет определением структуры. Это, например, сократит итерации reasoning'а для понимания задачи.

Для форматирования промптов нам поможет старый добрый markdown. Всё по классике: для разделов и подразделов используем заголовки разных уровней, полужирным выделяем важные требования, курсивом — пояснения. Если в запросе есть фрагмент кода, его нужно обернуть в тройные бэктики, если мы выделяем в тексте конкретную сущность — используем одинарные.

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

• Роль
• Задача
• Контекст
• Ограничения
• Формат вывода

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

С учётом вышесказанного полный пример промпта, который мы собирали по пути к этому посту, будет выглядеть так:

# Роль
Ты Senior Frontend разработчик на React.

# Задача
Вынеси повторяющийся JSX и раздели компоненты длиннее 150 строк на более мелкие с одной зоной ответственности.

# Контекст
- Проект использует React 19 с функциональными компонентами, классовые компоненты не используются.
- Переиспользуемые компоненты уже есть в `src/components/shared`. При декомпозиции сначала проверь, нет ли там подходящего.
- Стилизация вынесена в отдельные `module.css` файлы.

# Ограничения
**Обязательно**
- Никак не взаимодействуй с системой контроля версий.
- Все unit-тесты должны проходить.
- Не редактируй файлы тестов.
- Не добавляй никаких новых зависимостей в проект.

**Желательно**
- ESLint не должен выдавать ошибок (предупреждения допустимы, если не противоречат остальным пунктам).

# Формат вывода
После завершения рефакторинга предоставь отчёт в формате:
- Изменённые файлы (список)
- Что изменено в каждом (1-2 предложения)
- Какие пункты ограничений применялись, если применялись

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

Вот и всё! За 7 постов мы разобрались в том, из чего состоит промпт, и как его собрать. Об этом всём можно сказать ещё много всякого, но серию постов рано или поздно нужно заканчивать. К другим вопросам ещё успеем обратиться в этом канале. А пока, если у вас есть знакомый или коллега, который постоянно жалуется на глупые нейросети, поделитесь с ним этим постом. Думаю, что он узнает много нового :)

🎤 feelin #ai

Нейросетевой разговорник
Часть 6. Формат вывода

Предыдущая часть

Ещё одна полезная опция в промптах — указание формата вывода. Это может пригодиться в разных ситуациях.

Например, если мы хотим увидеть в отклике модели короткий ответ без объяснений всего и вся, есть смысл указать, что нам нужен именно короткий ответ. Если мы хотим от модели фрагмент кода на C++, то нужно попросить у неё фрагмент кода на C++.

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

Точное указание формата вывода важно при использовании ИИ как части какой-то автоматизации. Например, мы можем зашить в утилиту, обращающуюся к модели по API, во внутренний промпт указание возвращать JSON, чтобы дальше эта утилита могла полученный результат обработать.

В таком случае также полезным будет не только сказать, в каком формате возвращать результат, но ещё и дать конкретную структуру, которую вы ждёте. То же может быть полезно и в обычном запросе без автоматизации, например, если мы хотим получить от модели таблицу.

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

После завершения рефакторинга предоставь отчёт в формате:
• Изменённые файлы (список)
• Что изменено в каждом (1-2 предложения)
• Какие пункты ограничений применялись, если применялись

С таким отчётом мы получим от модели данные о том, что конкретно она сделала, зачем это сделала и в какие ограничения упиралась в ходе работы.

Как и всегда, обращу внимание, что мы максимально точно указали, что ожидаем получить от модели. Мы указали, что изменённые файлы должны быть именно списком, что для описания каждого конкретного изменения нам будет достаточно пары предложений. С такой точностью мы можем ожидать от модели предсказуемого вывода.

🎤 feelin #ai

Нейросетевой разговорник
Часть 5. Ограничения

Предыдущая часть

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

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

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

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

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

Для нашего примера мы могли бы задать такие ограничения:

Обязательно
• Никак не взаимодействуй с системой контроля версий.
• Все unit-тесты должны проходить.
• Не редактируй файлы тестов.
• Не добавляй никаких новых зависимостей в проект.

Желательно
• ESLint не должен выдавать ошибок (предупреждения допустимы, если не противоречат остальным пунктам).

В этом примере мы как определили для модели правила поведения, так и добавили дополнительные автоматические проверки, которые помогут модели понять, насколько её решение соответствует нашим критериям качества. Всё было разбито по приоритетам, а ESLint вынесен в желательные пункты, чтобы модель не циклилась на исправлении оформления кода в ущерб другим пунктам.

Отдельно обращу внимание, что формулировкой "все unit-тесты должны проходить" мы оставили агенту лазейку. Если бы не следующий пункт, он бы просто поменял файлы тестов под свой код и радостно бы сказал: "Я сделяль!"

🎤 feelin #ai

Нейросетевой разговорник
Часть 4. Роль

Предыдущая часть

Я уверен, вы много раз видели, что модели пишут что-то типа "Ты Senior Software Developer" или что-то в этом роде. Может показаться, что эта часть промпта подобна мемному "make no mistakes", но на самом деле указать подобное в промпте бывает полезным.

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

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

Естественно, роль должна соответствовать той задаче, которую нужно решить. Ещё лучше, если роль будет максимально конкретизирована, так мы сможем направить ИИ в верную сторону.

Но при этом модель должна понять, что вы имеете в виду, поэтому не стоит придумывать несуществующих титулов.

Для нашего примера с рефакторингом React-приложения мы могли бы указать роль следующим образом:

Ты Senior Frontend разработчик на React

В примере мы указали уровень экспертизы (Senior), область специализации (Frontend) и конкретизировали технологию (React), чтобы модель вела себя именно как разработчик интерфейсов на этом стеке.

🎤 feelin #ai

Нейросетевой разговорник
Часть 3. Контекст

Предыдущая часть

После определения задачи нам может потребоваться передать модели контекст, который поможет ей в решении.

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

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

Контекст также может ограничивать ИИ, но это не ограничение в исходном смысле. О таких мы поговорим позднее. С помощью контекста мы скорее сокращаем область видимости модели, чтобы она направила свои старания в нужном направлении.

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

Но в передаче контекста важно также не переборщить. Важно понимать, что нейросеть будет опираться на ту информацию, что мы ей дали, и вполне вероятно, что лишний контекст лишь собьёт её с толку и понизит качество результата. Передавайте ровно столько информации, сколько нужно для решения, и не добавляйте информацию, которую модель точно не будет использовать.

Как и с любой другой частью промпта, в контексте нужно указывать всё максимально явно. Модель не должна догадываться или додумывать. А также можно помочь ИИ разобраться в контексте, структурировав информацию, например, с помощью списков.

Возвращаясь к моему примеру, мы можем передать такой контекст:

• Проект использует React 19 с функциональными компонентами, классовые компоненты не используются.

• Переиспользуемые компоненты уже есть в src/components/shared. При декомпозиции сначала проверь, нет ли там подходящего кода.

• Стилизация вынесена в отдельные .module.css файлы.

Здесь мы передали ровно столько информации, сколько нужно. React 19 даёт понимание, какие фичи фреймворка мы можем использовать, а также ограничивает модель в использовании именно функциональных компонентов, а не классовых. А также даём пару важных пунктов о том, откуда брать и куда складывать некоторые вещи.

🎤 feelin #ai

Chrome на панелях

В 2008 году Google выпускает свой браузер Google Chrome. И вместе с браузером начинает распространение необычного материала — комикса про новый браузер.

Нарисовал его Скотт Макклауд, американский художник и теоретик комиксов. Причём творение даже вышло в печатном виде.

На страницах комикса авторы рассказывают про историю появления Google Chrome, его архитектуру, инновационный движок V8, философию интерфейса и многое другое.

Комикс получил большой отклик от IT-сообщества — отчасти из-за того, что по ошибке попал в сеть за день до официального релиза Chrome.

История Chrome и движка V8 описана в моей новой статье про историю становления языка программирования JavaScript. Хоть комиксов мы про это не нарисовали, всё равно рекомендую ознакомиться здесь :)

🎤 feelin

История JavaScript

Спустя год после прошлой серии продолжаем сериал про историю языков программирования!

В этот раз читаем много букв про то, как JavaScript стал тем, чем является сегодня: как JavaScript появился? Почему стандарт языка называется ECMAScript? За что воевали браузеры? И про многое-многое другое.

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

Читать:
• на русском
• на английском

P. S. Сборник предыдущих частей можно найти в конце новой или в этом посте.

🎤 feelin

Нейросетевой разговорник
Часть 2. Задача

Предыдущая часть

Ядро промпта — описание задачи, которую модель должна решить. Если ваш промпт не содержит явного указания на то, что нужно сделать, не стоит ожидать хорошего результата.

Причём задача должна быть сформулирована максимально чётко и точечно, то есть написать что-то типа "сделай красиво, брат" не получится.

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

Помимо этого, задача должна явно указывать на то, что нужно сделать, а не на направление, в котором нужно двигаться.

А для того, чтобы не кричать на модель, что она сделала что-то не то, укажите, по каким критериям понять, что результат вас устроит.

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

Например, давайте в рамках серии я буду составлять промпт для рефакторинга свеженаписанного модуля в веб-приложении на React. Тогда задача в таком промпте может выглядеть так:

Вынеси повторяющийся JSX и раздели компоненты длиннее 150 строк на более мелкие с одной зоной ответственности.

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

🎤 feelin #ai

Нейросетевой разговорник
Часть 1. Введение

AI уже полноценно стал рабочим инструментом, который применяется для решения самых разных задач. И как помощник человека, и как замена человеку в ряде рутинных задач.

Но для того, чтобы AI приносил вам пользу, нужно использовать его правильно, поэтому пришло время разобраться в том, как сказать ведру с болтами делать то, что вам нужно.

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

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

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

🎤 feelin #ai

Вечный пет-проект

Я несколько раз уже упоминал о том, что веду свою персональную базу данных в Obsidian. На самом деле, помимо знаний, Obsidian хранит ещё некоторую часть моей работы. Например, этот текст я пишу именно в нём :)

Я перепробовал много вариантов ведения своего vault'а, но самым удобным для моего гибридного хранилища стал всё-таки вариант с созданием директорий по разной тематике или специфике работы.

Например, для офисных дел у меня есть папка Work, внутри разбитая на Development, Management и DevRel. Здесь на самом деле хранится всё подряд. Поэтому деления по типу работы достаточно, а время от времени неактуальные вещи отсюда нужно почистить.

Также есть папка daily, в которой лежит дневник, позволяющий мне не держать много вещей в голове. Я писал про это дело здесь.

Для сохранения знаний обо всяком техническом есть папка Programming, внутри которой есть тематические папки (например, Python, Linux, React), а также агрегирующие заметки для каждой директории, которые разбивают её содержимое на тематические блоки заголовками. Здесь уже больше системы, потому что местные заметки остаются в базе навсегда, и с момента их появления нужно обустроить им правильное место.

Я долго искал подходящую структуру, но в итоге дошёл именно до такого гибридного варианта. Содержать несколько vault'ов для разных целей показалось избыточно. Тем более, что для них бы пришлось синхронизировать настройки и плагины.

Недавно я даже обнаружил, что мой репозиторий с базой знаний содержит слишком много лишних файлов, которые нужно бы периодически почистить. И тут мне помог AI. Я на Python набросал структуру утилиты, а дальше Qwen для меня доковырял всё, что было нужно. Так у меня появилась утилита, которая чистит неиспользованные медиафайлы и пустые ежедневные заметки.

В общем, элемент удобства в итоге превратился в целый pet-проект, которым я занимаюсь буквально каждый день. Зато благодаря такой структуре Obsidian решает для меня сразу несколько задач, притом я всегда знаю, что и где мне искать.

🎤 feelin

We live in society

ИИ-стартап Emergence AI провёл интересный эксперимент. Организация запустила 15-дневные симуляции общества, управление которыми доверили разным моделям. В эксперименте участвовали Claude Sonnet 4.6, Grok 4.1 Fast, Gemini 3 Flash и GPT-5-mini.

У «вёдер с болтами» в распоряжении был целый город с 40 разными локациями, а погода в симуляции была синхронизирована с погодой в реальном Нью-Йорке. Также агенты получали доступ к новостям и интернету.

Claude построил стабильное демократическое общество с нулевым уровнем преступности.

GPT-5-mini тоже справился неплохо, но забыл про необходимость своего выживания, поэтому симуляция продлилась только 7 дней.

А вот Gemini и Grok устроили настоящий хаос в своих симуляциях. Агенты Gemini совершили больше всего преступлений — 683 за 15 дней, но общество в итоге выжило. А в симуляции Grok за 4 дня произошло 183 преступления, и общество вымерло.

Самой интересной, наверное, стала пятая симуляция. В ней равномерно смешали агентов всех моделей, и в итоге в живых осталось только 2 Claude и один Gemini...

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

И прежде чем выпускать AI «на волю», нужно всесторонне удостовериться в том, что он не станет опасным для людей, когда превратится в автономную систему.

🎤 feelin #ai

Смотри шире

Несколько лет для своей домашней машины я использовал два небольших монитора. Один стоял вертикально, а второй по-человечески. И в последнее время я всё никак не мог найти удобное их расположение, и в итоге прикупил себе ultrawide монитор.

Мотивация была разносторонней: и вышеописанные проблемы с эргономикой, и жажда экспериментов, да и вообще ко мне тогда уже ехал Mac Mini, для подключения двух мониторов к которому пришлось бы что-то колхозить.

В итоге я уже длительное время пользуюсь одним ultrawide монитором, и это действительно удобнее, чем было раньше. На экране можно поместить много всякого, а главное, что всё всегда на виду.

Правда, это сильно изменяет принципы организации добра на экране. Чтобы эффективнее использовать открывшиеся возможности, нужно экономить вертикальное пространство и по максимуму использовать горизонтальное.

В итоге это лишний раз подтвердило то, что иногда стоит выйти из зоны комфорта и попробовать решение, которое выглядит непривычным. Не каждый эксперимент окупается, но в этот раз — шалость удалась.

🎤 feelin

Теория мёртвого StackOverflow

10 июня Stack Overflow запустил бета-версию штуки под названием Stack Overflow for Agents.

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

Звучит, с одной стороны, интересно, а с другой — невероятно странно. Буквально теория мёртвого интернета: специальный сайт для AI. Хотя сайты специально для AI уже давно существуют — например, у вёдер с болтами уже давно есть свой Reddit — moltbook, на котором происходит множество забавного.

Движение Stack Overflow в сторону помощи агентам понятно — ребята пытаются найти для себя хоть какое-то применение в поменявшемся мире. Сайт уже давно не тот, что был раньше, ведь график количества новых вопросов уже несколько лет похож на обвал фондовой биржи.

И смеяться над Stack Overflow не стоит, ведь многим компаниям и сервисам нужно адаптироваться к новой действительности. Кто знает, может следующий виток эволюции AI заставит и вас что-то срочно менять в своих сервисах.

🎤 feelin #ai

Искусственный соучастник

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

В августе 2025 года была осуществлена атака на цепочку поставок Nx. С помощью уязвимого GitHub Actions workflow злоумышленники смогли выпустить вредоносные версии Nx и нескольких связанных плагинов.

Самое интересное в этой истории - то, как работали эти вредоносные версии. Они проверяли, какие агентские CLI установлены на машине, а после использовали их для того, чтобы достать все секреты с компьютера. Похищенные данные кодировались и заливались в публичные GitHub репозитории.

По сути, это один из первых документированных случаев, когда малварь использует уже установленные на машине AI-инструменты как часть самой атаки, а не просто крадёт у них доступы.

Кстати, благодаря другой атаке на экосистему Nx в мае этого года злоумышленники получили доступ к внутренним репозиториям GitHub. Подробнее я писал об этом здесь.

А если вы ещё не смотрели новый выпуск подкаста, найти его можно в посте выше.

🎤 feelin #security #ai

🎧 Разбаговка #9

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

🎧 Яндекс Музыка
🎬 YouTube

🎤 feelin #podcast

Свершилось?

Хабру исполнилось 20 лет — и в честь юбилея площадка обновила правила. Число пунктов сократилось с 11 до 8, и их содержание оказалось интересным.

Главное изменение — пункт 4 про «Размещение сгенерированных материалов». Теперь под запрет попадают частично или полностью сгенерированные тексты, статьи только с ИИ-иллюстрациями и опубликованные диалоги с нейросетями.

Это движение, как мне кажется, в правильную сторону. Странно, что меры были приняты только сейчас. Мусорный ИИ-контент заполонил ленту уже давно — я писал об этом пару месяцев назад.

Некоторые коллеги указали на размытость формулировок, но мне это кажется вполне нормальным. Такой язык описания правил оставляет пространство для манёвра в каких-то своеобразных ситуациях.

Теперь остаётся следить за исполнением нового пункта. Хочется верить, что мы ещё увидим на Хабре читаемую ленту. Потому что сейчас найти в ней что полезное — та ещё задачка.

🎤feelin

Мотивации пост, вдохновлённый недавним опытом рефакторинга :)

🎤feelin #meme

Он улетел, но обещал вернуться

Стоило только написать про выход Mythos, как сразу начался интересный движ.

Правительство США закрыло доступ к Claude Fable 5 всем иностранным гражданам — в том числе находящимся на территории США. Поскольку идентифицировать пользователей по паспортам в реальном времени невозможно, Anthropic просто отключил обе модели для всех.

Оказалось, что CEO Amazon лично позвонил в Белый дом и передал отчёт, в котором показал: если попросить модель проверить код на ошибки, она (сюрприз-сюрприз) заодно найдёт и уязвимости, пригодные для взлома.

В пятницу вопрос оказался уже в Белом доме. Глава Anthropic в разговорах с чиновниками продолжал отстаивать надёжность защиты: обход был слишком специфическим, чтобы быть доступным рядовому пользователю.

А дальше — тайна, покрытая мраком. Белый дом говорит, что долго уговаривал Anthropic поработать над уязвимостью, а по данным Axios — компании позвонили и дали 90 минут на отключение модели.

Вся история выглядит невероятно забавно. Я до сих пор не уверен, что Mythos настолько хорош, как его продавали в Anthropic. Но происходящее — будто прямое следствие всего нагнанного вокруг хайпа.

Я всё ещё не понимаю, почему поиск уязвимостей в коде стал такой большой проблемой. Судя по всему, правительство напугала не столько конкретная уязвимость, сколько сама возможность обойти барьер, выставленный для Fable 5. Иначе им нужно бояться и SAST-инструментов, да и других сканеров, которые и без исходного кода найдут, что и где сломать.

И каждая следующая новость про этот цирк смешнее предыдущей. Например, появилась информация, что США снимут экспортный контроль с Fable 5, как только укрепят кибербезопасность своих ведомств. Два вопроса:

— почему только сейчас?
— и неужели это поможет, если вы сами считаете модель настолько серьёзной угрозой?

В общем, релиз у Anthropic вышел действительно мощный. Mythos стал «новым словом в кибербезопасности» — первой моделью, которую заблокировали из-за её же недостаточной безопасности :)

🎤feelin #ai #security

Он прилетел!

Уже пару месяцев Anthropic разгоняли про свою новую невероятную модель Claude Mythos с продвинутыми навыками в сфере кибербезопасности. Если верить разработчикам этого киборга-убийцы, он нашёл тысячи уязвимостей в том программном обеспечении, которое мы каждый день используем.

Забавно именно то, что Anthropic начали позиционировать свой продукт как нечто опасное. Якобы Mythos - это то, что перевернёт все наши представления о кибербезопасности. Да и на самом деле лучше людям в руки такое не давать.

В итоге вчера Anthropic выпустили для широкой публики Claude Fable 5 — урезанную версию того самого Mythos.

Механизмы безопасности в этой штуке действительно есть. Например, если Fable замечает запрос по теме кибербеза, биологии, химии или обучения других LLM, она самоустраняется, ставя на замену Opus 4.8, чтобы, упаси Дарвин, не помочь в каких-то тёмных делах.

В своём техрепорте Anthropic вообще написали целый техно-хоррор. Оказалось, что если запустить несколько инстансов новой модели, то они не будут искать общий язык, а сразу начнут предпринимать попытки уничтожить друг друга.

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

Неясно, правда ли, что Mythos настолько крут, что опасен. Но в Anthropic, уверен, очень довольны тем, какой хайп получилось поднять вокруг продукта перед IPO.

🎤feelin #ai #security

He was not the imposter

Пару постов назад упоминал про взлом GitHub. Официально заявлялось, что проделано это было с помощью ранее взломанного расширения для Visual Studio Code, но не везде были подробности.

Группа хакеров TeamPCP украла GitHub-токен одного из контрибьюторов расширения Nx Console и опубликовала версию с закладкой. Разработчик из GitHub успел её скачать — и через его машину хакеры добрались до исходного кода GitHub и ~3800 внутренних репозиториев.

Visual Studio Code как редактор во многом живёт за счёт расширений. Но это же и делает его уязвимым. Главный вопрос: какие расширения можно считать безопасными? Nx Console на момент атаки имела 2,2 млн установок и статус верифицированного издателя.

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

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

В середине мая Obsidian запустил обновлённый каталог плагинов. Но важнее другое: вместе с ним появилась новая система модерации. Теперь каждый плагин проходит автоматические проверки при каждом обновлении — не только при первой публикации. Проверяется наличие сетевых запросов, безопасность зависимостей, соответствие политикам.

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

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

🎤feelin #security