Внедрение ИИ в цикл разработки

Год назад купили команде AI-инструменты и ждали, что мидлы начнут уходить. Год прошёл, мидлы на месте, бюджет вырос, в отчёте — «стали эффективнее». Что произошло на самом деле и куда ушли деньги — разбираем на сцене.

Сажаем рядом бизнес и тех отдел. У бизнеса вопросы из P&L, у тех отдела — ответы про другую экономику. Каждый аргумент проверяется оппонентом — за кулисами такие разговоры идут давно, мы постараемся выноести их на сцену.

Ряд кейсов покрывают весь цикл расходов на AI: лицензии, инфраструктура, смена моделей, планирование, команды, утилизация. С реальными цифрами и позициями обеих сторон. Цифры из практики: $120K → $180K на лицензиях за год; $500K за свой кластер против $180K подписки; реальная утилизация AI-ассистентов; разница в скорости отделов при одинаковом бюджете.

Что заберёшь домой как CTO или Владелец бизнеса: рамку для разговора друг с другом. Какие расходы признавать как OPEX, какие как страховку, как обосновывать context engineering, почему сравнение «лицензия vs ещё один разработчик» — некорректное. И в обратную сторону — какие отговорки тех отдела перестают работать, когда бизнес считает всерьёз.

• Человек vs ИИ в хранилище данных — проверим вместе с вами, кто быстрее на реальных задачах
• Вместе с ИИ и без него: напишем SQL-код, построим data lineage, определим на что влияет атрибут таблицы, по коду "восстановим" постановку задачи, и как итог - починим "сломавшийся" отчет
• Поймем, где ИИ уже выигрывает :)
• А где все-таки без человека еще никак?
• Расскажем про реальные практические кейсы использования ИИ в Хранилищах данных на наших проектах
• Покажем метрики, которые мы замеряли: экономия рабочего дня в целом и экономия на отдельных задачах
• Поговорим про будущее хранилищ данных: кто все-таки выигрывает эту гонку - человек или машина, какой уровень автономности хранилищ нас ждет

Две части: первая сильно техническая (как устроено) - минут на 25, вторая перетекает из первой - как с этим жить - на оставшиеся 15

-- Первая часть

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

1. Что под капотом: весь низкоуровневый флоу того, что происходит после команды "сделай мне фичу Х"

   • Контекстное окно и харнесс
   • Токенизатор и его особенности работы с кодом
   • Проблемы контекстного окна, компактизация

2. Поиск кода: поиск, сигналы и документация

   • векторный поиск против разновидностей grep, плюсы и минусы подходов
   • high-signal tokens как философия ретрива
   • культура документации и сложности

3. Экономика: где горит бюджет

   • cache-hit и ttl
   • План/реакт и effort
   • cost per call / per outcome

4. Код как дашборд

   • Какая телеметрия появилась
   • acceptance vs revert
   • silent drift & regression set

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

1) Что происходит со структурой команды — стафф-лок тает (когда знание про то как работает Х у одного-двух человек) — специализации размываются (T-shape становится шире, вертикаль мельче) — численность команд падает

2) Как меняется культура работы и процессы - толерантность к перетурбациям инструментво (новый софт скилл) - изменение роли код-ревью - дисциплина эвалов становится общей на разработку вместо только ML

3) Новые боттлнеки и роли людей - что становится узким местом - как меняется иерархия в команде

Финальный вывод о том что инструменты становятся не просто инструментами - они меняют весь процесс и требуют его переосмысления

Доклад продолжает разговор о State of AI4SDLC (https://devopsconf.io/moscow/2026/abstracts/17935) и фиксирует, что AI в разработке уже перестал быть просто экспериментом, так как он массово используется для всех основных сценариев: coding, review, planning, debugging и работы с документацией. И теперь вопрос в том, а как встроить ускорение отдельных сценариев вокруг в наш продакшен цикл разработки: с понятной целью, достаточным контекстом, корректной интеграцией, доверием к результату и измеримым эффектом. И главное как это сделать не просто в стартапе или в greenfield проектах, а в устоявшейся компании в которой сотни, если не тысячи инженеров работают над созданием и развитием AI продуктов.

С трансформацией процессов разработки в сторону Agentic Development Lifecycle (ADLC) количество уязвимостей и возможностей для атаки в инфраструктуре растёт пропорционально числу агентов. Каждый агент имеет привилегии для управления инфраструктурой, работы с инструментами, доступа к данным. Компрометация такого агента открывает доступ ко всему, с чем он работает.

В докладе я рассмотрю ключевые уязвимости инфраструктуры ADLC и на примерах покажу, как можно скомпрометировать весь процесс разработки с помощью некорректно настроенных инструментов. Мы посмотрим, как архитектурные компоненты MCP, RAG и A2A открывают дополнительные возможности для изменения поведения агента, составим технологическую карту агентской разработки и определим для неё ландшафт угроз. Разберем примеры для самостоятельной оценки защищённости. В результате получим методику и набор инструментов, которые помогут разработчику и архитектору безопасности построить устойчивый процесс ADLC.

А вы уже в AI-native разработке? Или просто выдали разработчикам Claude/Cursor и считаете, что внедрили AI? Или построили сквозной процесс с общим контекстом? Или вся агентная инфраструктура уже работает автономно, а людям оставлены HITL-вставки в критичных точках? Кто-то застрял на начальных этапах, кто-то пытается перепрыгнуть стадии и запрыгнуть в полную автоматизацию.

В докладе:

— разберу мировые и локальные модели оценки зрелости AI в разработке;

— покажу, как честно определить, на каком уровне находится ваша команда или компания;

— расскажу, что меняется в инфраструктуре, процессах и роли разработчика на каждом следующем уровне.

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

AI-агенты в продакшене — это больше не эксперимент, а критичная инфраструктура. Но как понять, правильно ли агент отвечает, где и почему он «галлюцинирует» и во сколько реально обходится его использование?

На воркшопе мы разберём Langfuse — open source инструмент наблюдаемости для AI-приложений. Покажем, как организовать централизованный мониторинг ИИ-агентов и прямо на месте сделаем демо-агента наблюдаемым. Участники научатся трассировать вызовы LLM, собирать метрики, оценивать качество ответов и выполнять диагностику агентов так же, как и обычных продовых сервисов и приложений. Минимум слайдов, максимум практики: реальный агент, реальный прод-подход и живое инструментирование вместе с аудиторией.

Важно! Для участия в данном формате с собой необходимо иметь ноутбук. Код для воркшопа и требования к подготовке по ссылке: https://github.com/bocharovf/langfuse-workshop

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

Чего в интернете не достаточно, так это практических руководств по внедрению AI именно в процессную часть разработческой рутины.

Фактически, я хочу рассказать о своем тернистом пути:

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

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

Внедрение LLM в корпоративные процессы управления данными (Data Governance) часто превращается в хаос: непредсказуемые ответы, галлюцинации моделей и невозможность выпустить такое решение в прод из-за жестких требований ИБ.

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

В докладе я расскажу:

• Про "3 уровня прожарки данных" (Rare, Medium, Well-Done) и почему без уровня Rare корпоративный обмен данными невозможен.

• Как мы ушли от ненадежных автономных чат-агентов («Agentic AI») к детерминированным пайплайнам (AI Flow) со строгими контрактами на стыках.

• Как "научить" локальные модели (Qwen, DeepSeek) решать задачи Data Governance, и сравним их с облачной Gemini.

• Почему без глубокого промпт-инжиниринга локальные LLM проваливают задачи ИБ, и какие техники реально работают.

• Разберем архитектуру системы автоматической классификации чувствительных данных на базе событий (Event-driven) из каталога OpenMetadata.

Стали ли команды с AI-агентами выпускать лучше и быстрее? Зато точно известно одно: роли изменились, а договорённости об ответственности — нет.

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

Формат — батл с участием зала. Четыре раунда: размытие ролей, архитектура против скорости, релизы и доступ агентов к данным. Два спикера, две позиции, без правильного ответа — голосуете вы.

Заберёте с собой: практические ответы на три вопроса — где граница между «AI ускоряет» и «AI создаёт аварию»; как защитить прод от нейрослопа; что разрешать агентам делать самостоятельно, а где нужен человек.

Как context engineering заменяет prompt engineering Под капотом AI-агентов: как собирается контекст и почему он важнее модели AI-readability: как сделать проект понятным для AI-агентов Best practices: AGENTS.md, CONTEXT.md, MCP, Skills и toolchains Максимальный контекст: интеграция AI-агентов с трекером задач, CI и коллекторами ошибок

Внедрение ИИ-инструментов провоцирует у разработчиков всех уровней компетенций фундаментальный кризис идентичности:

• смещение из роли «создателя» в роль «контролёра ИИ» воспринимается ими как потеря статуса и профессиональной ценности
• исчезает «момент победы» - удовлетворение от самостоятельного решения сложных задач.

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

• потеря мотивации
• размывание инженерных компетенций
• долгосрочная потеря глубокой экспертизы.

Как же не потерять именно тот человеческий капитал, на котором держится качество разработки? Выход – в осознанном управлении переходом.

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

AI-агенты уже умеют писать код, но на больших проектах быстро упираются в навигацию: читают слишком много файлов, тратят лишние токены, медленно находят нужные символы и часто теряют контекст из-за базовых инструментов (grep / read). В докладе расскажу про ast-index — Rust CLI для структурной индексации кода через Tree-sitter и SQLite/FTS5. Покажу метрики и в общем расскажу про применение инструмента и как он появился.

(!) Для интерактивного участия требуется наличие ноутбука с софтом для вайбкодинга.

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

Средства ИИ разработки позволят нам не тратить время на boilerpalte-ы для Solidity, Python, JS и сосредоточиться на демострации работы различных видов сервисов, оперирующих криптоактивами.

Тезисы (общие): Токены растут вверх в цене, голый Claude или Codex уже не может удовлетворять требованиям современной разработки, но выход есть. Если хорошо настроить окружение, то можно вернуть старый добрый в 2025. Как это сделать - расскажу в своем докладе

Что происходит после фразы “давайте просто развернём open-source модель у себя”? На опыте Битрикс24 разберу грабли self-hosted AI: контекст, vLLM, GPU-пулы, evals, качество, стоимость и миллионы запросов в месяц. На выходе - чек-лист решений и метрик, который поможет оценить готовность к своим моделям и не сжечь бюджет на железе.

AI-агенты в enterprise без контекста — дорогие игрушки. Мы в Райффайзенбанке построили две платформы — Context Annotation (разметка бизнес- и технического контекста организации) и Context Memory (персистентная память агентов о клиенте) — которые дают агентам связное представление "модели мира" организации и клиента. Расскажу, как мы пришли к этой архитектуре, какие грабли собрали и какие результаты получили на трёх кредитных продуктах.

Как превратить LLM из обычного чат-бота в рабочий инструмент разработки 🔥

На этом воркшопе мы ближе познакомимся с мультиагентной разработкой, разберём подход Spec-Driven Development, а также в live-режиме сделаем фичу для небольшого проекта.

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

• системный аналитик

• backend-разработчик

• frontend-разработчик

• тестировщик

Посмотрим, как LLM может выступать не просто помощником в чате, а полноценным системным инструментом на каждом этапе разработки — от формализации требований до реализации и проверки результата.

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

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

Аналитики тратят часы на SQL-запросы, которые «почти как в прошлый раз, но не совсем». Каждая BI-система — свой синтаксис, каждый дашборд — ручная работа, каждая выгрузка — снова с нуля. Знакомо?

А что если просто написать: «Посчитай MAU и выручку по тарифам с 2025 года» — и получить готовый интерактивный график через 30 секунд?

Воркшоп построен по слоям. Сначала поднимаем рабочую среду и снимаем главную боль: агент читает схему вашей БД, историю запросов и отвечает на бизнес-вопросы на человеческом языке — без SQL вручную.

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

OpenCode — MIT open source, работает в терминале, без IDE и регистраций. Поддерживает 75+ провайдеров: Claude, GPT, Gemini и локальные модели через Ollama — данные не покидают вашу инфраструктуру.

Что заберёте с собой: - Поднятый рабочий стек с AI-агентом, настроенным под аналитику - Готовый AGENTS.md и понимание, как масштабировать решение в команде - Навык итеративного построения AI-инструментов: от прототипа до продакшена

Что сможете вписать в резюме: - Опыт построения AI-агентов для аналитики данных - Работа с OpenCode, ClickHouse, Redash, MCP в связке - Внедрение LLM-инструментов в data-процессы с учётом enterprise-требований

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

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

Вместе поищем способы как всё-таки добиваться от AI-агентов работающего результата, а не только красивую простыню кода: • Где ИИ уже годится в прод. • Где нестабилен в результатах, но дожать можно. • Где опасен и использовать нельзя. • И можно ли спасти запутавшегося ИИ.

В эпоху активного развития больших языковых моделей перед разработчиками часто встает дилемма: как совместить преимущества нескольких специализированных моделей, обученных на разных задачах, не запуская при этом множество моделей одновременно? В докладе мы рассмотрим актуальную проблему объединения параметров языковых моделей (model merging) и познакомимся с существующими подходами: от простого усреднения весов до методов LoRA merging и Task Arithmetic. Вы узнаете, почему традиционные методы часто приводят к деградации качества и как можно это исправить.

Мы представим новый метод Significant Deltas Merging with Weights (SDM-W), который позволяет интеллектуально объединять модели, учитывая только значимые изменения параметров и автоматически определяя вклад каждой модели. На практических примерах покажем, как метод помогает создать универсальную модель, которая одинаково хорошо справляется с генерацией кода, вызовом тулов и корпоративными задачами. Результаты экспериментов демонстрируют сохранение 95-98% точности при экономии до 30% вычислительных ресурсов.