Самый частый способ работать с агентом - просить сразу правку. "Сделай так, чтобы работало" - и агент выдаёт diff, который выглядит убедительно. Проблема в том, что убедительно выглядящая правка и доказанно верная правка - разные вещи, а на глаз они неотличимы. Пока результат не доказан, у вас на руках не решение, а гипотеза в форме кода.
Наивный ход - принять правку по внешнему признаку: код скомпилировался, выглядит разумно, агент уверенно объяснил, что сделал. Мы склонны доверять связному объяснению и аккуратному diff, потому что у человека это обычно коррелирует с правильностью. У агента корреляция слабее: он умеет писать убедительно и о неверном, и уверенность в тексте ничего не говорит о поведении кода.
Ломается это на том, что генерация и проверка - разные задачи, и смешивать их нельзя. Отсюда цикл из четырёх шагов. Inspect - воспроизвести проблему и найти причинную цепочку от входа до сбоя. Patch - сделать минимальное связное изменение, адресованное именно этой причине. Verify - запустить проверку, способную опровергнуть решение. Review - прочитать diff целиком и оценить побочные эффекты за пределами исходной точки. Пропуск любого шага возвращает вас к работе на веру.
Ключевое требование к шагу verify формулируется жёстко: проверка должна быть независимее генерации. Если агент сам придумал и код, и единственный тест под него, этот тест доказывает не корректность, а лишь внутреннюю согласованность его же замысла - он пройдёт, даже если замысел неверен. Независимость возвращают внешним контуром: существующим suite, статическим анализом, ручным контрпримером или отдельным ревью, которое не участвовало в написании кода.
Здесь помогает встроенный механизм - Quick Review. Это отдельный агент, дающий независимое второе мнение: он анализирует diff на корректность, стиль и потенциальные проблемы и пишет отзыв прямо в редакторе. Модель ревью выбирается из списка - от бесплатной SWE-check до платных фронтир-моделей. Важное ограничение по документации: Quick Review доступен только для Devin Local и не поддерживается для Cascade. Ценность его именно в раздельности ролей: пишет один контур, оценивает другой.
Отдельного разбора требует фраза "тесты прошли" - сама по себе она неполна и потому опасна. Проверка становится доказательством, только когда названы команда, код возврата, область прогнанных тестов и известные пропуски. Для UI к этому добавляют viewport и сценарий, по которому смотрели; для API - status, payload и обязательный negative case. Без этих деталей "прошли" может означать "прошли не те тесты", "прошла их часть" или "прошли, но не покрывали изменение". Поэтому доказательством считают не факт запуска, а воспроизводимую связку: вот команда, вот её код возврата, вот что именно она проверяла, - её при желании повторит и другой человек.
Цена пропущенного доказательства не в самой правке, а в её горизонте. Принятое на веру изменение уезжает в репозиторий, и цепочка от него тянется до чужого рабочего дня и до продакшена. Стоимость цикла - минуты на воспроизведение и прогон; стоимость его отсутствия - регрессия, которую найдут не там и не тогда, и разбирать которую будет уже не автор правки. Ранняя проверка дешевле поздней на порядок именно из-за этого удаления во времени.
Это не значит, что каждую однострочную правку нужно оборачивать полным циклом. На тривиальном изменении inspect и verify схлопываются в чтение diff, и это честно. Полный контур окупается там, где правка меняет поведение, трогает несколько мест или уходит в автономную работу: чем длиннее turn и шире радиус, тем важнее, чтобы проверка была отдельной от генерации и способной сказать "нет". На автономной поверхности это не роскошь, а страховка: чем меньше вы смотрите за каждым шагом вручную, тем важнее, чтобы независимый контур поймал ошибку раньше, чем она доедет до репозитория.
Проверять стоит не только результат, но и сам цикл: способна ли ваша verify-проверка в принципе провалить решение. Тест, который проходит при любой реализации, доказательством не является - он лишь создаёт его видимость. Хороший признак - вы можете назвать сценарий, при котором проверка покраснеет, и убедиться, что до правки она действительно краснела. Проверка, не умеющая опровергать, не умеет и подтверждать.
Типичные провалы располагаются по шагам цикла. Пропущенный inspect - правка симптома вместо причины, баг возвращается сбоку. Раздутый patch - "заодно" переписанное соседнее, которое ломает то, что работало. Зависимый verify - зелёный тест, написанный под тот же неверный замысел. Пропущенный review - невидимый побочный эффект за пределами исходной точки. Признак у всех один: "готово" произносят раньше, чем называют, чем именно это доказано. Сначала доказательство - потом "готово".