Opus 5.5 стоит проверять на скучном рабочем приложении, а не на красивой демке

Рабочая задача показывает модель честнее, чем эффектная игра

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

В тесте взяли именно такую задачу. Нужно было сделать личный сервис для наблюдения за роликами выбранных YouTube-каналов. Внутри - свежие видео, просмотры, лайки, комментарии и оценка того, насколько ролик набирает темп относительно обычных показателей. То есть не картинку на один экран, а связку из интерфейса, серверной части, базы данных и развёртывания.

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

Чёткие ограничения экономят попытки и не дают модели усложнить проект

Первый запрос пошёл не туда. Вместо плана приложения модель начала искать каналы. После уточнения ей дали ограниченный стартовый набор и конкретную рамку: один пользователь, простой Python, FastAPI, простая ORM, простая база данных, развёртывание на уже доступном сервере.

Примерно через десять минут появился план. В нём были разделы сервиса, добавление канала по ссылке, регулярный сбор данных, резервная копия базы и выбранный стек. Это хороший паттерн для работы с ИИ: сначала добиться короткого плана, затем проверить, не решает ли модель соседнюю задачу, и только после этого просить реализацию.

Фраза «сделай сервис» слишком расплывчата. Она оставляет модели пространство для лишних решений. Чем меньше проект, тем вреднее это пространство. Маленькому личному инструменту не нужна сложная архитектура только потому, что она выглядит солидно.

Полезно заранее назвать четыре вещи:

• кто будет пользоваться продуктом;
• какие действия обязаны работать в первой версии;
• что нужно хранить;
• где приложение должно быть запущено.

Если нужен ориентир для такой постановки и последующей сборки внутреннего инструмента, можно посмотреть ATLAS PANEL. Смысл тот же: сначала описать рабочий контур, а не просить ИИ угадать его по одному предложению.

Opus 5.5 собрал полный контур, но первый результат оказался медленным

После команды на реализацию Opus 5.5, по результатам теста, собрал и развернул сайт примерно за 20-25 минут. На выходе была парольная авторизация, лента роликов, открытие видео прямо в интерфейсе и показатели просмотров, лайков и комментариев. Расход лимитов оценили менее чем в 1% недельного лимита и примерно в 1-2% лимита на пять часов.

Это сильный сигнал для небольших проектов. Раньше самое неприятное место часто было не вёрсткой и даже не логикой, а развёртыванием. Код может выглядеть готовым, пока не сталкивается с сервером, переменными окружения, базой и фактическим запуском. Здесь модель прошла и этот участок.

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

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

Исправление после проверки важнее первого красивого результата

Проблему производительности не пришлось вручную искать по всему коду. После отдельной просьбы исправить тормоза модель за несколько минут нашла и устранила ошибки. Повторная проверка показала, что страницы и каналы стали открываться без полной перезагрузки.

Это не повод отключать контроль. Это повод строить работу правильно. ИИ хорошо ускоряет цикл «собрать - проверить - указать на дефект - поправить». Но цикл не работает, если человек пропускает этап проверки или формулирует претензию общими словами вроде «сделай лучше».

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

В тесте разница между первым и вторым состоянием была принципиальной. Функции существовали с самого начала. Пользоваться сервисом нормально стало только после проверки и исправления. Для небольшой команды это означает меньше потерь времени на ручную доработку вслепую, если тестировать приложение сразу после каждого заметного этапа.

Лучший первый шаг - собрать один замкнутый сценарий и сломать его проверкой

Сегодня не нужно пытаться поручить ИИ весь будущий продукт. Выберите один сценарий, который можно пройти от начала до конца. Например: добавить источник по ссылке, получить данные, увидеть их в списке и открыть карточку. Опишите этот сценарий в нескольких пунктах и попросите сначала план реализации.

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

Главный вывод из этого теста простой: Opus 5.5 можно использовать для сборки небольшого веб-приложения целиком, включая серверную часть и развёртывание. Но ценность даёт не один большой промпт. Её даёт дисциплина: сузить задачу, согласовать план, проверить работающий результат и отдельно потребовать исправить реальные дефекты.