Как я собрал мультиканального voice-бота на Spring Boot, который объединяет Discord, Telegram и веб-панель в одной системе.
Разбираю архитектуру, работу с голосом (TTS, запись каналов), интеграцию JDA + LavaPlayer и реальные проблемы продакшена — от memory leaks до ограничений Telegram API.
LangChain обещает: переключите модель одной строкой, подключите RAG за две. У меня в production мультиагентная система с RAG, CRM и тремя мессенджерами — и я построил её без LangChain. Под катом — почему абстракции ломаются, сколько стоит фоллбек на YandexGPT и при чём тут медведь с удочкой.
На GitHub лежат сотни AI-скиллов. Скилл для code review, скилл для дебага, скилл для обработки PDF, скилл для анализа безопасности. Установил в Cursor или Claude Code — и твой AI-ассистент стал умнее. Звучит как npm install: поставил пакет, он работает.
Но скилл — не пакет. Это текстовый файл с инструкциями, который читает языковая модель. А модели читают по-разному.
Представьте: вы написали подробное ТЗ и отдали его четырём специалистам. Все четверо — профессионалы, все мотивированы, все прочитали ТЗ целиком. Результат будет разный. Каждый делает как его учили, как привык, какой опыт накопил. И всегда есть шанс, что кто-то начнёт не с того конца или вообще решит ответить устно вместо того, чтобы сделать.
Модель = работник. Скилл = ТЗ. Я взял одно ТЗ, отдал четырём работникам, и каждый выполнял его 120 раз. Вот что получилось.
Забегая вперёд: скиллы работают. Но не так, как обещают. И самый интересный результат оказался не там, где я ожидал.
Есть такой момент, знакомый каждому, кто долго работает в паре с AI. Сидишь в терминале, Claude генерит код, ты ревьюишь, правишь курс, снова запускаешь. Проходит пара часов, и ты понимаешь: никто не записал, что вообще произошло.
Ни один тикет не обновлен. Таймер не запущен. Чат на тысячу строк, но он испарится, как только закроешь сессию. А когда коллега спросит, что было сделано за день, ты будешь восстанавливать картину по памяти. Удачи.
Меня это достало. Заканчиваю марафон-сессию с Claude или Codex, ощущение, что гора работы сделана, а доска проекта все так же показывает Not Started. Тайм-трекинг? Какой тайм-трекинг. Разрыв между реальной работой и тем, как выглядит проект, стал просто нелепым.
Недавно я обнаружил, что далеко не все знают об одной простой вещи — и это меня удивило.
Многие думают примерно так: «я описал интерфейс, указал что GET /users возвращает User[], TypeScript подсвечивает все поля, автодополнение работает — значит всё под контролем». Звучит разумно. Но есть одна проблема.
TypeScript работает только во время компиляции. В рантайме его нет.
Когда реальный ответ прилетает с сервера — никакой проверки не происходит. TypeScript просто верит вашей аннотации и молчит. Что реально вернул сервер — string вместо number, переименованное поле, отсутствующий объект — он не знает и знать не будет.
Вы узнаете об этом позже. Обычно от пользователей.
Я всю жизнь писал только бэк и подкапотщину - будь это классический КРУД, хайлоад, CLI, [вставьте свое]... И для любых сетевых взаимодействий чаще всего люди думают именно прикладными вещами - GRPC, REST, Kafka, не задумываясь об этом глубже - супер удобные инструменты с защитами от дураков и прочими радостями
Но тут спохватился я писать фронт - подключать свое же к себе же. И в этот момент я понял, насколько же это сложно, муторно и, главное, НЕУДОБНО взаимодействовать REST'ом
ЗАЧЕМ ОН НУЖЕН?? - У нас нет удобного контракта общения (eg Proto, Avro) кроме Swagger, который нужно поддерживать с обеих сторон. Да и к тому-же, сложность взаимодействия с JSONом с ОБЕИХ СТОРОН - одна постоянно маршаллит, защищается, ищет поля, в то время другая боится резких обновлений, что строчка получения поля может превратиться в что-то в роде
Во второй части мы сделали консольный чат с циклом и system prompt. Но у него был пробел: каждый запрос шёл к модели независимо, без контекста предыдущих реплик. В третьей части добавляем историю сообщений — и чат наконец начинает помнить разговор.
Когда в FastAPI-проекте появляется нормальная авторизация, код быстро начинает расползаться в стороны.
Сначала все выглядит терпимо: один Depends(get_current_user), один Depends(get_enforcer), одна ручная проверка. Потом роутов становится больше, правил доступа становится больше, и внезапно половина endpoint’ов начинает содержать не бизнес-логику, а обвязку вокруг нее.
В какой-то момент меня перестал устраивать и классический подход через dependency injection в каждом роуте, и вариант с middleware. Хотелось, чтобы правило доступа было видно прямо рядом с маршрутом, но при этом не приходилось таскать авторизацию в сигнатуры всех функций.
В итоге я собрал casbin-fastapi-decorator — тонкий слой над Casbin для FastAPI, который позволяет описывать authorization через декораторы.
Идея простая:
Всем привет!
Если вы хоть раз пытались нормально вкатиться в разработку Telegram-ботов, то почти наверняка сталкивались с одной проблемой: информации в интернете много, но она какая-то рваная. То есть где-то вам сразу дают библиотеку, заставляя писать код и даже не объяснив, как бот вообще работает.
В особых сценариях (например разработка userbot) смешивают воедино Telegram Bot API, Telegram API (да, это разные вещи!), api_id, api_hash, token, chat_id, webhook и еще десяток терминов.
А где-то вообще показывают “hello world”, который фактически-то работает, но только ты ступишь на шаг вперед, так всё начинает разваливаться, ведь понимания практически 0.
В этой статье моя цель - разобрать всё это нормально и по-человечески, объяснив как использовать Telegram Bot API для создания ботов.
Сейчас многие компании внедряют ИИ-агентов в свои процессы. И сталкиваются с проблемами. Классический пример: ИИ-агент по продажам самостоятельно пообещал клиенту скидку 50% на которую ему никто не давал разрешения. Явный провал разработчиков ИИ-агентов, хотя на прошлой неделе в демо всё работало идеально.
Мир явно разделился: одни говорят, что агенты готовы к продакшену, другие кричат что это не работает и работать не будет. Энтузиасты показывают впечатляющие демо. Чистые данные, правильные API, никаких сюрпризов. Но продакшен это другой зверь. Отчёт MIT показал, что 95% пилотов генеративного ИИ не достигают ожидаемых результатов. Модели не тупые. Инфраструктура вокруг них не готова.
Я это понял на собственном опыте, строя своего агента на базе OpenClaw, который отчитывается мне ежедневно в Telegram. Все здесь крайне интересно, но реальные области использования нащупать сложно.
Два месяца назад я выложил первую версию MCP для КОМПАС-3D. Реакция была предсказуемая: “круто для демо, но в реальной работе не взлетит”. Тогда они были правы.
Сейчас агент получает задачу, строит 3D-деталь, добавляет отверстия, проверяет дерево построения, сохраняет документ и возвращает скриншот. Сам.
Более того, теперь ИИ забирает на себя не только объемную геометрию, но и плоскую документальную рутину. Ему можно делегировать создание чертежа, автоматическое заполнение штампа и экспорт результата в DXF одним запросом.
Ключевое изменение здесь в том, что агент теперь держит в голове состояние модели на каждом шаге. Он понимает в каком документе находится, на какой стадии построения работает, какую грань или какой feature нужно взять в следующей операции, что именно изменилось после команды и какие свойства получились у детали в итоге.
Например:
Можно взять уже открытую деталь, спросить у неё текущее состояние через get_3d_context и узнать, что базовое тело уже создано, а в дереве висит 11 элементов. Агенту не нужно угадывать или строить всё с нуля - он понимает, на каком этапе находится модель, и сразу переходит к следующим шагам.
Можно не высчитывать координаты плоскостей вручную. Инструмент resolve_selection_3d по описанию сам находит нужную грань (например, «верхняя плоская») и возвращает её системный идентификатор. Агент просто берёт эту ссылку, ставит на неё новый эскиз и делает вырез точно там, где нужно.
Можно убедиться, что команды не просто улетели в пустоту, а реально сработали. Тул list_feature_tree_3d отдаёт агенту список шагов: базовый эскиз, выдавливание, вырез, отверстие, фаска. То есть ИИ доводит деталь до конкретной истории построения, которую вы потом можете открыть руками и проверить.
Недавно ходил в кино и, пока стоял в очереди на вход, поймал себя на мысли, что проектирую систему, которой пользуется контролер. На первый взгляд задача примитивная: есть база билетов, контролер сканирует QR, система должна проверить билет и пустить человека. Главное условие - один билет используется ровно один раз.
Я прикинул, и понял, что проблем там гораздо больше, чем кажется ..
Новая сертификация партнеров-разработчиков на Claude от Anthropic (Claude Certified Architect) не просто корпоративная бюрократия, а задокументированный чеклист современного вайб-кодера.
12 марта 2026 года Anthropic запустила свою первую техническую сертификацию — Claude Certified Architect, Foundations. Формально - это часть партнёрской программы на $100 млн. Фактически — публичный чеклист того, что теперь считается базовой грамотностью в работе с ИИ.
Когда команда пишет API, но документация живёт своей жизнью, а интеграторы часами гадают, что значит ошибка 500, — проект неизбежно тонет в хаосе. В этой описан подход, который является лучшим решением: Design‑First на основе OpenAPI.
Мы пройдём полный цикл: от проектирования спецификации до работающего Spring‑приложения с автоматической генерацией кода и централизованной обработкой ошибок.
Вы узнаете, как одна команда ./gradlew clean build может создать модели и интерфейсы, избавив вас от рутины.
Я периодически провожу технические интервью и смотрю pet-проекты кандидатов.
И почти всегда вижу одну и ту же картину:
Используется localStorage или заглушки вроде jsonplaceholder.
Я прекрасно понимаю, почему так происходит:
Открыл Postman, потыкал эндпоинты, всё ответило 200 — вряд-ли хорошее тестирование Разбираю что на самом деле нужно проверять в API, показываю примеры на Postman и Jest, и даю чеклист который можно взять и использовать прямо сейчас.
40 000+ записей без пагинации, 200 OK вместо 400 Bad Request, SQL-запросы в ответах клиенту. Собрал 10 ошибок API из реальных проектов: монолитов, микросервисов, стартапах и энтерпрайза.
Классические шины — это блокер цифровой трансформации, а не её энейблер. Рост числа сервисов, переход к микросервисной архитектуре и необходимость быстрой адаптации требуют большей гибкости и новых подходов к интеграции. Теперь связывать цифровые системы между собой необходимо в условиях постоянного роста объёма данных.
Из статьи вы узнаете, почему мы в MWS отказались от классических интеграционных шин, что выбрали взамен и как здесь используется ИИ.
Привет Хабр!
Меня зовут Дмитрий Гаврин, я заместитель директора департамента «Цифровые решения» компании «Диасофт». Есть тип совещаний, которые я узнаю с первой секунды по интонации приглашения. Когда директор проекта пишет «зайди, поговорим по цифрам» - это не про то, что кто-то перевыполнил план. Это про интеграцию. Почти всегда про нее.
Делаем из простого скрипта настоящий консольный чат: цикл общения, system prompt, обработка ошибок и первые шаги к “живому” AI-приложению на Python с Ollama и LiteLLM.
