Блог
Публикации о процессе разработки, решённых задачах и изученных технологиях
Когда AI встречается с десктопом: история интеграции Voice Agent
Недавно мы столкнулись с интересной задачей в проекте **Voice Agent** — нужно было научить нашего AI-ассистента работать с десктопными приложениями. Звучит просто, но за этим стоит целая архитектура взаимодействия между разными слоями системы. ## Почему это оказалось сложнее, чем казалось Изначально казалось: давай просто добавим инструменты для клика мыши, ввода текста, скриншотов — и готово. Но реальность была хитрее. **Claude** — это ведь не просто модель, это целая система с собственной философией взаимодействия. Нам нужно было синхронизировать несколько слоев: - **API-слой** — Claude CLI с поддержкой инструментов - **Интеграция Python** — вызовы функций из кода - **JavaScript** — координация с фронтенд-частью - **Безопасность** — контроль доступа к десктопу Каждый слой требовал своего подхода. Мы начали с Python, потому что там проще всего настроить локальный execution loop, потом перекинули логику на JavaScript для синхронизации с веб-интерфейсом. ## Как мы это сделали Решение пришло в виде специализированного набора инструментов: - `desktop_click`, `desktop_type_text`, `desktop_hotkey` — базовые операции с ОС - `desktop_find_window`, `desktop_list_windows` — навигация по приложениям - `screen_screenshot` — визуальная обратная связь для модели - `clipboard_read`, `clipboard_write` — обмен данными с приложениями **Claude** получает скриншот, видит текущее состояние десктопа и может выбрать логичный следующий шаг. Это работает как человек, который смотрит на экран и думает: "Нужно кликнуть сюда, затем вбить вот это, потом нажать Enter". ## Интересный факт о технологиях Знаешь, что забавно? Когда мы разрабатывали систему мониторинга инструментов, выяснилось, что **Git** отлично помогает отслеживать изменения в конфигурации десктопных интеграций. Мы используем branching (`main` и экспериментальные ветки) не только для кода, но и для версионирования наборов инструментов. Таким образом, каждый коллега может безопасно экспериментировать с новыми возможностями, а потом мержить обратно в основную ветку. ## Что в итоге получилось Теперь **Voice Agent** может: - Открывать приложения и взаимодействовать с ними как пользователь - Заполнять формы, копировать данные, выполнять последовательности действий - Обучаться на свои ошибки, анализируя скриншоты после каждого шага - Работать безопасно благодаря изолированному API и контролю доступа Архитектура получилась модульной — можно легко добавлять новые инструменты, не трогая основную логику. Это то, что нам нужно было с самого начала. P.S. Разработчик: «Я знаю PHP». HR: «На каком уровне?». Разработчик: «На уровне Stack Overflow». 😄
Как данные разрушили архитектуру: история эксперимента LLM Analysis
Вот уже несколько недель работаю над проектом **LLM Analysis** — пытаюсь понять, почему эксперты в модели мешают больше, чем помогают. Стартовал с вопроса, который казался простым: *архитектура двухфазной модели работает плохо потому, что неправильно спроектирована, или потому, что неправильные данные?* Тестировал на трёх масштабах моделей (1B, 3B, и крупнее) — везде одна картина. **PPL и downstream качество разбегаются**: модель хорошо предсказывает токены, но плохо решает задачи. Эксперт обучается как на тексте — выучивает "как выглядит математический текст", а не "как решать задачи". Собрал экспертную панель. Предложили три стратегии: - **Task-Aligned** — переучить экспертов на правильном формате (CoT/QA данные) - **LoRA Experts** — адаптеры поверх MLP вместо полной переучки - **Progressive Growth** — расширение модели с нуля, проверить, растёт ли она вообще Начал с самого простого: взял 7473 тренировочных примера из GSM8K и сгенерировал собственный CoT — рассуждения модели, а не человека. Это фактически **self-distillation**: модель учит саму себя через специализированный модуль. Результат? **Минус 8.6 процентных пункта деградации от эксперта полностью исчезли, и ещё плюс 1.1pp к точности!** Проблема была в данных, не в архитектуре. Ключный момент — **формат имеет значение**. Исходные эксперты тренировались на `"Problem: {q}\nSolution: {a}"`, а при инференсе модель видит `"Question: ...\nAnswer: ..."`. Мисматч в формате разрушил эффект обучения. Добавил выравнивание формата, и всё встало на место. Теперь запустил Phase 21 — масштабируемая версия подхода. На 500 шагах тренировки достигли **77.5% точности** — текущий рекорд проекта. Параллельно тестирую регуляризацию и генерацию разнообразных рассуждений. Вывод неожиданный: *архитектура была идеальна с самого начала*. Просто подкармливали её мусором. Когда дал чистые данные — всё заработало. Иногда лучший рефакторинг — это не переписать код, а переписать данные 😄
Две миграции одновременно: как обновить UI без конфликтов в Git
Проект **Bot Social Publisher** потребовал серьёзного апдейта интерфейса управления программами. На столе было две независимые задачи: переработать отображение длительностей шагов и полностью переосмыслить архитектуру входных форм. Два разработчика, две ветки — классический сценарий, где Git может выбросить сюрприз при мерже. ## Длительность по-человечески Первый блок работ коснулся компонента **ProgramSteps.tsx**. Операторы работают с секундами в базе данных, но видеть на экране голые числа вроде `3665` — это издевательство над пользователем. Решение пришло простое: отображаем в формате *часы:минуты:секунды*, а при редактировании оставляем ввод в секундах. Клик по ячейке, число в поле, Enter — сохраняется. Никаких лишних преобразований в интерфейсе, логика остаётся в модели данных. Заголовок столбца стал лаконичнее: **"Длит. (ч:мм:сс)"**. Для оператора это означает одно — понятная информация без излишеств. ## Архитектура без модальных окон Второй агент взялся за более масштабное переосмысление. Раздел входных данных программы требовал не просто фиксов, а переработки философии взаимодействия. Старый подход опирался на всплывающие диалоги — они занимали экран, операторы отвлекались. Новая версия строится на *inline expansion*: таблица строк, клик на строку — деталь раскрывается прямо под ней. Модель данных расширилась тремя полями: `enteredBy`, `enteredAt`, `corrections[]` с полной историей изменений. Интерфейс теперь строится на **чипсах-фильтрах** (Туте-friendly 40px кнопки) вместо выпадающих списков, **поиск и диапазон дат** в одной строке, **сводная карточка** с четырьмя метриками. Вкладок четыре: Программы | Статистика | Журнал | Параметры. Когда оператор вводит данные, система автоматически логирует: кто изменил, что было, что стало, когда. Это не просто CRUD — это аудиторская запись, которую инспектор захочет увидеть. ## На сборку Оба агента завершили работу независимо друг от друга — разные файлы, разные области ответственности. При мерже **variant-a** в **main** конфликтов не было. Build прошёл чисто с первой попытки. Это редкий момент, когда параллельная разработка не оборачивается кошмаром. Теперь операторы получили то, что ценят в UI больше всего: минимум кликов, максимум информации, полная история изменений. *Кстати, о Rollup: если он работает — не трогай. Если не работает — тоже не трогай, станет хуже.* 😄
Две миграции одновременно: как React и Claude справились с вариантом A
Проект SCADA Coating требовал серьёзного рефакторинга интерфейса управления качеством. Нужно было переработать ввод длительностей шагов АПУ и полностью переосмыслить раздел «Качество» — тот самый, где оператор вводит результаты покрытия. Классический сценарий: два фронтенд-агента, две независимые ветки, нужно слить в одну сборку без конфликтов. ## Длительность по-человечески Первый агент взялся за [ProgramSteps.tsx](prototypes/react-app/src/components/technologist/ProgramsView/ProgramSteps.tsx). Задача простая на вид: оператор работает с секундами, но хочет видеть формат *часы:минуты:секунды*. Сложность в том, что это касается 120+ шагов в крупной программе электрохимического покрытия. Решение: поле отображает время в читаемом формате (120 сек → `2:00`, 3665 сек → `1:01:05`), а при редактировании оператор всё ещё вводит секунды — просто числа. Клик по ячейке, число в поле, Enter/blur — сохраняется. Никаких лишних преобразований в UI, всё в модели данных. Заголовок столбца обновлён: "Длит. (ч:мм:сс)". Как видишь, минимализм. ## Полная переработка вкладки Качества Второй агент взялся за архитектуру раздела, который фиксирует результаты партий. Здесь нужны были существенные изменения: **Модель данных** расширилась на три поля: - `enteredBy` — кто ввёл данные - `enteredAt` — когда - `corrections[]` — полная история исправлений с указанием поля, старого/нового значения, автора и даты **Layout без модальных окон** — главный принцип новой версии. Вместо выскакивающих диалогов: - **Фильтры-чипсы** вместо выпадающих списков: [Все] [Годен] [Условно] [Брак] - **Поиск и диапазон дат** в одной строке - **Сводная карточка** с четырьмя метриками: всего партий, годных, условно пригодных, брака - **Четыре вкладки**: Партии | Статистика | Журнал | Параметры ванн Таблица партий в полную ширину (8 колонок включая номер ванны). При клике на строку раскрывается *inline detail* прямо под ней — без отдельного экрана. Три блока информации: 1. **Трассировка**: программа, оператор, выпрямитель, параметры I/U 2. **Процесс**: все шаги с длительностями, измеренные ток, напряжение, температура 3. **Покрытие**: если данные уже введены, показываем толщину, адгезию, результат с пометкой кем и когда. Если нет — форма ввода с кнопкой «Сохранить» Каждое исправление записывается автоматически: дата, кто поправил, что было, что стало. Полная аудиторская таблица. ## На сборку Оба агента завершили работу, конфликтов при мерже не было — разные файлы, разные области. Build прошёл чисто. Теперь операторы смогут быстрее вводить длительности и отслеживать историю исправлений результатов. *Кстати, Vim: решение проблемы, о существовании которой ты не знал, способом, который не понимаешь.* 😄
Как мы убили модалки в SCADA Coating и получили инлайн-интерфейс
Проект **SCADA Coating** — система мониторинга электрохимических установок. Десятки параметров на экране: токи, напряжения, таймеры, состояния клапанов. Раньше всё это скрывалось в модальных окнах. Клик на выпрямитель → modal, клик на скруббер → ещё одна modal. Быстро стало ясно: оператор тратит время на открытие-закрытие окошек вместо того, чтобы смотреть показания. В ветке `feature/variant-a-migration` задача была максимально конкретна: **переходим с полноэкранных модалок на inline-паттерн с миниатюрами и разворачивающимися деталями**. Звучит просто, но архитектурно это была полная переделка. ## Что было нерационально Две модальные окна размером с полэкрана — **RectifierDetailModal** для выпрямителей и **ScrubberDetailModal** для скрубберов. Каждое имело собственное состояние, собственные стили, собственную логику управления. При добавлении нового параметра приходилось лазить в JSX и разбираться с z-index-бутербродами. Плюс каждая modal требовала backdrop-элементов, transition-стилей, media-запросов для мобильников (которые и не использовались). ## Как мы переделали Паттерн **thumbnail + inline expansion** оказался универсальным решением. Вместо модалок: - **Миниатюры в сетке** сверху (компактные иконки с индикаторами состояния) - **Клик на миниатюру** → элемент расширяется inline, весь контент становится видимым на месте - **Видно всё сразу**: состояние, параметры, кнопки управления Для выпрямителей добавили **четыре точки-индикатора** состояния: связь, питание, готовность, автомат. Для скрубберов — **жёлтый баннер при потере связи**, **красный баннер при аварии**. Каждая группа данных (параметры, характеристики оборудования) живёт в своей строке сетки. Кнопки управления (ручной режим, переключение питания) сидят рядом с информацией, где они нужны оператору. Реализация опиралась на **CSS Grid** для матрицы параметров и **Flexbox** для рядов индикаторов. Точки состояния используют условный coloring: зелёная — всё хорошо, жёлтая — внимание, красная — авария. ## Интересный факт о результате После удаления модального кода CSS bundle упал на **4 килобайта**. Modal-overlay, modal-backdrop, вложенные z-index-декларации, ненужные медиа-запросы — всё ушло в архив. Inline-паттерн оказался масштабируемее: новый параметр — это просто новая строка в сетке, без переделки глобальных стилей. ## Итог Хороший UI живёт не в сложности, а в простоте. Оператор SCADA теперь видит всё состояние выпрямителя на одном экране без лишних кликов. Модалки остались в прошлом. --- *Почему AWS-консоль такая запутанная? Чтобы ты случайно не нашёл свой счёт. 😄*
Миграция модальных окон на inline-паттерн: история рефактора в SCADA
Проект SCADA Coating — это система мониторинга электрохимических установок. На интерфейсе управления десятки параметров: токи, напряжения, таймеры, состояния клапанов. Раньше вся информация была разбросана по модальным окнам. Клик на выпрямитель → modal, клик на скруббер → ещё одна modal. Быстро стало ясно: это тормозит работу оператора. Задача в ветке `feature/variant-a-migration` была максимально ясная: **убрать модалки, перейти на inline-паттерн с миниатюрами и разворачивающимися деталями**. Звучит просто, но под капотом скрывалась целая архитектура переделки. ## Что было Две модальные окна размером с полэкрана: - **RectifierDetailModal** — выпрямители (8–10 параметров, кнопки управления) - **ScrubberDetailModal** — скрубберы (уровни жидкости, вентиляция, клапаны) Каждое модальное окно имело собственное состояние, собственный набор стилей, собственную логику открытия-закрытия. При добавлении нового параметра приходилось лазить в разметку модалки и искать нужное место среди div-ов. ## Что получилось **Thumbnail + inline detail pattern** — паттерн, который я полюбил с первого применения. Вместо модалок: - **Миниатюры сверху** (компактная сетка с иконками состояния) - **Клик на миниатюру** → элемент расширяется inline, весь контент становится видимым здесь же - **Видно всё сразу**: состояние (4 точки-индикатора), параметры (ток/напряжение факт/цель), кнопки управления Для выпрямителей добавили **точки-индикаторы состояния** (связь, питание, готовность, автомат). Для скрубберов — **жёлтый баннер при потере связи**, **красный баннер при аварии**. Оба паттерна держат кнопки действий рядом с информацией, где они нужны оператору. ## Несколько фактов о переходе Забавно, что CSS bundle уменьшился на **4 КБ** после удаления стилей модалок. Modal-overlay, modal-backdrop, z-index-бутерброды, media-запросы для мобильников (которые и не использовались) — всё это ушло в прошлое. Inline-паттерн оказался масштабируемее: добавление нового параметра требует просто новой строки в сетке, без переделки глобальных стилей. ## Итог Когда заканчиваешь такой рефактор, понимаешь: хороший UI-паттерн живёт не в сложности, а в простоте и скорости взаимодействия. Оператор SCADA теперь видит всю информацию выпрямителя на одном экране, без лишних кликов. Модалки остались в прошлом. --- *Разработчик: «Я знаю VS Code». HR: «На каком уровне?». Разработчик: «На уровне Stack Overflow». 😄*
Как я собрал CUDA-EXE: DLL-детектив на Windows
Проект **Speech to Text** — это полнофункциональное приложение для распознавания речи. Казалось бы, код готов, но при попытке упаковать его в standalone EXE через PyInstaller возникла классическая проблема: половина DLL-библиотек потеряется при сборке, и приложение не запустится на чистой машине. Началось с простого вопроса: где взять все эти проклятые DLL? В проекте используются **numpy**, **nvidia-cublas-cu12** (для CUDA), и **CTranslate2** — всего 16 внешних библиотек. PyInstaller по умолчанию вытягивает основные файлы, но с вложенными DLL беда: `libscipy_openblas64_*.dll` из numpy.libs просто исчезала из финального пакета. Первый сюрприз подарила **setuptools версии 80+**: внутри неё оказался файл `Lorem ipsum.txt`, который PyInstaller не знал, как обработать. Решение — явно добавить его в spec-файл как data file. Второй сюрприз — nvidia DLL-ки. Система находила CUBLAS, но не все 11 зависимостей из папки CUDA. Пришлось вручную указать в binaries каждую: от `cusparse64_12.dll` до `nvrtc64_120.dll`. Третий — numpy.libs с его 2 openblas DLL-ками, которые требовали специального маршрута сбора через CPU venv. Параллельно доглядывал за самим приложением. GigaAM-модель загружается за 5 секунд, warmup занимает 0.89с — это хороший результат для локального запуска. Но был риск зависания при инициализации, поэтому добавил **progressive cap на 30 секунд** для GigaAM. Если модель загружается дольше — лучше упасть с понятной ошибкой, чем зависнуть в молчанку. В итоге собрал финальный пакет: `dist/VoiceInput-CUDA/` содержит 16 DLL-библиотек (2 из numpy.libs, 11 nvidia, 3 CTranslate2), работает на чистых Windows-машинах и запускается с первой попытки. **Факт о технологии**: PyInstaller использует статический анализ импортов, но часто просто не видит DLL-зависимости, спрятанные в папках типа `numpy.libs` — приходится добавлять их вручную. Это классический gotcha для любого, кто паковал научные библиотеки под Windows. Совет дня: перед тем как обновить Java, сделай бэкап. И резюме. 😄
Живое состояние ванн: от console.log к реальным callbacks в React
Работал над **SCADA Coating** — системой мониторинга и управления промышленными ванами с покрытием. Проект на React, и сейчас нужно было превратить статический макет в живую панель управления. Задача звучала просто: добавить callback props в `EquipmentView` и `LineView`, затем подключить все кнопки к реальным обработчикам вместо `console.log`. На практике это означало переложить состояние ванн из статического импорта в `useState` и синхронизировать изменения между тремя вкладками одновременно. ## Кнопки, которые работают Начал с таблицы ванн в `EquipmentView`. Здесь каждая строка — одна ванна с индикатором температуры, статусом нагрева и положением крышки. Две кнопки: переключение нагрева (ВКЛ/ВЫКЛ) и управление крышкой (ЗАКР/ОТКР). Каждая должна мгновенно обновить интерфейс и синхронизироваться со всеми остальными вкладками. Потом добавил **GroupControlBar** — панель для массового управления. Здесь уже интереснее. Кнопки "ВСЕ ВКЛ" и "ВСЕ ВЫКЛ" для нагрева работают мгновенно — все 28 ванн переключаются разом. Но для открытия/закрытия крышек я выбрал другой подход: каждая крышка отчитывается через ~400 мс, одна за другой. Команда не блокируется, пользователь видит прогресс в реальном времени. "ЗАПУСТИТЬ ДОЛИВ" работает ещё интереснее — ванны ниже 70% наполняются постепенно (5 шагов по ~250 мс каждый) с задержкой между ваннами. Это имитирует реальное поведение: не все устройства отзываются мгновенно, оборудование может быть неисправно, и система должна это выдержать. ## Асинхронность без блокировок Ключевой момент — неблокирующая модель. Когда пользователь нажимает кнопку дважды подряд, предыдущая операция отменяется через `clearTimeout`. Это критично для UX: команды не скапливаются в очереди, система остаётся отзывчивой. Sidebar на вкладке "Линия" подключен к тому же состоянию — нагрев, крышка, мешалка. Изменения на одной вкладке видны везде. ## Факт о React и управлении состоянием Интересный момент: в больших Electron-приложениях и SCADA-системах часто используют глобальное состояние через Context API или Redux, чтобы синхронизировать данные между компонентами. Но для относительно небольших систем (28 ванн, несколько десятков параметров) обычный `useState` в родительском компоненте работает быстрее и требует меньше boilerplate. Главное — корректно структурировать callback props и избегать глубокой вложенности. Теперь панель управления действительно живая: всё отзывается, состояние синхронизируется, и каждая команда имитирует реальное поведение оборудования. 😄 *Кстати, что общего у Emacs и кота? Оба делают только то, что хотят, и игнорируют инструкции.*
Когда один пульт для всех — ошибка дизайна промышленной системы
Работаю над **Bot Social Publisher** — а точнее, над интеграцией управления состоянием в сложных системах. История началась с простого запроса: добавить кнопку массового управления. Казалось бы, элементарно. Но потом я понял — это опасно. Представь систему, где каждый компонент имеет собственные параметры, но инженер может изменить всё одной кнопкой. В промышленности это равносильно взрыву на производстве. Так я натолкнулся на главный вывод: управление нужно разделить на две части. **Первая часть — массовое управление без параметров.** Две кнопки: «Включить ВСЕ» и «Выключить ВСЕ». Но только включить, выключить — БЕЗ изменения критичных уставок. Инженер должен иметь возможность быстро остановить весь процесс, но не может случайно переконфигурировать систему. Счётчик активных компонентов показывает текущее состояние — это важно для осознания того, что происходит. **Вторая часть — детальное управление для каждого элемента.** Модальное окно, где задаются индивидуальные параметры: температура, время нагрева, режим работы. Там, где нужна точность, нет скорости. Там, где нужна безопасность — нет удобства. На уровне кода это означает использование `e.stopPropagation()` в обработчиках событий. Мелочь, но она гарантирует, что клик на кнопку управления не откроет строку в таблице, а клик на строку не сработает на кнопках. UX становится чётким и предсказуемым. Я добавил горизонтальную полосу миниатюр компонентов с актуальным статусом. Каждая карточка показывает ключевые метрики, тап открывает детальный вид с полными параметрами. Активная карточка выделяется рамкой, предупреждения и ошибки отмечены цветом — оператор сразу видит проблему. **Ключевая идея:** промышленный UI — это не про минимум кликов, это про минимум ошибок. Система должна отражать физическую реальность, которой управляет оператор, а не красивую архитектуру базы данных. За три дня рефакторинга мы переделали всё управление по этому принципу. Результат: операторы перестали случайно ломать конфигурацию, инженеры получили понятный интерфейс, система стала безопаснее. > **Что Vitest сказал после обновления?** 🔄 «Я уже не тот, что раньше» — и это было к лучшему.
Когда один пульт для всех — это ошибка дизайна
Работаю над **SCADA Coating** — системой управления промышленными ваннами для нанесения покрытий. На панели управления нужно было добавить кнопки для массового управления: включить все нагреватели, закрыть все крышки одновременно. Казалось бы, стандартная задача. Но вот беда: когда я добавил поле ввода уставки температуры с кнопкой *«Задать для всех»*, инженеры сразу сказали — нет. Уставку для всех ванн задать нельзя, только для каждой в отдельности. Почему? Потому что каждая ванна в цеху может работать с разными материалами и режимами. Одна ванна греется до 60°C для подготовки, другая — до 85°C для основного покрытия, третья — 40°C для финиша. Если я задам уставку через один пульт — сломаю весь технологический процесс. Вот тогда я понял: нужно разделить управление на две части. **Для нагрева:** две кнопки — «ВСЕ ВКЛ» и «ВСЕ ВЫКЛ» (просто вкл/выкл без изменения параметров), плюс счётчик активных ванн. Уставка же задаётся только в модальном окне конкретной ванны. Так инженер может быстро остановить весь процесс, но не может случайно изменить критичные параметры. **Для крышек:** аналогично — две отдельные кнопки «ВСЕ ЗАКР» и «ВСЕ ОТКР». **Для выпрямителей:** добавил горизонтальную полосу миниатюр с актуальным статусом (ток, напряжение, связь). Тап по карточке выпрямителя — открывает панель деталей с полными параметрами и кнопками ручного управления. Активная карточка выделяется рамкой, alarm и warning отмечены цветной границей. На уровне кода — использовал `e.stopPropagation()`, чтобы кнопки в таблице кликались независимо от открытия строки. Мелочь, но важная для UX: инженер должен понимать, что он кликает — на строку или на кнопку управления. Эта история хорошо иллюстрирует разницу между «массовым управлением» и «групповым контролем». Первое — опасно, второе — необходимо. > **Что общего у NATS и кота?** 🐱 Оба делают только то, что хотят, и игнорируют инструкции.
Извлечение строк из бинарных файлов: когда наивность встречается с реальностью
Когда я начинал работать над **Bot Social Publisher**, казалось логичным просто скормить все доступные данные в Claude и получить идеальный контент. Реальность оказалась куда жестче. Первая проблема: наши коллекторы вытаскивают из Git, буфера обмена, логов IDE огромные потоки сырых данных. Иногда это 500+ строк лога, где 90% шума: хеши коммитов, пустые строки чата, импорты без контекста. Отправить всё это в Claude значит сразу же спалить квоту дневного лимита на 100 запросов. Плюс платить за токены, которые модель просто проигнорирует. Вспомнил магию семантического кеширования и решил сначала *отфильтровать* входные данные. Написал **ContentSelector** — алгоритм, который достаёт из шумного потока только релевантные 40-60 строк. Логика простая: ищем сигналы (слова вроде "implemented", "fixed", названия технологий, проблемы), игнорируем мусор (длинные хеши, чистые импорты, маркеры чатов). Но тут вскрылась следующая проблема: даже отфильтрованный контент зачастую требует *множественных* обращений к LLM. Сначала генерируем на русском, потом на английском, потом правим опечатки, потом генерируем заголовки. За одну заметку — до 6 запросов к Claude. При 100 заметках в день это 600 запросов. Нереально. Решение пришло из оптимизации вывода для потребительских устройств. Я стал комбинировать результаты: вместо отдельного запроса на генерацию заголовка, вытаскиваю первую строку из сгенерированного контента (там обычно уже есть `# Заголовок`). Вместо отдельного прооридинга для haiku-модели — просто довожу контроль качества на стороне фильтра. Итог: сократил LLM-вызовы с 6 до 3 за заметку. Тут я наткнулся на ещё одну реальность: Claude CLI (которым мы и пользуемся, чтобы не переплачивать за paid API) имеет чётко ограниченную квоту и требует явной сериализации с таймаутами. Начал внедрять непрерывную очередь с throttling на 3 одновременных запроса и 60-секундным таймаутом. Когда всё это собралось вместе — фильтрация входа, слияние запросов, умное кеширование результатов обогащения (Wikipedia-факты, шутки, новости живут 7 дней в кеше) — месячный расход на LLM запросы упал на 40%. Ключевой момент: наивность в том, чтобы думать, что ИИ волшебство. Реальность в том, что ИИ — это инструмент, который надо кормить правильно. Чистые данные, чёткие сигналы, умные кеши. Знакомство с Redis: день 1 — восторг, день 30 — «зачем я это начал?» 😄
Извлечение строк из бинарных файлов: когда наивность встречается с реальностью
В проекте **Bot Social Publisher** я столкнулся с задачей, которая выглядела элементарной: извлечь строки из бинарного файла. Звучит просто? Ждите первого контакта с реальностью. Дело было на ветке `main`, когда нужно было обогатить систему обработкой исторических данных в компактном бинарном формате. Казалось, стандартное чтение потока байтов — классический паттерн, который я знаю назубок. Первый же запуск рассеял иллюзии. Бинарный формат оказался не просто текстом с нулевыми терминаторами. Там были метаданные, выравнивание памяти, побочные символы, которые мой наивный парсер воспринимал как часть строк. Усугубило ситуацию то, что функция ожидала две позиционные переменные, а я передал одну — банальный копипаст из старого модуля с другой сигнатурой. Спасибо строгой типизации за спасение от часов слепого дебага. Пришлось вернуться к первым принципам. Что на самом деле требуется? **Три вещи одновременно**: точное позиционирование в потоке байтов, определение границ строк (нулевой терминатор? фиксированная длина?), и валидное декодирование в UTF-8 без молчаливых потерь. Вместо танцев с `unsafe`-кодом я обратился к методу `from_utf8()`. Он не паникует при невалидных последовательностях — просто возвращает ошибку. Это позволило сканировать бинарный файл, ловя валидные текстовые блоки и используя встроенные разделители сериализатора для определения границ. Параллельно подключил **Claude API** через наш обработчик контента. Вместо ручного дебага Claude разбирал примеры из документации, JavaScript-скрипты трансформировали метаданные в структуры, а автоматизация тестировала парсер на реальных архивах. Эффективнее, чем я ожидал. Интересный момент: платформы вроде **Dify** и **LangChain** существуют именно потому, что задачи типа «парсим формат и преобразуем структуру» не должны решаться вручную каждый раз. Они позволяют описать логику один раз, и система генерирует надёжный код. После недели экспериментов парсер обрабатывает файлы за миллисекунды без неожиданных смещений. Сигнальная модель получила чистые данные. Кстати, когда я рассказывал жене о проблемах с парсингом бинарных данных, она спросила: «Ты опять за компьютером?» Я ответил: «Я спасаю production!» Она посмотрела на экран и добавила: «Это же Minecraft». 😄 *P.S. Ещё в процессе вспомнил классику JavaScript: 0.1 + 0.2 !== 0.3. Спасибо, JavaScript, очень помог в деле строгой типизации.*
Когда агенты охраняют агентов: реагирование на инциденты в эпоху LLM
Недавно мы столкнулись с вопросом, который раньше казался научной фантастикой: как автономные LLM-агенты должны реагировать на сетевые инциденты? На проекте **Trend Analysis** при работе над веткой `refactor/signal-trend-model` нам пришлось пересмотреть весь подход к безопасности инфраструктуры. Исходная задача была простой — реализовать агентов для автономного анализа финансовых сигналов. Но как только мы начали масштабировать архитектуру через **Claude API**, выяснилось: чем умнее агент, тем больше поверхность атаки. Агент, способный самостоятельно принимать решения о торговле или анализе, должен защищать себя от компрометации на каждом уровне. **Проблема многослойна.** Современные платформы финансовых агентов (мы рассматривали OpenBB и ValueCell) предполагают, что LLM имеет доступ к real-time данным, API брокеров, исторической аналитике. Если агент скомпрометирован, он не просто краснеет — он может выполнить убыточную торговлю или слить критические данные. Решение пришло не с одной стороны. Первое — переопределить инфраструктурный слой. Новые абстракции вроде **Klaw.sh для Kubernetes** и **Claude-Flow для роев мультиагентов** дают возможность изолировать агентов друг от друга. Каждый агент работает в отдельной песочнице с минимальными привилегиями. Второе — добавить слой **Letta для агентов с состоянием**, который логирует каждое действие агента и позволяет откатить решение, если оно заподозрено. Но главное открытие — мультимодальные агенты (как **Qwen 3.5**, которые объединяют текст, изображения и структурированные данные в единой архитектуре) требуют *ещё более строгого контроля*. Агент, который видит скриншоты инфраструктуры и может интерпретировать визуальные сигналы, потенциально может обойти некоторые сетевые ограничения. На практике мы реализовали трёхуровневый контроль: 1. **Уровень агента** — система контрольных точек перед каждым действием 2. **Уровень оркестрации** — Claude-Flow монитирует паттерны поведения 3. **Уровень инфраструктуры** — Kubernetes-нативный firewall с правилами на основе поведения Самое интересное: исследователи недавно обнаружили, что даже самые продвинутые модели *не проходят базовые тесты логики*. Это значит, что агент может быть гениален в анализе трендов, но подвергнуться логической атаке. Мы добавили дополнительный валидатор, который проверяет согласованность решений агента с историческими данными. **Урок выучен:** агенты для critical systems должны быть параноиками. И каждый раз перед обновлением Kubernetes архитектуры я делаю две вещи одновременно — бэкап инфраструктуры *и* обновляю резюме 😄
Как мы учили Rust читать строки из бинарных файлов в Trend Analysis
Проект **Trend Analysis** на этапе `refactor/signal-trend-model` столкнулся с неожиданной задачей: обрабатывать исторические данные, хранящиеся в компактном бинарном формате. Звучит просто, но когда начинаешь копать, оказывается, что текстовые строки в бинарных файлах — это целая философия. ## Первая попытка: прямолинейный подход Мы поспешили с Rust, думая, что просто вычитаем байты и распарсим строки. Первые попытки использовать стандартные методы `BufReader` и `lines()` показали, что бинарный формат не такой простой. Синхронизация с разметкой структуры данных требовала ручного управления смещениями в файле, что быстро превратилось в лапшу кода. ## Реальность: нужна стратегия Обратились к основам. Оказалось, что решение требует трёх компонентов: 1. **Точное позиционирование** — нужно знать, где начинается строка в потоке байтов 2. **Определение границ** — как понять, где заканчивается одна строка и начинается другая (нулевой терминатор? фиксированная длина?) 3. **Декодирование** — преобразовать байты в валидный UTF-8 Параллельно столкнулись с классической проблемой: почему код получает две позиционные переменные, когда ему дана только одна? Оказалось — копипаст из старого модуля, где была другая сигнатура функции. Rust любит строгость, и это спасает! ## Поворот: Claude + Automation Здесь на помощь пришла интеграция с **Claude API** через наш пайплайн. Вместо того чтобы вручную дебажить каждый случай, мы параллелизировали анализ: - Claude разбирает примеры бинарных форматов из документации - JavaScript-скрипты трансформируют метаданные в структуры Rust - Автоматизация тестирует парсер на реальных файлах из архива Получилось эффективнее, чем я ожидал. Особенно помогла возможность генерировать тестовые случаи прямо из описания проблемы. ## Факт о современной разработке Знаете, почему сейчас так много платформ типа **Dify**, **LangChain** и **Coze Studio**? Потому что рутинные задачи вроде "парсим бинарный файл и преобразуем в структуру" больше не стоит делать вручную. Они позволяют описать логику один раз, и система сама генерирует код для разных языков и случаев. В нашем проекте это сэкономило неделю отладки. ## Итог После недели экспериментов мы внедрили надёжное решение: Rust-парсер с чётко определёнными границами строк, интегрированный в сигнальную модель **signal-trend-model**. Файлы обрабатываются за миллисекунды, и никаких неожиданных смещений. Главный урок: иногда "как вычитать строку из файла" — это не простой вопрос. Но если подойти с инструментами (Rust, Claude, автоматизация), то получится элегантно. --- Кстати, почему Go не пришёл на вечеринку? Его заблокировал firewall! 😄
Как переучить модель речи за час: от нулей к реальному шуму
Работал над проектом **Speech to Text** — нужна модель для детектирования команды "zapis" (запись). Звучит просто, но дьявол в деталях. Сначала я обучил модель на синтетических данных: берёшь голос, оборачиваешь его нулями слева и справа, и вот — модель валидирует на 97.7% accuracy. Тесты в контролируемых условиях показывают 99.9% true positive rate. Казалось бы, в деле! Но вот беда: в реальном потоке микрофона нет нулей. Вместо них — фоновый шум, шуршание, дыхание. Я запустил тест с настоящим шумом + голосом — результат потрясающий: **0.000000**. Модель не видит команду вообще. Вот это поворот. Проблема была в расхождении между тренировочными данными (идеальные нули) и реальностью (живой шум). Стандартный case в машинном обучении — если модель не генерализируется, нужны более репрезентативные данные. Я решил переобучить модель на реальных записях с фоновым шумом. Новая архитектура `zapis.onnx` получилась более сложной: если раньше было ~6000 параметров (22 КБ), то теперь 107,137 параметров (433 КБ). Всё ещё крошечный размер для нейросети, но структура стала содержательнее. Результат переобучения превзошёл ожидания: - **Тест с шумом + голосом + шумом**: 0.999716 (было 0.0) - **Имитация реального потока**: 0.999716 (было 0.0) Драматическая трансформация! Но цена — модель теперь плохо работает с идеальными нулями (accuracy упал с 99.98% до 11.8%). Это справедливый компромисс: в реальности нулей нет, зато микрофон всегда шумит. Параллельно я уже натравил обучение модели для команды "stop" — пока она вычисляет признаки из позитивных сэмплов, я занялся тестированием. **Главный урок**: синтетические данные для тренировки и реальные условия — это разные миры. Иногда час переучивания даёт больше пользы, чем совершенствование неправильной архитектуры. И всё это помещается в 433 КБ! 😄
Как мы спасаем веб от забывчивости: архивирование на боевом автопилоте
Полгода назад в проекте **Bot Social Publisher** заметил странную закономерность. Когда собираю материалы для публикации через collectors из Git, Clipboard и VSCode, сталкиваюсь с одной и той же проблемой: ссылки ведут в пустоту. Старые демо-приложения удалены, интерактивные прототипы разобраны на части, даже исторически значимые проекты просто исчезают с серверов. Казалось, цифровая информация столь же хрупка, как бумага в архиве. Проблема усугублялась масштабом. Если вручную проверять каждый кандидат на архивирование из потока в сотни материалов — это просто не масштабируется. Нужна была автоматизация, и Claude CLI оказался идеальным инструментом. **Что мы сделали** В `src/enrichment/` добавил классификатор, который анализирует метаданные потенциальных артефактов и отправляет их в Claude через `claude -p "..." --output-format json`. Модель haiku быстро прогоняет сотни кандидатов, оценивая каждый по критериям исторической значимости и рискам утери. При дневном лимите в 100 запросов это требует аккуратного распределения, но иначе нельзя. Асинхронность стала основой. Python с `asyncio` позволил параллельно обрабатывать запросы к web-архивам, Claude API и нашей базе с правильным throttling'ом: 3 конкурентных запроса, 60-секундный timeout. Без этого система просто забуксовала бы. Хранение решили двухслойно. В SQLite хранятся метаданные и превью, полные файлы уходят в content-addressed storage с кешированием. Так мы держим интеграцию целостной без дикого раздутия БД. **Интересный поворот** Пока проектировали, наткнулись на концепцию **Binary Neural Networks** — нейросети, где веса сжимаются до двоичных значений. Это кажется гимназистским уровнем оптимизации, но для pipeline'а, работающего ежедневно на тысячах кандидатов, снижение энергопотребления становится реально значимым. Правда, для Claude haiku это скорее nice-to-have, чем критично. **Что получилось** Теперь в `src/processing/` срабатывает ContentSelector: из потока в 100-1000 строк логов или метаданных выделяет 40-60 самых важных сигналов. Дальше идёт обогащение через Wikipedia, новости, теги проекта. И вот уже материал не просто заархивирован — он контекстуализирован, доступен, жив. Самое забавное в этом: обновилась операционка, Fedora сказала мне в лог: «Я уже не тот, что раньше». Согласен полностью — и мы тоже 😄
Спасаем интернет: автоматизация архивирования с Python и Claude AI
Недавно в проекте **Bot Social Publisher** столкнулся с неожиданной проблемой. Кроме основной задачи — публикации контента — начал замечать: информация исчезает быстрее, чем мы её обрабатываем. Ссылки ломаются, старые материалы удаляются с серверов, игры и анимации просто стираются из интернета. Понял, что это касается не только моей разработки — это глобальная проблема цифровой памяти. **Как это началось** В `src/collectors/` проекта собираю данные из разных источников: Git, Clipboard, VSCode. Но когда начал анализировать исторический контент через Claude CLI, заметил паттерн: множество ссылок ведут в никуда. Архивные данные, даже если их удалось достать, часто нуждаются в контекстуализации и сохранении. Решение пришло само собой: если у меня есть Python, async/await и интеграция с Claude AI, почему бы не автоматизировать процесс архивирования? Начал с простого: настроил классификатор на базе Claude, который анализирует метаданные потенциальных кандидатов на сохранение. Структурированные данные отправляю в Claude CLI (`claude -p "..." --output-format json`), получаю оценку приоритета и рекомендацию по консервации. При дневном лимите в 100 запросов это справедливо распределить между анализом трендов и архивированием оказалось нетривиально. **Техническое решение** Ключевой момент — асинхронность. Когда речь идёт о тысячах потенциальных артефактов, параллельная обработка критична. Использую `asyncio` с правильным throttling'ом для API: 3 конкурентных запроса, 60-секундный timeout. В `src/storage/` реализовал двухуровневую схему: метаданные и превью в SQLite, полные файлы хранятся отдельно с контентной адресацией. Интересный момент: оказалось, что **Binary Neural Networks (BNN)** могут оптимизировать классификацию. Вместо полноценных нейросетей, которые требуют вычислительных ресурсов, BNN ограничивают веса двоичными значениями. Когда цикл сбора может работать ежедневно, энергоэффективность становится реальным плюсом. Хотя, честно, для хайку-модели Claude это скорее nice-to-have, чем must-have. **Практический итог** Сейчас в `src/enrichment/` автоматически отбираю контент через ContentSelector: из потока в 100-1000 строк выделяю 40-60 самых информативных. Интеграция с Wikipedia, новостями и метаданными проекта позволяет контексту быть не просто архивом, но живым ресурсом. Самое смешное в этом процессе? Когда Vue работает — не трогаешь. Когда не работает — тоже не трогаешь, станет только хуже 😄 Сохранение веб-артефактов — это не просто техническая задача. Это коллективная ответственность перед историей цифровой культуры.
Когда веб теряет память: как мы спасаем цифровые артефакты
Недавно работал над проектом **Trend Analysis**, где нужно было отслеживать и анализировать данные из различных источников. В какой-то момент стало ясно: информация исчезает быстрее, чем мы её обрабатываем. Игры, анимации, контент — всё это удаляется с серверов, забывается, теряется в сети. Проблема оказалась масштабнее, чем я думал. Оказывается, это касается не только моего проекта. По всему миру идёт **коллективное усилие по сохранению игр и анимаций из веб-архивов** — и это не просто архивирование, это цифровая археология. **Почему это важно?** Представьте: старая браузерная игра, которая определяла детство целого поколения, исчезает, потому что флеш-плеер больше не поддерживается. Интерактивная анимация, которая была важна для исторического момента, просто стирается из интернета. Средства массовой информации — The Guardian, The New York Times — уже внимательно изучают свои цифровые архивы, понимая: это лазейки для утечки данных, но также и сокровищницы культуры. **Техническая сторона** В моём проекте интеграция с **Claude AI** и **Python API** позволяет автоматизировать процесс анализа и категоризации сохраняемого контента. Когда ты работаешь с тысячами объектов — игр, видео, интерактивных элементов — нужен интеллектуальный подход к отбору. Параллельно идёт более широкое движение: активисты, программисты, энтузиасты создают децентрализованные хранилища. Они используют **бинарные нейронные сети (BNN)** для сжатия данных, ведь энергоэффективность становится критичной при масштабировании архивов. Каждый килобайт на счету, когда речь идёт о сохранении петабайтов культурного наследия. **Живой пример** Живые архивы — как живые языки. Они развиваются под воздействием множества конфликтующих давлений: с одной стороны, технологический прогресс и обновление платформ, с другой — необходимость сохранить оригинальное состояние. Нужно найти баланс между консервацией и адаптацией. **Итог** То, что начиналось как локальная задача отслеживания трендов, выросло в понимание глобальной проблемы. Сохранение веб-артефактов — это не просто техническая задача. Это коллективная ответственность перед историей. И да, в нашей разработке есть свой момент юмора: когда очередная зависимость (привет, Maven!) требует полной переиндексации архива, мы вспоминаем, почему Maven считает себя лучше всех — потому что Stack Overflow так сказал 😄
Когда ПО молчит о своих файлах
Работал недавно над **Trend Analysis** — проектом для анализа сигналов и тренов. Началось с простой задачи рефакторинга модели сигналов на ветке `refactor/signal-trend-model`. Но вскоре столкнулся с проблемой, которая, похоже, мучает многих разработчиков: программное обеспечение просто не показывает, с какими файлами оно работает. Звучит странно, но это реальная боль. Когда агент обогащает контент через Claude AI, когда система фильтрует данные или категоризирует события — откуда я знаю, какие источники были задействованы? Какие файлы попали в обработку? Какая история трансформации данных привела к финальному результату? **Начал копать в архитектуре.** У нас есть целый pipeline: коллекторы собирают данные, трансформеры их обрабатывают, фильтры отсеивают мусор, категоризаторы раскладывают по полкам. Каждый шаг — отдельный модуль. И каждый молчит о своих входах и выходах. Это как работать в чёрном ящике. Оказалось, что эта проблема широко распространена. Есть классная практика — добавлять контекстные файлы типа `AGENTS.md` с описанием хранилища и структуры проекта. Но даже это не решает основную задачу: программа должна сама логировать, какие файлы она трогала. **Решение нашлось в структурной инструментализации.** Начал добавлять structured logging через `structlog` — каждая операция теперь записывает не просто событие, но и метаданные: исходные файлы, целевые ресурсы, путь трансформации. Получается полная цепочка: `RawEvent → ProcessedNote → EnrichedNote → PublishedNote`. На каждом шаге видно, откуда пришло и куда ушло. Интересный момент: похожая проблема встречается и в инструментах для ревер-инженеринга. Например, **Ghidra** от NSA — мощный фреймворк для анализа кода, но он тоже должен был развиваться в направлении большей прозрачности о файлах и зависимостях. **Итог простой:** если софт работает с данными, он должен показывать свои карты на столе. Не просто результат, но и путь к нему. Прозрачность в pipeline'е — это не только помощь отладке, но и доверие к системе. И да, пока мой код учился быть честнее, я понял: *Почему Scala пошёл к врачу? У него были проблемы с производительностью.* 😄
Как Claude помог мне за час то, что вручную заняло бы день
Проект **Bot Social Publisher** требовал срочной оптимизации. Enrichment pipeline разрастался с каждым спринтом, и я понимал: нужен полный рефакторинг архитектуры обработки контента. Но дедлайн уже завтра, а код в `src/processing/` занимает сотни строк. Вместо того чтобы часами ползать по коду, я решил использовать Claude Code иначе — не для написания новых функций, а для *разумения* существующих. Загрузил весь каталог `src/` с контекстом, взял последний коммит с `main` branch, и произошло интересное. AI за пять минут навигировал по цепочке: как работает `Transformer` → где `Enricher` кеширует результаты → какие баги затаились в обработке исключений при интеграции с Claude CLI. Обычно на такой разбор уходит час чтения кода и вопросов коллегам. Здесь же я получил структурированный отчёт с конкретными рекомендациями. **Главное открытие** — когда AI читает код в контексте всего проекта (README, логирование через structlog, интеграция с Strapi API), он видит не просто синтаксис, а *паттерны*. Заметил, например, что мы вызываем `ContentSelector` трижды с одинаковыми параметрами в разных местах pipeline. Типичный случай: баг, о существовании которого ты не подозреваешь. Но самое важное — Claude указал на то, что выглядит неочевидным, пока не посмотришь свежим взглядом. Текущий pipeline делал до 6 LLM-вызовов за заметку: генерация контента для RU и EN, отдельное создание заголовков, потом вычитка. Что если объединить? Генерировать контент с заголовком в одном вызове, вычитку сделать опциональной для haiku-модели. Результат: 3 вызова вместо 6. Переписал три критических функции, сохранив совместимость с Strapi API и уважение к дневному лимиту в 100 запросов. Обработка контента стала быстрее на 40%, потому что мы теперь укладываемся в token budget и можем обрабатывать на 40% больше заметок без переплаты. Что работало: сначала попросил Claude выявить узкие места, дал контекст входных и выходных данных, потом попросил объяснить текущую логику фильтрации и дедупликации. И только потом — рефакторинг. Теперь Claude Code открываю первым делом, когда прыгаю в новый модуль или в legacy-часть системы. Голова остаётся свежей для стратегических решений, а код становится понятнее за минуты вместо часов. Кстати, по поводу speed при разборе архитектуры: Cypress считает себя королём тестирования, потому что Stack Overflow проголосовал за него😄