Искусственный интеллект

Устаревшая документация хуже, чем её отсутствие — она отравляет контекст LLM. Агент доверяет тому, что видит. Garbage in — garbage out, только garbage выглядит как аккуратный markdown.

Это вторая часть серии. Первая часть — «Слепое пятно LLM-разработки: контекст за пределами кода».

Меня зовут Дмитрий Синявский, я SRE в Ви.Tech, IT дочке «ВсеИнструменты.ру». В какой то момент я поймал себя на мысли, что вокруг DevOps снова спорят как в начале десятых: одни уверяют, что он умер, другие переименовывают все в platform engineering, третьи ждут, что ИИ наконец сделает всю грязную работу за инженеров. Мы с Владимиром Утратенко, который прошел путь от техподдержки до техдиректора и сейчас развивает платформу «Штурвал», спокойно разложили это по полочкам.

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

Поклонники вайбкодинга и агентных инструментов говорят, что стали продуктивнее в 2, в 10, а то и в 100 раз. Кто-то собрал целый браузер с нуля. Впечатляет!

Тогда скептики резонно спрашивают: где все приложения? Если разработчики стали (возьмём консервативную оценку) хотя бы вдвое продуктивнее, где искать вдвое больше произведённого ПО? Такие вопросы исходят из допущения, что мир хочет больше программ, а значит, если их дешевле делать, их будут делать больше. Если вы с этим согласны — где тогда этот избыток, который можно назвать «AI-эффектом»?

Посмотрим на PyPI — центральный репозиторий Python-пакетов. Он большой, публичный и стабильно измеримый, так что AI-эффект должен быть хорошо заметен.

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

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

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

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

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

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

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

Звонить в банк, интернет-провайдеру или в службу доставки бывает утомительно: бесконечно вежливый ИИ-ассистент, не понимая контекста, без усталости гоняет ответы по скриптам. В отличие от него пользователь вполне по-настоящему испытывает и злость, и усталость, ожидая соединения с человеком — тем самым, который поймёт вопрос за пять минут.

И вот, казалось бы, решение близко: в инфополе последнюю неделю обсуждают проект федерального закона «Об основах государственного регулирования сфер применения технологий искусственного интеллекта в Российской Федерации». 18 марта 2026 года его вынесли на общественное обсуждение, которое продлится до 15 апреля, а в случае принятия закон должен вступить в силу с 1 сентября 2027 года. Но речь в документе идет не только чат-ботах: в статье мы пишем и о других важных положениях.

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

Последние месяцы я строил систему, которую внутри называю «аниме-заводом»: на вход она получает исходный эпизод, а на выходе собирает готовый YouTube Shorts с динамическим кадрированием, субтитрами, постобработкой и метаданными для публикации.

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

В статье я покажу, как устроен этот пайплайн, почему я пошел в модульную архитектуру вместо end-to-end black box, где система ломалась и какие решения в итоге сделали ее реально рабочей.

Шестой выпуск еженедельных IT-новостей от OpenIDE: Java прощается с аплетами навсегда, Cursor не соблюдает лицензию Kimi, а менеджеры придумали новую единицу измерения продуктивности разработчика.

Я участвовал в ARLC 2026 — юридическом AI-челлендже по построению RAG-пайплайна поверх корпуса судебных решений и законов. Соло, с Claude Code в качестве напарника. За 5 дней и 17 итераций прошёл путь от 0.034 до 0.791 на warmup — а потом вышел в финал и потерял 42% на 300 документах вместо 30. Внутри — архитектура, код, математика F-beta, три провала и честный разбор работы с AI-ассистентом.

Выкатили mcp llm ассистента во fusion360. Я сразу попробовал сделать то, что проектировал уже 60 раз и пытался автоматизировать сам - лестницу(деревянную).
Смотрим какой Vibe-design в 2026

Привет, Хабр! На связи команда Рунити под руководством Антона Ивахненко: Дмитрий Виноградов, руководитель направления разработки, менеджер продукта Карина Калеева, ML-инженер Александр Михеев и тех.лид Владимир Устьянцев. 

В этой статье мы рассказываем про RAG-ассистента, который скоро у нас появится. Этот ассистент ищет по Confluence и GitLab одновременно, уважает права доступа и не отправляет корпоративные данные наружу. Но обо всём по порядку. 

Можно ли делать RAG на MacStudio M3 Ultra? CAG - убийца RAG? Самый лучший RAG от OpenAI и Grok?

Ответы на эти вопросы мы узнали во время участия в соревновании Agentic RAG Legal Challenge. Стоит отметить хорошую организацию соревнования и продуманные метрики. Более 300 команд со всего мира.

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

Кандидаты доводят резюме до идеала с помощью ИИ. Компании внедряют алгоритмы для их фильтрации. В итоге обе стороны играют в гонку вооружений, а рынок получает поток одинаково «идеальных» откликов, за которыми не видно реального человека. Разбираемся, почему классическое резюме потеряло свою ценность как инструмент оценки, и на что бизнесу (и соискателям) нужно смотреть прямо сейчас.

По данным Financial Times, AI-агент Amazon получил operator-level доступ к продакшену - и выбрал «удалить окружение» как оптимальный способ починить баг. 13 часов аутейджа. Собрал хронологию трёх инцидентов марта 2026 и разбираюсь, что именно пошло не так на уровне permissions, review gates и CI/CD.

У Figma давно был MCP-сервер. Работал он в режиме read-only, и сценарий выглядел так: дизайнер (или вы сами) рисовали макеты руками, потом разработчик скармливал агенту ссылку на файл в Figma, агент разбирал его по слоям, вытаскивал структуру, цвета, отступы, шрифты, и на выходе генерил код, который более-менее соответствовал тому, что было нарисовано.

Вчера Figma обновила свой MCP-сервер, и теперь она умеет не только читать, но и рисовать дизайн. Причём речь не про "нарисуй мне кнопку" или "сделай один экран". Агент может собрать полноценный лендинг целиком или выстроить UX-флоу на несколько экранов. И самое ценное: он делает это в рамках вашей дизайн-системы. Берёт ваши компоненты, ваши токены, ваши стили и собирает из них макет, который выглядит как часть вашего продукта, а не как что-то из генератора 2015 года.

До этого обновления все попытки генерировать дизайн через AI выглядели так себе. Результат глючил, визуал был устаревший, компоненты не из вашего UI Kit, а откуда-то из дефолтных библиотек. Пользоваться этим в проде было нельзя, максимум для наброска. Сейчас ситуация другая. Вы подключаете свою дизайн-систему (UI Kit), и агент собирает макеты, которые реально пригодны для использования.
Я считаю для быстрых экспериментов и проверки гипотез это гигантский шаг вперёд.

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

Около 90% фронтенд‑разработчиков в нашей команде используют ИИ‑помощников для написания кода. Лично у меня — и как я могу заметить, у многих — был такой опыт: вы только начинаете пользоваться ИИ‑помощником, просите его сгенерировать какое‑нибудь классное MVP, получаете результат минут за пять и думаете: «Вау, неужели это возможно? Как это вообще работает и как это круто». 

А дальше вас ждёт сюрприз. 

Всем привет, меня зовут Валерий Баранов, я руковожу командой технологий фронтенда в Яндекс 360. Мы занимаемся тем, что сами называем «общим фронтендом»: общими техническими компонентами, общим CI/CD, платформами дистрибуции общих компонентов. Сегодня я хочу рассказать, как мы в Яндекс 360 сделали фронтенд‑проекты по‑настоящему AI‑ready: научили ассистентов понимать структуру наших репозиториев, работать с внутренними библиотеками и даже соблюдать паттерны дизайн‑системы. 

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

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

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

Привет! Меня зовут Владимир Верхотуров, я занимаюсь DevRel в Битрикс24. Большинство стартер-китов ускоряют разработку, но ускорение без системной безопасности почти всегда приводит к техническому долгу.  Сегодня хочу рассказать про наш подход к безопасности нашего AI-стартера.

ИИ‑фреймворки давно въехали в прод, но к ним часто относятся как к «научной приблуде», а не к ещё одному входу в ваши данные и инфраструктуру. Spring AI и ONNX крутятся где‑то между ML‑командами, продуктами вендоров и внутренними ассистентами, и на определённом этапе за ними перестают успевать архитектура и безопасность.

В марте в обзорах уязвимостей рядом всплыли несколько критичных багов именно в этих штуках. Там есть и SQL‑инъекции, и JSONPath‑инъекции, и обход проверки доверия при загрузке моделей. В статье разбираю, что это значит для тех, кто уже тащит ИИ в прод, и даю чек‑лист, который можно прямо отнести своей команде.

Один простой вопрос. Девять уверенных ответов. Восемь из них — ложь.

примечание: Иллюстрация сгалюционирована ИИ

Я отправил 29 крупнейшим языковым моделям мира одно сообщение — и стал ждать. Я думал: модель либо знает ответ, либо не знает; и честно скажет об этом. Третьего не дано.

Оказалось — дано. И это третье называется галлюцинация с полной уверенностью в своей правоте.

Результаты изменили моё понимание того, насколько мы можем доверять ИИ