В финале прошлой статьи я обещал разбор контура генерации ответов с гибридным извлечением данных (LLM‑tools + regex). Но пока немного переиграем планы и переключимся в другую тему — причина практический инженерный эксперимент. Постараюсь вкратце и по существу.:‑)
Нас всех учили писать красивый код, в универе или в умных книжках рисовали идеальный мир с чистыми функциями, изящными паттернами и идеальной математикой. Но потом ты приходишь в студию и выясняется, что реальная кодовая база движка это кое-как собранное на коленке поделие, где память течет, потоки дерутся, ос отбирает ядра в процессе выполнения, а физический движок отправляет игрока на орбиту просто потому, что кто-то перепутал индексы осей.
Отладка багов, пожалуй, самый недооцененный инженерный навык. Ему толком не учат, его очень редко просят "осветить" на собеседовании, и еще ни одного синьора-отладчика я в жизни не встречал. Все обучение сводится к тому, что ты просто сидишь три часа и смотришь краш-дамп, пытаясь понять, почему игра упала. Рецептов поимки и починки хитиновых товарищей тыща и один, и у каждого обязательно будет свой, поэтому смысла рассказывать о них я не вижу, но попробую рассказать о том какие собственно товарищи бывают.
Как мы скрестили Go, Rust и MCP, чтобы построить масштабируемый оркестратор ИИ-агентов часть 2.
Глубокий разбор архитектуры Zettaverse AgentHub
Кастомная валидация структуры flow_json и построение DAG
Я довольно давно вожусь с сервисами вокруг товарных данных: делаю price‑matrix (обработка прайсов поставщиков) и CatalogLoader (парсеры сайтов). InventoryMod вырос из той же темы, но с другого конца — не «собрать и разобрать данные», а «вести по ним складской учёт».
InventoryMod — учётная система для склада: товары, остатки, движения, заказы, закупки, инвентаризация, отчёты. Начал где‑то в середине апреля 2026-го с расширения для Chrome с локальной базой (первый коммит в git датирован 19 мая — до него первая версия довольно долго собиралась «в столе»), потом добавились мобильное приложение и полноценный SaaS с сервером.
Главная проблема, с которой я жил всё это время, формулируется просто: как не писать три раза одну и ту же бизнес‑логику, когда база данных в каждой среде своя. Где‑то SQLite прямо в браузере, где‑то удалённый сервер по HTTP.
Дальше разберу на реальном коде из репозитория, как из query‑модулей выводится API‑контракт, почему я в итоге слез с IndexedDB на SQLite‑WASM и что творилось с транзакциями в резервировании остатков. Про сам продукт скажу ровно столько, сколько нужно для контекста.
Я делаю полностью работающую реплику пип‑боя для ролевых игр по вселенной Fallout. Сама по себе эта задача тривиальная с инженерной точки зрения, но есть в ней кое‑что, что, возможно, заинтересует пытливые умы. Расскажу, как научил телефон распознавать вейк‑слово, с матюгами заставил правильно работать речевой парсер и сплясал чечётку на полном ассортименте садовых инструментов, связанных с голосовым управлением вещами.
Полгода назад я начал писать веб-лист персонажа для D&D 5e, и почти весь код в нём пишет Claude Code. В какой-то момент лимиты подписки стали заканчиваться к обеду, и я распарсил транскрипты сессий, чтобы понять, куда уходят токены. Выяснилось: ответы модели — полпроцента расхода, а две трети съели 22 длинные сессии, в которых контекст рос на каждом шагу. В статье — скрипт замера на тридцать строк, разбор того, почему одна длинная сессия дороже пяти коротких, и восемь приёмов, которые я после этого внедрил: лимит сессии в Stop-хуке, карта кода вместо разведки грепом, запрет на повторное чтение файлов, вынос браузерных проверок в сабагента и рутины — на дешёвые модели.
Последние два года я строю свои продукты без разработчиков — весь код пишут нейронки. Я делаю относительно небольшие продукты, которым не нужно выдерживать сверхнагрузок. Но как обстоят дела у реально крупных компаний с внедрением AI в свои процессы? Мне стало интересно, поэтому я поресёрчил эту тему. Оказалось, что всё не так однозначно.
Год назад я написал статью «Переводим fb2 книжки, с нейронками, для себя» — про то, как собрал на паре Tesla P40 в гараже программу Sunny Narrator («Солнечный сказочник»), которая переводит художественные книги через локальные и облачные LLM. Тогда это был скорее прототип «доказать себе, что так можно»: черновики читались с головной болью, книга в тысячу страниц переводилась два дня, а электричество, отключённое посреди процесса, стоило ещё двух.
За год программа доехала до версии 2.1, я перевёл достаточно книг, чтобы набить руку, и понял главное: это уже инструмент не только для меня, но и для переводчиков — и для всех любопытных. Рассказываю, что изменилось, сколько это стоит в токенах и почему без человека ничего не работает.
Прочтя недавний перевод про запаковку БД в exe, решил рассказать об идеи, которую реализовал лет 6 назад в своем домашнем проекте. Сам проект недоделал, но речь в статье об архитектуре файлов и их запаковке.
Model Context Protocol (MCP) от Anthropic перевернул работу с ИИ-агентами, но когда их становится больше трех, начинается ад с правами доступа, сетевым I/O и визуальным контролем. Мы задолбались собирать костыли на Python и написали масштабируемый опенсорс-оркестратор. Внутри — честный инженерный разбор: почему для ядра выбрали Go, как упаковали асинхронный движок JSON-RPC 2.0 на Rust в cdylib для вызова через cgo, и как мы героически побеждали утечки памяти на стыке этих двух миров.
Последние несколько лет я, похоже, одержим двумя темами: а) Nix в качестве инструмента для исследования новаторских идей, требующих возможностей перестройки мира; б) замена ELF на SQLite в качестве формата исполняемых файлов. Возможно, вы заметили, что эти две идеи хорошо сочетаются друг с другом.
Я изучал вторую идею в рамках своей диссертации, однако реакции окружающих оказались довольно разочаровывающими. Радикальные идеи сложно продвигать, ведь приходится бороться с инерцией давно устоявшегося решения.
Одним из результатов этого исследования стал инструмент sqlelf, позволяющий декларативно исследовать файл ELF при помощи SQL. [Я написал статью arXiv:2405.03883, которую мне не удалось опубликовать]. SELECT name FROM elf_symbols вместо возни с readelf и grep. Это оказалось на удивление просто благодаря использованию виртуальных таблиц для ELF, однако мне всё равно было интересно исследовать формат файлов ELF. Но всё же я понимал, что можно сделать нечто гораздо большее.
Меня всё не покидала эта мысль, а в свете прогресса LLM мне показалась привлекательной идея исследовать эту тему глубже. В частности, мне было любопытно, что будет, если мы заменим ELF на SQLite в качестве формата исполняемых файлов?
Не просто «база данных, описывающая исполняемый файл», а реальный файл, с которым можно сделать chmod +x и запустить его.
Одно из удобных свойств файлов JPEG заключается в том, что в них можно опционально сохранять первыми низкочастотные компоненты. Это означает, что частично скачанное изображение будет отображаться в низком разрешении, а не обрезаться снизу.
Внутри файла это реализуется разбиением сжатых данных на несколько «сканов», перед каждым из которых добавляется заголовок. Вот первый скан изображения:
FF DA - Маркер "начало скана"
00 0C - Поле длины в big endian (12 байт); включает и свою длину
03 - Количество каналов в скане (3)
01 - Глобальный id первого включённого канала
00 - Индекс 1 таблицы Хаффмана (DC: 0, AC: 0)
02 - Глобальный id второго включённого канала
10 - Индекс 2 таблицы Хаффмана (DC: 1, AC: 0)
03 - Глобальный id третьего включённого канала
10 - Индекс 2 таблицы Хаффмана (DC: 0, AC: 0)
00 - Начальный коэффициент DCT (DC)
00 - Конечный коэффициент DCT (тоже DC)
01 - Точность: половинная, предыдущие данные отсутствуют.
f8ad 512d d3f1 cd96 - Зашифрованные кодом Хаффмана коэффициенты DCT
bcb0 58df 53d5 5d97 [...и так далее]
В него включён самый низкочастотный коэффициент (DC-компонент) преобразования Фурье для всех трёх цветовых каналов.
В качестве трёх цветовых каналов вместо привычного RGB используется YCbCr. Яркость (Luminance, Y) отделена, потому что должна иметь высокое качество, а цвета можно передавать кое-как и они всё равно будут выглядеть неплохо.
Токен, прочитанный из кеша, стоит не «немного дешевле». Он дешевле в 10–31 раз: DeepSeek — $0.44 против $0.014 за миллион, OpenAI — $4.00 против $0.40.
Кеш провайдера — префиксное дерево по токенам. Он работает ровно до первого расхождения с прошлым запросом. Дальше — всё по полной цене.
Поэтому одна строка вида Current time: {datetime.now()} в начале системного промпта отключает кеш целиком: время меняется на четвёртом слове, и остальные две тысячи токенов политик и базы знаний каждый раз оплачиваются заново. Хотя не менялись ни разу.
Я замерил это на живых вызовах DeepSeek. Один и тот же агент, одни и те же четыре вопроса, одна и та же минута — разница только в том, куда положить время. Ноль попаданий в кеш против 1152 токенов из 1180.
Потом направил профайлер на 97 877 собственных вызовов Claude Code — 32,5 млрд входных токенов, 98% из кеша.
Внутри: как найти такой баг у себя, почему совпадение текста на 96% ещё не значит, что кеш работает, и какие поломки не видно глазами вообще — схемы инструментов из словаря с плавающим порядком ключей, база знаний из set(), «префикс совпал, а кеша нет».
Плюс отрицательный контроль: сценарий, где фикс не даёт ничего, и инструмент честно об этом пишет.
Инструмент открыт: github.com/Isk4R1oT/prefixcash
Внутри — экономика доставки, стриминговых войн, билетного сервиса и целой экосистемы без прикрас. Игры бесплатные, банкротство — учебное.
Полгода собирал контекст для агента: на работе через трекер, вики и GitLab, в пет проекте через markdown файлы и граф. Выгрузил 494 задачи и 410 merge request'ов, чтобы проверить, стало ли лучше. Комментариев ревью на MR стало втрое меньше
Как я навайбкодил панель для Wireguard ASC 3.x чтобы не просто безопасно выходить в Интернет, но и объединять устройства в одну сеть.
Всем привет! Для меня электричество — это магия, и ИИ — тоже. После того, как я приделал к стене водостойкую розетку, решил что и ИИ можно покорить.
Первым упражнением в вайбкодинге локальной RAG системы стало приложение, которое позволит управлять коллекцией векторных документов и кормить локального агента нужными и вкусными данными.
Сразу к делу — вот репозиторий на ГитХабе, в нем исходники по лицензии MPL 2.0. Приложение для macos 14+, написано на SWIFT и для своей работы тянет только системные зависимости и (при необходимости) пакет установки ChromaDB.
Я делаю агента, который умеет дописывать себе навыки: упёрся в то, чего не умеет — сгенерировал код, собрал, установил, пользуется.
Первый раз это сработало ровно так, как я мечтал. Агент сказал «у меня нет такого навыка», спросил разрешения, минуту пыхтел компилятором и отчитался: готово.
Метода не было. То есть он был — в манифесте, в списке, который скилл про себя рассказывает. А в коде, который этот вызов должен обрабатывать, его не было. Модель объявила метод, забыла реализовать и об этом не узнала. Валидация прошла. Установка прошла.
Проблема оказалась не в том, что модель ошиблась — это скучно и ожидаемо. Проблема в том, что я не смог поймать ошибку, потому что спрашивал у того же, кто её сделал. Скилл заявляет о себе сам, проверить заявление можно только у него же, а он в этом вопросе — заинтересованная сторона.
Дальше — про то, как это чинится отрицательным контролем на девять строк, почему у проверки должно быть три исхода вместо двух, и зачем на самом деле нужен контейнер.
Я поставил перед агентом перехватчик разрушительных команд и шестнадцать дней писал в журнал всё, что агент делал. Хотел получить красивую статистику предотвращённых катастроф. Получил единицу.
Дальше — что было в журнале и почему единица оказалась интереснее, чем то, на что я рассчитывал.
Свой язык программирования пишут все. Обычно это калькулятор с переменными, пересказ главы про рекурсивный спуск и заброшенный репозиторий.
Интересно в моём не то, что он считает выражения. За время работы я дважды полностью переименовал проект, вырезал из ядра обход дерева и заменил компиляцией в замыкания, поднял скорость втрое и прогнал по языку два фаззера. Любой из этих шагов мог тихо сломать что угодно.
Не сломал. Полная перестройка ядра — 350 строк — прошла все 444 проверки, и ни один эталон не пришлось трогать.
Разбираю, что для этого пришлось построить: пять замков, каждый из которых закрывает то, что гниёт молча — вывод примеров в документации, списки слов в подсветке синтаксиса, формулировки сообщений об ошибках. Почему стенд замеров строится до первой оптимизации, а не после. И как выяснилось, что запас стека я всё это время мерил неправильно.
Плюс двенадцать дефектов, которые нашёл фаззер: равенство, переставшее быть симметричным; undefined, вылезающий наружу в языке, где его нет; += , вычислявший цель дважды. Два из двенадцати нашёл не фаззер, а я — когда писал тесты к его находкам.
Отдельно — про то, что четыре из пяти находок второго фаззера оказались враньём самого фаззера, и почему я довёл его до нуля ложных срабатываний вместо «ну там четыре из них шум».