Бэкенд

Запись пред-ивента «Почему агенты не работают — и с чего начать» — уже на видео:

🔗 https://youtu.be/yYYH0P4gmXc

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

А где ломается у вас? Напишите в комментариях.

Эти места разбираем и лечим на курсе «AI-агенты, которые работают»: старт 21.10, занятие 1 из 7, среды 19:00–21:00 МСК.

Доступ — по подписке «Мастер»: https://boosty.to/polnyistek/purchase/3939761

Бэкенд усложняется. Как за ним успевать?

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

Как расширять техническую экспертизу и увереннее справляться со сложными задачами?

Собрали 15 бесплатных вебинаров от наших преподавателей, на которых будем разбирать реальные инженерные подходы, инструменты и решения.

Архитектура и взаимодействие сервисов

• 20 октября, 19:00. «Балансировка HTTP и L4 сервисов в Angie (Angie)». Записаться

• 21 октября, 20:00. «Apache Kafka: быстрый старт для разработчиков и инженеров». Записаться

• 22 октября, 19:00. «Основы проектирования бизнес‑логики в микросервисной архитектуре». Записаться

• 9 ноября, 20:00. «Монолит или микросервисы? Руководство для архитекторов, которые ценят свои нервы». Записаться

Базы данных и производительность

• 19 октября, 20:00. «Анализируем длинные и сложные запросы в SQL Server». Записаться

• 20 октября, 20:00. «OpenTelemetry в.NET: от чёрного ящика к наблюдаемой системе». Записаться

• 22 октября, 20:00. «Spring Boot под нагрузкой: почему сервис работает локально и падает в production». Записаться

Java, Python и работа с API

• 26 октября, 20:00. «Тестирование FastAPI: проверяем API с помощью pytest». Записаться

• 28 октября, 20:00. «JDBC: как Java‑приложения взаимодействуют с базами данных». Записаться

• 29 октября, 20:00. «Магические слова async/await». Записаться

• 11 ноября, 20:00. «Обработка исключений в Java: как писать стабильный код». Записаться

Go и надёжность кода

• 5 ноября, 20:00. «Тесты в Go без боли: ловим баги раньше пользователей». Записаться

• 10 ноября, 20:00. «Использование каналов в Go на практике». Записаться

ИИ и интеграции

• 19 октября, 20:00. «ИИ‑агенты в реальной разработке: что умеют делать вместо вас». Записаться

• 20 октября, 20:00. «Tool Calling и MCP: интеграция ИИ‑агентов с корпоративными системами». Записаться

ЧТО ПОЧИТАТЬ ПО ТЕМЕ?

Пока ждёте открытые уроки, можно разобраться в тонкостях работы с HTTP/2, подготовиться к обновлению Java‑проектов и освежить знания C++. Собрали четыре технических материала с практическими примерами:

• Создаём HTTP/2-сервер на C++ и хостим на нём свой сайт — разбираемся в устройстве HTTP/2 на практике.

• Миграция на Spring Boot 4 и Java 25: пошаговый план, чтобы обновиться и не уронить прод — планируем обновление стека с учётом рисков для работающего приложения.

• Move‑семантика в C++: пять задач, в которых легко ошибиться — проверяем понимание перемещения объектов и разбираем типичные ошибки.

• std::expected в C++23: гайд по миграции с исключений на функциональный error handling — знакомимся с альтернативным подходом к обработке ошибок.

На Бирже заказов Инфостарта за неделю с 7 по 14 октября появились новые задачи для разработчиков, консультантов и аналитиков 1С: от настройки обменов и обработки документов до доработки учета и интеграций с внешними системами:

• Автоматизация процесса переноса данных/Исключить ручной вод

• Установка и запуск локального 1С:Сервер Взаимодействия

• Создать обработку для загрузки реализаций из Saby в 1С:УТ 10.3 (товары загрузить со сроками годности)

• Обновление 1с УПП 1.3 (1.3.279.1)

• Обработку для 1С:УНФ – Подготовить из расходных накладных комплекты «УПД + счёт» для последующей отправки контрагентам через 1С-ЭДО

• Перевести бухгалтерию с 1С 7.7 на 1С 8

• обновление для синхровб 1С:Розница

• Автоматизация обработки документов

• Интеграция по API между 1С:ДО и внешней системой

• В 1С:КА нужно доработать блок – расчет коммунальных услуг

• Интеграция между 1С:УХ и B2B-Center

• Доработка «Загрузка 3-НДФЛ из отчета Freedom Finance в 1С:Бухгалтерию 3.0»

• Необходимо корректно провести свёртку информационной базы 1С

• Поменять единицу измерения номенклатуры и пересчет товаров в процессе

• Настройка синхронизации между 1С:УНФ 3.0 (3.0.14.159) и 1С:Бухгалтерия предприятия 3.0 (3.0.199.13)

На Бирже Инфостарта можно разместить задачу и выбрать специалиста или команду по откликам, рейтингам и кейсам. Комиссия — 0%, контакты и расчеты — напрямую с исполнителем. Безопасная сделка доступна по желанию.

155 000 вакансий: полный анализ IT‑рынка России. Как описание вакансии влияет на зарплату

Каждая вакансия - это маленькое письмо от работодателя. В нём есть «дружная семья», «стрессоустойчивость», «опыт от 3 лет», ДМС, печеньки и иногда даже зарплата. Мы читаем такие письма каждый день, листаем, вздыхаем и жмём «Откликнуться». А что, если прочитать их все сразу, и тысячами…, сконвертировать стоимость каждой фразы в рубль? Сколько работодатель готов платить, если он пишет, что мы «дружная семья». Чего рынок ждёт от джуна. За что сегодня доплачивают, а что стало просто гигиеной. Где торговаться, а где бесполезно. И когда вообще лучше откликаться, чтобы тебя хотя бы заметили. Об этом у меня вышла большая статья.

Более 15 графиков, показывающих то куда двигается Российский IT-рынок и что при этом всём делать.

Так что если кто-то ещё не успел прочитать, очень рекомендую...

10 ноября в Москве пройдёт Go Birthday Conf от RWB

Отметим день рождения Golang вместе с экспертами RWB, YADRO, Т-Банка, VK и Avito. Разберём кейсы из продакшена, поговорим о highload и будущем Go в эпоху AI

В программе:

➡️ Доклады:

• 10 лет Go глазами практика: как менялся язык и что с ним сейчас;

• SIMD без ассемблера: что изменилось и какой прирост производительности можно получить;

• Архитектура доставки продуктовых метрик под высокой нагрузкой;

• Геокодинг и построение маршрутов под нагрузкой.

➡️ Дискуссия «Go в эпоху AI» — обсудим, как меняется разработка, что остаётся инженеру и почему растёт роль инженерного мышления.

➡️ Воркшоп и архитектурные каты, где можно порешать задачи вместе с другими участниками.

Ждём Go-разработчиков, backend-инженеров, тимлидов и всех, кто работает с highload и архитектурой или хочет разобраться, как AI меняет разработку.

📍 Москва
Старт в 15:00

➡️ Программа и регистрация

От Copilot к Autopilot: как GitVerse строит первую агентную фабрику разработки

Классический CI/CD дает контроль, но тормозит инновации, а вайбкодинг дает скорость, но разрушает предсказуемость. GitVerse ищет третий путь и встраивает агентов внутрь конвейера, превращая дисциплину пайплайнов в трамплин для автономной разработки.

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

Спикер: Анатолий Шипов — управляющий директор, лидер продукта GitVerse.

Трек: Разработка

📅 Когда: 15 октября в 14:00–14:30 мск

👉 Зарегистрироваться

Вышел fx 40!

fx — интерактивный терминальный просмотрщик и процессор таких форматов как JSON.

В версии 40 теперь можно писать запросы прямо в интерфейсе и видеть, как результаты обновляются по мере ввода, а также использовать форматы XML, HTML, EDN и MAML на входе и команды в стиле vim.

GitHub

ChangeLog

Что изменилось в task_struct между двумя ядрами? Написал diff для BTF

bpftool умеет показывать BTF-структуры, но сравнивать их между двумя ядрами уже приходится самому. Можно, конечно, открыть два дампа и искать отличия глазами. Только когда в них тысячи строк, а идентификаторы типов отличаются, занятие быстро надоедает.

Особенно если интересует одна конкретная структура и хочется понять, поменялся ли её размер, сместилось ли поле или появилось что-то новое.

Решил написать для этого небольшую утилиту - btf-layout-diff

Что она делает?

Это CLI-инструмент на C++20, который читает raw-дампы bpftool и сравнивает layout именованных STRUCT и UNION

Смотрит на размер структуры, поля, их битовые смещения и размеры bitfield. При этом не учитывает BTF type_id: идентификаторы могут отличаться между дампами, даже если сама структура не изменилась.

Получить дамп можно так:

bpftool btf dump file /sys/kernel/btf/vmlinux format raw > kernel.raw

Снимаем его на двух Linux-хостах, переносим файлы на одну машину и запускаем:

./build/btf-layout-diff kernel-old.raw kernel-new.raw --type task_struct

Для примера в репозитории есть две тестовые фикстуры. В одной task_struct занимает 24 байта, в другой - 32. Заодно добавлено поле new_field.

Вывод получается таким:

~ STRUCT task_struct  size: 24 -> 32 bytes  + new_field at 192 bits

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

А как насчёт CO-RE?

Собственно, из-за CO-RE мне и стало интересно сравнивать BTF.

Когда BPF-программа работает на одном ядре, но возникают проблемы на другом, хочется посмотреть, какие типы и смещения отличаются. CO-RE как раз использует BTF для адаптации обращений к структурам, но это не значит, что любые изменения layout автоматически ломают программу.

И наоборот: одинаковый layout ещё не гарантирует, что программа успешно загрузится.

Поэтому btf-layout-diff не проверяет совместимость CO-RE. Он не анализирует релокации из ELF, не отслеживает рекурсивно типы полей и ничего не знает о решениях verifier.

Задача гораздо проще: показать разницу между описаниями структур, чтобы не искать её вручную.

Что проверил?

Я добавил тесты на изменение размеров структур, смещений полей и bitfield. Отдельно проверил случай, когда меняются только type_id: ложных отличий в отчёте быть не должно.

Есть проверки неполной записи структуры и неоднозначных имён.

Локально собирал проект на macOS. В GitHub Actions сборка и тесты проходят на Linux и macOS.

Запустить можно из репозитория: sairex53/btf-layout-diff.

Пока следующий шаг — сравнить BTF двух реальных ядер, взять BPF-программу, которая обращается к изменившейся структуре, и посмотреть, как с этим работают её CO-RE-релокации.

Сейчас инструмент решает только первую часть задачи. Но для неё мне и хотелось иметь отдельный diff, а не разбирать два больших вывода bpftool вручную.

Пять уровней форматирования - и aiogram перестаёт отвечать

Наткнулся на issue #1925 в aiogram: после получения сообщения с rich_message бот перестал отвечать. Внутри JSON была цепочка форматирования:

spoiler → subscript → bold → italic → underline

На aiogram 3.31.0 вызов Update.model_validate(...) загружал одно ядро на 100% и блокировал event loop. Автор issue пишет, что бот простоял так около часа.

Захотелось разобраться, как несколько уровней форматирования вообще могли положить обработку обновлений.

Что происходило при валидации

За вложенный текст отвечает RichTextUnion - рекурсивный union из строк, списков и 26 моделей форматирования. У каждой модели есть поле text, которое снова может содержать RichTextUnion.

RichTextUnion = (    str    | list["RichTextUnion"]    | RichTextBold    | RichTextItalic    # ... ещё 24 модели
)

Поле type у моделей было, но для выбора ветки union оно не использовалось. Поэтому Pydantic пробовал разные варианты. При проверке неподходящей модели он мог снова перейти к вложенному text, а там - очередной union с теми же вариантами.

То есть проблема не в огромном размере JSON. Валидатор многократно проходил по вложенной структуре, и с каждым новым уровнем количество проверок быстро росло.

Что исправили

В PR #1934 добавили callable discriminator. Он выбирает ветку сразу: строку по "str", список по "list", модель - по её полю type.

Обычного Field(discriminator="type") здесь недостаточно: строки и списки поля type не имеют.

По замерам автора PR, валидация проблемного обновления сократилась с 5,4 секунды до 0,3 мс. Исправление влили 11 октября.

Проверил отдельно от aiogram

Собрал небольшой стенд: 26 упрощённых рекурсивных моделей, два варианта union — обычный и с дискриминатором.

На Python 3.14.8 и Pydantic 2.12.5 для глубины 4 получил:

• Обычный union - 195,061 мс

• С дискриминатором - 0,004 мс

Разница почти в 49 тысяч раз. Для варианта с дискриминатором проверил и глубину 100: 0,073 мс. Медленный вариант ограничил глубиной 4 - дальше выполнение становилось слишком долгим.

Бенчмарк использует прогрев и медиану пяти запусков. Есть четыре теста на вложенность и выбор моделей; в CI они запускаются на Python 3.10–3.13.

git clone https://github.com/sairex53/aiogram-rich-text-validation-lab
cd aiogram-rich-text-validation-lab
python -m pip install -r requirements.txt
python -m unittest -v
python benchmark.py

Это не воспроизведение исходного update: стенд не импортирует aiogram и не использует JSON из issue. Я сравнивал именно поведение Pydantic на похожей структуре типов.

Похожую проблему с RichBlockUnion в aiogram уже исправляли в PR #1845. А рекурсивный RichTextUnion тогда остался без дискриминатора.

Оказывается у callback_data надо считать байты, а не символы

В Telegram ограничение для callback_data - 1–64 байта. В Python len() считает символы. Для ASCII разницы нет, но для emoji и других многобайтных символов она быстро становится заметной:

prefix = "🐍" * 10
len(prefix)                 # 10
len(prefix.encode("utf-8")) # 40

В aiogram-tool 1.2.3 я нашёл расчёт длины служебного идентификатора для LongCallbackData. Он вычитал len(prefix) из лимита 64, то есть при emoji оставлял себе лишнее место. Дальше библиотека генерировала ID, который уже вместе с префиксами не помещался в лимит aiogram.

Минимальное воспроизведение — класс с prefix="🐍" * 10. В регрессионном тесте _UniqueIDCallbackData.build(Data).pack() на исходном коде падает с ValueError: Resulted callback data is too long. То есть длинный payload библиотека умеет убирать в storage, но даже короткая ссылка на него может не поместиться, если пользовательский prefix не ASCII.

Исправление — считать UTF-8 байты для каждого поля, участвующего в расчёте:

separators_len = len(cls.__separator__.encode("utf-8")) * len(cls.model_fields)
unique_id_len = (    64    - len(UNIQUE_PREFIX.encode("utf-8"))    - len(callback_data.__prefix__.encode("utf-8"))    - separators_len
) // 2

Проверка не ограничивается сравнением длины: тест строит длинный callback, проверяет, что результат укладывается в 64 байта, а затем прогоняет его через LongCallbackQueryFilter и проверяет восстановленные данные.

На исходной версии новый тест падает на сборке служебного ID. После патча два теста файла test_unique_id.py проходят (2 passed). Тест, патч и инструкция по воспроизведению лежат в репозитории: тест, патч, инструкция. PR в upstream пока не открывал.

Проверял на Linux, Python 3.12, aiogram 3.29.1. Это unit-тесты упаковки и распаковки; реальный callback в Telegram не отправлял.

Вышел gomponents 1.4.0 !

Gomponents - фреймворк, который позволяет описывать HTML-компоненты на чистом Go. Он генерирует HTML5 и позволяют легко создавать компоненты многократного использования. Благодаря этому вы можете сосредоточиться на разработке приложения, а не на изучении html.

Основная новика релиза - официальный навык (skill) для агента.

Пример работы с html в gomponents:

package main

import (
	. "maragu.dev/gomponents"
	. "maragu.dev/gomponents/components"
	. "maragu.dev/gomponents/html"
)

func Navbar(authenticated bool, currentPath string) Node {
	return Nav(
		NavbarLink("/", "Home", currentPath),
		NavbarLink("/about", "About", currentPath),
		If(authenticated, NavbarLink("/profile", "Profile", currentPath)),
	)
}

func NavbarLink(href, name, currentPath string) Node {
	return A(Href(href), Classes{"is-active": currentPath == href}, Text(name))
}

GitHub: https://github.com/maragudk/gomponents

ChangeLog: https://github.com/maragudk/gomponents/releases/tag/v1.4.0

Ошибка в on_error может остановить очередь сообщений бота

В очереди исходящих сообщений ошибка Telegram API - обычная ситуация: пользователь заблокировал бота, запрос оборвался, Telegram вернул временную ошибку. А что будет, если обработчик этой ошибки тоже выбросит исключение?

Я проверил этот сценарий в aiogram-dialog-yaml.

В очередь кладутся два сообщения. Первое падает при отправке. MessageQueue вызывает on_error, а тот, например, пишет в базу и сам падает из-за недоступной базы. Исключение выходит из worker-корутины. Второе сообщение остаётся в очереди, а queue.join() ждёт его бесконечно: рабочего, который мог бы его забрать, уже нет.

Это воспроизводится без токена и запросов к Telegram. Тест подменяет бота объектом, у которого отправка первого сообщения выбрасывает RuntimeError, и проверяет оба варианта on_error: обычную и async-функцию. На исходном коммите оба теста завершились TimeoutError на queue.join().

Исправление небольшое: ошибку самого callback логируем и продолжаем цикл очереди

try:    result = self._on_error(task, exc)    if inspect.isawaitable(result):        await result
except Exception:    log.exception(        "on_error callback failed for %s(chat_id=%s)",        task.method,        task.chat_id,    )

Здесь важно ловить Exception, а не BaseException: отмена worker-задачи через asyncio.CancelledError должна по-прежнему доходить до asyncio. И это не retry: неудачное сообщение не отправляется повторно. Изменение только не даёт сбою в обработчике ошибок уронить единственного worker’а и оставить остальные сообщения без обработки.

После патча регрессионный тест проходит, полный набор тестов проекта на Python 3.12 — 21 passed. Тест, патч и инструкция по воспроизведению лежат в репозитории: тест, патч, инструкция. Pull request автору проекта пока не отправлял.

Проверить можно на том же коммите: добавить test_error_handler_failure.py в tests/, применить queue.patch и запустить PYTHONPATH=src python -m pytest -q.

Это локальная проверка очереди с fake bot, не интеграционный тест Telegram API. Для production retry, backoff и dead-letter очередь всё равно надо проектировать отдельно.

В какой момент Telegram-бот имеет право сказать «задача отменена»?

Хочу разобрать мысленный эксперимент с Python + aiogram, PostgreSQL и несколькими воркерами. Бот собирает PDF. Пользователь может отменить работу и сразу запустить новую. Генерация долгая, сам файл отправляется через Telegram.

Неприятная гонка:

1. Воркер закончил PDF, проверил в базе: задача активна, версия диалога совпадает.

2. Начал отправлять документ. Сетевой запрос завис.

3. Пользователь нажал «Отменить». Бот записал отмену и ответил «Отменено».

4. Старый запрос завершился, PDF появился в чате уже после этого ответа.

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

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

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

Какой контракт вы бы выбрали для такого бота и как реализовали бы его при нескольких воркерах? Интересует конкретный порядок действий при отмене, отправке и перезапуске процесса. И тест, который воспроизводит именно эту гонку, а не просто проверяет флаг cancelled.

Если уж делать своего агента, то почему бы не такого?

За прошедшую неделю на Бирже заказов Инфостарта появились новые задачи для разработчиков, консультантов и DevOps-специалистов 1С. Заказчикам нужны специалисты по ЗУП, Комплексной автоматизации, ERP, Рознице, Бухгалтерии, мобильной платформе и организации процессов разработки.

• Создать внешнюю обработку для 1С:ЗУП

• Доработать «Личную карточку учета выдачи средств индивидуальной защиты» для Комплексной автоматизации

• Доработать механизм ERP для распределения денежных средств по объектам расчетов

• Объяснить вопросы по работе в 1С:Рознице

• Внедрить GitLab CI/CD, EDT и SonarQube для разработки в 1С

• Адаптировать заявки на финансирование в БП 3.0 для мобильного приложения «1С:Бухгалтерия»

Биржа заказов Инфостарта помогает найти исполнителя для задач по 1С: консультаций, доработок, интеграций, настройки обменов, переноса данных и сопровождения проектов.

Как выбрать только нужные колонки по шаблону, не перечисляя их в SELECT

В прошлом посте я рассказывал про модификатор APPLY, с помощью которого можно применять функцию ко всем колонкам сразу. Сегодня расскажу про еще один мощный инструмент — динамический выбор столбцов с помощью выражения COLUMNS.

Иногда бывают ситуации, когда в таблице десятки или сотни полей, а нам нужны только те, которые, например, начинаются с utm_ или содержат в названии слово id.

В классических базах данных мы бы сидели и вручную перечисляли названия всех нужных колонок в SELECT. В ClickHouse это делается гораздо изящнее.

Чтобы не писать десятки колонок руками, можно использовать выражение COLUMNS('regexp'). Оно автоматически находит и подставляет в выборку все столбцы, названия которых подходят под регулярное выражение.

В качестве примера рассмотрим таблицу traffic, в которой хранятся метки рекламных кампаний и метрики:

┌─utm_source─┬─utm_medium─┬─utm_campaign─┬─clicks─┬─costs─┐
│     google │        cpc │      promo_1 │    150 │    10 │
│     yandex │        cpc │      promo_2 │    200 │    15 │
└────────────┴────────────┴──────────────┴────────┴───────┘

Чтобы выбрать только utm-метки, обычно мы привыкли писать так:

SELECT 
  utm_source, 
  utm_medium, 
  utm_campaign 
FROM traffic

С использованием COLUMNS можно написать гораздо короче:

SELECT COLUMNS('utm') 
FROM traffic

┌─utm_source─┬─utm_medium─┬─utm_campaign─┐
│     google │        cpc │      promo_1 │
│     yandex │        cpc │      promo_2 │
└────────────┴────────────┴──────────────┘

Несколько нюансов:

1. Внутри скобок пишется регулярное выражение (синтаксис re2). Например, COLUMNS('a') выберет все колонки, в названии которых есть хотя бы одна буква «a».

2. Выбранные столбцы возвращаются в том порядке, в котором лежат в таблице (а не по алфавиту).

3. Если регулярному выражению не соответствует ни один столбец, и кроме COLUMNS в SELECT больше ничего нет — ClickHouse выдаст ошибку.

Ссылка на доку.

Мои статьи по ClickHouse на Хабре.

P.S. Систематизировать знания и получить крепкую базу можно на моем бесплатном курсе «ClickHouse с нуля». А закрепить пройденный материал на его практическом продолжении «ClickHouse с нуля: практика».

Как относитесь к разрабам, которые постоянно пилят что-то своё (это я)?

Пугает ли вас данный факт, несет ли угрозу вашему бизнесу?

NanoMuse 

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

Это важный сдвиг в восприятии подобных решений. Закрытый SaaS обычно предлагает набор функций, а open-source-репозиторий позволяет отдельно посмотреть на архитектурные решения, ограничения и границы применимости. NanoMuse не обязательно воспринимать как универсальную замену существующим инструментам. Скорее, это практический материал для тех, кто хочет разобраться, как могут быть устроены кросс-девайсные AI-агенты.

Что здесь представляет интерес

У агента, который работает с телефоном и компьютером, есть несколько связанных задач:

• взаимодействовать с интерфейсами разных устройств;

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

• выполнять действия в соответствии с поставленной целью;

• сохранять понятные границы ответственности и контроля.

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

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

Как подходить к проверке

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

Перед запуском стоит отдельно ответить на несколько вопросов:

1. Какие права нужны агенту на телефоне и компьютере?

2. Какие данные передаются между устройствами и где они хранятся?

3. Можно ли ограничить набор доступных действий?

4. Как остановить выполнение сценария и вернуть систему в безопасное состояние?

5. Какие операции требуют обязательного подтверждения человека?

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

Кому стоит изучить репозиторий

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

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

Итог

NanoMuse стоит рассматривать не как универсальный SaaS с заранее заданным способом работы, а как открытый пример кросс-девайсного AI-агента. Его ценность — в возможности изучить идею на практике, развернуть проект в контролируемом окружении и адаптировать его под собственные сценарии автоматизации.

Главный интерес здесь не только в количестве функций, а в инженерных вопросах вокруг них: как передаётся контекст, как агент взаимодействует с разными интерфейсами и как сохранить контроль над действиями системы. Именно с этих вопросов стоит начинать оценку проекта.

Ссылки

• NanoMuse на GitHub — исходный код и материалы проекта.

Как попасть в бигтех в 2026 году?

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

Во втором выпуске подкаста «Бэкенд расправил плечи» Коля Губин и Паша Агалецкий разбираются, как сегодня устроен найм в бигтехе. Чтобы взглянуть на вопрос не только глазами кандидата, но и глазами работодателя, приглашённой гостьей выпуска стала Валерия Ильницкая, руководитель группы по подбору персонала Авито.

В выпуске обсудили:

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

Cмотрите и слушайте на площадках:
🔵 VK Видео 
📺 YouTube
📌 RuTube
Ⓜ️ Mave

Как перейти от хаотичной генерации кода к детерминированному конвейеру? Узнаете на GoCloud Tech 2026

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

На докладе команда стриминга КИОН поделится своим опытом по переходу к Spec-Driven Development в условиях кроссплатформенного монолита. Разберут, как ограничения ИИ-моделей влияют на автоматизацию рефакторинга, и покажут механизмы slice-изоляции контекста монорепозитория. Отдельное внимание уделят управлению дельтой изменений через неизменяемые спецификации и RFC-патчи, решению дедлоков ИИ-агентов при параллельной работе и организации конкурентного доступа к Gradle-процессам. Продемонстрируют практические результаты миграции DI-слоя Kotlin Multiplatform-приложения и метрики снижения затрат на API-запросы к LLM.

Спикер:
Сергей Лодинев — старший разработчик, МТС Web Services КИОН.

Трек: Разработка

📅 Когда: 15 октября в 13:00–13:40 мск