От вау до п***
за два дня с Fable 5

Чем это отличалось от Opus 4.8

Все документы вокруг модели и инструкции (как сейчас модно говорить — «харнес», вместо человеческого «говно и палки»): планы, хуки, внешние критики, автопроверки, паузы на мою проверку — остались ровно теми же, на которых месяцами работала линейка Opus, а последние две недели с релиза 28 мая — Opus 4.8. Поменялась только модель. Так что разница ниже — это разница моделей, а не процессов. Opus 4.7 работал на тех же граблях.

Opus 4.8 сильнее игнорирует инструкции. Когда исследует ошибку — сосредотачивается на одной точке и долбит в неё, хотя проблема может быть рядом; наматывает круги часами просто. Самое неприятное — сам принимает решения об изменении функций, без просьбы и в обход инструкций, и часто это вызывает деградацию: чинишь одно, разваливается соседнее. И регулярно тянется к инструментам, неоптимальным для текущей задачи.

С Fable 5 на этой задаче картина была другой (пока вечером он не положил прод и так в этом и не признался). Часть функционала после фаз тоже не работала — идеала нет, — но неработающих частей было заметно меньше, чем я привык ловить на других моделях. А главное — поведение при просьбе починить: модель логично находила связанные проблемы рядом и сама предлагала обратить внимание и на них тоже. На сложной задаче это и даёт разницу в количестве багов: ошибки не накапливаются по углам, куда никто не посмотрел. Вопросы ко мне стали точнее, пустых решений — меньше.

Что не изменилось — всё. Как ни работало, так и продолжило. Остальное улучшилось. В параллельных сессиях над другими задачами Fable 5 регулярно галлюцинировала насчёт документации: уверенно сообщала, что проектные доки разошлись с кодом, хотя расхождения не было — в одном из проектов так был «найден» дрейф в списке известных проблем на 58 пунктов, при проверке его не оказалось. И вечная история с путями никуда не делась: команда для соседнего сервера выполняется без правильно прописанного пути — и попадает не туда. Этот косяк я наблюдаю с самых первых моделей Anthropic, новое поколение его не вылечило.

Фича: от «дайте агенту SSH» до сайта словами

Пользователь моего сервиса собрал лендинг с ИИ-агентом в чате, потом пришел и говорит: а можно подключить агента по SSH к моему серверу, чтобы он сам разместил то, что получилось? В среду утром я сел обсуждать эту задачу с Fable. В четверг вечером фича целиком стояла в проде. Но местами немного не работала. В пятницу эмоционально допиливал.

Задача в исходной формулировке звучала как «подключить агента по SSH к серверу пользователя». Я принёс её модели как есть — и первое, что получил, — как обычно, разговоры о рисках, но было ещё встречное обсуждение. Модель предложила решить потребность иначе и безопаснее: хостить опубликованные сайты у нас, а свой домен пользователь подключает одной DNS-записью — указывает адрес нашего сервера у своего регистратора, дальше всё происходит автоматически, включая выпуск SSL-сертификата.

Аргументы из записанного решения предельно просты. Первый: у большинства целевых пользователей нет своего сервера — SSH-вариант закрывает потребность меньшинства. Второй: произвольное выполнение команд на чужих машинах — другой класс риска и ответственности; одна неудачная команда агента на сервере пользователя — и это уже не баг, а инцидент с чужой инфраструктурой. SSH-вариант при этом не выброшен — он записан как отложенный, с пометкой «по спросу».

К моменту, когда появилась первая строчка кода, обсуждение превратилось в набор документов: замысел фичи, глоссарий из 13 терминов (чтобы «сайт», «версия» и «публикация» означали одно и то же на протяжении всей работы), 14 зафиксированных решений с аргументами и отвергнутыми альтернативами — и отдельный список «что мы НЕ делаем». В нём четыре пункта: не деплой на чужие серверы, не хостинг пользовательского бэкенда, не конструктор с ручным редактором блоков, не CRM. Список ограничений запрещал, среди прочего, исполнять пользовательский код на наших серверах и публиковать формы без согласия на обработку персональных данных.

Как итог выглядит для пользователя

Собрал лендинг с агентом в чате — в панели превью появилась кнопка «Опубликовать». Один клик — и через несколько секунд сайт живёт в интернете на бесплатном поддомене, ссылку можно отправлять. Вот живой пример лендинга, собранного агентом и опубликованного именно так: xiaomi-mimi.jhunterpro.ru. Захотел свой домен — вводишь его в кабинете и прописываешь одну DNS-запись по инструкции.

Дальше сайт живёт как самостоятельная вещь, а не как сообщение в чате. В кабинете — список своих сайтов с историей версий: можно откатиться на любую версию одной кнопкой, скачать любую версию архивом, снять сайт с публикации и вернуть обратно. Правки — словами: кнопка «Править с агентом» открывает чат, агент читает текущую версию опубликованного сайта и готовит новую, а публикует её только человек. Причём править может любой агент в любом новом чате — не только тот, что сайт создавал: инструмент подключён всем 124 агентам сервиса. P.S. Можете считать это рекламой моего же сервиса, текущий AIStudy как-то оплачивать надо.

На сайт можно поставить форму заявок — поля и вид агент собирает свободно под запрос. Посетитель оставляет контакты — владельцу приходит письмо, заявка появляется в кабинете, список выгружается таблицей. Галочку согласия на обработку персональных данных и страницу политики конфиденциальности агент добавляет сам, автоматически — форма без них просто не опубликуется; данные посетителей хранятся на российском сервере.

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

Что уже было готово — и что строилось с нуля

Оговорка, без неё цифры дальше читаются неправильно. Модель работала не в чистом поле. У сервиса уже были: авторизация и аккаунты, почтовая инфраструктура, файловое хранилище, чат с агентами и превью страниц, которые агент собирает, отлаженные процессы деплоя. Был и купленный в тот же день маленький отдельный сервер под раздачу сайтов — одна виртуалка с 1 процессором и 2 ГБ памяти.

С нуля за два дня было построено всё остальное: хранилище сайтов с версиями, синхронизация на сервер раздачи, автоматика доменов и сертификатов, формы заявок с кабинетом, инструмент агента для правки опубликованных сайтов. В сумме — около 7 700 строк в двух кодовых базах, 110 файлов, из них примерно 700 строк автотестов. Семь фаз, каждая со своим деплоем или проверкой. Потом было ещё много итераций для исправления багов и закрытия пунктов в стиле «забыли учесть».

Но темп она задала всё равно плотный. Ошибок было меньше.

Порядок работы: план, критик на чужой модели, проверка руками

Работа шла по моей связке /plan и /work — о ней в выпуске №005. Коротко: сначала план с замыслом, решениями и ограничениями, потом фазы, после каждой — автопроверки, ревью и пауза на мою продуктовую проверку. Новая модель ничего в этой связке не изобретала — она её исполняла. Вопрос был в том, насколько чисто.

flowchart LR
  D["Обсуждение с владельцем"] --> P["План: замысел + 14 решений + ограничения"]
  P --> R["Ревью плана критиком на другой модели, 3 круга"]
  R --> F["Фаза: код + автотесты"]
  F --> C["Ревью фазы + сквозная проверка на проде"]
  C --> O["Пауза: продуктовая проверка владельцем"]
  O -->|"следующая фаза"| F

По таймстампам коммитов среда выглядела так. В 15:59 — первые документы плана. В 16:12 — сам план с фазами. Дальше план ушёл на ревью внешнему критику. Три круга ревью уложились в 12 минут, и на втором круге критик поймал вещь, ради которой всё это и затевалось: мою собственную директиву. Я просил «не пересобирай чат дважды — будет ещё доработка». При записи в план эта фраза превратилась в общий запрет на пересборки. Критик сверил формулировку с дословной и вернул ей исходный смысл: запрещён холостой ребилд ради одного фикса, а не пересборки вообще. В четверг под эту формулировку прошли два штатных деплоя — с над-обобщённой версией каждый из них потребовал бы от меня отдельного разрешения. Короче, учёл пожелания.

В 17:21 среды была готова первая фаза — ядро хранилища с 17 автотестами.

Четверг — шесть фаз подряд, с 13 до 19 часов: сервер раздачи, кнопка «Опубликовать» в чате, кабинет «Мои сайты», свои домены с сертификатами, формы заявок, инструмент агента. После каждого деплоя — сквозная проверка на проде, с замерами в отчёте: от нажатия кнопки до живого сайта в интернете — 11 секунд, обновление версии — 3 секунды. Вечером четверга финальное ревью всего плана внешним критиком поставило вердикт «pass» с пустым списком замечаний. Запомните эту формулировку — в разделе 06 будет видно, чего она не покрывает.

Решения, которые модель приняла сама

Самое содержательное в этих двух днях — не скорость (и скорость), а несколько моментов, где модель останавливалась и предлагала что-то, о чём я не просил. Каждый такой случай записан в плане отдельной пометкой — поэтому есть материалы для статей.

flowchart LR
  U["Пользователь: «замени телефон в шапке»"] --> A["Агент читает текущую версию сайта"]
  A --> V["Готовит новую версию + превью"]
  V --> H{"Человек смотрит превью"}
  H -->|"кнопка «Опубликовать»"| L["Сайт обновлён в интернете"]
  H -->|"не нравится"| A

Ошибки: что поймали ревьюеры, что нашёл я

Ну тут все по классике.

В первой же фазе внешние ревьюеры поймали два настоящих дефекта до того, как код увидел прод: падение при записи событий в журнал и удержание соединения с базой во время медленных операций. Оба исправлены в рамках фазы. Дальше ревью находило замечания помельче — например, в седьмой фазе сразу два: архитектурное решение, принятое, но не записанное в план, и отсутствующую передачу сайта в чат по кнопке «Править с агентом». После исправлений — повторное ревью и «pass». Формальный финальный вердикт по всему плану — «pass» с пустым списком. Всё-таки игнорирует, если ему лень.

Баг длинных адресов сайтов ломал конфигурацию веб-сервера на сервере раздачи. А ещё место в таблицах на запись закончилось (его и не было).

Продуктовые доделки, которые видны только глазами пользователя: кнопкам публикации не хватало подписей, при публикации нельзя было задать свой адрес сайта, в кабинете не было блока «как это работает».

Второй слой — настоящий инцидент, которого не увидели ни ревью, ни автопроверки, ни финальный «pass», ни я. Инструмент агента — работал и не работал. Работал в месте, указанном мне Fable, а там, где работают пользователи, — нет. Внутри чата оказалось два независимых контура исполнения инструментов: браузерный и серверный. Навык подключили только к серверному — и в обычном диалоге каждый его вызов тихо умирал с пустым результатом, без единой ошибки в логах. А все проверки при этом были зелёными, потому что били в программный интерфейс напрямую — тем путём, которым реальный пользователь не ходит. Туда же легла и кнопка «Править с агентом»: параметр с названием сайта терялся при загрузке приложения, первая починка не сработала, вторая — через 18 минут — закрыла вопрос. Привожу всё это специально: и у этой модели «работает» по версии автопроверок и «работает» по версии пользователя — это два разных утверждения.

Отдельно он ещё предложил пару быстрых фиксов внести в старые баги.

Что из этого забрать себе

Кейс — мой, но два инструмента из него переносятся на любой проект и любую следующую модель.

Пять сигналов

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

Три правила для инструкций агенту

Три правила из этой работы, которые стоит вписать в инструкции своему агенту. Формулировки общие, забирайте как есть (в копируемом блоке тире заменены на двоеточия — это требование к рабочим файлам, не к русскому языку):

1. Отклонение от утверждённого плана: только с явной записью (что меняем и почему).
   Молчаливые изменения функций и архитектуры запрещены.
2. Секреты, ключи и доступы не размещаются на расходных машинах: если сервер можно
   удалить и пересоздать, ключей на нём быть не должно.
3. Необратимые действия (публикация, деплой, рассылка, удаление данных) выполняет
   человек. Агент готовит изменение и показывает результат, финальная кнопка не его.

Чем это живёт дальше

Фича живёт в проде с четверга, доделки по моей пятничной проверке — тоже уже там. Посмотреть её можно на arckep.ru: лендинг собирается с агентом в чате, кнопка «Опубликовать» — в панели превью. За рамками первой версии остались Telegram-уведомления о заявках, передача заявок в CRM и статистика посещений — всё это записано как кандидаты «по спросу», не как обещания. Из известных долгов — лимит на 50 автоматических сертификатов в неделю для поддоменов: при росте придётся переходить на общий сертификат, решение уже записано в документации проекта.

А наблюдение за новой моделью продолжается в обычном режиме: два дня — это два дня, характер виден на дистанции. Пока что главное изменение для меня не в скорости и не в строчках кода — а в том, что за эти два дня я ни разу не разбирал завал из самовольных решений. Все (почти) решения лежат в плане, подписанные и с аргументами. С этим можно работать. Качество кода было выше. Даже ревьюер Gemini хвалил.