ЗС

Заработай с помощью ИИ AI От веб-кодинга к вайб-кодингу 🔥

Без категории · 1 ноября 2026 г.

Открыть канал в MAX

🤖 5 правил, по которым агент не превращается в спамера

🤖 5 правил, по которым агент не превращается в спамера Вчера DeepSeek выложил исследовательский прототип dsh-superagent — агента, который работает с GitHub-репозиторием проактивно. Сам код там спорный: это альфа-плагин для DeepSeek Harness, весь выложен за два с половиной часа, README прямо говорит, что многое в нём написали кодовые агенты и баги будут. Но вот что интересно. В репозитории есть отдельный документ с философией, и там написано про то, что обычно проговаривают вскользь: «Занимать как можно меньше человеческого внимания и давать как можно больше ценности» Дальше — пять конкретных правил, и каждое из них выводится прямо из кода. Не из маркетинга, а из архитектуры. Правило 1. Действовать только когда попросили Агент работает, если к нему обратился человек из разрешённого списка. Или если есть написанное вами же правило, которое разрешает такую работу. Причём проактивная работа по умолчанию не выполняется — она только записывается. Вы смотрите, что агент сделал бы, и если это нормально, разрешаете ему это в следующий раз. Это контринтуитивно. Мы привыкли, что агент-ассистент ждёт команды. Здесь наоборот: сначала докажи, что тебя можно выпустить без надзора. Правило 2. Молчать, пока работаешь Агент подтверждает запрос один раз и называет, что собирается сделать. Дальше — тишина. Он пишет снова только когда: результат готов, нужно решение человека, или он не смог закончить. Никаких «я начал», «сейчас посмотрю», «подождите минуту». Каждое сообщение стоит чужого внимания, и оно должно давать больше, чем стоит. Правило 3. Один вопрос за раз Не список из десяти вопросов в конце, а один конкретный вопрос в структурированном виде, чтобы он вообще дошёл до человека. Обратите внимание на деталь: если вопрос требует дизайнерского решения, агент останавливается и спрашивает. Он не принимает решение за вас и не идёт дальше наугад. Правило 4. Останавливаться по влиянию, а не по усилию Локальная правка доводится до состояния, которое можно посмотреть и принять. Изменение, требующее архитектурного решения, заканчивается ясным вопросом — и ждёт. Принцип рабочий. «Я старался и вот что получилось» — плохой результат. «Вот вариант, вот почему я остановился здесь, нужно твоё решение» — хороший. Правило 5. Расширять доверие постепенно Начинать с короткого списка разрешённых и с записи вместо действий. Расширять — только когда увидели, что агент сделал бы, и это выглядит правильно. И прямо в документации: не используйте его для объёма. Массовые pull request и рассылки съедают у команды больше, чем дают. мах