Когда разработчики обращаются к нейросетям за помощью в рефакторинге или отладке, часто возникает дилемма: довериться одной топовой модели, протестировать сразу несколько независимых вариантов или попытаться поручить другой LLM объединить результаты коллег в единый монолит? Чтобы проверить эти подходы на практике, был проведен двухэтапный эксперимент на реальном проблемном bash-скрипте.
Анатомия тестового скрипта
Объектом исследования стал служебный скрипт run-code.sh, предназначенный для пакетного тестирования LLM через внешний Python-скрипт и формирования итоговой сводки. В коде намеренно содержалось семь дефектов различной степени критичности:
- Поврежденные данные в пресетах: отсутствующие разделители и пустые параметры рейтрейтов, вызывавшие предупреждения в
stderr. - Отсутствие защитного парсинга: предположение, что входные данные всегда содержат корректные целые числа.
- Отсутствие предварительной проверки файлов: скрипт запускал цикл бенчмарка, даже если исполняемый файл отсутствовал.
- Критический сбой подсчета статусов: сводная таблица искала несуществующие ключи, из-за чего статистика всегда выдавала нули независимо от результата тестов.
- Ложные аварийные завершения: скрипт не делал различия между фатальным крашем и ситуацией, когда модель прошла часть тестов.
- Хрупкий разбор JSON: падение сводки целиком при повреждении хотя бы одного отчета.
- Устаревшая документация: неактуальные имена файлов в комментариях и справке.
Раунд 1: Одиночный ремонт вслепую
В первом этапе четыре модели — Sonnet 5, HY3, Qwen3-Max и DeepSeek-V4-Flash — получили исходный файл без подсказок и работали полностью изолированно.
| Баг / Проблема | Sonnet 5 | HY3 | Qwen3-Max | DeepSeek-V4-Flash |
|---|---|---|---|---|
| 1. Ошибки в пресетах | Исправлено точечно | Пропущено | Исправлено через guard | Нейтрализовано дефолтами |
| 2. Защита парсера лимитов | Не требовалось | Пропущено | Полная защита | Частичная защита |
| 3. Проверка наличия файла | Пропущено | Исправлено | Пропущено | Пропущено |
| 4. Корректные ключи статусов | Пропущено | Полная категоризация | Детальная разбивка | Частично (только pass/fail) |
| 5. Разделение сбоев и деградации | Пропущено | Исправлено | Строгая валидация | Пропущено |
| 6. Защита JSON-парсера | Полный try/except | Частично | Частично | Частично |
| 7. Актуализация документации | Частично | Пропущено | Пропущено | Пропущено |
Главный итог первого тура: ни одна модель не справилась со всеми багами в одиночку. Sonnet 5 уделила внимание оформлению и защите от исключений, но пропустила критическую ошибку сбора статистики. HY3 блестяще переписала логику подсчета и единственная заметила отсутствие проверки файлов, но проигнорировала битые данные. Наиболее сбалансированный результат показала Qwen3-Max, закрывшая большинство функциональных дыр.
Раунд 2: Слияние чужих решений
На втором этапе семи моделям (включая участников первого раунда, а также Mistral-Medium-3.5, Nemotron-3-Super-120B, Gemini Pro и dots-studio-3-note) предоставили все четыре варианта исправлений с заданием скомпоновать наилучшую финальную версию.
| Модель-агрегатор | Критические баги (1–5) | Защита парсера (6) | Очистка доков (7) | Атрибуция источников | Итоговый результат |
|---|---|---|---|---|---|
| Qwen3-Max | Учтены | Да | Да | Полная таблица правок | 1 место |
| Gemini Pro | Учтены | Да | Да | Отсутствует | 2 место |
| DeepSeek-V4-Flash | Учтены | Да | Да | Частичная | 3 место |
| Mistral-Medium-3.5 | Учтены | Да | Потеряно | Отсутствует | 4–5 место |
| dots-studio-3-note | Учтены | Да | Потеряно | Отсутствует | 4–5 место |
| ling-3.0-flash | Учтены | Нет | Потеряно | Отсутствует | 6 место |
| Nemotron-3-Super-120B | Учтены | Нет | Потеряно | Отсутствует | 7 место |
Все сборщики предоставили рабочий код, прошедший базовый запуск. Однако разница проявилась во внимании к деталям: большинство моделей молча вырезали неочевидные исправления (например, правки документации от Sonnet 5). Лидером стала Qwen3-Max, которая не только сохранила все полезные изменения, но и приложила детальный список изменений с указанием авторов исходных правок.
Ключевые выводы
- Универсальных моделей не существует: даже флагманские решения имеют слепые зоны, причем у каждой нейросети они свои.
- Рейтинг не гарантирует полноту: аутсайдеры первого раунда находили уникальные баги, которые полностью упустил победитель.
- Слияние требует верификации: при объединении кода нейросети склонны отбрасывать правки, значимость которых они не поняли.
- Важность прозрачности: агрегатор кода ценен не только работоспособностью результата, но и способностью объяснить происхождение каждой строчки.