Claude Code и копеечная Step 3.5 Flash: боевая проверка
Claude Code — это агентный инструмент: он сам читает файлы проекта, пишет код, запускает сборку, видит ошибки и чинит их в цикле, пока не получит рабочий результат. Обычно за этим циклом стоит топовая модель, но Claude Code можно направить на стороннюю модель через прокси (как это сделать, я разбирал в прошлой статье).
В этой статье проверим практическую гипотезу: справится ли дешёвая модель Step 3.5 Flash с реальной задачей, если поместить её в агентный цикл Claude Code? В качестве подопытного — типовой пет-проект.
Начинаем
Запускаем Claude Code подключенный к Step 3.5 Flash и ставим задачу:
Привет, я хочу создать telegram сервис который будет показывать сколько у меня подписчиков на канале, проверка будет производится каждые 15 минут, написать хочу на C# и потом как нить за деплоить на Linux
Шаг 1. Генерация проекта
Здесь агент отработал ожидаемо. Сначала задал три уточняющих вопроса, на которые я ответил так:
Как сервис должен показывать информацию о подписчиках? → Я хочу чтобы проверка была и если добавились новые люди отправляло мне письмо
Какого типа ваш канал? → Публичный
Когда отправлять уведомления? → При любом изменении
Получив ответы, агент приступил к генерации.
На выходе — не один файл, а полноценный каркас проекта:
- TelegramMonitor.csproj проект и зависимости (Telegram.Bot, MailKit)
- Program.cs вся логика мониторинга
- appsettings.json конфигурация: токены, почта, интервал проверки
- Dockerfile сборка контейнера
- docker-compose.yml запуск одной командой
- telegram-monitor.service файл для автозапуска на Linux (systemd)
- README.md инструкция на русском
- .gitignore исключения для Git
Логика разумная: приложение читает конфиг, раз в 15 минут запрашивает Telegram, сравнивает число подписчиков с сохранённым ранее и при изменении отправляет письмо на почту. Предусмотрены сразу три способа запуска на сервере. На уровне проектирования каркаса дешёвая модель показала себя хорошо.
Проверить генерацию можно только одним способом — попробовать собрать проект.
Шаг 2. Первая сборка: устаревший код
Первая же сборка завершилась с ошибками. Причина типичная: модель писала код под старую версию библиотеки Telegram.Bot, а система подтянула более новую, где часть команд переименовали и переделали. Из-за этого возник и конфликт имён — в проекте оказалось два разных типа с одинаковым названием File, и компилятор не понимал, какой из них имеется в виду.
Модель разобралась с этим корректно: уточнила, какой именно File нужен, и заменила устаревшие названия команд на актуальные. Это ровно то, что требовала новая версия библиотеки.
Шаг 3. Выдуманное API
На следующей сборке проявилась характерная слабость дешёвых моделей — обращение к функциям, которых в библиотеке уже нет. Чтобы узнать число подписчиков, модель пыталась читать свойство, которое в новой версии Telegram.Bot отсутствует, и проверять типы каналов, которых тоже больше нет. Был и обходной трюк, рассчитанный «на авось» — в надежде, что нужное свойство всё-таки найдётся во время работы программы.
Компилятор такой код не пропустил и снова выдал ошибки. Это важный момент для понимания всей затеи: модель уверенно генерирует правдоподобный, но несуществующий код. Спасает то, что в цикле стоит компилятор — без него такая ошибка ушла бы дальше, в готовый продукт.
Шаг 4. Поломанный текст письма
Параллельно модель переписывала HTML-шаблон письма и при этом нарушила синтаксис самого языка. Дважды подряд споткнулась на кавычках: сначала неправильно их экранировала внутри текста, потом случайно создала «пустой символ» — снова из-за путаницы с кавычками. Оба раза сборка падала.
Здесь хорошо видно, как у модели плывёт удержание контекста: исправляя одно место, она ломала соседнее. Чтобы выбраться из этого, она переписала основной файл целиком и вынесла оформление письма в отдельную функцию, собирая его более простым и надёжным способом. Это устранило проблему в корне.
Шаг 5. Рабочее решение
В итоге модель отказалась от попыток вытащить число подписчиков «окольными путями» и оставила единственную правильную команду — ту, что специально предназначена для подсчёта участников канала в актуальной версии библиотеки. К правильному решению она пришла методом исключения, перебрав неработающие варианты, но результат верный. Финальная сборка прошла успешно — ноль ошибок.
Осталось несколько некритичных предупреждений: расхождение версии одной библиотеки и известная уязвимость в старой версии почтового пакета, которую модель тут же закрыла обновлением.
Что в итоге получилось
Связка «дешёвая модель + агентный движок Claude Code» довела задачу до конца. Проект собирается, имеет понятную структуру, конфиг, контейнеризацию и автозапуск на сервере — это рабочая основа, с которой можно идти к деплою.
Сильные стороны:
- Проектирование каркаса. Структура проекта, файлы для запуска и инструкция — всё адекватное.
- Самовосстановление. Цикл «сборка → ошибка → исправление» довёл проект от состояния «не собирается» до рабочего без участия человека.
Слабые стороны, о которых стоит знать:
- Выдуманные функции. Модель уверенно пишет код, обращающийся к тому, чего в библиотеке нет. Здесь критически важен компилятор в цикле — он отлавливает то, что не отловила модель.
- Хрупкое удержание контекста. Правка в одном месте ломала другое, особенно в тексте письма.
- Перебор вместо знания. К правильному решению модель пришла, исчерпав неверные варианты, а не сразу.
И главный аргумент в пользу затеи — цена. Вся сессия целиком (генерация проекта плюс все пять раундов исправлений) обошлась в $0.153, то есть около пятнадцати центов. За такие деньги мы получили собранный, готовый к деплою сервис.
Практический вывод: на простой и хорошо документированной задаче дешёвая модель в обвязке Claude Code доходит до полноценного рабочего результата. Платой за низкую стоимость становятся лишние итерации — там, где сильной модели хватило бы одной-двух правок, здесь их понадобилось около пяти. Для пет-проектов, прототипов и черновиков это разумный размен.
Больше про LLM и AI — в нашем Telegram-канале (@devgeek_sh). Разбираем новые модели, делимся опытом и полезными находками.