Почему микроменеджмент на самом деле делает ваших ИИ-агентов глупее

Откройте сегодня случайный system_prompt.txt в любом современном репозитории на GitHub, и что вы там увидите? Обычно это паническая простыня текста. "НЕ делай X. Ты ДОЛЖЕН вывести ровно три пункта. НИКОГДА не используй эту библиотеку."

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

Исторически эта паранойя вполне объяснима. Всего пару лет назад ранние LLM нужно было буквально водить за ручку, просто чтобы они не теряли нить разговора. Но времена изменились. Современные модели невероятно умны, а мы все еще пишем промпты так, будто программируем микроволновку из 80-х. Мы пытаемся захардкодить интеллект.

Недавно в Vercel произошло кое-что интересное, что отлично это доказывает. Их команда инженеров опубликовала разбор того, как они улучшили свой продукт v0, подробно описав весьма контринтуитивный шаг: они удалили 80% инструментов своего агента.

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

В этом кроется глубокий урок для всех, кто сейчас строит проекты с ИИ: Задавайте принципы, а не жесткие правила.

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

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

Плохой подход (Жесткие правила):

"Напиши функцию на Python для получения данных пользователя. Ты должен использовать библиотеку requests. Ты должен обрабатывать ошибки с помощью блока try/except. Ты должен вернуть словарь, содержащий ровно ключи 'name', 'email' и 'status'. Не используй async. Добавь комментарии к каждой строке."

Хороший подход (Принципы и цели):

"Напиши надежную функцию на Python для получения данных пользователя. Отдавай предпочтение современным стандартным библиотекам. Код должен быть production-ready, то есть корректно обрабатывать сбои сети и краевые случаи. Ставь читаемость и чистую архитектуру выше хитрых решений. Система-потребитель ожидает стандартные профили пользователей (name, email, status)."

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

Конечно, из этого правила есть одно важное исключение.

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

Если вы хотите прямо сегодня прокачать своих ИИ-ассистентов для написания кода, просто скопируйте и вставьте этот блок в ваш claude.md, memory.md или в главный системный промпт вашего агента:

## Prompt Writing Philosophy
When writing LLM prompts (system prompts, skill specs, subagent prompts): **give principles, not rigid rules.**
- Tell the LLM what good output looks like and why — let it figure out how
- Avoid prescribing exact fields, counts, or formats unless the output is a machine-consumed intermediate
- Exception: structured handoffs between agents can be rigid because downstream agents need consistent field names

Хватит пытаться микроменеджерить машину. Доверьтесь современным LLM. Они быстрее, умнее и бесконечно способнее, когда мы перестаем обращаться с ними как с несмышлеными детьми.