Alexandr Fadeev

📺 Ютюб Премиум на год за тысячу рублей

2026-09-02T16:39:32.616Z

Долгое время у меня Premium висел на российском регионе, поэтому стоил какие-то совсем смешные деньги. Но спустя несколько лет YouTube наконец сбросил регион и зафорсил покупать подписку по европейской цене — а это между прочим 15 евро в месяц вместо пары, которые я платил раньше.

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

Не знаю, почему сразу не вспомнил про Plati.Market (plati.ru). Я там уже кучу раз покупал игры, подписки и прочие штуки значительно дешевле. Решение нашлось буквально за несколько минут.

💸 Покупал вот этот конкретный лот примерно за тысячу рублей на год (€10). Сейчас он временно недоступен, но в категории YouTube полно аналогичных предложений.

После оплаты прислали ссылку для активации. Перешел по ней с одного из своих YouTube-аккаунтов — и Premium сразу заработал. Никаких передач логина и пароля, привязки чужих карт или гемора с регионом.

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

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

Подпишешься на мой Telegram?

🎙 Локальные диктовалки для Mac

2026-08-31T16:39:09.755Z

Для голосовых заметок я пользуюсь Voicenotes. Сервис хороший, но рекомендовать его я не буду, своих денег только ради транскриайба он не стоит. Вообще платить тут не нужно, ведь хватает бесплатных альтернатив Wispr Flow и другим сервисам.

🎤 Самым интересным сейчас выглядит FluidVoice. Это нативная open source апка для macOS с live preview, историей, настройками для разных приложений и словарем, который учится на исправлениях. Есть режимы для переписывания выделенного текста и выполнения голосовых команд.

🤓 TypeWhisper — самое задротное решение. Здесь можно собирать отдельные воркфлоу для приложений и сайтов: в Terminal оставлять почти сырой транскрипт, в Slack чистить текст, а в IDE сохранять технические термины. Поддерживаются локальные и облачные LLM, постобработка, словари, сниппеты и т.п. Но и возиться с настройками придется больше.

Сам Handy никуда не делся. Самый популярный полностью локальный Whisper или Parakeet, push-to-talk, вставка текста в активное поле и поддержка разных ОС. Я им сам долго пользовался. Он делает свою одну задачу, но без прикольных фич.

🆓 Spokenly закрытое, но локальные LLM бесплатны, работают офлайн и без лимитов. Использование собственных API-ключей тоже бесплатное. По отзывам у него очень неплохая скорость работы.

В общем, платить за нормальную диктовку уже необязательно. FluidVoice выглядит самым универсальным вариантом, TypeWhisper — самым настраиваемым, а Handy остается хорошим выбором, если нужен простой push-to-talk без лишних фич.

Подпишешься на мой Telegram?

😴 Самый дешевый апгрейд сна

2026-08-31T15:41:53.526Z

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

Но внезапно оказалось, что эта максимально примитивная и глупая штука реально очень круто работает. Мне маска помогает быстрее заснуть, меньше просыпаться от света и в целом заметно лучше спать. Именно простота эффекта и подкупает.

🥷 Причем не нужен никакой оверпрайснутый биохакерский девайс. Типа электрических масок, с охлаждением, гигантскими поролоновыми вставками и прочими хитровыебанными конструкциями. Я отлично спал даже в обычной маске, которую мне дали в экономе в самолете.

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

🌅 Единственный минус — первое время может стать тяжелее просыпаться утром. Маска продолжает изображать глубокую ночь, даже когда вокруг уже светло. Но если вставать примерно в одно время, организм постепенно подстроится.

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

Подпишешься на мой Telegram?

🧩 Как переключаться между аккаунтами Codex и Claude

2026-08-31T15:14:52.259Z

В последнее время слишком быстро высасываются квоты Codex-а. Резеты происходят уже не часто, а работать надо 🙃 Поэтому наконец мне понадобилось нормально переключаться между сервисами и подписками, не занимаясь постоянным logout/login.

По совету из чатиков поставил Quotio — приложение для управления квотами и аккаунтами. Под капотом оно запускает локальный прокси CLIProxyAPI, через который и проходят запросы.

Работает так:

Codex / Claude Code
        ↓
      Quotio
        ↓
  локальный прокси
   CLIProxyAPI
        ↓
 несколько аккаунтов

🔀 Мой основной кейс — переключение между корпоративным и персональным аккаунтом. Первому выставляешь priority 100, всем остальным меньше и выбираешь стратегию Fill First. Пока на основном аккаунте есть квота, все запросы идут туда. Затем прокси должен автоматически перейти к следующему. Если нужно переключиться вручную, аккаунт можно временно отключить руками в Quotio.

💣 Отдельно пришлось разбираться с моими скриптами для автоматизации. Некоторые из них запускают codex -exec во временном CODEX_HOME, чтобы окружение было изолированным. Они копируют только авторизацию и ничего не знают про настройки Quotio.

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

🛠️ С Claude оказалось сложнее. У меня один логин, внутри которого есть Business и Personal workspace с разными квотами. Но Quotio видел только один аккаунт. В исходниках CLIProxyAPI выяснилось, что имя OAuth-файла строится только из email. Поэтому при авторизации второго workspace файл первого просто затирается.

Решение: авторизовать один workspace, сразу переименовать его credential-файл, переключить активный workspace и повторить OAuth. После этого прокси видит оба файла и может работать с ними отдельно. Я по очереди отключил каждый и проверил реальные запросы — обе квоты действительно работают.

✅ В итоге Codex и Claude Code теперь ходят через один локальный роутер, который сам выбирает аккаунт. Схема не идеальная: при повторной авторизации Claude можно снова затереть credential-файл, приоритеты приходится настраивать руками, а без запущенного Quotio ничего через прокси не работает. Но это все редко, а перелогиниваться между аккаунтами больше не нужно.

Подпишешься на мой Telegram?

Практический playbook по внедрению мультиагентных систем

2026-08-20T22:27:45.686Z

Мультиагентные системы легко рисовать и неожиданно сложно эксплуатировать. Исследователь, проверяющий, планировщик и исполнитель на диаграмме выглядят как аккуратная модульная архитектура. В production эти прямоугольники превращаются в независимо падающие компоненты, которые передают друг другу неидеальные данные, конкурируют за состояние, повторяют внешние действия и иногда не согласны даже с тем, что уже произошло.

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

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

1. Сначала докажи, что тебе вообще нужны несколько агентов

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

Отдельный агент оправдан, если у этапа появляется хотя бы одна настоящая граница:

• ему нужен отдельный большой или специализированный контекст;

• ему требуются другие данные или права;

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

• его результат необходимо независимо проверить;

• ему нужна другая модель, промпт, latency budget или набор инструментов;

• его можно повторять, отключать или заменять без перезапуска всего процесса;

• его результат образует естественный проверяемый контракт для следующего этапа.

Не создавай нового агента только потому, что роли «исследователь», «критик» и «редактор» звучат как серьёзная команда. Если различие существует лишь в системном промпте, а контекст, инструменты, права и failure domain остаются общими, это могут быть режимы одного агента, а не три отдельных компонента.

Полезный тест — заменяемость. Если компонент нельзя независимо запустить, оценить и заменить, скорее всего это просто шаг.

2. Опиши workflow до проектирования агентов

Перед архитектурой заполни карточку процесса:

Название:
Цель:
Триггер:
Входные данные:
Финальный результат:
Кто использует результат:
Допустимое время выполнения:
Допустимая стоимость:
Внешние изменения:
Обязательные подтверждения:
Что считается успехом:
Что считается частичным успехом:
Что считается провалом:

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

Если карточку невозможно заполнить без фразы «агент сам решит», границы процесса пока не определены. Автономность должна работать внутри ясных правил, а не заменять отсутствующие продуктовые решения.

3. Явно выбери модель координации

Для сложных процессов и нормального аудита безопасным default обычно будет оркестрация.

Триггер
  → Orchestrator
  → Сбор контекста
  → Независимая работа агентов
  → Валидация контрактов
  → Синтез
  → Человеческое подтверждение
  → Применение

Orchestrator отвечает за порядок, состояние, параллельность, таймауты, retry policy, валидацию и остановку. Агенты получают вход, выполняют ограниченную работу и возвращают результат. Они не вызывают друг друга и не импровизируют глобальный workflow.

Choreography подходит процессам, которые действительно построены вокруг независимых событий. Завершённый импорт может отдельно запустить индексирование, аналитику и уведомление. Если уведомление упало, это не должно отменять сам импорт.

Не используй чистую choreography, если порядок меняет результат, несколько агентов участвуют в одном решении, присутствуют внешние действия, требуется полный audit trail или отсутствуют правила для повторных и пришедших не по порядку событий.

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

4. Проектируй агентов по ответственности, а не по персонажам

У каждого агента должна быть одна понятная зона ответственности и операционная карточка:

Имя:
Назначение:
Входной контракт:
Выходной контракт:
Разрешённые инструменты:
Разрешённые данные:
Разрешённые изменения:
Timeout:
Лимит стоимости:
Условия отказа:
Безопасность повтора:
Fallback:
Компенсирующее действие:

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

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

5. Не заставляй модель выполнять работу обычного кода

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

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

Это повышает надёжность и резко упрощает тестирование. Нет смысла спрашивать LLM, валиден ли JSON, когда парсер отвечает на этот вопрос идеально.

6. Считай каждый handoff контрактом

Агенты не должны передавать друг другу произвольный текст со словами «вроде всё готово». Для каждой передачи нужна версионированная схема.

{
  "schema_version": "1.0",
  "run_id": "weekly-2026-W34",
  "producer": "research_agent",
  "created_at": "2026-08-20T12:00:00Z",
  "input_state_version": 3,
  "status": "complete",
  "findings": [],
  "sources": [],
  "confidence": 0.84,
  "warnings": []
}

Минимально сохраняй версию схемы, идентификатор запуска, производителя, timestamp, версию входного состояния, статус, confidence, warnings и использованные доказательства.

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

Не меняй значение существующего поля молча. Добавление необязательного поля обычно совместимо. Превращение confidence из «уверенности агента» в «процент подтверждённых утверждений» требует новой версии схемы.

7. Храни состояние workflow вне контекста модели

Контекстное окно — не база данных. Для каждого запуска нужен долговечный record с версией workflow, триггером, текущим шагом, входным snapshot, версиями состояния, попытками, статусом подтверждения, внешними действиями, финальным результатом и причиной отказа.

Предпочитай append-only transitions или immutable snapshots:

state_v0 → контекст собран
state_v1 → источники классифицированы
state_v2 → исследование завершено
state_v3 → черновик создан
state_v4 → человек подтвердил
state_v5 → внешнее действие применено

Исправление создаёт новую версию, а не переписывает историю. Для каждого snapshot сохраняй агента-производителя, входную версию, модель, версию промпта, инструменты, timestamp и результат валидации.

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

8. Определи семантику повторов до первого сбоя

Для каждого шага заранее ответь: что произойдёт, если он выполнится дважды?

Read-only анализ обычно можно повторить безопасно. Внешние действия — нельзя. Создание задачи, отправка письма, платёж или публикация должны использовать idempotency_key:

workflow + run_id + action_type + target

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

Автоматический retry допустим только для временных технических ошибок: timeout, сетевого сбоя, известной кратковременной недоступности и rate limit с определённой задержкой. Не повторяй автоматически ошибки валидации, отсутствие прав, отказ пользователя, несовместимые контракты и операции с неоднозначным результатом.

Timeout не доказывает, что внешний эффект не произошёл. Сначала проверь целевую систему и только затем решай, безопасен ли новый запрос.

9. Назначь каждому сбою явный результат

У каждого шага должно быть одно заранее выбранное поведение:

• Fail closed: остановить workflow. Подходит для прав, безопасности, финансовых решений и публикации.

• Degraded mode: продолжить с явно ограниченным результатом.

• Cached fallback: использовать последний допустимый результат с ограничением по свежести.

• Human escalation: создать review artifact с объяснением проблемы и доступными действиями.

• Skip: пропустить некритический шаг и показать это в финальном результате.

Молчаливого fallback быть не должно. Пользователь обязан отличать полноценный результат от созданного в degraded mode.

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

10. Запланируй компенсацию внешних действий

Каждое действие классифицируй как обратимое, компенсируемое или необратимое.

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

Если поздний шаг упал, компенсация выполняется в обратном порядке завершённых действий, но только там, где она безопасна и осмысленна. Если точный rollback невозможен, зафиксируй инцидент и передай его человеку вместо того, чтобы называть «примерно вернули как было» чистым состоянием.

11. Сделай человеческое подтверждение настоящим состоянием

Human review — не диалог подтверждения, прикрученный в конце. Это часть state machine:

draft_ready
  → awaiting_review
  → approved / rejected / edited / expired
  → apply

Review artifact должен объяснять, что изменится, почему, какие данные и агенты участвовали, что было пропущено, какие есть warnings, как выглядит точный preview или diff и какие действия доступны пользователю.

Подтверждение относится к конкретной версии. Если после него изменился черновик, target или параметры, старое approval перестаёт действовать.

Разумный default: автоматически разрешать чтение, анализ и создание черновика, но требовать явного подтверждения для внешних изменений, сообщений, публикации, удаления, чувствительных данных и платных API.

12. Сделай наблюдаемым весь запуск

Один run_id должен проходить через orchestrator, агентов и инструменты. Для каждого шага сохраняй агента, номер попытки, latency, модель, версию промпта, входную и выходную версии состояния, tool calls, результат валидации, токены, примерную стоимость, тип ошибки и fallback.

Не складывай чувствительный input в обычные логи. При необходимости сохраняй редактированную версию, hash или ссылку на защищённый artifact.

Полезные метрики всего workflow: успешные и частично успешные запуски, ручные вмешательства, ошибки каждого этапа, общая и поагентная latency, количество повторов, стоимость, токены, частота fallback, отклонённые approvals, остановленные дубли и доля результата, которую переписал человек.

Последняя метрика особенно важна. Если пользователь переписывает 80 процентов работы агента, агент не экономит время только потому, что технически завершился успешно.

13. Тестируй систему слоями

Детерминированные unit-тесты должны проверять контракты, переходы состояния, idempotency, retry policy, circuit breakers, права, approval gates, компенсацию и редактирование чувствительных данных.

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

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

Наконец, искусственно ломай workflow. Проверь timeout, повторную доставку, рестарт orchestrator, повреждённый snapshot, несовместимую схему, отказ пользователя и падение сразу после внешнего действия. Если процесс нельзя безопасно продолжить после исчезновения orchestrator, он не готов.

14. Увеличивай автономность поэтапно

Используй последовательность:

ручной прототип
  → shadow mode
  → draft mode
  → reversible apply
  → controlled automation

В ручном прототипе сохраняются inputs и outputs, но внешних действий нет. В shadow mode workflow запускается автоматически и сравнивается с существующим ручным процессом. Draft mode создаёт review artifact. Reversible apply допускает низкорисковые действия с idempotency, audit и компенсацией. Controlled automation оставляется для хорошо изученных операций небольшого риска; необратимые и чувствительные действия остаются за approval.

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

15. Установи production-readiness gate

Workflow готов к регулярному использованию, когда у каждого агента есть понятная причина существовать, все handoff валидируются машиной, состояние переживает рестарт, повторный запуск не создаёт дубли, для каждой зависимости определено поведение при отказе, внешние действия защищены approval, версии моделей и промптов сохраняются, чувствительные данные не попадают в обычные логи, частичные сбои проверены, неудачный запуск можно воспроизвести, а стоимость и latency укладываются в заданные бюджеты.

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

16. Удаляй агентов так же охотно, как добавляешь

Периодически и после крупных изменений моделей проверяй, какие агенты часто падают, какие результаты постоянно переписываются, какие дорогие этапы почти не влияют на итог, где постоянно срабатывает fallback, какие данные собираются без применения и какую LLM-работу можно заменить обычным кодом.

Мультиагентная система не обязана развиваться только добавлением новых ролей. Удаление агента часто сильнее улучшает надёжность, стоимость, latency и понятность всей архитектуры.

Практический default намеренно скучный: детерминированный trigger, детерминированный orchestrator, минимальный контекст, несколько read-only специалистов, валидация контрактов, один этап синтеза, review artifact, явное подтверждение, отдельный apply-компонент и audit record.

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

Мультиагентная система — это распределённая система. Пора относиться к ней соответственно

2026-08-20T22:09:54.769Z

Один AI-агент обычно выглядит обманчиво просто. У него есть промпт, набор инструментов, доступ к данным и понятная задача. Он получает запрос, что-то делает и возвращает результат. Если результат плохой, мы правим промпт, меняем модель или добавляем контекст.

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

Но пять агентов — это не просто пять промптов в плаще. Это уже распределённая система.

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

Модель может работать идеально, а система — всё равно ошибаться

В выступлении о production-grade мультиагентных системах приводится пример автоматизированной кредитной проверки. Один агент рассчитывает кредитный рейтинг, другой проверяет доход, третий оценивает риск, четвёртый ищет признаки мошенничества, а последний принимает решение.

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

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

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

Оркестр или танцпол

Есть два базовых способа организовать взаимодействие агентов.

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

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

В хореографии центрального координатора нет. Агенты реагируют на события. Исследователь публикует research.completed, аналитик подхватывает событие и после своей работы публикует analysis.ready, а генератор отчёта слушает уже его.

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

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

Проблемы начинаются не тогда, когда команда выбирает «неправильный» паттерн, а когда вообще не делает выбор. Агенты просто начинают вызывать друг друга, писать в общую базу и надеяться, что как-нибудь разберутся. Охуенная идея, только вот работать будет ровно до первого параллельного запроса.

Общее состояние — удобный способ устроить хаос

Представим, что два агента одновременно читают одно значение. Первый обновляет его с 680 до 750, второй — с 680 до 720. Если оба просто записывают результат обратно, последнее обновление побеждает, а первое бесследно исчезает.

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

Более устойчивый подход — не позволять агентам бесконечно переписывать один общий объект, а сохранять новые версии состояния. Агент получает конкретный snapshot, выполняет работу и создаёт следующий. Предыдущие версии остаются неизменными.

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

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

Агенты должны общаться через контракты

Одна из самых привлекательных особенностей LLM — способность понимать неструктурированный текст. Из этого легко сделать странный вывод, что между агентами можно передавать произвольный JSON или простыню Markdown, а следующая модель как-нибудь догадается, что имелось в виду.

Она действительно часто догадывается. В этом и ловушка.

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

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

Это особенно важно потому, что LLM умеют создавать правдоподобные ошибки. Обычная программа чаще падает на неожиданном формате. Модель может принять его, неверно интерпретировать и продолжить работу так уверенно, будто всё идёт по плану.

Сбой должен быть частью дизайна

Любой удалённый вызов иногда не отвечает. Модель достигает лимита, инструмент падает, сеть тормозит, провайдер возвращает ошибку, агент зависает в цикле или выдаёт результат, который не проходит валидацию.

Поэтому таймауты, ограниченные повторы и circuit breaker — не дополнительные production-фичи, которые можно прикрутить потом. Это часть нормальной семантики вызова.

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

Circuit breaker нужен, чтобы один сломанный компонент не утянул за собой весь воркфлоу. После серии ошибок система временно перестаёт обращаться к нему и либо переходит в ограниченный режим, либо использует последний допустимый результат, либо передаёт решение человеку. Что именно делать, определяется не инфраструктурной библиотекой, а смыслом процесса. Пропустить генерацию красивого саммари можно. Тихо пропустить проверку мошенничества — уже не очень.

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

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

Observability важнее ещё одного агента

В демо достаточно увидеть финальный ответ. В production нужно понимать, как он появился.

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

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

Хорошая трассировка нужна не только для поиска багов. Она позволяет сравнивать версии моделей, воспроизводить неудачные запуски, видеть, какой агент расходует большую часть токенов, и понимать, действительно ли добавление нового компонента улучшило результат. Без этого мультиагентность легко превращается в дорогой способ сделать систему сложнее, не имея возможности доказать, что она стала лучше.

Хорошая мультиагентная система выглядит скучно

Самая полезная мысль здесь довольно неприятная: основная работа при создании надёжной мультиагентной системы происходит не в промптах.

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

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

Именно это отличает систему от набора агентов, которые бодро разговаривают друг с другом и иногда случайно делают правильную вещь.

💸 Код стал дешевым. Софт — нет

2026-08-19T15:05:15.167Z

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

Именно поэтому все вокруг обложились личными новостными дайджестами, ассистентами, трекерами калорий и прочей автоматизацией. Я в том числе. Но почти все эти штуки объединяет одно: ими пользуется один человек. Если что-то сломалось, можно открыть Claude Code, немного поругаться, поправить и жить дальше.

🛠️ Реальным продуктом пользуются другие люди, у него появляется куча данных, интеграций, платежи и невообразимые сценарии использования. В итоге старые решения влияють на новые, и любая небольшая правка внезапно ломает что-то в другом месте.

🗑️ Чем дольше живет проект, тем дороже становится каждая следующая строчка. Агент, который сначала делал фичу за один промпт, постепенно начинает тратить бесконечное количество итераций даже на простые изменения. А потом четыре дня из пяти будут уходить не на новые фичи, а на исправление багов.

Очевидно, что AI сильно изменил разработку, но не отменил ее базовые правила. Написать код стало дешево. Написать что-то хорошее, что сможешь развивать и поддерживать несколько лет, — все еще сложно.

🧠 При этом самое полезное, что сейчас можно делать, чтобы не застрять в старом мире, — учиться AI. Не обязательно только вайбкодингу, хотя без него уже тоже сложно. Можно разбираться во всем, что связано с AI и может сделать эффективнее именно в той работе, которой уже занимаешься.

Главный навык — не просто умение быстрее генерировать результат. Намного важнее научиться принимать нормальные решения заранее, ставить задачи и держать агентов в рамках системы. Иначе магия заканчивается ровно в тот момент, когда нужно продолжить работать над первой версией. Чего большинство вообще сейчас не умеет.

Подпишешься на мой Telegram?

🎓 Тебе не нужны курсы по AI

2026-08-17T15:05:15.388Z

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

🏎️ И это логично — все меняется слишком быстро. А сложные агентские системы еще нужно месяцами проверять на разных проектах, чтобы понять, дадут ли они хоть какой-то эффект где-то еще.

А ведь материал еще нужно структурировать, красиво упаковать, зарекламить и продать. К моменту выхода курса половина уже может устареть. В лучшем случае такое обучение отстает на несколько месяцев, а обычно — на год.

🤡 У меня самого тоже чешутся руки сделать какой курс по вайбкодингу. Но смысл мне рассказывать о собственных кейсах, которые сработают у всех.

📚 При этом бесплатной информации полно. Например, есть прекрасный Claude Code How To: команды, память, скиллы, сабагенты, хуки, MCP, плагины, продвинутые фичи и готовые примеры. Я сам еще не прошел его целиком, но уже нашел кучу вещей, о которых не знал. Полезно будет даже тем, кто сидит в CC целыми днями. Если просто пройти этот сайт и параллельно пробовать все на реальных задачах, понимание инструмента уже будет выше, чем у большинства людей, называющих себя вайбкодерами.

Есть курсы Matt Pocock, набор скиллов которого я уже давно рекомендую всем. Банальные cheat sheets по СС и прочее. Развлекайтесь.

Кстати мои гайды по целеполаганию и похудению проживут намного дольше любого курса по AI. Люди пока обновляются реже, чем Codex резетит лимиты 🙃

Подпишешься на мой Telegram?

Weekly (15 August)

2026-08-15T11:05:14.661Z

Вчера не успел, исправляюсь.

🎧️ Слушаю и смотрю 👀

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

➣ Galaxy Z Fold 8 Review — очень странный телефон, но чуваку этому понравился. В целом я пока вайб складных телефонов все еще не уловил, хотя хочется.

➣ The robot hype is worse than you think — на канале Fireship хороший разбор текущего состояния роботов. Удивительно, насколько там всё плохо и как мы, похоже, далеки от реально полезных гуманоидов.

📚️ Читаю

➣ Неплохая статья о том, как чел сделал домашний сервер из телефона на Android: phone-server.

➣ В очередной рассылке Арнольда интересный обзор про отсутствие эффекта яблочного уксуса на похудение (внезапно, лол).

💻️ Приложения и сервисы

➣ x.ai и Cursor выпустили GrokBot, своего десктопного AI-ассистента. И я уже было заинтересовался, но проблема тут одна — $200. Спрашивается, зачем, если за те же деньги у ChatGPT ты получаешь тьму всего?

👨‍💻 VibeCode

➣ Увидел в одном из видео про приложение cmd ctrl app — удаленный доступ к AI агентам с телефона. Апка имхо стоит внимания.

➣ Одна из самых важных фич агентов — это их кеш. Вот есть скилл, который аудирует кеш LLM-агента, находя фейлы и прочее, тем самым оптимизируя его работу. Если тема сильно интересна, то вот здесь референс на большую статью про кэш. Но тут важно понимать, что это аудит не локального CC или Codex, а агентского пайплайна в разработке.

➣ У Глеба Кудрявцева старая, но хорошая статья на тему того, как правильно ставить цели (/goal) Кодексу, чтобы он реально их делал и проверял.

➣ Сборник "loop"-ов для агентов. Фактически это набор промптов для goal.

➣ Cloudflare представил кучу AI-продуктов. Из интересного: браузер для агентов Kitesurf и AI Search. У первого пока не успел попробовать и понять, в чем разница с Browser Run, а вот поиск — это по сути готовый RAG из коробки. Звучит очень интересно, буду пробовать, напишу отдельный пост.

➣ Скилл для поиска и удаления дубликатов скиллов. Полезная хрень, ведь растет бесконечно, у меня уже штук шесть скиллов на код-ревью 🙃

➣ Warp добавили поддержку Grok через подписки на X. Грок примечателен тем, что входит в подписку на сам X, поэтому любое его внедрение куда-либо — это хорошо.

➣ Thermo-Nuclear Code Quality Review — хороший скилл от команды Cursor. Он больше проверяет "спагетти"-код, чем просто ревью багов.

➣ diagram-design — плагин с типами диаграмм, который учит агента делать хорошие диаграммы, а не вот этот Mermaid-стоп, который они создают по дефолту.

Подпишешься на мой Telegram?

🚀 Шесть законов гиперроста AI-компаний

2026-08-12T15:05:14.688Z

Наткнулся на большое исследование Севы Устинова о том, как росли Harvey, Sierra, Deel, Glean, Wiz и еще десяток быстрорастущих AI-компаний. Он собрал их метрики, интервью с фаундерами и сотрудниками, а затем выделил шесть повторяющихся законов роста.

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

🎯 1. Начинать с узкой специализаци. Не строить «AI-платформу для всего», а найти один процесс, где продукт дает не 20% улучшения, а десятикратную экономию времени или денег.

👑 2. Первый клиент должен быть максимально известным. Один большой и уважаемый клиент создает больше доверия, чем десяток неизвестных компаний.

🧑‍💼 3. Нанимать в продажи экспертов из индустрии. Юрист лучше продаст продукт другому юристу, а бывший банкир — банку. Эксперта можно за несколько недель научить продукту, но продавцу невозможно быстро выдать двадцать лет отраслевого опыта.

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

💰 5. Сравнивать цену с человеческим трудом, а не с другим софтом. Sierra продает обработку обращения дешевле доллара, тогда как человеческий контакт обходится примерно в $13. На таком фоне даже дорогой AI-продукт выглядит почти бесплатным.

📈 6. Встроить рост выручки в сам продукт. Больше обращений, сотрудников или использования — больше выручки автоматически. Не нужно раз в год приходить к клиенту и вымучивать очередной апсейл.

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

Подпишешься на мой Telegram?