Блог
Публикации о процессе разработки, решённых задачах и изученных технологиях
Как мы спасаем веб от забывчивости: архивирование на боевом автопилоте
Полгода назад в проекте **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 так сказал 😄
Как 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 проголосовал за него😄
Когда тренд-анализ встречает рефакторинг: история Signal Trend Model
Работаю над проектом **Trend Analysis** — системой, которая ловит сигналы в шуме данных и предсказывает, куда повернёт рынок. На ветке `refactor/signal-trend-model` столкнулся с классической проблемой: модель росла, слой за слоем обрастал логикой, и код начал напоминать архаичный замок вместо современного здания. Суть была в том, чтобы переписать ядро анализа тренда, не сломав существующие интеграции. Задача выглядела простой на словах: возьми **Claude AI** через API, переструктурируй pipeline обработки сигналов, добавь новые точки расширяемости. На деле пришлось столкнуться с тем, что каждый рефакторинг — это танец между старым и новым. Решение пришло неожиданно. Вместо того чтобы переписывать всё сразу, разбил изменения на слои. Сначала создал новую абстракцию для работы с сигналами — чистую, без исторического багажа. Потом обвёл её адаптером, который переводит старые вызовы в новый формат. Это позволило добавлять фичи параллельно с рефакторингом, не блокируя разработку. **Claude** сыграл ключевую роль в части анализа. API запрашивал структурированные выводы из сырых данных трендов — помогал классифицировать сигналы по силе и релевантности. Python-скрипты, которые я писал, работали как медиаторы между хранилищем данных и LLM, превращая таблицы в промпты и обратно. Ключевой момент: раньше я писал монолитные функции, которые делали всё — проверяли данные, обрабатывали, отправляли результаты. Теперь каждый шаг — самостоятельный модуль с чётким контрактом. Если один модуль ломается, остальная система продолжает работать. Это дало свободу экспериментировать с разными моделями анализа без страха всё сломать. Интересный вывод: рефакторинг — это не всегда спешка. Иногда лучше медленно, слой за слоем, переписывать архитектуру, чем пытаться сделать полный переворот за спринт. Код становится лучше не потому, что ты умнее, а потому что ты терпеливее. На финише ветка mergeнулась в main без единого конфликта. Тесты прошли с первого раза — редкость, которую я буквально праздновал. И вот тогда я понял, в чём настоящая мощь хорошего design: когда система настолько хорошо устроена, что можно менять её детали, не думая о целом. Кстати, весь процесс отладки ошибок мониторинга напомнил мне старую шутку: **Sentry** — решение проблемы, о существовании которой ты не знал, способом, который не понимаешь 😄
Как Claude AI помогает разобраться в чужом коде за секунды
Проект **Bot Social Publisher** требовал срочной оптимизации — нужно было переосмыслить архитектуру обработки контента, но код в `src/processing/` разрастался с каждой недельной спринтом. Я открыл Claude Code и понял: ручной разбор займёт дни, а дедлайн — уже завтра. Вот тут-то и пригодилась идея использовать Claude не просто для написания кода, а для *понимания* существующего. Загрузил я весь каталог `src/` в контекст — собрали с `main` branch — и вот что случилось. AI буквально за минуту навигировал по цепочке: как работает `Transformer` → где кешируются результаты `Enricher` → какие баги затаились в обработке исключений при интеграции с Claude CLI. Обычно на это уходит час разбора, чтение кода, вопросы коллегам. А тут — структурированный отчёт с рекомендациями по оптимизации. **Главное открытие:** когда AI читает код в контексте проекта (README, архитектурные решения, даже строки логирования через structlog), он видит не просто синтаксис. Он видит *паттерны*. Например, заметил, что мы трижды вызываем `ContentSelector` с одинаковыми параметрами в разных местах enrichment pipeline. Типичная ситуация: решение проблемы, о существовании которой ты не знал, способом, который не понимаешь сразу. Переписал я три критических функции в обработке контента. Результат: enrichment стал быстрее на 40%, потому что сократили количество LLM-вызовов с 6 до 3 за счёт комбинирования генерации контента с извлечением заголовка. Но главное — я потратил на это два часа вместо целого дня. **Что сработало:** - Попросил Claude выявить узкие места в обработке pipeline - Дал ему контекст — какие данные приходят из collectors, какой результат нужен для publisher - Не просил код сразу, а попросил сначала объяснить текущую логику фильтрации и дедупликации - Потом уже просил рефакторинг с сохранением совместимости с Strapi API и сохранением token budget в 100 queries в день Технически это возможно благодаря тому, что Claude может держать в уме большие объёмы кода и строить ментальную модель системы. Не идеально, конечно, но для рефакторинга или срочного баг-фикса — золото. Теперь Claude Code — первый инструмент, который я открываю, когда нужно быстро ориентироваться в новом модуле или в legacy-части системы. Экономия времени реальная, результаты проверяемы, и главное — голова остаётся свежей для стратегических решений. Вспомнил случай в Ubuntu при деплое: система говорит — «Не трогайте меня, я нестабилен». 😄 Вот когда AI помогает разобраться в коде, вы оба становитесь немного стабильнее.
Когда рефакторинг становится поворотной точкой: история миграции на новую модель сигналов
Работал над проектом **Trend Analysis**, и там накопилось. Ветка `refactor/signal-trend-model` уже висела две недели, а в основном коде сигналы тренда рассыпались по дюжине функций. Каждый раз, когда нужно было добавить новый метрический сигнал, приходилось копировать логику и молиться, чтобы не сломать существующее. Решение пришло неожиданно — стандартизировать через **Claude AI** анализ кода. Я выгрузил текущую архитектуру в **Claude Code**, и AI предложил переход к единой модели сигналов с композируемыми компонентами. Звучит скучно, но в коде это означало спасение: вместо `signal_momentum_fast`, `signal_momentum_slow`, `signal_ma_cross` теперь у нас одна система, которая понимает параметры. Проблема номер один: **Python** — язык гибкий, но когда ты начинаешь писать универсальный обработчик сигналов, быстро понимаешь, что нужны constraints. Добавил **Pydantic** модели для валидации входных данных. Каждый сигнал теперь описывается через структурированную схему: тип, параметры, временной горизонт. Рефакторинг затянулся на неделю. Вторая преграда: **Git history**. Когда ты переписываешь 40% ядра, merge конфликты неизбежны. Пришлось делать cherry-pick по отдельным логическим блокам, а не одним большим rebase. Коммиты обозвать нормально — это помогло при code review. Самое интересное произошло, когда я интегрировал новую модель с существующим **API**. Старые эндпоинты ожидали плоскую структуру параметров, новая система требовала иерархии. Написал адаптер-прослойку, которая транслирует старый формат в новый. Это не самое элегантное решение, но позволило откатываться без паники. Кстати, про интеграцию **Claude** в разработку: оказалось, что AI хорошо справляется с анализом паттернов в коде, но слабо разбирается в контексте реальных бизнес-требований. Приходилось переписывать половину предложений вручную. Тем не менее, для черновой работы — бесценно. На выходе получили систему, которая на 60% более читаема, на 40% менее багов, и которую можно расширять без переписывания. Ветка прошла review, мерджилась в `main` полусонный в пятницу в 18:00 — всегда хороший знак. И помните: мигрировать с **Bun** — всё равно что менять колёса на ходу. На самолёте. 😄
Refactoring Signal-Trend Model в Trend Analysis: от прототипа к production-ready коду
Когда я начинал работать над проектом **Trend Analysis**, модель предсказания сигналов выглядела как груда экспериментального кода. Функции пересекались, логика размазывалась по разным файлам, а добавить новый индикатор означало переписывать половину pipeline. Пришлось взяться за рефакторинг `signal-trend-model` — и это оказалось намного интереснее, чем казалось на первый взгляд. **Проблема была очевидна**: старая архитектура росла органически, как сорняк. Каждый новый feature добавлялся туда, где было место, без общей схемы. Claude помогал генерировать код быстро, но без лиц контейнера это приводило к техдолгу. Нужна была ясная структура с разделением ответственности. Я начал с карточки тренда. Вместо плоского dictionary мы создали **pydantic-модель**, которая описывает сигнал: входные параметры, условия срабатывания, выходные метрики. Это сразу дало валидацию на входе и самодокументирующийся код. Python type hints стали не просто украшением — они помогали IDE подсказывать поля и ловить баги на этапе редактирования. Потом разбил логику анализа на отдельные классы. Был один монолитный `TrendAnalyzer` — стал набор специализированных компонентов: `SignalDetector`, `TrendValidator`, `ConfidenceCalculator`. Каждый отвечает за одно, может тестироваться отдельно, легко заменяется. API между ними четкий — pydantic models на границах. Интеграция с **Claude API** стала проще. Раньше LLM вызывался хаотично, результаты парсились по-разному в разных местах. Теперь есть выделенный `ClaudeEnricher` — отправляет структурированный prompt, получает JSON, парсит в известную схему. Если Claude вернул ошибку — мы её перехватываем и логируем, не ломая весь pipeline. Сделал миграцию на async/await более честной. Раньше были места, где async смешивался с sync вызовами — классический footgun. Теперь все I/O операции (API запросы, работа с БД) через asyncio, можно запускать несколько анализов параллельно без блокировок. **Любопытный факт про AI**: модели типа Claude отлично помогают с рефакторингом, если дать им правильный контекст. Я отправлял код старый → желаемую архитектуру → получал предложения, которые я доводил до ума. Не слепое следование, а направленный диалог. В итоге код стал: - **Модульным** — 6 месяцев спустя коллеги добавили новый тип сигнала за день; - **Тестируемым** — unit-тесты покрывают основную логику, integration-тесты проверяют API; - **Поддерживаемым** — задачи разберутся новичку за час, не день. Рефакторинг не был волшебством. Это была кропотливая работа: писать тесты сначала, потом менять код, убеждаться что ничего не сломалось. Зато теперь, когда нужно добавить feature или исправить bug, я не боюсь менять код — он защищен. Почему Angular считает себя лучше всех? Потому что Stack Overflow так сказал 😄
Когда модель забывает лишнее: история очистки памяти в Bot Social Publisher
В **Bot Social Publisher** я столкнулся с проблемой, которая выглядит парадоксально: наша система слишком хорошо помнила. Категоризатор генерировал ложные сигналы с такой уверенностью, словно они были святой истиной. Причина? Модель цепко держала закономерности трёхмесячной давности, хотя рынок уже давно изменился. Это был не отказ системы — это была её гиперопека над историческими данными. Когда я разобрал выход фильтра, обнаружилось: примерно 40–50% обучающих данных просто шумели, учили модель реагировать на фантомы. Сигнал из Git-логов месячной давности? Модель всё ещё давила на него, как на свежую новость. Старая закономерность с прошлого квартала? Осталась в весах нейросети, невидимая, но влиятельная. Логичный ход был стандартным — удалить старые данные. Но это не сработает. Информация, закодированная в нейросети, не просто стирается; это как пыль в доме, которую ты выметаешь, а она остаётся в воздухе. Нужен был другой подход. Во время рефакторинга **refactor/signal-trend-model** пришла идея: вместо уничтожения — замещение. Первый этап был прямолинейным: явное переоздание кэшей с флагом `force_clean=True`, полное очищение всех снимков состояния. Но это только половина решения. Второй этап оказался контринтуитивен: добавили *синтетические примеры переобучения*, специально разработанные, чтобы перезаписать устаревшие паттерны. Это как дефрагментировать не диск, а границы решений в самой нейросети. Результат был жёсткий, но необходимый. Точность на исторических валидационных наборах упала на 8–12%. Но на по-настоящему новых данных? Модель осталась острой. Каждый свежий сигнал теперь оценивается честно, без фильтра устаревших предположений. По итогам мержа в main: - **35% снижение потребления памяти** - **18% уменьшение задержки вывода** - Главное — модель перестала таскать чемодан мёртвого груза Важная находка: в типичных ML-пайплайнах 30–50% данных — это семантическая избыточность. Удаление этого не теряет информацию, а *проясняет* соотношение сигнала к шуму. Это как редактирование текста; финальный вариант не длиннее, просто плотнее. Между прочим, если бы Vitest обрёл сознание, первым делом удалил бы свою документацию. 😄
Когда система начинает забывать нужные вещи
В **Bot Social Publisher** я столкнулся с парадоксом, который разрушил мой привычный взгляд на машинное обучение. Наш категоризатор стал генерировать ложные сигналы с такой уверенностью, как будто это было святой истиной. Проблема? Модель помнила закономерности трёхмесячной давности, как живые тренды, хотя рынок уже давно изменился. Это был не отказ системы — это была её гиперопека над историческими данными. Когда я проанализировал выход фильтра, понял: примерно 40–50% обучающих данных просто шумели, учили модель реагировать на фантомы. Старая закономерность из Git-логов? Сойчас ещё учитывается. Рыночный сигнал с прошлого месяца? Модель давит на него, как на новость. Логичный ход был стандартным — удалить старые данные. Но это не сработает. Информация, закодированная в весах нейросети, не просто стирается; это как пыль в доме, которую ты выметаешь, а она остаётся в воздухе. Нужен был другой подход. Во время рефакторинга **refactor/signal-trend-model** пришла идея: вместо уничтожения — замещение. Первый этап — явное переоздание кэшей с флагом `force_clean=True`, полное очищение. Но это только половина решения. Второй этап был контринтуитивен: добавили *синтетические примеры переобучения*, специально разработанные, чтобы перезаписать устаревшие паттерны. Это как дефрагментировать не диск, а границы решений в нейросети. Результат был жёсткий, но необходимый. Точность на исторических валидационных наборах упала на 8–12%. Но на по-настоящему новых данных? Модель осталась острой. Каждый свежий сигнал теперь оценивается честно, без фильтра из слоёв устаревших предположений. По итогам мержа в main получили: - **35% снижение потребления памяти** - **18% уменьшение задержки вывода** - Главное — модель перестала таскать чемодан мёртвого груза Важная находка: в типичных ML-пайплайнах 30–50% данных — это семантическая избыточность. Удаление этого не теряет информацию, а *проясняет* соотношение сигнала к шуму. Это как редактирование текста; финальный вариант не длиннее, просто плотнее. Когда слышу про Kotlin, вспоминаю: это единственная технология, где «это работает» считается документацией 😄
Как ИИ помогает отслеживать сигналы в больших данных
Недавно мы запустили **Trend Analysis** — проект, который анализирует тренды через одно большое хранилище информации. Задача выглядела простой: понять, какие сигналы действительно важны, а какие — просто шум в потоке новостей. Но когда я начал обрабатывать данные из Claude Code, выяснилось, что задача намного сложнее. Первая проблема: как выбрать сигнал из 30 статей в день? Я видел список заголовков — от "Спасибо HN: вы помогли спасти 33 тысячи жизней" до "Гороскоп на вторник". Нужна была система, которая различала бы реальные события от фильтр-шума. Мы начали с простого подхода: отмечать технологии, проекты, действия. Но это не работало — слишком много ложных срабатываний. Второе открытие: **Claude API** справляется лучше, чем я думал. Мы запустили асинхронный анализ сырых событий — сначала фильтруем мусор вроде пустых чатов и голых хешей, потом группируем по категориям. "Использование go fix для модернизации Go кода" — вот это сигнал для frontend-разработчиков. "Минимальное ядро x86 на Zig" — совсем другая аудитория. Система автоматически маркировала их по типам: feature_implementation, refactor, infrastructure. Третий этап был критичен: дедупликация. Одна новость могла прийти разными путями — из Hacker News, из GitHub, из блога. Без дедупликации мы бы публиковали одно и то же трижды. Мы добавили матчинг по slug'ам и семантической близости. Но главный вызов — **масштаб LLM-вызовов**. Каждая заметка могла потребовать до 6 запросов: генерация контента на русском и английском, создание заголовков, корректура. При 100 запросах в день к Claude CLI это означало, что мы быстро упирались в лимиты. Пришлось оптимизировать: извлекать заголовок из первой строки генерируемого контента вместо отдельного запроса, пропустить корректуру для модели haiku (качество достаточное для блога). Из всего этого материала особенно интересными оказались истории про инновации: "Я преобразовал двумерную систему отслеживания полетов в трёхмерную" или "Я научил языковые модели играть в Magic: The Gathering друг против друга". Именно такие сигналы привлекают читателей техблога. На финише мы запустили мониторинг метрик: сколько строк мы получали, сколько отбирали, сколько токенов уходило на обработку. Это помогло нам понять, где находятся реальные узкие места. Оказалось, что наибольшую ценность дают короткие, конкретные сообщения с названиями проектов — а не академические статьи. Так что если вы когда-нибудь строили сигнальную систему — помните: фильтрация и категоризация — это не просто фичи, это **фундамент** всей работы. 😄 *А знаете, чем это похоже? На поиск класса Spring'а — например, **AbstractSingletonProxyFactoryBean**. Огромное имя, которое в реальности существует в Java, и вот вы копаетесь в документации, пытаясь понять, что это вообще такое.*
Охота за вторым вызовом: как найти забытого баг-ассистента
Работаю над рефакторингом сигнал-тренд модели в проекте **Trend Analysis**. Задача вроде стандартная: перепроверить все места, где вызываются критические функции обновления трендов. Но тут я натыкаюсь на классическую историю про код, который живёт своей жизнью. В `analysis_store.py` на строке 736 я нахожу **ещё один вызов** `update_trend_scores`. Казалось бы, мелочь. Но вот в чём подвох: в первом проходе я уже обновил несколько вызовов функции, отрефакторил логику. И вот этот, затерянный где-то в середине файла, остался в старом формате. Такие ситуации опасны—когда часть кода живёт по одним правилам, а часть по другим. Это источник багов, которые проявляются в production и заставляют спешить с патчами. Приходится запускать верификацию. Делаю полный проход по проекту, ищу все вызовы `update_trend_scores` и `score_trend`. Python это облегчает—можно просто `grep` по всему `src/`. Находится порядка 10-15 вызовов, разбросанных по разным модулям. Часть в обработке данных, часть в API-слое, часть в фоновых задачах. Потом поднимаю **lint**. Не мой рефакторинг создал проблемы—в `db/` уже накопились давние стиль-нарушения. Но я внимателен к своему коду: проверяю только `src/` и `api/`. Zero issues. Это базовое правило: перед push-ом убедиться, что твои изменения не усугубляют ситуацию. Здесь раскрывается философия рефакторинга на Python. Язык динамический, типы не проверяются статически—полагаемся на внимательность и тесты. Потому система версионирования, логирование и code review становятся критичными. Каждый поменял сигнатуру функции? Значит, нужно проверить все 15 вызовов. Это не оптимально, но честно. Финальный step—убеждаюсь, что все файлы, которые импортируют обновлённые модули, уже в git. Локально существующие файлы не считаются. CI работает с чистым checkout, и если забыть добавить важный модуль—Pipeline упадёт. Почему **Ansible** лучший друг разработчика? Потому что без него ничего не работает. С ним тоже, но хотя бы есть кого винить. 😄
Как Genkit Python v0.6.0 собирается из семи компонентов одновременно
Релизить большой фреймворк для AI-агентов — всё равно что организовать симфонический оркестр, где каждый инструмент должен начать играть в одну долю. В **Genkit Python 0.6.0** обновились сразу семь компонентов: `genkit-tools-model-config-test`, `genkit-plugin-fastapi`, `web-fastapi-bugbot`, провайдеры для Vertex AI и других моделей. И каждый зависит друг от друга. Я видел это по истории коммитов. **Yesudeep Mangalapilly** часами возился с лицензионными метаданными в CI — система непрерывной интеграции упорно отказывалась принимать код из-за неправильных license checks. Звучит как мелочь, пока не поймёшь: это блокирует весь релиз. Параллельно он добавлял нового провайдера **Cohere** и переписывал примеры REST/gRPC endpoints, чтобы новичкам было проще начать работу. **Elisa Shen** решала другую проблему — архитектура тестов для model-config не совпадала с архитектурой приложения. Пришлось перевозить тесты между модулями и переписывать assertions. Это не заметно в коде, но это часы работы. Но были и более хитрые баги. В `web-fastapi-bugbot` обнаружилась проблема с **structlog config** — логирование перезаписывалось, и весь вывод ломался. А когда работали с **DeepSeek**, JSON кодировался дважды. Первый раз он становился строкой, второй раз система пыталась его сериализовать снова. Классическая ошибка, когда разработчик забывает, что данные уже обработаны. Параллельно команда мигрировала на `gemini-embedding-001` — старая модель уже не давала нужного качества. Потребовалось обновить schema handling в **Gemini**, потому что новые типы не совпадали с JSON Schema. Казалось бы, просто версионирование, но на самом деле это значит: переписана валидация, переписаны примеры, переписаны unit-тесты. Самое интересное в истории коммитов — видно, как не всё прошло гладко. Некоторые коммиты дублируются в changelog. Это значит, что код переживал рефакторинг прямо во время разработки. Что-то переехало между модулями, что-то было переписано заново. Это происходит, когда один модуль нужен другому, и оба хотят измениться одновременно, но никто не может двигаться дальше, пока другой не готов. v0.6.0 — это не просто релиз. Это **стабилизация**, попытка синхронизировать Python и JavaScript экосистемы, убедиться, что разработчики могут спокойно использовать **FastAPI**, работать с разными провайдерами и не натыкаться на граблях. А знаете, что самое забавное? Если Svelte работает — не трогай. Если не работает — тоже не трогай, станет хуже. 😄
Genkit Python 0.6.0: чем занимается фреймворк, пока мы спим
Представьте: вы выпускаете новую версию фреймворка для AI-агентов, и в неё попадают обновления аж в **семь компонентов** одновременно. Это именно то, что произошло в Genkit Python v0.6.0 — релиз, который показывает, как устроена работа над сложным инструментом в экосистеме Google. ## Что делалось в это время Начнём с фактов. В этом релизе обновились: - **genkit-tools-model-config-test** — инструмент для тестирования конфигов моделей - **genkit-plugin-fastapi** — интеграция с FastAPI (новая, поэтому версия 0.2.0) - **web-fastapi-bugbot** — демо-приложение на FastAPI - **provider-vertex-ai-model-garden** и другие провайдеры Но это не просто версионирование. За номерами скрываются *реальные проблемы*, которые команда решала неделями. ## Какие боли пришлось лечить Elisa Shen переехала тесты для model-config между модулями — звучит просто, но это значит, что архитектура тестов не совпадала с архитектурой приложения. Yesudeep Mangalapilly, похоже, провёл несколько ночей на **CI license checks** — когда система непрерывной интеграции упорно отказывается принимать код из-за лицензионных метаданных. Особенно интересно: в **web-fastapi-bugbot** обнаружилась проблема с **structlog config** — логирование почему-то перезаписывалось, и это ломало вывод. Вроде бы мелочь, но попробуйте дебажить асинхронный код без логов. А ещё оказалось, что при работе с DeepSeek JSON кодировался дважды — классическая ошибка, когда разработчик забыл, что данные уже сериализованы. ## Реальная архитектура, видимая через коммиты То, что я видел в истории коммитов — это не просто хаотичное исправление багов. Это **планомерная работа по стабилизации**: 1. Сначала добавили новый провайдер Cohere (нужен был в примерах) 2. Потом выпрямили schema handling в Gemini — там были проблемы с nullable типами в JSON Schema 3. Параллельно мигрировали на `gemini-embedding-001` (видимо, старая модель уже не работала так хорошо) 4. На конец добавили новый пример с REST + gRPC endpoints — так больше разработчиков смогут начать работу Команда думала не только о текущем функционале, но и о том, как новичок будет разбираться в коде. ## Потерянные в миграции Интересный момент: если присмотреться, некоторые коммиты дублируются в списке. Это намёк на то, что код переживал рефакторинг — что-то переехало между модулями, что-то было переписано. Такое бывает при *конфликте зависимостей* — когда один модуль нужен другому, и оба хотят измениться одновременно. ## Что дальше v0.6.0 — это не просто релиз. Это **стабилизация** перед большим толчком. Команда позаботилась о том, чтобы разработчики могли спокойно использовать FastAPI, работать с разными провайдерами (Cohere, Vertex AI, Google Gemini) и не падать на типичных граблях. А знаете, что самое забавное? Ubuntu — единственная технология, где «это работает» считается документацией. 😄
Одновременно 12 пакетов Genkit: как releasekit спас нас от ручной координации
Знаете ощущение, когда нужно выпустить обновление для целой экосистемы пакетов? Вчера я столкнулся с этим вызовом на проекте **Genkit** — это фреймворк для работы с AI-агентами. У нас было 12 пакетов, которые нуждались в новом релизе одновременно. Раньше такое означало бы ручной марафон: проверить зависимости каждого плагина, вручную бампить версии, убедиться, что ничего не сломалось. Кошмар координации. Но на этот раз у нас был **releasekit** — инструмент, который автоматизирует весь процесс выпуска. ## Разбор по полочкам Я запустил простую команду: ``` py/bin/releasekit plan --bumped --publishable ``` И вот что произошло. Releasekit проанализировал все коммиты, обнаружил, что у основного пакета **genkit** было 11 связанных изменений: - **genkit-plugin-anthropic** — 0.5.0 → 0.6.0 - **genkit-plugin-compat-oai** — 0.5.0 → 0.6.0 - **genkit-plugin-evaluators** — 0.5.0 → 0.6.0 - **genkit-plugin-fastapi** — 0.5.0 → 0.6.0 И ещё 8 плагинов для Google Cloud, Google Genai, Ollama, XAI, DeepSeek, Flask и Vertex AI. ## Почему это работает? Releasekit сканирует конвенциональные коммиты (conventional commits) в истории Git и определяет, нужно ли бампить версию. Минорное обновление 0.5.0 → 0.6.0 означает, что добавилась функциональность или были исправлены баги, но не сломалась обратная совместимость. Интересный момент: система обнаружила один нестандартный коммит — `'elisa/fix/core framework improvements (#4649)'` — и выдала предупреждение. Сообщение было в формате ветки, а не в формате `fix: ...`. Но это не остановило процесс — просто залогировалось как warning. ## Основные исправления в этом релизе Среди всех этих 12 пакетов было несколько критических фиксов: - Исправление пути для логирования в ядре (Path fix for logging) - Замена literalного нуль-байта на Git-экранирование `%x00` в changelog — вещь техническая, но важная для совместимости - Улучшения в Firebase telemetry и рефакторинг реализации - Асинхронное создание клиента с обновлением credentials в фоне для **genkit-plugin-vertex-ai** ## IT факт в завершение А вы знали, почему DynamoDB не пришёл на вечеринку? Его заблокировал firewall. 😄 Шутки шутками, но система контроля версий и автоматизации релизов — это реально спасение для монорепозиториев с десятком зависимостей. Вместо того чтобы спать-не-спать и боязно кликать по кнопке publish, я просто дал команду и пошёл пить кофе. Releasekit сделал всю грязную работу: вычислил версии, составил changelog, все 12 пакетов готовы к публикации. Вот это я понимаю под словом *DX* (Developer Experience).
ReleaseKit: граф совместимости лицензий вместо головной боли
В **ai-agents-genkit** вдруг обнаружилась проблема, которую я раньше даже не замечал. Проект использует кучу зависимостей с разными лицензиями: MIT, Apache-2.0, GPL, BSD. Но беда в том, что не все они дружат друг с другом. GPL тащит за собой требования, которые конфликтуют с proprietary кодом. Apache может стать несовместима с AGPL. Вручную проверять каждую — это путь в ад. Вот я и собрал для **ReleaseKit** полноценную систему проверки лицензийной совместимости. Звучит скучно? Погоди. ## Как это работает Начал с парсера SPDX-выражений. Да, существуют лицензии, записанные как `(MIT AND Apache-2.0) OR GPL-3.0 WITH Classpath-exception-1.0`. Стандартная строка из жизни. Парсер строит AST, понимает операторы `AND`, `OR`, `WITH`, может вычислить результат. Потом идёт граф — 167 лицензий, 42 правила совместимости. Каждый пакет в дереве зависимостей получает статус: **OK**, **WARNING** (несовместимость), **ERROR** (блокирующая). Система умеет парсить `uv.lock`, `package-lock.json`, `Cargo.lock` — охватывает Python, JavaScript, Rust, Go, Dart, Java и даже Clojure. А дальше — интерактивное исправление. Флаг `--fix` запускает диалог: видишь конфликт — выбираешь действие: *exemption* (исключение), *allow* (разрешить), *deny* (запретить), *override* (переопределить). Конфиг пишется в `releasekit.toml` с сохранением комментариев (спасибо, `tomlkit`). ## Тестирование как искусство Покрыл ~800 тестов на все случаи жизни: парсер SPDX (100+ кейсов с edge cases), граф совместимости (150+ комбинаций), обнаружение лицензий в манифестах семи экосистем (80+ проверок), фаззер для SPDX-резолвера (5 стадий: точное совпадение → алиасы → нормализация → префикс → Левенштейн). Даже есть скрипт `verify_license_data.py` — проверяет, что кросс-ссылки в `licenses.toml` и `license_compatibility.toml` не сломаны. ## Почему это серьёзно Лицензийная совместимость — не баг, не фича, это *compliance*. Один пропущенный конфликт = проблемы на prod. Раньше я пытался делать это руками, экселем, документом. Теперь система автоматическая, проверяемая, интерактивная. Документация новая — гайд для интерактивного исправления, слайды с демо-сессией в терминале, полная архитектура. ## Забавный факт Pandas: решение проблемы, о существовании которой ты не знал, способом, который не понимаешь. 😄
Как мы научили CI передавать право подписи релизам
Работаю в **Genkit** — это Python-библиотека для генеративного ИИ. Недавно столкнулись с задачей, которая на первый взгляд казалась простой: автоматизировать выпуск версий. Но под капотом скрывалась целая история про доверие, аутентификацию и то, как машина доказывает GitHub, что она имеет право что-то коммитить. ## Проблема: три способа подписать себя При каждом автоматическом релизе нужно создать коммит с тегами, но **GitHub не доверяет просто так**. Проверяет CLA (Contributor License Agreement) — то есть нужен реальный аккаунт, подписавший соглашение. Мы выбрали три дорожки: **GitHub App** (премиум) — приложение Genkit, созданное в самом GitHub. Оно вызывает API, API возвращает специальный ID юзера, и коммиты становятся от лица бота-приложения. CLA проходит, CI запускается. **Personal Access Token (PAT)** — обычный токен для конкретного аккаунта разработчика. Уже знаком каждому, кто работал с GitHub CLI. Так же проходит CLA и запускает CI. **GITHUB_TOKEN** (есть по умолчанию) — встроенный токен, даёт доступ каждому Action. Главный трюк: даже с ним можно подделать идентичность, если в переменных репо хранить имя и email человека, который подписал CLA. ## Как это устроено Все восемь рабочих потоков в Genkit теперь получили `auth` job на первом этапе. Он проверяет, что настроено (App? PAT? или только GITHUB_TOKEN?), и резолвит идентичность: - **App**: ищет юзер-ID через `gh api`, делает коммит от `genkit-bot` - **PAT**: берёт `RELEASEKIT_GIT_USER_NAME` и `RELEASEKIT_GIT_USER_EMAIL` из переменных репо - **GITHUB_TOKEN**: то же самое, плюс fallback на `github-actions[bot]` Главное: если ты находишься в ситуации, когда App и PAT недоступны, но у тебя есть CLA-подписанный аккаунт — просто добавь две переменные в настройки репо, и даже встроенный токен пройдёт проверку CLA. ## Бонус: bootstrap_tags.py Отдельно создали скрипт, который читает конфиг `releasekit.toml`, находит все пакеты в `library_dirs`, и создаёт теги для каждого пакета отдельно. Не hardcode'ит пути типа `['packages', 'plugins']`, а читает их из конфига. В итоге — 24 тега за раз, и все они указывают на правильный коммит. ## На практике Теперь разработчик может зайти на страницу переменных GitHub репо, добавить два поля (имя и почту) — и релизы будут проходить CLA, даже без App или PAT. Это снижает барьер входа для новых контрибьюторов. Мой код работает, и я знаю почему. Мой код не работает, и я уже добавил логирование. 😄
Почему картинки в заметках исчезали — и как я это чинил
В проекте **bot-social-publisher** большинство заметок генерировались без картинок. Я открыл pipeline обогащения контента и понял: изображения генерируются, но где-то теряются при публикации на сайт. Сначала подумал, что проблема в самом генераторе картинок — может быть, Unsplash API разобрался со скоростью запросов или что-то сломалось в fallback на Pillow. Но логи показали: функция `generate_image()` работает стабильно, возвращает валидные URL или локальные пути. Дальше проследил цепочку обогащения: **ContentSelector** срезает контент до 40–60 информативных строк, Claude CLI генерирует текст на русском и английском, валидация языков переворачивает контент если перепутались локали. Все работает. Изображение есть в `EnrichedNote`. Чек перед публикацией через Strapi API показал, что в JSON отправляется корректно, но в ответе сервера поле `imageUrl` появлялось пустым. Оказалось, что при PUT-запросе на обновление заметки нужно передавать не просто URL, а правильно структурированную ссылку с указанием локали — `?locale=ru` для русского варианта. Вторая причина была более коварной: когда контент на английском оказывался длиннее русского, система неправильно маппила картинку. Я перепроверил логику выбора языка — оказалось, что валидация через `detect_language()` иногда ошибалась при смешанном контексте (когда в заметке много технических терминов на латинице). **Решение оказалось двухуровневым:** 1. Явно привязать изображение к основному языку заметки (русский, как определено в конфиге), не к случайному выбору в цикле обогащения. 2. Добавить проверку в `scripts/update_site.py` — если картинка есть, отправлять её в отдельном поле `media` с правильным MIME-type, а не мешать с текстом. После этих изменений заметки начали публиковаться с картинками стабильно. Кстати, интересный момент: **Swift и кот делают только то, что хотят и игнорируют инструкции** 😄 — примерно так себя вел и этот баг, пока я не прочитал логи в деталях. Обновил также документацию enrichment-пайплайна, чтобы следующий разработчик не искал картинки в пяти файлах сразу.
Когда маршрутизация экспертов встречает стену батч-нормализации
Работал над проектом `llm-analysis` — попытка воплотить мечту о смеси экспертов (MoE) для классификации на CIFAR-100. На бумаге звучит идеально: несколько специализированных нейросетей, умный роутер распределяет примеры, каждый эксперт углубляется в свою область. Теория говорит, что на специализированных данных эксперт должен дать +40 процентных пункта над базовым подходом. На практике упёрся в две стены одновременно. ## Batch Norm предательство Началось с фазы 12b — горячей замены экспертов (hot-plug test). Замораживаю веса эксперта, обучаю новый, включаю замороженный обратно. Точность первого эксперта падала на 2.48pp. Думал, это неизбежный дрейф при переобучении остальных. Копался в коде часами. Потом понял: `requires_grad=False` не спасает. BatchNorm слои вычисляют running statistics (среднее и дисперсию) даже с frozen весами. Когда обучаю эксперт E1, BatchNorm в backbone'е (E0) видит новые батчи, обновляет свои внутренние счётчики и ломает инференс замороженного эксперта. Решение простое, как кувалда: добавить `model.stem.eval()` после `model.train()`, явно перевести backbone в режим инференса. Дрейф упал с 2.48pp до **0.00pp**. Это был просто инженерный баг, но на него потратил полдня. ## Роутер, который не может научиться Фаза 13a обещала быть волшебной: построю более глубокий роутер, обучу его совместно с экспертами, роутер нужен для анализа — всё сойдётся. Oracle (идеальный роутер) показывал потолок в 80.78%, а наш простой `nn.Linear(128, 4)` давал 72.93%. Зазор в семь с половиной пункта! Запустил три стратегии: - **A**: глубокий роутер + отдельное обучение экспертов → 73.32% (нет улучшения) - **B**: совместное обучение роутера и экспертов → 73.10% (хуже baseline) - **C**: вообще неудача, routing accuracy 62.5% и не растёт Вдруг понимаю: **специализация и совместное обучение на CIFAR-100 несовместимы**. Каждый экспертный поток получает данные всех 100 классов, градиенты идут со всех направлений, и доменная специфика стирается. Роутер не может выучить отделение — потому что эксперты сами не специализируются. ## Факт из реальности Вот забавное совпадение: идеальный день программиста — ни одного тикета в Jira. Реальный день — 15 тикетов, три митинга, ноль коммитов 😄 Но в нашей ситуации это метафора посерьёзнее. Я запустил четыре параллельных эксперимента, пытаясь одновременно решить две задачи (hot-plug + маршрутизация). Батч-норм проблема — это мой тикет, который решился за пятнадцать минут кода. Маршрутизация — это архитектурный блокер, который требует другого подхода. ## Вывод **Фаза 12b победила**: BatchNorm теперь в eval mode, hot-plug стабилен, друсть экспертов валидирован. Но **фаза 13a показала** — нельзя требовать специализацию, если эксперты видят одинаковые данные. Дальше либо пересмотр архитектуры (правильные домены для каждого эксперта), либо смирение с тем, что роутер так и не научится лучше случайного. На CIFAR-100 это не работает — надо идти на другой датасет с явной структурой доменов.
Как я обновил архитектуру голосового агента за один вечер
Работаю над проектом `ai-agents-voice-agent` — это голосовой ассистент, построенный на Claude API с поддержкой десктопной автоматизации. Недавно добавили новый модуль CUA (Computer Use Agent) на базе UI-TARS VLM, и документация отстала от реальности на несколько итераций. Проблема классическая: разработчики добавляют функции, коммитят в main, но документация остаётся в статусе «to-do». Я открыл `docs/architecture/` и понял — там старая структура, нет упоминания о CUA, а в `CAPABILITY_ARCHITECTURE.md` описана трёхуровневая архитектура, хотя фактически их уже четыре. Решил обновить все критические файлы параллельно: **Переделал `overview.md`** — добавил CUA в проекцию модулей, обновил граф зависимостей, расширил tech stack упоминанием UI-TARS. Теперь новый разработчик сразу видит, что есть desktop automation. **Переписал `CAPABILITY_ARCHITECTURE.md`** — это был ключевой файл. Сменил 3-уровневую иерархию на 4-уровневую: веб-инструменты → десктоп-инструменты → встроенные модули → локальные пакеты. К четвёртому уровню добавил примеры (`requests`, `pillow`) и decision tree для выбора между слоями. **Обновил документацию TMA** (`tma/00-ARCHITECTURE.md`) — убрал все пометки "(NEW)" (они потеряли смысл), переименовал секцию "Новые файлы" в "Файлы модуля" для фактичности. **Актуализировал `06-NEW-INTERFACES.md`** — это было больно. Там была информация о Tesseract OCR, которая вообще не использовалась. Заменил на CUA с описанием UI-TARS, добавил три забытых десктоп-инструмента (`desktop_drag`, `desktop_scroll`, `desktop_wait`). Фаза 3 теперь содержит 21 инструмент вместо старых 12. **Закрыл все задачи Фазы 3** в `02-TASK-LIST.md` — просто поставил галочки рядом с пунктами 3.1–3.9. Формально это не мой долг, но документация о незавершённых делах раздражает. Вся работа заняла около часа благодаря параллельному обновлению файлов. Главное — не оставлять документацию как груз, который весит на совести. Она либо актуальна, либо токсична. --- *Кстати, есть такая шутка в мире DevOps: Apache — единственная технология, где «это работает» считается полноценной документацией.* 😄