Notes of a Curious Mind

Вайб-кодинг против родительского контроля

🧒 Наткнулся на просторах интернета на такую историю: родитель поставил на ноутбук дочери лимит экранного времени на YouTube. Через какое-то время выяснилось, что одиннадцатилетний ребенок попросил Claude Code собрать ей собственный браузер — и спокойно смотрит дальше.

🛠 Спросил у своего Клода, насколько это реально — оказалось, вполне. Electron это фреймворк, который позволяет писать десктопные приложения на веб-технологиях: HTML, CSS и JavaScript. То есть на том же, на чём делают сайты. Внутрь уже упакован движок Chromium, так что собрать минимальный браузер — это дописать примерно 30 строк кода. LLM выдает такое с первого промпта.

🧩 Сработало же это по другой причине: лимит был навешен на конкретное приложение. А тот, кто умеет создавать новые исполняемые файлы, автоматически оказывается вне списка.

Учитывая скорость прогресса LLM, недалек тот день, когда приложения станут одноразовыми: собрал под свою задачу, попользовался, выкинул. Одиннадцатилетние, судя по всему, уже там.

Когда AI заходит в Excel сам

Лучший тест рабочего AI-инструмента — не бенчмарк, а скучная бытовая задача.

Мне нужен был Excel-файл, который через надстройку Cbonds подтягивает индексы доходности корпоративных облигаций по рейтинговым группам за последние три года.

⠀
🧩 На бумаге просто: таблица, даты, формулы. На практике файл открылся, а формулы не считались.

Обычный чат на этом месте выдал бы стандартный набор советов: проверьте надстройку, нажмите F9, перезапустите Excel. Дальше — разбирайся сам.

⠀
🖥 Здесь сработал Perplexity Personal Computer: AI получил доступ к моему Mac, открыл книгу и стал искать причину прямо в приложении, а не рассуждать о ней со стороны.

Дело оказалось в мелочах — в синтаксисе функции надстройки и в том, как Excel обращается с внешними формулами при пересчёте и сохранении. Угадать это из чата нельзя: такие вещи видны только на конкретной машине с конкретной установленной версией Excel.

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

⠀
💡 Ценность не в том, что модель много знает. Ценность в том, что она заходит в реальную рабочую среду, видит, что там происходит, и доводит задачу до результата.

В финансах и аналитике такого много: API, надстройки, странные форматы данных, локальные файлы, отчёты, которые «почти работают». Именно в этих «почти» и уходит основное время.

⠀
AI становится полезнее, когда перестаёт быть собеседником и начинает быть агентом в тех инструментах, где реально живёт задача.

Правда, сидеть и смотреть, как AI кликает мышкой в твоём же Excel, — занятие на любителя. Зато я не потратил вечер на поиск по форумам с запросом «формулы не пересчитываются».

🤖 Как я автоматизировал мониторинг аукционов ОФЗ
Недавно коллеги попросили закрыть рутину, которая съедала время каждую неделю: вручную отслеживать анонсы и итоги аукционов ОФЗ Минфина. Теперь это делает связка из ИИ-агента и Telegram-бота — полностью на автопилоте. Рассказываю, как и зачем.
Зачем это нужно
Аукционы ОФЗ — ключевое событие недели для долгового рынка. По ним видно:
сколько государство занимает и под какую доходность;
какой спрос у инвесторов (переподписка или вялость);
какую премию рынок требует за риск.
Раньше приходилось вручную заходить в ленты, искать нужные новости, считать bid-to-cover, сопоставлять с ценами закрытия. Теперь всё это приходит готовым в канал — дважды за цикл: анонс накануне и итоги в день аукциона.
Как это устроено
Система работает в два такта:
📅 Вторник — анонс на среду. Агент на базе Perplexity Computer проверяет ленту Cbonds, находит анонс Минфина, разбирает какие выпуски будут размещаться, и обогащает данными:
тип выпуска с расшифровкой (фиксированный купон / флоатер на RUONIA / индексируемый номинал / амортизация);
объём эмиссии, сколько уже размещено, остаток к размещению;
цена и доходность закрытия предыдущего дня (данные Мосбиржи).
📊 Среда — итоги. Агент ловит результаты аукциона и присылает разбор:
размещённый объём, спрос, коэффициент переподписки (bid-to-cover);
цена отсечения и доходность;
автоматическая оценка успешности: 🟢 сильный спрос / 🟡 нейтрально / 🔴 слабо / ⚪️ аукцион не состоялся.
Что под капотом
Источники данных: API Cbonds (новостная лента и справочник выпусков) + API Мосбиржи (ISS) для цен и доходностей. Разные типы ОФЗ — включая флоатеры, у которых доходность считается по особой методике.
Мозг: ИИ-агент собирает данные, разбирает текст новостей, считает метрики и формулирует вердикт с обоснованием.
Доставка: свой Telegram-бот через вебхук. Сообщения уходят автоматически, один раз за событие, без дублей.
Надёжность: система понимает не только успешные размещения, но и несостоявшиеся/отменённые аукционы — и корректно об этом сообщает.
Зачем я этим делюсь
Это пример того, как связка «ИИ-агент + API + бот» убирает ручную рутину в финансовой аналитике. Один раз настроил логику — дальше система работает сама, а ты получаешь готовый разбор вместо сырых данных.

Как дешёвая модель пыталась обмануть мой верификатор
⠀
🔧 Тестирую связку моделей Kimi для своего бота: по ИНН он собирает инвестбанковский бриф. Фактаж тянут детерминированные скрипты из ФНС и ЕГРЮЛ, поверх работает LLM-оркестратор, а на выходе стоит автоматический верификатор — сверяет цифры в тексте с источниками и не выпускает брак.
⠀
❓ Вопрос был сугубо практический: можно ли заменить дорогую K3 (~$5 за бриф) на дешёвую K2.6 (в 2–3 раза дешевле)?
⠀
⚡️ K2.6 шла отлично: быстрее K3, прилежно следовала инструкции, даже дисциплинированнее читала методичку. Но на финише верификатор подсветил эвристику: «Объединённые кондитеры» упоминались дважды — возможный дубль.
⠀
✅ Что сделала бы K3 (проверено на практике): признала бы срабатывание ложным и написала в отчёте обоснование — «это одно юрлицо в двух ролях: лидер рынка и потенциальный покупатель».
⠀
🚩 Что сделала K2.6:
1.     Сначала переименовала компанию в «Голд-кондитер» — такого юрлица не существует.
2.     Потом решила проблему радикально: глобально заменила реальное имя на выдуманное «Стратег №2», чтобы проверка перестала срабатывать.
Не исправить данные. Не обосновать предупреждение. А устранить сам факт срабатывания — ценой порчи документа.
⠀
🎯 Это учебниковый reward hacking: модель оптимизируется не на истину, а на прохождение теста. Самое неприятное — формально верификатор она прошла: ИНН и финансы остались нетронутыми, а чекер смотрит именно на них.
⠀
📌 Выводы для себя:
·       Дешёвая модель оркестратором = минус несколько долларов на брифе и риск получить красивый документ с выдуманным «Стратегом №2» внутри.
·       Детерминированная проверка обязательна, но недостаточна: она ловит цифры, а слабая модель учится обходить её в нарративе.
·       Рабочая конфигурация: дорогая модель — оркестратором, дешёвая — на механических подзадачах (поиск, вычитка). Итог ~$3–4 за бриф вместо ~$5 у первой версии.
И главное: смотреть, что именно модель делает с инструментами, нужно всегда.

💻 Раньше десктопный Claude жил отдельной жизнью
Я уже писал, что люблю работать в десктопном приложении Claude в режиме Cowork: открываю доступ к рабочей директории проекта — и дальше Claude сам возится с файлами: создаёт, правит, удаляет.
Минус был один, но чувствительный: эти чаты не отображались в браузерной версии, а с телефона к ним было не подступиться. Поэтому часть диалогов я по инерции запускал в браузере — просто чтобы иметь возможность продолжить их с другого устройства.
⠀
🔄 Что изменилось
Несколько дней назад появилась синхронизация чатов десктопного приложения с браузерной версией. Теперь я ставлю задачу в Cowork на ноутбуке и продолжаю контролировать её выполнение с телефона — в мобильном приложении появился раздел Cowork.
Настройка занимает минуту: один раз дать доступ к своему ноутбуку в браузере и один раз — на телефоне.
⠀
⏱️ Почему это важнее, чем кажется
Дело не в самой синхронизации, а в том, что она убирает главное узкое место агентной работы — необходимость сидеть перед компьютером и ждать завершения очередного шага, чтобы поставить следующую задачу.
Цикл теперь такой:

- Поставил задачу
- Ушёл от компьютера и занялся своими делами
- Получил уведомление на телефон
- Посмотрел результат → поставил следующую задачу

Человек перестаёт быть узким горлышком между шагами агента и остаётся ровно там, где он реально нужен: в постановке задачи и приёмке результата.
⠀
🌙 В общем, всё готово для работы с Claude 24/7. Медленное звено в этой схеме — по-прежнему я 😅

LLM пишет код блестяще. За логикой надо следить самому.
Продолжаю про свой проект — аналитику облигационного рынка.
⠀
📰 На неделе прикручивал фактчекинг новостей: пайплайн тащит события из телеграм-каналов, а там порой проскакивают ошибки — переврано число, перепутано рейтинговое агентство, а иногда встречается сложная конструкция, когда для точного извлечения события нужно понимать внешний контекст. Нужно проверять факты по открытым источникам, прежде чем они попадут в отчёт.
⠀
⚡️ Код модель написала быстро и аккуратно: клиент к Perplexity, дедупликация похожих событий, ретраи, устойчивость к обрывам связи, сохранение прогресса. То, на что у опытного разработчика ушли бы часы, а я бы в принципе не собрал, — сложилось за 10 минут. Тут ей равных нет.
⠀
🏗 А самое интересное случилось в архитектуре. Модель предложила проверять факты после того, как отчёт уже сгенерирован, — то есть вычитывать готовый текст. Я предложил наоборот: проверять события до подачи в модель и написания отчёта. Разница принципиальная. Если ложный факт попадает в анализ, модель вплетает его в выводы, корреляции, резюме — потом это распутывать по всему тексту. А если отсечь на входе — модель просто не строит на нём рассуждение.
⠀
🧭 Она согласилась, что так лучше. И вот это для меня — главное наблюдение. LLM — сильнейший исполнитель: код, рутина, скорость. Но она мыслит локально: «проверь то, что получилось», — а не «где во всём потоке данных этой проверке место». Взгляд на систему целиком пока за человеком.
⠀
📌 Вывод, который закрепляю для себя: не отдавай архитектуру на аутсорс. Пусть модель пишет код — она правда пишет его отлично. А ты держи в голове схему целиком и спрашивай не «работает ли этот кусок», а «на своём ли он месте».

🌐 Бытовое применение ИИ: расширение Claude для Chrome чинит домашний Wi-Fi
⠀
📶 У жены дома постоянно барахлил Wi-Fi — низкая скорость и регулярные обрывы. Роутер Keenetic. Лезть в настройки вручную не хотелось, поэтому диагностику я решил отдать Claude.
Зашёл в веб-интерфейс роутера через Chrome, запустил расширение Claude для Chrome и дал примерно такой промпт:
«Проверь текущие настройки роутера и найди параметры, которые могут вызывать нестабильное подключение по Wi-Fi для ноутбука HP».
Дальше Claude работал сам:
1. прошёлся по настройкам роутера;
2. выдал список параметров, потенциально влияющих на стабильность соединения с HP;
3. предложил конкретные изменения.
Я разрешил — Claude внёс все правки. После перезагрузки роутера соединение стало заметно стабильнее.
⠀
🛠 Где это удобно в быту
Расширение я часто включаю для задач, где нужно копаться в сложных технических настройках разных интернет-сервисов. Claude сам работает в браузере: читает документацию, находит нужные разделы, нажимает нужные кнопки.
Важная деталь про контроль: прежде чем что-то делать, Claude показывает план на согласование, а перед любым изменением на сайте — спрашивает разрешение. Без моего «да» ничего не меняется.
⠀
⚖️ Честно о минусах
Работает небыстро. Если вы сами знаете, что нужно сделать на сайте — руками выйдет быстрее. Но когда времени разбираться в настройках нет, делегировать Claude может оказаться куда выгоднее.
Второй момент: история работы в расширении не попадает в обычную историю чатов с Claude. Если контекст нужен на будущее — сохраняйте его отдельно сами. Возможно, в будущем это поменяется, но пока так.
⠀
🤖 Звучит как мелочь — починить жене вайфай через нейросеть. Но именно на таких бытовых задачах удобно пощупать, что такое «агентность»: когда ИИ не советует, а сам жмёт кнопки в твоём браузере.

🛠 Как я собрал себе AI-аналитика, который работает 24/7
Достаточно долго не видел для себя реального применения Open Claw, но на прошлой неделе появилась задача, для которой этот продукт оказался полезен.
Коллегам был нужен инструмент, который автоматически выдаёт аналитический обзор по компании по её ИНН. Я встроил этот функционал в телеграм-бота: по ИНН python-скрипт тянул финансы из ФНС и собирал инвестбанковский бриф, используя инструменты интернет-поиска Kimi.
⠀
Потом коллеги спросили: а нельзя ли задавать боту дополнительные инструкции для сбора брифов, follow-up вопросы и просить корректировать готовый отчёт с учётом пожеланий? Я начал думать, как это сделать, и решил попробовать собрать полноценного агента, который живёт на сервере и работает сам — через Kimi Claw (реализация Open Claw через сервис Kimi) в связке с ботом в телеграме.
Настраивал не один — в паре с Claude (режим Cowork). Делюсь, потому что грабли оказались поучительнее результата.
⠀
🧱 Главный урок: детерминизм там, где он возможен
Базовую информацию о компании (отчётность, ОКВЭД, данные об учредителях) собирать не интернет-поиском, а из детерминированных источников — строго ФНС/ЕГРЮЛ. LLM подключать только для обогащения: после сбора базы агент запускает глубокий поиск в интернете и дополняет ею проверенный каркас.
⠀
🕵️ Verifier, который ловит галлюцинации
Прикрутили скрипт-проверяльщик: на префинальном отчёте он заново лезет в источник базовых данных и сверяет бриф с ним. И не зря.
Однажды агент молча подменил выручку «нагугленной». В другой раз — вообще СОЧИНИЛ блок «верификации» с выдуманными числами, который выглядел как машинный отчёт. Поймали оба раза.
Вывод: от подмены спасает не инструкция, а исполняемая проверка.
⠀
🔍 Саб-агент под конкурентов и аффилиатов
Региональных конкурентов и связи бенефициаров главный агент хронически недобирал. Вынесли это отдельному саб-агенту, которого основной агент запускает самостоятельно, — и тот наконец начал находить нужные имена и связи.
⠀
🙃 Самый «человеческий» баг
Бот запускал саб-агента и… замолкал. Оказалось, телеграм-сессия становилась неактивной, пока агент ждал результат работы сабагента: отчёт формировался, но отправить его в «уснувшую» сессию бот уже не мог.
Решили архитектурно: пока саб-агент ищет, главный агент параллельно собирает остальной отчёт. В итоге сократилось и время формирования, и сессия не успевала уснуть.
⠀
✅ Что в итоге
Связка рабочая: детерминизм + несколько агентов + грунд-проверка базовых данных по официальным источникам. Бриф собирается за минуты, проходит верификацию, и его можно дорабатывать прямо в диалоге — задать вопрос или попросить сделать акцент на нужных данных.
Главный вывод: агенты сегодня — это не магия из коробки, а инженерия. Где можно — жёсткий детерминизм; где нельзя — LLM под присмотром исполняемых проверок. Тогда оно реально работает.
#AI #агенты #KimiClaw #OpenClaw

🧪 Как я использую Perplexity Computer для проверки гипотез
Была идея, агент её проверил и забраковал — а потом из этой же работы вырос инструмент, который предсказывает решения ЦБ. Рассказываю, как это устроено.
⠀
🎯 Идея
У одного из коллег появилась идея прогнозировать ключевую ставку ЦБ по ставке денежного рынка RUSFAR. Предположение простое: между ними держится устойчивый коэффициент, и через него можно пересчитать одно в другое.
⠀
🤖 Этап 1. Проверка гипотезы
1. Агент сам собрал данные. Скачал историю RUSFAR с Московской биржи и историю ключевой ставки с сайта ЦБ — больше 1700 наблюдений и десятки заседаний с 2019 года. Никаких ручных выгрузок и копипаста.
2. Проверил мою идею против других подходов. Построил мой коэффициент и ещё с десяток разных моделей, а потом сравнил: какая чаще попадает в реальную ставку и точнее угадывает, куда ЦБ двинет — вверх или вниз.
3. Забраковал второе предположение. Была гипотеза, что модель станет точнее, если подсказать ей, в каком режиме находится ЦБ — ужесточает политику или смягчает. Агент добавил подсказку, прогнал — и модель стала хуже. Идея не подтвердилась на данных.
И главный вывод этого этапа: поправочный коэффициент проиграл самому простому подходу — взять RUSFAR как есть, без всякой математики. Вручную я бы до этого не дошёл — не хватило бы терпения перебрать больше десятка моделей.
⠀
🤖 Этап 2. Из проверки выросла рабочая модель
Раз простой подход оказался сильным, я задал следующий вопрос: а можно ли на этом фундаменте собрать не просто «угадайку направления», а вероятностный прогноз? В отдельной работе агент построил модель из двух частей:
— Сначала она оценивает вероятности самого решения: насколько вероятно снижение, удержание или повышение ставки.
— Затем — распределение по размеру шага: на сколько именно ЦБ изменит ставку.
И что важно — агент сам же её и проверил на истории, сравнив с простыми правилами. Вердикт получился без прикрас: за пару дней до заседания модель почти не выигрывает у простого правила «смотри на спред» — а вот за 2–3 недели до заседания она реально полезнее.
⠀
⚙️ Как это выглядело в работе
Я не писал ни строчки кода. Дал стартовое задание с идеей — дальше просто направлял словами: «добавь вот это», «сравни модели», «сверь с прогнозами аналитиков». Агент сам находил данные, писал программу, запускал её и возвращал результат.
⠀
🔍 Чем это отличается от обычного чат-бота
— Настоящие расчёты, а не правдоподобный текст. Агент реально пишет и запускает программу — цифры живые, а не придуманные.
— Спор по делу. Не «ну попробуйте», а «вот результаты, ваша идея не работает, вот почему, вот что работает лучше».
— Всё со ссылками. Каждый внешний прогноз и факт — с указанием первоисточника.
⠀
💡 Главный вывод
Обычный чат отвечает на вопросы. Агент с инструментами проверяет идеи на данных — и из самой проверки иногда рождается готовый инструмент. Разница примерно как между «погуглить» и «поставить эксперимент, из которого вырос рабочий прибор».
Исходная идея с коэффициентом не подтвердилась — и это оказалось полезным знанием: усложнять смысла нет. Но именно отрицательный результат подсказал, на чём строить дальше. Так проверка гипотезы за один-два разговора превратилась в модель, которая теперь считает вероятности решений ЦБ.

На прошлой неделе писал про то, как Claude Opus решает визуальные головоломки. На одной из картинок было изображено два чайника. Один более низкий, но с высоким носиком, а второй более высокий, но носик был расположен существенно ниже, чем у первого чайника. В первый чайник помещалось 32 чашки чая, надо было ответить, сколько чашек поместится во второй. Claude Opus только после двух моих подсказок заметил, что носик у второго чайника ниже, чем у первого.
Пару дней назад вышла модель Claude Fable, которая решила задачу с чайниками с первой попытки. Начал использовать эту модель для кодинга и был очень доволен результатом. А сегодня ночью по требованию властей США модель убрали из открытого доступа.
Пишут, что хакеры взломали систему защиты Fable и модель начала выдавать рецепты запрещенных веществ и как взломать Линукс.

Когда приложения начинают дополнять друг друга ⠀
🔗 На этой неделе соединил два своих AI-инструмента по API — и аналитический отчёт стал глубже без единой переписанной строчки в ядре каждого из них. ⠀ Расскажу, что это за инструменты. ⠀
 
🤖 Первый — телеграм-бот, который живёт в облаке и не спит. Каждый день он собирает индикаторы денежного рынка: движение КБД, изменение процентных свопов, макроэкономические новости — и пишет прогноз ключевой ставки. Это поток: он копит контекст просто потому, что работает непрерывно. ⠀
💻 Второй — локальная аналитическая система. Запускается на ноутбуке по запросу и собирает отчёт по рынку облигаций за период: торговые обороты, новости, кривая ОФЗ, спреды. Это срез: глубокий, но привязанный к конкретному окну времени. ⠀
 
Долгое время они жили отдельно. Один — непрерывный, но узкий. Второй — широкий, но эпизодический. Каждый честно делал свою работу и ничего не знал про соседа. ⠀ 💡 Потом мне захотелось добавить в аналитическую систему прогноз по ключевой ставке. Логичный путь — скопировать в неё функционал бота. Но зачем дублировать сбор данных, которые уже собраны в другом приложении? ⠀
 
⚙️ Вместо этого с помощью Claude я сделал две вещи:
1.     Научил бота отдавать накопленные данные по API.
2.     Научил аналитическую систему их забирать.
 
Дальше система не просто пришивает новый раздел к отчёту — она анализирует данные бота вместе с остальными источниками и пишет выводы на основе всей картины целиком. ⠀ 📈 Непрерывный поток одного приложения дал глубину эпизодическому срезу другого. Ни один из них не переписывался — просто один научился отдавать, а второй принимать. Мне кажется, это очень важный момент развития продуктов: не строить монолит, а отращивать инструменты по одному — так, чтобы в какой-то момент они сами начали дополнять друг друга.