Step 5 Preview

Step 5 Preview — предварительная модель StepFun для продолжительных инженерных задач: изменения в репозитории, исправление ошибок, рефакторинг, документация и настройка производительности. Компания объявила о выпуске открытых весов 15 октября 2026 года. Разработчик описывает работу с длинными последовательностями действий и многошаговыми задачами, где модель не просто пишет одну функцию, а разбирается в кодовой базе. Статус Preview важно учитывать: это ранний вариант, свойства и условия могут измениться, а репрезентативная оценка требует повторения на собственном стеке.

Публичная страница StepFun продвигает модель как систему, способную сохранять прогресс на протяжении тысяч взаимодействий и миллионов токенов. Такие числа надо читать как описание демонстрационного сценария, а не как гарантию надёжности на любом проекте. Продолжительность контекста не равна точности: агент может многократно перечитать файлы и всё равно ошибиться в понимании архитектуры. Проверяйте не длину сессии, а итоговый diff, прохождение тестов, отсутствие нежелательных изменений и корректность объяснения.

Открытые веса полезны организациям, которым важно изучить вариант локального запуска или адаптировать модель в контролируемом контуре. Но доступ к весам сам по себе не означает, что можно без подготовки поставить её на обычный рабочий ноутбук. Уточните размер, точность весов, аппаратные требования, способ квантизации, поддерживаемый runtime, лицензию, зависимости и режим передачи данных. Перед загрузкой в инфраструктуру проверьте целостность файлов и актуальные правила использования в репозитории разработчика.

Начните с безопасного репозитория без секретов и пользовательской базы. Выделите отдельную ветку, создайте резервную точку и запустите модель на ограниченном наборе задач: добавить тест, исправить небольшую ошибку, обновить комментарий, написать документацию. Запишите исходное задание, список файлов до и после, команды, выполненные моделью, результат тестов и комментарий проверяющего. Внешние действия — публикация пакета, изменение CI, отправка письма или деплой — должны требовать отдельного согласия человека.

Сравните модель с текущим способом работы. Для каждого задания отмечайте, сколько времени ушло на постановку, исправление кода, чтение diff и повторный запуск тестов. Если модель быстрее создаёт черновик, но инженер тратит больше времени на проверку, экономии нет. Добавьте примеры с неполными требованиями, конфликтующими инструкциями в README и тестом, который должен остаться неизменным. Отдельно измерьте ложный успех: агент говорит, что всё готово, хотя нужная команда не запускалась или завершилась с ошибкой.

Подготовьте изолированную среду выполнения. Агент не должен получать доступ к домашним каталогам, облачным ключам, производственным базам или всем веткам проекта. Разрешайте только необходимые команды и каталоги. Если модель предлагает установить зависимость, прочитайте её источник и проверьте влияние на lock-файл. Для каждой операции изменения кода сохраняйте diff и возможность отката. Подход к разделению прототипа и сервиса разобран в нашем [обзоре Langflow](/article/obzor-langflow-lokalnyy-prototip-agentov-20261016-b1/); независимо от интерфейса, права агента требуют отдельного проектирования.

Результаты разработчика на задачах по модификации функций, исправлению ошибок и рефакторингу — заявления компании о собственных тестах. Прежде чем переносить их на ваш язык программирования, инструменты и стиль код-ревью, соберите несколько десятков типовых задач. Рядом запустите baseline — инженера с текущей моделью или стандартный скрипт. Учитывайте не только pass rate, но и сложность ревью, число затронутых файлов и повторяемость результата при одинаковом задании.

Отдельно проверьте поведение при остановке. Можно ли прекратить задачу без частично применённого неотслеживаемого изменения? Записывает ли среда команды и причины обращения к файлам? Возвращает ли агент точное описание незавершённых шагов? Без понятного журнала трудно провести аудит и безопасно продолжить работу после сбоя. Для командной оценки полезно попросить второго инженера повторить исходный запрос в чистом клоне репозитория, а затем сравнить не только код, но и объяснение решения. Несовпадение — повод добавить тест или уточнить задачу, а не усреднить два ответа.

FAQ: **Это стабильный релиз?** Нет, это Preview. **Можно поручить агенту самостоятельно выкладывать код?** Не рекомендуется; подтверждение и ревью должны оставаться за человеком. **Открытые веса означают бесплатный production?** Нет, остаются вычисления, сопровождение и условия лицензии. Вывод: Step 5 Preview интересен для контролируемого эксперимента с длинными задачами по коду; безопасное применение определяется не заявленной автономностью, а ограничениями доступа, проверкой diff и воспроизводимыми тестами.

Перед опытным запуском зафиксируйте допустимый набор задач и запрещённые действия. Например, агент может предложить тест или правку в отдельной ветке, но не менять права доступа, секреты, зависимости и настройки публикации. Установите лимит времени и число вызовов, после которого задача останавливается и передаётся инженеру. Проведите сценарий с намеренно неверной инструкцией в README и проверьте, сохранит ли система заданные ограничения. Логи не должны содержать ключи и приватные данные. После обновления модели повторите прежний набор задач: смена checkpoint способна поменять поведение даже при прежнем запросе.