Глава 11. Правила, которые работают

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

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

Случается это не от кривого запроса, тут хоть заобъясняйся. Так ведут себя все кодовые агенты, на любых проектах, во все месяцы. Привычка держится крепче остальных, и на ней охуенно видно, чем рабочее правило отличается от нерабочего.

ЧТО ТАКОЕ ЭВРИСТИКА И ПОЧЕМУ ЭТО СЛОВО ЗВУЧИТ КАК ДИАГНОЗ Эвристика: упрощённое правило, которое обычно даёт верный ответ и не требует думать. Скажем, если в сообщении встретилось слово "пожар", считаем, что случилась авария. Регулярное выражение, оно же регексп, позволяет такое правило записать: это шаблон для поиска подстрок в тексте. Инструмент нормальный, половина полезного кода в мире так и работает. Ломается всё там, где задача требует понимания смысла. Именно туда агент лезет первым делом, потому среди практиков слово "эвристики" давно звучит как диагноз.

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

ЧТО ПРОИСХОДИТ, КОГДА АГЕНТ ПОЛУЧАЕТ ЗАДАЧУ ПРО СМЫСЛ

Задача: понять смысл текста

Сравнить строки по списку слов Отдать оценку модели

быстро, дёшево медленно, верно

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

Правила, которые работают

Как это выглядит на живом проекте Лучше всего историю объясняет система, которая читает домовые чаты и вылавливает сообщения об авариях. Задача целиком про смысл: жилец пишет как умеет, и понять, случилась беда или нет, можно только вникнув в текст.

ПОЖАР В СЕРДЦЕ Агент упирался до последнего. Ждать ответа модели незачем, доказывал он, ведь слова "пожар", "затопило", "искрит" ловятся прямым сравнением строк: быстро, дёшево, без лишних запросов. Спор кончился, когда разработчик придумал контрпример. Человек вполне может написать, что у него пожар в сердце и он затопил свои трусики. Два слова из списка совпали, аварии не случилось. После этого агент согласился и сам вписал в правила проекта запрет на такие решения.

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

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

Откуда это берётся Объяснение простое. Агент воспроизводит то, чего в его обучающих данных было до хуя, а в открытом коде больше всего именно быстрых решений на совпадении строк. Модель не вредничает и не саботирует. Она прёт по самому вероятному пути, как вода по канаве.

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

ГЛАВНОЕ ПРО ЭТУ ПРИВЫЧКУ Агент не саботирует задание, он идёт по самому вероятному маршруту из своего опыта. В мире открытого кода этот маршрут ведёт к сравнению строк. Значит, воевать надо не с отдельным регекспом в отдельном файле, а с самим маршрутом: перекрывать его в начале задачи и держать перекрытым до конца.

Есть формулировка порезче. Она уже не про данные, а про поведение модели под давлением задачи. Модель уверенно докладывает, что сделала как просили, а сама пиздит и лезет в обход. Задачу закрыть хочется, прямой дороги она не видит, вот и находит любую другую.

Правила, которые работают

Четыре приёма, которые работают За полгода практики набралось четыре рабочих способа. Заменить один другим не выйдет, они закрывают разные дыры.

Приём Когда применять Что ловит

Запрет с причиной При настройке правил проекта Обход ограничения по формальному признаку

Контроль в трёх точках На входе, в процессе, на выходе Упрощения, пока они дёшевы в правке

Пересказ своими словами После крупного куска работы Расхождение кода с замыслом

Цикл самопроверки Постоянно, автоматически Всё, что пропустили первые три

Запрет с причиной Приём неочевидный, зато самый убойный. Идея пришла из производственной методологии Toyota TWI, где мастер учит прямо на рабочем месте и объясняет не только порядок действий, но и на кой хуй они нужны.

Голый запрет модель воспринимает как формальность и при первом удобном случае обходит его по такой же формальности, без зазрения совести. Запрет с причиной ложится в рассуждение целиком.

ЗАПРЕТ БЕЗ ПРИЧИНЫ ЗАПРЕТ С ПРИЧИНОЙ

запрещено округлять до целых запрещено округлять до целых, потому что на разнице мы в прошлый раз потеряли 12 000 USD в коммерческом предложении

Модель видит ограничение, ищет лазейку и Причина попадает в рассуждение, и модель находит её в первом же неоднозначном месте. учитывает её даже там, где формально запрет не нарушен.

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

Контроль в трёх точках Проверка в конце опаздывает намертво. К финалу упрощения уже вросли в код, и вычищать их это такая ебля, что дешевле написать заново.

Точка Что смотреть Цена пропуска

На входе Как агент понял постановку и что Минуты на переформулировку предлагает делать

В процессе Чем он занят на самом деле, а не Часы на переделку куска что докладывает

Правила, которые работают

Точка Что смотреть Цена пропуска

На выходе Совпадает ли результат с замыс- Дни на разбор проекта лом

Первая точка самая дешёвая и самая недооценённая. Агент выдаёт свои намерения уже в первом ответе на постановку, надо просто взять и прочитать, а не пролистывать по диагонали.

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

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

Цикл самопроверки Разовое "проверь себя" слабее, чем требование крутиться до чистого результата.

КАК ВЫГЛЯДИТ РАБОЧИЙ ЦИКЛ

Написать код Сверить со стандартом Исправить найденное

нашли нарушение, заходим снова

Разница между "проверь" и "проверяй, пока не станет чисто" на практике решает всё. Первое агент сделает для галочки, второе заставит его коноёбиться до результата.

Где это не работает У подхода есть граница, и знать её лучше заранее.

Правила, которые работают

ЗАПРЕТ ПОМОГАЕТ НЕ ВСЕГДА Позиция первая. Запрещать надо жёстко и сразу: эвристики, тихие подмены при ошибках, поддержку устаревших веток. Дальше строить агенту узкий коридор из правил, готовых сценариев, линтеров и автопроверок. Чем уже коридор, тем предсказуемее результат. Иначе придётся вечно читать код глазами, а это возвращает нас туда, откуда уходили. Позиция вторая. Работает такой запрет только на подготовленной почве, когда разработка идёт по рельсам и модели есть куда свернуть. На открытой задаче агент, которому запретили эвристики, но не показали правильного пути, всё равно не остановится. Закрыть задачу хочется, и он выкрутится. Чем строже запрет, тем изобретательнее обход. Вывод из спора. Запрет закрывает половину работы. Вторую половину закрывает готовый способ сделать правильно: инструмент, образец, пример решения. Без него ограничение родит не качество, а изворотливость.

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

ЧТО ДЕЛАТЬ НА СВОЁМ ПРОЕКТЕ 1. Впиши в правила проекта запрет на решения по совпадению строк там, где задача про смысл. Обязательно с причиной, желательно с ценой ошибки в деньгах или времени. 2. Читай первый ответ агента на постановку. Он там сразу выдаёт, куда собирается свернуть, а править на этом этапе дешевле всего. 3. После каждого крупного куска проси пересказ обычными словами. Быстрее чтения кода и надёжнее. 4. Разошлось с замыслом, правь сразу. По накатанной агент дотащит это упрощение до самого конца проекта, и хуй его потом выкорчуешь. 5. Замени разовую ревизию циклом самопроверки по стандартам, с требованием повторять до чистого результата.

← Файл правил · оглавление · Скиллы: механика и жизненный цикл →

Спросить книгу может любой, кто вошёл в Neuraldeep Hub: агент ищет ответ по тексту и приводит цитату со ссылкой на главу.