Пост #357

Чем длиннее вы обьясняете AI, что делать, тем выше шанс купить себе дорогую иллюзию контроля. На [Habr](https://habr.com/ru/articles/1031498/?utm_campaign=1031498&utm_source=habrahabr&utm_medium=rss) человек вскрыл свой рабочий скилл: 663 строки, 36 капс-блоков, MANDATORY, MUST, NO EXCEPTIONS. Такой регламент уже выглядит не как инструкция, а как корпоративная паника, уложенная в текст. И да, для GPT-5.5 это оказалось проблемой. Тут важна не сама цифра 663. В [arXiv](https://arxiv.org/abs/2605.00817) показали более узкую вещь: когда у модели растет длина процедуры и появляются зависимости между шагами, ей заметно тяжелее держать ход выполнения. То есть дело не в том, что "LLM не умеют следовать инструкциям" вообще. Дело в том, что длинный, перегруженный процесс не становится надежнее только потому, что вы написали его капсом. Вот где начинается тема денег. Если вы скармливаете модели толстый регламент и ждете "автоматизации процесса", вы не обязательно автоматизируете процесс. Иногда вы просто автоматизируете видимость послушания. Снаружи все прилично. Внутри модель где-то потеряла нить, но ответ уже приехал, бодрый, уверенный, с интерфейсом. Поэтому куда практичнее сначала ставить AI не на место исполнителя, а на место вредного внутреннего критика. В [Техномотеле](https://t.me/technomotel/18572) как раз разбирали скилл для Codex: дать идею, получить разбор слабых мест, спроса, конкурентов, набросок MVP. Вот это пока звучит взрослее, чем еще один промпт-комбайн на 700 строк. Короче: если у вас сырой MVP, спорная идея или хрупкая логика продукта, просите модель сначала ломать, а не строить. Искать дыры. Давить на уязвимости. Проверять, где вся конструкция держится на "ну вроде должно работать". Слепая автоматизация любит красивые обещания. Проверка на слабые места обычно дешевле. И, что неприятно, честнее.