Открыть код — не значит запустить open source. В статье разберём пять ошибок, из‑за которых корпоративные open‑source‑проекты быстро теряют контрибьюторов, комьюнити и DevRel‑эффект.
Последние полгода я почти не пишу код руками. Вместо этого я проектирую инженерную систему, в которой AI пишет код, а Git, тесты, CI, агенты и правила не позволяют ему принимать неправильные решения.
В статье расскажу, как устроен этот процесс и почему, на мой взгляд, именно такой подход делает AI пригодным для реальной разработки.
Мы делаем proxykey — credential proxy: настоящие API-ключи лежат у нас зашифрованными, а приложения и ИИ-агенты ходят с отзываемыми виртуальными токенами. Недавно мы писали здесь про саму схему. Под ней и в личках всплыл один и тот же вопрос — самый правильный вопрос к любому такому сервису:
«А вы сами можете прочитать мои ключи?»
Короткий честный ответ: технически — да. И вместо того чтобы прятать это в маркетинговый туман, мы сделали две вещи: опубликовали крипто-модуль целиком и написали страницу с моделью угроз, где этот пункт стоит первым и жирным. Этот пост — о том, почему так, и что именно мы открыли.
Как хранить генеалогическое дерево у себя, подключить к нему ИИ-агента и что из этого получается на практике.
Проект: gramps-web-mcp-rs
Я давно хотел убрать из backend‑разработки одну особенно липкую рутину: когда для каждой новой сущности снова и снова приходится собирать одни и те же слои REST API — repository, service, handlers, request/response модели, OpenAPI, auth, тесты, curl‑примеры, Docker и прочую инфраструктуру.
В этой статье рассказываю про query‑first подход и open‑source Go CLI rest, который позволяет реализовать эту идею. Смысл простой: если SQL‑запросы или MongoDB‑контракты уже описывают, какие операции нужны приложению, то из них можно сгенерировать согласованный каркас REST‑сервиса.
В статье показано, как это работает для PostgreSQL и MongoDB, что именно генерируется, что такоеrest doctor и почему цель инструмента — не заменить бизнес‑логику, а снять первые 80–90% повторяющейся ручной работы.
После рабочих встреч часто остаются записи. В моем случае это записи Яндекс Телемоста.
Запись есть, но пользоваться ей не всегда удобно. Если нужно что‑то вспомнить, приходится открывать видео, перематывать, искать нужный кусок, переслушивать. Если нужно передать встречу другому человеку, одного видео обычно мало.
У меня часто бывает такой сценарий: нужно передать программисту контекст по задаче. Можно скинуть запись встречи и написать: «посмотри, пожалуйста». Но человеку придется самому смотреть видео, искать важные места, понимать, где обсуждение, где решение, где задача.
Мне хотелось получить более удобный вариант: вместе с записью отправлять текстовый итог встречи.
Идея была простая: загрузить видео встречи и получить транскрипт, протокол и DOCX, который можно отправить дальше.
Первую рабочую версию получилось собрать через Codex примерно за 30 минут.
Салют, Хабр!
Сегодня мы выкладываем в open source GigaChat 3.5 Ultra — нашу новую 432B-модель. В этом релизе мы впервые для нашей линейки масштабировали собственную гибридную архитектуру на сотни миллиардов параметров, ускорили инференс и усилили модель в коде, агентных сценариях и сложных областях.
GigaChat 3.5 Ultra компактнее прошлого флагмана: 432 млрд параметров вместо 700 млрд у GigaChat 3.1 Ultra. Но это не компромисс «меньше, зато дешевле»: за счёт новых данных, обновлённого рецепта обучения и архитектурных изменений модель стала сильнее, а также эффективнее по памяти и скорости генерации.
Интересно? Добро пожаловать под кат.
Как работает ядро Joomla 6 на уровне Приложения (Application)? Сколько видов Приложений на самом деле есть в Joomla и в чём между ними разница? Какой жизненный цикл каждого Приложения Joomla, включая роутинг, диспетчеризацию и события плагинов? На эти и другие вопросы попытается дать ответ эта статья, опирающаяся на кодовую базу Joomla 6.1.0. Также в статье хронология вызова триггеров плагинов в разных сценариях.
👉 Бонус для любопытных читателей: а вы знали, что Joomla можно использовать в качестве daemon-процесса?
Идея этого проекта появилась после обсуждения с коллегой устройств, которые могли бы автоматически регулировать яркость мониторов по окружающему свету. Картина была довольно унылая: встроенные решения обычно встречаются в дорогих моделях мониторов, отдельных внешних устройств на рынке почти нет, а то, что есть, либо стоит слишком дорого, либо недоступно, либо просто выглядит не очень.
После этого разговора я решила сделать такое устройство для себя из подручных средств — у меня была простая плата esp32c3 и фоторезистор ky018. Я хотела получить быстрое и простое решение, потому что сама задача довольно тривиальна, а для меня она при этом решала вполне реальную проблему: постоянное напряжение глаз из‑за изменения освещения в течение дня.
MCP упростил жизнь разработчикам: теперь у AI-агентов есть единый способ подключаться к инструментам и сервисам.
Но у этой стандартизации есть обратная сторона — каждый MCP-сервер становится новой точкой доверия и потенциальной атакующей поверхностью.
В статье разбираю:
-почему у LLM нет чёткой границы между данными и инструкциями -как tool poisoning, indirect prompt injection и sampling abuse работают на уровне MCP -почему даже “безобидные” документы и описания инструментов могут приводить к выполнению команд -какие реальные атаки уже зафиксированы в экосистеме MCP
как индустрия пытается закрыть это через gateways, sandboxing и OAuth-архитектуры
Также показываю практическую проверку на уязвимом MCP-стенде и результаты детекции вызовов инструментов на своем сканере BarkingDog.
Давно ничего не писал где-либо: разработка занимает много времени. Надеюсь, наш путь будет кому-либо полезен, особенно тем, кто обучает модельки на малоресурсных языках.
Большая в данном контексте - это условно. По сути, взяли Qwen3-4B-Instruct-2507 и обучили на карачаево-балкарском языке (тюркский, половецко-кыпчакская группа). По дороге пришлось написать собственный морфологический процессор для аугментации диалектов, обучить токенизатор с нуля, и найти баланс в обучении модели на сырых данных, чтобы она не забывала инструкций (а хотелось, чтобы могла отвечать).
Модель лежит на HuggingFace: TSjB/QM-4B. Работу представляли на конференции TurkLang 2026
Ghidra — это фреймворк для реверс-инжиниринга, который создан и поддерживается АНБ.
Как выяснилось, агенты эффективно применяют Ghidra через MCP-сервер GhidraMCP, а с декомпилятором Radare2 это позволяет находить закладки в бинарных файлах почти в автоматическом режиме.
В бенчмарках Claude Opus 4.6 нашёл 49% бэкдоров, Gemini 3 Pro — 44%, а Claude Opus 4.5 — 37%.
DeepSeek выпустил DSpark — спекулятивный декодер для V4. В окне 27–30 июня 2026 рабочего публичного пути для GB10 не было — мы портировали его сами, нашли унаследованный баг, убивавший качество драфта, и сняли профиль своего стенда. Потом комьюнити выложило рецепт вдвое быстрее нашего. Мы его воспроизвели — и вместо гонки за цифрой сняли данные, которых в паблике не нашли: кривую деградации до реального 1M, механизм выигрыша NVFP4 и петли когерентности на глубине. Плюс три негативных результата.
Обычно процесс разработки API выглядит так: мы пишем контроллер. Затем каким-то образом его документируем. После чего фронтер, опираясь на такую документацию, пишет клиент.
Мы делаем одну и ту же работу трижды.
В прошлой статье я рассказывал, как избавиться от первого дублирования. С помощью бандла sunrise-studio/symfony-openapi можно генерировать OpenAPI-документ из кода, минуя процесс документирования.
Но это решает проблему только наполовину. Если OpenAPI-документ вытекает из кода, то клиент должен вытекать из OpenAPI-документа. Иначе написание клиента – и есть то самое дублирование.
В этой статье я расскажу как замкнуть цепочку:
Controller → OpenAPI → Client → Feature
Где каждый последующий шаг вытекает из предыдущего, а не дублирует его.
Как разработчик, я должен пользоваться ИИ на работе. Я бы, конечно, предпочел безлимитный Claude, но мне доступен только Qwen Code, а он часто галлюцинирует. В этой статье я расскажу, как искал причины галлюцинаций, устранял их и к чему это привело.
Первая моя задача для ИИ-помощника – CLI-агента, была простой, её можно было бы решить инструментом «найти и заменить» в IDE минут за 20, а агент трудился – часа два, что непозволительно много. Он постоянно галлюцинировал, добавлял ненужные артефакты, а я продолжал попытки направить его в нужное русло уже из спортивного интереса. Только после этого замечательного опыта я наконец решил «прочитать инструкцию»...
Я хотел использовать Claude прямо в мессенджере MAX — без браузера, без переключения контекста. Готового решения не было. Нашёл на GitHub китайский проект cc-connect — Go-фреймворк с plugin-архитектурой для подключения AI-агентов к мессенджерам. Telegram, Feishu, Discord там были. MAX — нет.
Написал адаптер, открыл PR. Приняли. Теперь поддержка MAX — часть основного репозитория.
Что такое cc-connect
cc-connect — Go-фреймворк с чёткой трёхслойной архитектурой:
Привет, Хабр! Меня зовут Артур Валиев. Я продолжаю делать свой VST3-плагин Mix Teacher AI.
В прошлый раз я рассказывал про идею плагина: поставить его на дорожку, посмотреть уровни, пики, RMS, примерный LUFS, частотные зоны и получить простую подсказку человеческим языком.
Но довольно быстро стало понятно, что анализировать только одну дорожку мало.
Потому что в сведении часто проблема не в одной дорожке.
Кик сам по себе нормальный.
Бас сам по себе нормальный.
Вокал сам по себе нормальный.
Барабаны вроде тоже нормальные.
А вместе всё почему-то не звучит.
И вот тут начинается самая интересная часть: конфликты между дорожками.
TL;DR. Из интереса обучил собственный русский RAG‑сплиттер — захотелось проверить, можно ли сделать context‑aware‑нарезку русских документов лучше готовых чанкеров.
Я взял идею датской context-aware-splitter, пересобрал её под русский на базе T-lite-it-2.1 и изменил главное: модель возвращает индексы границ, а не переписанный текст. Хост потом режет оригинал по этим индексам.
У index‑output оказалось три практических плюса:
После появления ChatGPT и массового распространения GitHub Copilot, Cursor, Claude Code, Windsurf и других AI-инструментов разработка стала заметно быстрее. Код, тесты, README, комментарии и небольшие utility-функции теперь можно получить за секунды.
Но вместе с этим появился менее очевидный вопрос: если миллионы разработчиков используют похожие модели и похожие промпты, не становится ли открытый код более однообразным?
В этой статье я проверяю эту гипотезу на данных GitHub за 2019-2025 годы: через GH Archive, BigQuery, commit messages, README, имена функций и собственный GitHub Uniformity Index.
Привет! Началось всё с дурацкого вопроса. Я который месяц живу в Claude Code — ставлю задачи, ругаюсь, прошу переделать, снова ругаюсь. И тут до меня дошло: каждая моя реплика лежит на диске. Вообще каждая. Каждое «сделай», каждое «проверь», каждый капс в три часа ночи — всё это тихо копится в JSONL‑файлах в домашней папке. У меня таких логов набралось на 200 тысяч слов за полтора месяца. Это, на минуточку, две «Мастер и Маргариты».
И вот сижу я, смотрю на эту гору данных и думаю — а как я вообще выгляжу со стороны машины? Не «хороший я или плохой», а буквально: какими словами командую, в котором часу наиболее опасен, сколько раз прервал модель на полуслове. Досье же готовое. Осталось его вскрыть.
Так за сутки диалога родился Prompt Warrior — опенсорсный скилл для Claude Code и других харнесов, который превращает локальные логи сессий в геймифицированный психологический портрет: титул, уровень, 74 ачивки с редкостями как в Стиме, шесть шкал характера и биография, которую пишет сама нейросеть.
