поддержка

Модель Harvi Code

Claude Sonnet 4.5: рабочая модель для кода, а не витрина возможностей

Sonnet 4.5 хорош не громкими демонстрациями, а тем, что его можно открыть утром на обычной задаче и не думать, не слишком ли она маленькая для модели. Ошибка в форме, неясный тест, правка API, небольшой рефакторинг — именно такой поток составляет большую часть разработки.

01Модель для нормального рабочего дня

У разработчика редко бывает задача уровня «построй новую платформу». Чаще нужно понять чужой участок кода, добавить ветку обработки ошибки, обновить тесты и не расползтись в соседние файлы. Sonnet 4.5 подходит для этого ритма: можно давать ей короткие конкретные поручения и быстро проверять результат.

Хорошая постановка здесь почти всегда содержит артефакт. Не «почини авторизацию», а «вот ответ 401 и вот маршрут; найди первый слой, который теряет заголовок, добавь тест». Чем уже граница задачи, тем полезнее модель и тем проще оценить сделанное.

02Почему она удобна для исправлений

Anthropic выпускала Sonnet 4.5 вместе с обновлениями Claude Code: контрольными точками, инструментами для работы с проектом и Agent SDK. Это хорошо описывает её естественное место — не выдавать фрагмент в чате, а пройти короткий инженерный цикл рядом с вашим кодом.

Используйте это буквально: сначала попросите воспроизвести ошибку или прочитать тест, затем внести минимальную правку, затем прогнать проверку. Так вы не получаете «правдоподобный» код без связи с проектом.

03Когда лучше не упираться в Sonnet

Если расследование растягивается на множество сервисов и у каждого изменения высокая цена, разумнее позвать Opus. Sonnet может сделать такую работу, но вы быстрее упрётесь в необходимость постоянно направлять её и перепроверять гипотезы.

И наоборот: для массовых рутинных преобразований не обязательно выбирать модель с инженерной амбицией. Там полезнее заранее задать формат и отправить поток на более экономичный уровень.

Коротко

Для чего Sonnet 4.5 подходит лучше всего?
Для ежедневной разработки: локальных исправлений, тестов, ревью небольших изменений, разбора ошибок и понятных задач в одном участке проекта.
Как проверить её результат?
Давайте задачу через воспроизводимый симптом или тест и просите завершать работу фактической проверкой, а не описанием того, что «должно работать».