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

Андрей Карпати пожаловался в посте, который широко разошёлся, что модели для программирования «делают за вас неверные предположения и просто продолжают действовать исходя из них, ничего не проверяя». Кто-то превратил эту мысль в файл с правилами для Claude Code, и теперь разные его версии вставляют во множество промптов для агентов: думай перед тем, как писать код, не усложняй, вноси точечные изменения, заранее определи критерии успеха и проверяй результат, пока не убедишься, что всё работает. Логика кажется очевидной. Агенты ошибаются, потому что несутся вперёд, не проверяя себя; значит, если заставить их притормозить и действовать осторожнее, результат должен стать лучше.

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

Что именно я тестировал

Файл взят из репозитория сообщества, где наблюдение Карпати превратили в четыре правила дисциплины. Я дословно добавил весь файл в промпт агента. Вот эти правила:

1. Думай перед тем, как писать код. Не делай предположений. Не скрывай неуверенность. Явно обозначай компромиссы.

• Явно формулируй свои предположения; если не уверен, спроси.

• Если возможны разные трактовки, перечисли их, а не выбирай одну молча.

• Если есть более простой подход, скажи об этом; при необходимости возрази.

• Если что-то непонятно, остановись, объясни, что именно вызывает вопросы, и спроси.

2. Сначала простота. Минимум кода, достаточный для решения задачи. Ничего «на будущее».

• Не добавляй функций сверх того, что попросили; не создавай абстракции ради кода, который используется один раз.

• Не добавляй гибкость и настройки, которых никто не просил.

• Не обрабатывай сценарии, которые в принципе невозможны.

• Если написал 200 строк там, где можно обойтись 50, перепиши.

3. Точечные изменения. Меняй только то, что необходимо. Убирай только то, что испортил сам.

• Не улучшай попутно соседний код, комментарии или форматирование.

• Не рефактори то, что и так работает; придерживайся существующего стиля.

• Удаляй только те импорты и переменные, которые стали неиспользуемыми из-за твоих собственных изменений.

4. Выполнение с ориентацией на результат. Определи критерии успеха. Повторяй цикл, пока результат не будет проверен.

• «Исправить баг» превращается в «написать тест, который воспроизводит баг, а затем добиться, чтобы он проходил».

• Чёткие критерии успеха позволяют агенту самостоятельно повторять этот цикл.

Это реконструкция от энтузиастов, а не файл самого Карпати. Но люди вставляют в промпты именно её, поэтому тестировать имеет смысл именно её.

Сравнение попарное: каждая задача запускается дважды – один раз с обычным агентом по умолчанию, второй раз с тем же агентом плюс эти правила. Единственное различие между вариантами – наличие правил в промпте. В качестве базового варианта используется вполне способный агент с настройками по умолчанию, а не заведомо слабый соперник: набор инструкций (skill) легко выглядит полезным на фоне плохой базы, но в реальной конфигурации такой эффект быстро исчезнет. И весь эксперимент я провёл трижды, потому что один прогон легко вводит в заблуждение: даже при нулевой температуре этот стек при повторном запуске даёт разброс в пару задач.

Конфигурация

Всё запускалось локально на обычном пользовательском железе.

• Железо: 1 × RTX 4090 (24 Гбайт) и 1 × RTX 3090 (24 Гбайт).

• Сервинг: llama.cpp, собранный из исходников с CUDA и поднятый как OpenAI-совместимый API-эндпоинт. Не vLLM.

• Модель: Qwen3.6-27B с 4-битной квантизацией (Q4_K_M GGUF, около 17 Гбайт), плотная модель для программирования с рассуждением.

• Бенчмарк: SWE-bench Lite, тестовая выборка, первые 100 задач. Каждая задача основана на реальном баге из GitHub: скрытый тест должен перестать падать, а остальные тесты – продолжить проходить.

• Тестовый фреймворк (harness): SWE-agent, который управляет моделью через встроенный вызов функций (function calling) и настоящий редактор str_replace.

• Бюджет на задачу: 30 вызовов инструментов, контекстное окно на 32 тыс. токенов, лимит вывода 4 тыс. токенов, температура 0.

• Прогоны: 3 попарных прогона. Первый – на RTX 4090; два повторных были распределены между обеими GPU через очередь задач, при этом базовый вариант и вариант с набором инструкций для каждой задачи всегда запускались на одной и той же карте.

Стало хуже. И каждый раз результат оставался хуже

В трёх прогонах базовый вариант решил 47, 49 и 45 багов из ста. С правилами тот же агент решил 40, 43 и 40. Изменение относительно базового результата (lift) каждый раз было отрицательным: минус семь, минус шесть и минус пять. В среднем – минус шесть, то есть относительное падение примерно на 13%.

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

Здесь важны не сами минус шесть. Важно то, что результат ни разу не приблизился к нулю. Три независимых прогона дали падение от пяти до семи задач, и списать такую стабильность на случайность уже трудно. Статистика это подтверждает: если считать результаты трёх прогонов независимыми повторениями эксперимента, t-тест даёт p примерно 0,009; если объединить результаты по отдельным задачам, тест Мак-Немара даёт около 0,022. Более строгая проверка, где каждая задача учитывается один раз, а не три, даёт менее убедительный результат – около 0,09, поэтому строить весь вывод вокруг одного p-value я не собираюсь. Но как ни разбивай данные, эффект остаётся отрицательным, и в большинстве вариантов анализа он проходит стандартный порог статистической значимости.

Почему осторожные советы Карпати ухудшают результат

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

Посмотрите, что агент с правилами делает хорошо. Он почти не ломает существующие тесты: проходит около 99,9% регрессионных проверок против примерно 96% у базового варианта. Эти показатели рассчитаны на разных наборах задач, поэтому важнее само направление, а не точная разница. Агент реже что-то ломает и оставляет репозиторий в более чистом состоянии. Если исходить из принципа «прежде всего не навреди», он действительно лучше.

Проблема в том, что багов он исправляет меньше. Четыре правила дисциплины в основном работают как тормоза: вноси точечные изменения, пиши минимум кода, меняй только необходимое, не исправляй то, что и так работает. А в бенчмарке, где итоговый балл определяется одним вопросом – прошёл ли ранее падавший тест, – агент, который меньше правит код, доводит до конца меньше исправлений. У этого подхода две стороны: он безопаснее, но и набирает меньше баллов. Вот точная раскладка по всем ста задачам при попарном сравнении.

Матрица 2 × 2 результатов базового варианта и варианта с набором инструкций: оба исправили 35 задач, набор инструкций ухудшил результат в 12, помог в 6, ни один вариант не справился с 47.

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

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

Зато хотя бы экономнее

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

Но и это не подтверждается.

Горизонтальные столбцы с изменением относительно базового варианта: входные токены почти без изменений, вызовов инструментов больше, выходных токенов примерно на 12% меньше.

Дешевле тоже не становится: агент читает столько же, чаще вызывает инструменты и пишет меньше.

Основная часть стоимости такого прогона приходится на чтение репозитория, а агент с правилами читает столько же: число входных токенов практически не меняется, если не считать шум, а на вход приходится около 99,8% всех токенов. Те показатели, которые действительно меняются, движутся не в ту сторону. Агент делает чуть больше вызовов инструментов, а не меньше, и генерирует примерно на 12% меньше выходных токенов. Но экономии это почти не даёт, потому что объём вывода ничтожен по сравнению со входом. Снова проявляется та же осторожность: в логах токенов она выглядит как больше обдумывания и меньшие патчи. В итоге вы столько же платите за чтение, чуть чаще используете инструменты, немного меньше пишете – и при этом исправляете меньше багов.

Чего из этого не следует

Одна модель, один тестовый фреймворк, один бенчмарк – и эти ограничения важны. В SWE-agent уже заложена довольно строгая рабочая дисциплина, поэтому базовый вариант изначально нельзя назвать наивным. Среди этих ста задач особенно много django и astropy, а модель вроде Qwen3.6 почти наверняка видела достаточно примеров с ними во время обучения. Базовая доля решённых задач в 47% высока отчасти потому, что это хорошо знакомые модели задачи, возможно уже встречавшиеся при обучении, а не чистый показатель возможностей модели. И хотя эффект повторился, речь всё же о трёх повторных прогонах одной и той же сотни задач, поэтому эти прогоны нельзя считать полностью независимыми. В более чистом эксперименте стоило бы каждый раз брать новые задачи или прогнать весь набор целиком.

Самая важная граница применимости вот какая: я один раз проверил те же правила на меньшем наборе более сложных и менее знакомых задач, и там явного эффекта не было – ни выигрыша, ни проигрыша. Поэтому этот результат относится к относительно простым, хорошо знакомым задачам и достаточно способному агенту. Он не означает, что дисциплина вредна. Он означает, что здесь она не помогла, а когда что-то меняла, то меняла к худшему.

Тормоза, а не мощность

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

Поэтому прежде чем вставлять такие правила в промпт агента, стоит спрашивать не «хорошие ли это советы». На бумаге они выглядят разумно. Вопрос в том, какая проблема есть именно у вас. Если агент действует безрассудно – начинает править код, не разобравшись в баге, переписывает половину файла, объявляет задачу решённой, даже не запустив проверку, – тормоза нужны именно такие. Если же агент и так достаточно осторожен или просто не успевает довести исправление до конца в отведённый бюджет, эти тормоза лишь замедляют его. И расплачиваться приходится багами, которые он так и не исправил.

Независимый тест на одной RTX 4090 и одной RTX 3090: llama.cpp обслуживал Qwen3.6-27B с 4-битной квантизацией, SWE-agent запускал модель на SWE-bench Lite. Проверялся набор инструкций из созданного сообществом репозитория andrej-karpathy-skills, основанный на наблюдениях Карпати о программировании, а не файл, написанный самим Карпати.

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

• 22 сентября в 20:00. «Можно ли доверять ИИ-коду: как находить галлюцинации, уязвимости и устаревшие решения». Записаться

• 1 октября в 20:00. «Продуктивность разработчика и Agent Skills». Записаться

Больше бесплатных уроков сентября смотрите в дайджесте.