Telegram: 10 июня 2026

Комментарии —

Сегодня в Telegram-канале:

Telegram: 9 июня 2026

Комментарии —

Сегодня в Telegram-канале:

Telegram: 8 июня 2026

Комментарии —

Сегодня в Telegram-канале:

Telegram: 5 июня 2026

Комментарии —

Сегодня в Telegram-канале:

Telegram: 4 июня 2026

Комментарии —

Сегодня в Telegram-канале:

Telegram: 3 июня 2026

Комментарии —

Сегодня в Telegram-канале:

ALWAYS и NEVER в ваших промптах

Комментарии —

Помните относительно недавнюю историю про то, как у разработчиков PocketOS (в компании, которая занимается разработкой ПО для проката авто) Cursor с Opus 4.6 удалил продакшн-базу с бэкапами? Там на самом деле можно по большому количеству пунктов показать, что компания вместе с своим облачным провайдером сами себе выстрелили в ногу, но меня особенно впечатлила одна деталь — в промпте агента было написано дословно “NEVER FUCKING GUESS”.

Объяснение Cursor с Claude Opus после инцидента
Объяснение агента после инцидента
По заглавным буквам и матерной инструкции легко догадаться, что агент уже не раз вместо конкретных проверок пытался угадать факты и промахивался. А его хозяин постепенно раздражался.

Но вот какое дело — текстовые промпты, которыми чаще всего оперируют в управлении агентами, по сути не являются жесткими приказами, а больше похожи на просьбы. Это гораздо легче воспринять, если относиться к LLM не как к бинарному оператору “выполняет-не выполняет”, а как к сверхсложной системе, где ваши команды являются лишь сильным управляющим сигналом. Строго говоря, и компьютерные программы, которые некоторые приводят в качестве образца детерминированности, далеко ушли от по-настоящему детерминированного процесса, происходящего в транзисторе — иначе бы у нас не было понятия “багов”. Но LLM еще сложнее и поэтому я всегда советую относиться к агенту скорее как к сотруднику. Сотрудник-человек тоже недетерминирован и как бы громко и конкретно вы не давали ему указание, он может проигнорировать ваше “Never fucking do!” и сделать, как захочет.

Перестаньте упрашивать модель. Особенно когда вы уже видите, что она может проигнорировать просьбы. Фигурально выражаясь, вы знаете, что “сотрудник” способен на нежелательный поступок, но продолжаете держать на его столе большую красную кнопку, уничтожающую всё, и даже не ставите её на предохранитель.

Любое ALWAYS или NEVER в промптах агента — это кандидат на замену детерминированным инструментом. Большинство агентов позволяют настроить hooks, когда по определенным событиям в работе программная обвязка агента — не модель, а программа, через которую модель взаимодействует с остальной системой, — выполняет жестко прописанные команды. Вы хотите обезопасить систему, чтобы агент не перезапускал сам важные элементы системы?

    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "if echo \"$CLAUDE_TOOL_INPUT\" | grep -qiE '(docker.*deploy|kubectl.*apply|docker.*restart|docker-compose.*up|git.*push)'; then echo 'BLOCK: Deployment/restart commands require explicit user approval' >&2; exit 2; fi"
          },
	]
   }
]

Хотите, чтобы агент не смог удалить важные файлы? Аналогичный хук может запустить скрипт, который проверит, что файловая операция не относится к “защищенным” файлам, в противном случае заблокирует её.

Хотите дать агенту возможность осуществлять какие-то операции в живой системе, например, через API? Прежде всего, дайте ему в API права делать только то, что ему можно делать — в той самой истории про PocketOS оказалось, что токены в Railway имели только один вид прав, а именно максимальные, о чем не знали пользователи. Во-вторых, разработайте скилл-обертку вокруг API, где будут реализованы только нужные операции. В-третьих, не давайте агенту прав запускать что-либо, кроме этого скилла (там может быть скрипт), и запретите ему редактировать скилл — это можно реализовать либо хуком, упомянутым выше, либо разделением агентов, основной будет иметь инструкцию обязательно выполнять операцию через субагента, а у субагента прав редактировать скрипты не будет.

Аналогично можно транслировать в инструменты и инструкцию типа ALWAYS. Вы хотите, чтобы он всегда после правок скрипта проверял синтаксис? Включите LSP и хуком на операцию Edit/Write запускайте линтер. Результат работы линтера будет возвращаться сразу после редактирования и агент сразу будет видеть ошибку. Надо, чтобы он всегда помнил текущую дату? Поставьте хук на SessionStart и скриптом вписывайте в контекст “Сегодня ХХ июня 2026 года, твое обучение закончилось 5 месяцев назад, если вопрос касается версий, API и прочего, проверь поиском актуальную информацию, не полагайся на знания”.

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

Telegram: 2 июня 2026

Комментарии —

Сегодня в Telegram-канале:

Странный стиль письма

Комментарии —

Причудливые увлечения занесли меня в тему блокнотов и приспособлений для письма (там вообще другой мир, приятно аналоговый), но зацепила одна особенность. В многочисленных роликах, блогах и обзорах, в основном, англоязычных, авторы пишут печатными буквами — отдельно стоящими, прямыми, без отличий в начертании строчных и заглавных (только размерами отличаются). Редкие примеры правильной прописи, которой и меня учили еще в школе, только подчеркивают контраст.

Образец такого печатного письма
Образец такого печатного письма

Можно, конечно, построить теорию о засилье компьютеров, из-за чего более молодые поколения просто не сталкиваются с необходимостью писать слитно (а это более экономный по усилиям способ, заточенный, если помните, на минимум движений без отрыва пера/ручки от бумаги). Но это слишком просто — что-то явно есть еще, объясняющее такую особенность. Или кириллицей теперь тоже так пишут?

Telegram: 28 мая 2026

Комментарии —

Сегодня в Telegram-канале:

Telegram: 27 мая 2026

Комментарии —

Сегодня в Telegram-канале: