При разработке ИИ-агента для базы знаний, мне казалось, что задача почти типовая: складываем информацию в Qdrant, находим информацию через векторный поиск и поиск в интернете и формируем красивый ответ через LLM. На деле ИИ-агент начал уверенно галлюцинировать, приносить не только нерелевантные ответы, но и тупить с короткими пользовательскими запросами. И самое неприятное, при всем при этом метрика «похожести» similarity выглядела достаточно высокой, что сильно вводило в заблуждение.

После серии экспериментов и улучшений пришло понимание, что промышленный ИИ-агент — это не столько про LLM, сколько про качество извлечения информации и гибкую оркестрацию компонентов ИИ-агента. Что в итоге полностью поменяло архитектуру моей системы.

В статье расскажу, как я пришла от «просто добавь LLM» к промышленному графовому ИИ-агенту на LangGraph + Qdrant.

Ваш AI‑чат или автокомплит тормозит при 50 запросах в секунду? Монолит убивает GPU и латенси?

В этом туториале — реальная архитектура low‑latency инференса на high‑load: почему изолированный inference‑bundle вместо монолита, как выбрать между vLLM и SGLang без маркетинга, зачем нужны continuous batching и admission control.

Мы все привыкли строить производство софта как конвейер. Продакт берёт идею, отдаёт аналитику. Аналитик пишет требования, отдаёт разработчику. Разработчик пишет код, отдаёт QA. QA проверяет, отдаёт DevOps. DevOps выкатывает в прод.

Каждый знает свой участок. Каждый передаёт результат дальше. Лента сама довозит результат до пользователя.

Так работало 30 лет. И вот в каждый из этих участков пришёл AI-агент. И конвейер начал барахлить.

async fn в Rust — это не магия и не зелёный поток, а обычный enum, который компилятор генерирует за тебя. Разбираем, почему Future это машина состояний, зачем нужен Pin, как работает Waker и executor, и как одна .await-точка может незаметно заставить твой сервис есть память гигабайтами.

Привет, Хабр!

Примерно год назад наша команда загорелась идеей создать продукт, который позволил бы «поговорить с кодом». Мы, как и многие, находились под впечатлением от возможностей LLM. Казалось, что ещё немного – и нейросеть возьмёт на себя всю рутину по анализу легаси, аудиту систем и онбордингу новых разработчиков.

Мы представляли себе идеальную картинку: загружаем исходники, документацию, ТЗ в модель, нажимаем кнопку и на выходе получаем JSON с описанием архитектуры, связей, интеграций и методов. Вишенкой на торте должен был стать умный чат, в котором можно спросить что-то вроде «как у нас реализованы выплаты по убыткам?» и почти мгновенно получить ответ.

В начале пути всё это выглядело довольно прямолинейно. LLM же обучены на массе источников в интернете, умеют читать код, у нас есть фреймворки для аудита. Казалось, напишем крутой промпт, загрузим его в модель и будем пожинать плоды.

Но не тут-то было. Идея разбилась о суровую реальность enterprise-разработки. За несколько месяцев мы собрали коллекцию из 12 ошибок, которые едва не похоронили наш проект Code Scope (именно так мы назвали решение). Сегодня расскажу о пяти, на мой взгляд, самых показательных. Спойлер: в итоге наш код на 99% состоит из «инженерии», и только 1% – это тексты промптов.

Ошибка 1: Один запрос обо всём

Мы начали красиво. Взяли внутреннюю систему, написали «классный» промпт и попросили LLM вернуть все возможные факты о коде в виде структурированного JSON-объекта: описание методов, интеграции, точки входа, расчёт метрик и так далее. 

Описываю методологию разработки эффективных чат-бот промптов, направленных на оптимизацию рутинных процессов.

Показываю на практике философию пошагового решения задач с помощью нейросетей. Указываю на необходимость контролировать контекст работы ИИ.

Показываю весь цикл разработки промпта. Даю промпты для создания промптов.

У меня на столе стоит небольшая золотистая коробочка размером чуть больше Mac mini. Внутри — приватный AI-сервер: чат с локальной 26B-моделью, поисковая индексация моих документов с GPU-парсингом, конструктор агентов в Dify, RAGFlow для тяжёлого парсинга PDF, мониторинг, бэкапы, опциональный кластер из двух машин по QSFP 200G. Тридцать контейнеров, пять минут на установку через sudo bash install.sh, ноль обращений к внешним API.

Я делал это не как pet-project, а под себя — мне нужна была машина для работы с корпоративными документами, договорами и регламентами, которые ни при каких условиях нельзя отдавать в облачные ассистенты. Сборка получилась самостоятельным дистрибутивом — назвал его AGmind, выложил на GitHub под Apache 2.0.

В статье разберу:

— из чего собран стек и зачем там каждый компонент; — почему RAGFlow пришлось пересобрать с нуля и что я туда добавил; — как устроен кластер из двух Spark'ов; — пять конкретных грабель GB10, которые я ловил вечерами; — почему Claude Code за месяц превратил один из этих компонентов в работающий продукт, но при этом не заменил собственно программиста.

Всё больше выходит больших MoE моделей с малым числом активных параметров. У MoE совсем другой сценарий нагрузки и использования ресурсов нежели у Dense моделей, достаточно немного VRAM. Большие MoE модели устроит 1 GPU и много обычной RAM. О том, как устроены MoE и как ускорить работу одним параметром не меняя железо.

Самый просто способ запустить локальную LLM - это установить ollama или LM Studio. Это быстро и просто, но вы теряете и в скорости, и в качестве. Почему UD_Q4_K_XL лучше при том же размере, почему квант Q3 может быть медленнее чем Q4. Хорошая ли идея взять REAP для вырезания ненужных экспертов из MoE. Кто быстрее, Linux или Windows. В общем как выжать больше из локальных LLM на домашнем железе.

Как клонировать экспертизу человека, на которого у тебя нет бюджета? Я взял двухчасовой разговор с топовым маркетологом, прогнал транскрипт через промпты, построенные на научных методах извлечения знаний — CogKC, Knowledge Graph, поведенческое клонирование — и получил JSON-файл, который отвечает на вопросы почти как она.
Сначала проверил на себе: файл с «душой» выглядел банально, но агент на его основе пугающе точно воспроизводил мою логику решений. Внутри — наука, два эксперимента, этика и готовые промпты.

Ваша LLM галлюцинирует? Наденьте на неё экзоскелет — и заставьте работать по правилам

Тесты на Qwen и DeepSeek показали: одна системная инструкция превращает модель из «уверенного вруна» в инструмент, которому можно доверять.

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

Привет. Меня зовут Вадим, в разработке очень давно — поучаствовал во всём чём можно: стартапы, продуктовые команды, инфра, питчи, продажи. Последнее время плотно живу в терминальных AI-агентах: Claude, Codex, и всё что появляется каждую неделю.

В какой-то момент заметил — инструменты стали умнее, а способ работы с ними остался прежним. Поставил Claude Code — дал полный доступ и молишься что не сломает систему. Не дал — натыкиваешь права руками, половина функций не работает. Хочешь нормальную изоляцию — нужны контейнеры или VM, к ним надо подключаться, пробрасывать порты, SSH-сессии, всё это руками.

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

Когда 4 машины, 12 сессий и половина из них — AI-агенты которые что-то пилят в фоне, есть ощущение что что-то пошло не так. Нужна штука которая решает обе проблемы: и изоляцию сред, и визуальное управление всем этим хозяйством — со статусами, переподключением из браузера, и чтобы не надо было жонглировать SSH-сессиями вручную.

В итоге — запилил решение для себя, показал знакомым бойцам — сказали, жги в опенсорс.

Я не хочу возвращаться к ручному кодингу.

Но чем больше кода пишут агенты, тем яснее: главная проблема AI-first разработки - и это не качество AI-кода.

Проблема в том, что из профессии исчезает фаза, в которой мы восстанавливались.

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

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

Эта статья — не туториал и не обзор. Это история о том, как я искал инструмент для своих задач, не нашёл, расстроился, а потом успокоился и написал свой. Речь пойдёт о Ботинке — консольном AI-агенте для работы по SSH. Но сначала немного контекста.

Я работаю с Linux-серверами уже лет пятнадцать. За это время видел разные эпохи: когда всё настраивали руками, когда появился Ansible, когда все бросились в Kubernetes, когда устали от Kubernetes и вернулись к простым docker-compose. Скрипты-костыли множились, документация устаревала, а сервера как требовали внимания, так и требуют.

И вот теперь добавился ещё один слой — LLM. Можно спросить у модели, как настроить nginx, и получить рабочий конфиг. Можно попросить проанализировать логи. Но каждый раз копировать-вставлять между терминалом и чатом — это отдельный вид боли. Хочется, чтобы модель жила прямо в консоли, понимала контекст сервера и могла сама выполнить рутину.

Статья будет полезна тем, кто:

Работает с серверами по SSH и устал от рутины

Интересуется AI-агентами, но хочет что-то лёгкое и локальное

Имеет ограниченные ресурсы (не у всех есть 24GB VRAM)

Хочет понять, как строится архитектура агента с инструментами

Зачем ещё один AI-агент?

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

На волне хайпа попробовал OpenClaw — хайповый проект 2025-2026 года, self-hosted AI-агент для автоматизации жизненных задач. Идея в целом норм: агент работает 24/7, отвечает в Telegram/WhatsApp, умеет чистить почту, управлять календарём, чекиниться на рейсы. Четырёхслойная архитектура, куча интеграций, активное сообщество.

Но на практике для моих задач оказалось слишком тяжело:

Оверсложнённая архитектура — Gateway, Integration, Execution, Intelligence — это отлично для энтерпрайза, но перебор для «зайти на сервер и поправить конфиг»

Ориентация на lifestyle-автоматизацию — почта, календарь, бронирования. А мне нужно: логи, systemd, docker, nginx

Постоянно висящий сервис — 24/7 демон, который кушает ресурсы. А я хочу: запустил — поработал — закрыл

Мессенджер как интерфейс — удобно для личного ассистента, но для админской работы нужен терминал и SSH

OpenClaw крут для своей ниши — персональный ассистент в Telegram. Но моя задача другая: консольный агент для системного администрирования. Зайти по SSH, диагностировать проблему, поправить, уйти. Без демонов, без мессенджеров, без оверхеда.

Так родился Ботинок.

Ключевая идея: не сервис, а инструмент

Здесь важно остановиться на главном. Ботинок — это не фоновый сервис и не постоянно висящая служба. Это обычное приложение: запустил, поработал, закрыл. Никаких веб-серверов, демонов, системных служб.

Идея пришла из наблюдения за тем, как работают разработчики с Cursor, Windsurf и подобными IDE. Там ты открыв

Темпы развития ИИ в разработке программного обеспечения не просто сохранились — они фундаментально изменились. Если 2025 год стал годом, когда ИИ закрепился в роли ежедневного помощника разработчиков, то 2026 — это год, когда он стал полноценным соавтором. Сегодня 67% разработчиков по всему миру применяют их в своих рабочих процессах. Мы перешли порог от экспериментов к инфраструктуре.

Вот десять трендов, которые определяют разработку с использованием ИИ в 2026 году и что вам с этим делать.

1. Agentic AI: от диалога к автономным действиям

Самый большой сдвиг парадигмы в 2026 году — это переход от разговорного ИИ к агентному ИИ — системам, которые не ждут запросов, а самостоятельно формируют и выполняют многошаговые планы. Инструменты вроде Claude Code, агентного режима GitHub Copilot и Cursor теперь берут на себя целые рабочие процессы: читают кодовую базу, планируют изменения в нескольких файлах, запускают тесты и итеративно исправляют ошибки — полностью автономно.

Это уже не просто автодополнение кода. Эти агенты понимают контекст репозитория, историю коммитов и архитектурные паттерны. В отчёте Anthropic «Agentic Coding Trends 2026» это называется «интеллект репозитория» — ИИ, который понимает не только строки кода, но и связи и намерения за ними.

Что изменилось с 2025 года: в прошлом году мы говорили о «инструментах разработки с ИИ, выходящих за рамки автодополнения». В 2026 году мы перескочили от расширения возможностей к делегированию. Разработчик уровня 10x может превратиться в 100x — не за счёт написания большего количества кода, а за счёт управления агентами, которые это делают.

Собрал свой опыт настройки проектов для кодовых агентов. Как написать правила, чтобы агент не делал глупых ошибок, как научить его работать с окружением, как делиться скиллами между репозиториями и не сойти с ума, когда в команде у каждого свой инструмент — Claude Code, Cursor, Copilot.

Всем привет! На связи Сергей Смирнов, действующий и практикующий AI-инженер. ИИ интересовал меня задолго до нынешнего хайпа: ещё со времён защиты кандидатской, он всегда был для меня не панацеей, а инструментом автоматизации и решения прикладных задач.

С началом «эры» генеративного ИИ я занимаюсь разработкой агентских систем — и в этой статье хочу поделиться тем, что происходит, когда агента нужно не просто запустить, а сделать так, чтобы он работал надёжно, предсказуемо и без страха отдать его реальным пользователям.

Это будет своего рода дорожная карта подготовки агента к продакшену.

Команда разработчиков под руководством Андрея Бреслава, российского разработчика и автора языка программирования Kotlin, представила публичную альфа-версию нового инструмента для разработчиков — CodeSpeak. Платформа позиционируется как язык программирования нового поколения, в котором инженеры пишут спецификации на английском языке, а нейросети берут на себя генерацию, тестирование и рефакторинг исполняемого кода. Полноценное внедрение инструмента позволяет сократить объем кодовой базы в проектах в пять-десять раз. Технология поддерживает интеграцию в существующие сложные проекты на Python.