Вайбкодинг on Игорь Лазарев

Как Fable 5 воскресил мою заброшенную научную работу

Mon, 06 Jul 2026 20:19:00 +0300

Хочу поделиться своим опытом использования модели Fable 5 от Anthropic. Сейчас это горячая тема, так как модель доступна ограниченное время по подписке. До этого момента я воздерживался от подписки Claude Code - хватало возможностей Cursor для кодинга и Codex для проектирования и сложных задач. Но активная маркетинговая кампания и buzz в чатах простимулировали всё-таки попробовать.

Первый заход: 4 с плюсом

С первой задачей Fable 5 справился… ну не знаю, скорее на 4 с плюсом. Дал ему доработать сложный проект с STT, написанный на Rust + Tauri. Нужно было внедрить мультиязычность в desktop-приложение и сделать onboarding для новых пользователей. Результат в целом получился, но где-то местами поехала вёрстка, где-то онбординг оказался сложен для “нулевого пользователя” (в плане скачивания моделей). То есть дорабатывать ещё много, но прогресс хороший - всю базовую работу модель сделала самостоятельно.

Из очевидных проблем: я запустил сессию полностью на Fable 5, без субагентов на другие модели. В итоге за полчаса он съел всё 5-часовое окно, и параллельные задачи на Opus были прерваны. Понятно, что этого следовало ожидать, но это был первый опыт запуска.

Незакрытый гештальт

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

И вот спустя много лет, когда появились кодинговые агенты, я подумал - а почему бы не попробовать? Честно говоря, сама тематика мне интересна не столько с инженерной точки зрения, сколько с пользовательской. У меня был определённый незакрытый гештальт. Когда я выступал на конференциях, я даже пробовал сделать живой тестовый стенд: помню, как на юге включал свой нетбук, крепил к нему CCTV-камеру и показывал, как приложение распознаёт звёзды со снимков. Но на тот момент оно работало посредственно - по сути была только внутренняя начинка без красивого визуала. После того как интерес угас, работа завалилась куда-то в архив.

Месяца три назад я решил попробовать её воскресить. Набросал с агентом план, заложил требования и… снова забил :-) Проблемой было то, что нужно было заниматься оркестрацией, следить за деталями работы агентов, и я попросту переключился на более интересные мне технические темы (агентская память, приложения для стриминга, персональная база знаний).

И вот… выходит Fable 5! А почему бы не дать ему такую задачу? Пусть сам всё прооркестрирует и напишет полноценное приложение - он же такая мощная модель (как заявлено разработчиком)!

Рабочая схема делегирования

Дальше я учёл опыт первой задачи (не стоит прям всё сваливать на Fable), а также узнал опыт других разработчиков из чатов. Рекомендация логичная: пусть Fable делает самую сложную работу, а более простую - делегируйте моделям попроще.

У меня как раз начала складываться рабочая схема. Сложные задачи и deep research я делегирую субагенту на Opus, а более линейные задачи средней и низкой сложности - через Cursor модели Composer 2.5. Честно говоря, мне эта модель очень нравится: Cursor получилось хорошо её прокачать, и при этом она относится к бюджетному классу.

Буквально недавно столкнулся с интересным опытом. Делегировал хорошо проработанную задачу на Sonnet 4.6. Я привык работать в связке “умная модель” (GPT-5.5 / Opus 4.8) для детального проектирования и “рабочая модель” для реализации. Каково же было моё удивление, когда Sonnet очень сильно “налажал”: там, где Composer 2.5 с лёгкостью справляется, следует инструкциям из скиллов и смотрит соседний код, Sonnet совершил критические ошибки. Интереса ради я потом запустил эту же задачу полностью на Opus 4.8 и полностью на Composer 2.5. Opus справился на 5: всё архитектурно чисто, соблюдены слои абстракций, правильно сделано взаимодействие с внешним сервисом (тут важно было “подсмотреть”, как сделано соседнее решение, - Sonnet этого не сделал и в итоге даже нарушил контракт из проектирования). На Composer 2.5 тоже получилось хорошее решение без критических замечаний, но не такое архитектурно чистое (местами не соблюдены слои абстракций, хотя и не критично). Может быть, опишу этот опыт подробнее в одном из следующих постов.

Как оказалось, интегрировать Claude Code и Cursor не так уж и сложно - есть плагин cursor-plugin-cc (по сути аналог codex-plugin-cc для интеграции Codex). Я как раз успел набить с этим взаимодействием несколько шишек и написать скилл для более качественного делегирования задач.

Запуск

Теперь переходим к сути. Вот буквально тот промт, который я дал Fable на вход:

Хочу довести этот проект до рабочего состояния.

Цель проекта - получить GUI приложение для распознавания снимков звездного неба. Изучи концепцию проекта.

Конечная цель работы - в GUI (Desktop) приложении должна быть возможность загрузить снимок, запустить процедуру распознавания и на оверлее (поверх снимка) нарисовать созвездия. Так же отметить наиболее яркие светила. Из задачи со звездочкой - отмечать планеты.

В директории data/input приложил реальные снимки звездного неба. Хочу чтобы именно на них вся система заработала. По сути можно считать это acceptance criteria.

По технической части - приложение на Rust + Tauri. Дизайн продумай сам. Он должен быть удобным и красивым (импортируй нужные скиллы из хаба скиллов - см. ~/work/agentmem, ~/work/skills). По алгоритмический части - нужно найти золотую середину. Начать можно с неоптимальных алгоритмов, но к конечному результату лучше добиться хорошей эффективности, но не слишком сильно уходить в микрооптимизации.

Перед запуском в работу имеет смысл сделать Deep Research на тематику с помощью субагента Opus и сверить стратегическое направление.

Так же перед разработкой проверь окружение - установлен ли rust, скачаны ли базы данных (лучше hyg_v42)? Если самостоятельно это не получится сделать, то сразу сигнализируй.

Сам процесс разработки распланируй и бери в работу поэтапно. Сложные части делегируй субагентам Opus, более линейные и определенные задачи через Cursor (см. скилл task-delegation).

И он ушёл работать. Надолго. Пришлось даже его перезапускать - не уложился в одно 5-часовое окно на тарифе Max. В общей сложности работал около 4-5 часов.

Результат

Вот результат, который ждал меня в пулл-реквесте - оно работает! Приложение успешно распознаёт звёзды на моих снимках 15-летней давности, сделанных на CCTV-камеру:

После этого я ещё попросил сделать презентацию для уровня студентов. Получилось тоже очень прилично - как будто можно взять и выходить завтра на защиту :-) Саму презентацию можно посмотреть прямо в блоге: StarGlyph - слепое распознавание звёздного неба .

Получившийся исходный код выложил в открытый доступ: github.com/starglyph/engine .

Итог

Fable действительно оказался хорош и смог справиться с такой объёмной задачей без единого уточняющего вопроса. Жаль, что по подписке он доступен совсем недолго… Цена на API сильно кусается. Хотя, думаю, скоро нас всех ждут корректировки на любые виды ИИ-подписок :-)

Как я навайбкодил CommRelay и перестал бояться desktop-приложений

Sun, 21 Jun 2026 15:36:56 +0300

Недавно я выпустил CommRelay - локальное приложение для стримеров, которое собирает чат из Twitch, YouTube Live и VK Live в один overlay для OBS. На игровом блоге уже есть релизный пост , а здесь хочу скорее зафиксировать инженерную часть истории: как я в очередной раз подумал “а почему бы не навайбкодить свое?” - и внезапно получил рабочее desktop-приложение.

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

В какой-то момент я понял, что хочу контролировать этот кусок сам. У меня большой опыт backend-разработки на Go, а задача по сути выглядела знакомо: взять несколько источников сообщений, привести их к общей модели, раздать через WebSocket и показать в браузере. Не космический корабль, а понятный локальный сервис.

Первой версией CommRelay была обычная CLI-тулза. Запускается локальный HTTP-сервер, у него есть админка и отдельная страница overlay для OBS:

1
2

http://127.0.0.1:17877/
http://127.0.0.1:17877/overlay

Для меня как для разработчика это нормальная модель. Запустил бинарник, открыл адрес, добавил Browser Source в OBS - всё понятно. Но для обычного пользователя это уже лишний слой сложности. Хочется, чтобы было как с нормальным приложением: скачал, распаковал, кликнул, окно открылось, всё работает.

И тут я подумал про desktop.

До этого у меня уже был опыт вайбкодинга desktop-приложения на Rust для распознавания голосовых команд. Опыт был полезный, но местами болезненный. Rust мне менее знаком, а с GUI постоянно всплывали какие-то мелочи: то внешний вид, то поведение компонентов, то странные проблемы в деталях интерфейса. У меня сложилось ощущение, что кодинговые агенты сейчас гораздо увереннее работают с web-интерфейсами, чем с классическим desktop GUI.

А Go мне роднее. Плюс CommRelay всё равно по природе серверное приложение: коннекторы, reconnect, OAuth для YouTube, локальный config, WebSocket, раздача статических файлов. Поэтому мысль “оставить core на Go, а desktop сделать как тонкую оболочку вокруг web UI” выглядела очень естественно.

Примерно в это же время мне попалась статья про Wails. И внезапно оказалось, что это почти идеально ложится на задачу. Wails даёт desktop-окно, lifecycle приложения, сборку под разные платформы и возможность использовать привычный веб-фронтенд внутри. В CommRelay desktop-версия просто поднимает локальный сервер в фоне и открывает админку в окне приложения. Overlay при этом остаётся обычным URL для OBS, что отлично совпадает с моделью Browser Source.

Технически это оказалось приятно простым. Основная логика не переехала в какой-то новый мир: Go-код остался Go-кодом, HTTP-сервер остался HTTP-сервером, overlay остался веб-страницей. Wails добавил удобную упаковку, а не заставил переписывать архитектуру.

В первом релизе я даже не стал усложнять фронтенд: админка и overlay сделаны на обычных HTML/CSS/JS. Но после этого опыта мне стало гораздо спокойнее смотреть и на связку React + Go + Wails. Если нужен более сложный интерфейс, можно взять React и всё равно держать backend-часть на знакомом Go. Получается очень понятное разделение: Go отвечает за надежность, интеграции и локальный сервер, frontend - за удобный интерфейс.

Самое приятное, что результат не остался игрушечным прототипом. CommRelay уже умеет собирать чат из Twitch, YouTube Live и VK Live / VK Video, показывает статусы подключений, поддерживает emotes, безопасные превью картинок, настройки overlay и автоматический reconnect. А главное - я сам уже провожу с ним стримы.

Итог для меня довольно важный: я перестал бояться desktop-приложений. Раньше они казались отдельной категорией боли, где нужно заново погружаться в чужой GUI-стек и постоянно бороться с деталями платформ. Теперь у меня появилась более спокойная модель: если приложение хорошо раскладывается на локальный backend и web-интерфейс, то Go + Wails закрывают огромную часть задач.

Само приложение лежит на GitHub: github.com/mechastrider/comm-relay . А если интересна пользовательская сторона проекта, то вот тот самый релизный пост в игровом блоге: Первый релиз CommRelay - локального мультичата для OBS .