Дал Gemini 3.1 Pro тот же скилл, что запускаю в Claude Code. Попросил обработать 300 постов. Claude потом написал формальный review - 4.6 из 10.
Честно: ожидал худшего результата от эксперимента. Получил интересный.
Задача
Я собрал скилл telegram-channel-processor - 5-этапный пайплайн: SETUP → PARSE → CALIBRATE → PROCESS → EXPORT.
Скилл определяет релевантность постов через LLM-классификацию. Результат - структурированная Knowledge Base с элементами: цитаты, инсайты, статистика, инструменты.
Скилл написан для Claude Code. Но из-за того, что скилы являются открытым стандартом, я его просто скопировал в .gemini/skills/ и дал задачу: обработать один из тегерамм каналов, 300 постов.
Что Gemini сделал
Через LLM он обработал 1 чанк из 7.
Для остальных шести написал Python-скрипт auto_process.py с keyword-matching через regex. Назвал это “автоматизированной обработкой” - без предупреждения, что переключился с LLM на regex. Сам решил, что ему так нужно сделать.
Результаты:
- 259 из 300 постов помечены как “useful” (retention rate 86%)
- Норма при LLM-классификации: 30-50%
- 591 KB-элемент - из regex, не смыслового анализа
- Критический файл
extracted_channel_name.json- не создан - 5+ ручных “Continue” потребовалось от меня
- HTTP 503 MODEL_CAPACITY_EXHAUSTED на середине работы
Retention rate 86% - это красный флаг. Regex пропускает почти всё подряд. LLM-классификация режет нерелевантное. В базе в итоге принципиально разные данные.
Оценка
Я попросил Claude написать формальный review по 7 критериям:
| Критерий | Оценка |
|---|---|
| Автономность | 4/10 |
| Стабильность | 3/10 |
| Соответствие скиллу | 5/10 |
| Качество данных | 4/10 |
| Сохранность данных | 3/10 |
| Работа с лимитами | 6/10 |
| Коммуникация | 7/10 |
Средний балл: 4.6 / 10
Коммуникация - 7/10. Gemini честно объяснил архитектурные ограничения после завершения. Не притворялся, что всё сделал как надо.
Почему так вышло
Gemini физически не мог сделать иначе.
Output limit: 32K токенов. Генерировать JSON на сотни постов через LLM при таком лимите - невозможно. Claude Code решает это через субагентов: каждая задача в своём контексте, параллельно. У Gemini CLI субагентов нет.
Regex - рациональный fallback при таких ограничениях. Проблемы две: не предупредил о переключении, и retention rate 86% не насторожил его как аномалия.
503 MODEL_CAPACITY_EXHAUSTED - отдельная боль. На пике нагрузки Gemini 3.1 Pro просто недоступен на нужном уровне.
Что взяли от Gemini
Gemini предложил хранить rejected-посты только как ID, без полного контента. Это реально экономит токены при передаче контекста между этапами пайплайна. Идею взял - обновил свой основной скилл для Claude Code.
Что понял
Один и тот же скилл, два агента, разный результат - не потому что один “умнее”. Из-за архитектуры.
Субагенты в Claude Code - не просто фича. Это возможность разбить задачу на независимые куски и честно обработать каждый через LLM. Без них агент вынужден идти на компромиссы, которые ломают результат.
Буду продолжать тестировать один скилл на разных движках. Бенчмарки - это одно. Реальная задача - другое.