Научная отладка

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

Non-reasoning модель не будет применять научный метод. Она будет "угадывать", что за фикс нужен, и попробует one-shot. Если в agent loop'е, она может перезапустить test suite, чтобы посмотреть, сработало ли, а потом рандомно пробовать разные вещи, пока не получится (но скорее всего попадет в death loop).

Общий consensus — для дебага надо использовать reasoning модели (обычно люди предпочитают что-то вроде Grok 3 или DeepSeek-R1 для таких задач). Лично я при AI-кодинге все еще держу довольно детальную ментальную модель того, как код должен работать, поэтому считаю разумным пытаться диагностировать проблему самому (не обязательно фиксить — если скажешь модели, что не так, она обычно справляется).

Примеры

• Один из самых ужасающих death loop'ов, в который может попасть LLM агент — попытка пофиксить неправильные конфиги в окружении; например, когда по какой-то причине пакет отсутствует. Забавная проблема с Sonnet 3.7 — она ожидает, что «pip» будет доступен, чего нет в venv, созданном по дефолту, и не может понять, что пошло не так, тратя кучу токенов на рандомное метание.