Comments 21
Контур 2. Запуск обязателен, чтение кода не считается
У вас тут грабли вырисовываются, если мы пишем какой то плагин, или только часть файлов в целом проекте, то запуск его физически не возможен а значит модель вам все равно соврет что все ок, при этом намотав еще кучу кругов в разборе как это запустить, и в конце выдав желаемое за действительность. сделать снапшот в огромном проекте, ну такое себе, контур сказать легально не знаю, модель выберет часто его вместо реальной проверки, это особенно актуально для слабых моделей, фонтир модели с этим справляются и без кастылей
если мы пишем какой то плагин, или только часть файлов в целом проекте, то запуск его физически не возможен
Можно запустить отдельный файл с исполняемым кодом, если соорудить для него окружение. Юнит-тестирование и моки - они как раз про это. Можно и БД замокать, если надо. И сеть. Как раз таки плагин тестить проще, чем целое.
Другое дело, что искусственно поднятое окружение может значимо отличаться от натурального. Но, если такое выявляется, то и эти отличия можно замокать.
Можно запустить отдельный файл с исполняемым кодом, если соорудить для него окружение. Юнит-тестирование и моки - они как раз про это.
Как раз на моках и юнит тестах модели радостно рапортуют о зеленых галочках, потому что они подстраивают эти тесты под нужный результат, если вы это сами просмотрели в логах, считайте получили пустышку в красивой обертке. они умудряются даже е2е тесты делать зелеными при нерабочей в принципе архитектуре, правда современные модели уже меньше этим страдают, тут да улучшение на лицо
Пагинированное чтение файлов. Агент читал файл кусками по 100 строк. Четырёхтысячный файл превращался в четырнадцать перекрывающихся чтений, каждое из которых заново въезжало в контекст на каждом ходу. Прочитать файл целиком одним вызовом дешевле, чем читать его по частям четырнадцать раз. Контринтуитивно ровно до первого замера.
Ок, а если файл не влазит в окно ?
а если модель еще и локальная, и что бы найти проблему в коде надо прочитать несколько таких файлов ?
Короче как мне кажется, вы еще не до конца поняли какие грабли вас ждут на проектах, больше чем крестики нолики =)))
Сколько раз пришлось наступить на грабли чтобы появились правила "никаких Х", правила неполные и не переносимые на другой проект?
Стоило ли оно того?
Уже выходила похожая статья, только там к "тупой" модели пытались прикрутить не проверки, а "память":
https://habr.com/ru/articles/1073448/
Напрашивается вопрос, какие именно модели вы сравнивали? Если в вышеназванной обвязке "тупую" модель можно легко заменить на "умную", то какой смысл в сравнении прокачанной "тупой" модели и дефолтной "умной"?
Подход с инструментами мне нравится: это дополнительный слой проверки прямо в процессе работы, а не попытка поверить модели на слово.
Но тезис «дешёвая модель с контролем побеждает сильную» я бы всё же не делал. По вашей же статистике при одинаковом цикле сильная модель даёт 88% против 73% у дешёвой. То есть контроль сильно помогает, но разницу в возможностях модели не отменяет.
При этом для множества простых и хорошо формализованных задач условная Astra действительно не нужна. Если точно сказать, что сделать, и нормально проверять результат, дешёвая модель часто оказывается просто практичнее — особенно с учётом разницы в цене. Да и быстрее скорее всего простую работу сделает как раз более простая модель (хотя скорость часть еще и от провайдера зависит).
Но если модели объективно не хватает уровня для задачи, никакой цикл проверки ей этот уровень не добавит. Чудес тут не будет.
Особенно если задача как раз сложная, требует не терять нить рассуждений на долгом забеге и решить задачу, а не просто что-то поделать долгое время, по факту часто ходя кругами и не родив решения.
Автор пытается заново изобрести Codex
Нельзя опираться на то, что модель будет следовать правилам, они любят что-нибудь забывать.
Только TDD, тесты и жёсткая приёмка.
$0 - ну, камон! (с)
Как правило, локальная модель дольше работает, а это на многих запусках добавляет десятки минут, которые стоят уже ощутимо в человеко-часах. Да, еще вам потребовалось купить комп мощнее (да, возможно, он у вас уже был, но для других это правило не работает).
Короче, главное – поднять для своей задачи TDD, дальше и модели будут лучше работать, и можно пользоваться дешёвыми.
Это все классно, когда действительно можно создать петлю обратной связи. Печально, когда такое физически невозможно или стоимость создания петли сложнее самого проекта.
Я не совсем понимаю, как можно запретить агенту писать через shell?
Просто написать в prompt "не используй bash для записи файлов, используй Write"? Так это же не запрет.
Например, хуком или настройками. В опенкоде есть разрешения для встроенных инструментов, как на глобальном уровне, так и на уровне отдельного проекта. Если bash - deny, агент вернет модели ошибку, а та уйдет чесать репу, как этот запрет обойти и какой инструмент взять вместо шелла. Это эффективно с точки зрения контекста, потому что многие вызовы (тот же ngspice/verilator) загаживают контекст с одного вызова. Туда же идет find / или локальный find без --exclude-dir и это тоже можно запретить без возможности обхода.
Я не очень понял, что конкретно делает автор - claude code или Google Antigravity делает ровно тоже самое - т.е. вот этот вот агентский цикл - написал-запустил-получил результат-отправил на следующий цикл.
Ну по крайней мере у меня это так и работает. Другое дело, что меня это не совсем устраивает (главным образом по цене) и я модифицирую стандартный агентский цикл (ну как... просто насильно свой harness со своим набором субагентов. Оно конечно работает, но каждый проект настраивается по отдельности)
здесь как с людьми
а люди до ии придумывали всякие ТDD подходы на тему «сперва пишем тесты, потом код». и логично что модели должны работать так же
Что такое "Инструмент Write" ? Это какая-то кастомная программа? Или что-то стандатное и входящее в состав чего-то?
Тупая модель с жёстким циклом проверки бьёт умную модель без него