Ответы на вопросы после митапа по AI

Pavel Veinik

Login
Ответы на вопросы после митапа по AIКраткая история IT: От ткацкого станка до нейросетей

Внедрение AI в команду и процессы

- В чём основная сложность при таком подходе разработки приложений?

Основная сложность — это переход от детерминированной логики к недетерминированной. Традиционный код при одинаковых входных данных всегда дает одинаковый результат. LLM-приложения — нет. Это порождает каскад проблем, незнакомых классическим разработчикам.

  1. Тестирование и валидация. Как написать юнит-тест для функции, которая каждый раз возвращает разный текст? Классические assert-ы бесполезны. Разработка смещается в сторону эвалюации (evaluation) на основе метрик. Мы создаем золотые наборы данных (golden datasets) и прогоняем через них ответы модели, измеряя:

    • Faithfulness: насколько ответ соответствует предоставленному контексту.
    • Answer Relevancy: насколько ответ релевантен вопросу.
    • Context Recall: смогла ли RAG-система найти все нужные фрагменты в базе знаний.

  2. Хрупкость промптов (Prompt Fragility). Минорное изменение в промпте, например, замена одного слова, может кардинально изменить поведение системы. Это превращает поддержку в кошмар. Современный подход — это переход от prompt engineering к prompt programming с помощью фреймворков вроде DSPy. Он позволяет определять программу через сигнатуры и ограничения, а компилятор сам находит оптимальный промпт под конкретную модель.

  3. Управление состоянием и потоком. Сложные AI-агенты требуют управления долгосрочным состоянием и выполнения многошаговых цепочек (chains). Простой вызов модели превращается в граф исполнениz, где узлы — это вызовы LLM, инструментов или условная логика.

Технологии и лучшие практики:

  • Для эвалюации: Фреймворки Ragas, DeepEval, использование LLM-as-a-Judge, где одна сильная модель (например, GPT-5) оценивает ответы другой.
  • Для надежности промптов: Фреймворк DSPy, который компилирует Python-код в оптимизированные и стабильные промпты.
  • Для управления сложными агентами: LangGraph, который позволяет строить циклические графы вычислений, что идеально подходит для реализации паттернов ReAct (Reason+Act).

Что может пойти не так: Создание системы, которая отлично работает на 5-10 примерах, но полностью разваливается в продакшене на реальных данных. Причина — недостаточная эвалюация и переоценка стабильности промптов.

Полезные материалы:

- Неопределенность с внедрением на уровне всей компании.

Эта проблема решается созданием централизованной AI-платформы и Центра Компетенций (Center of Excellence), который устанавливает стандарты, но не становится бутылочным горлышком.

В 2026 году хаотичное внедрение, когда каждая команда использует свои инструменты и модели, считается антипаттерном. Эффективная стратегия строится на следующих принципах:

  1. Центральный AI Gateway. Создается единая точка доступа ко всем LLM. Это внутренний сервис, который:

    • Абстрагирует конкретные модели. Команды делают запрос к claude-3.5-sonnet-equivalent, а гейтвей решает, использовать ли реальный Claude, Gemini или fine-tuned Llama 3.1.
    • Управляет API-ключами, безопасностью и квотами.
    • Кэширует запросы, экономя деньги и время.
    • Логирует все взаимодействия для последующего анализа и fine-tuning.

  2. Платформа для RAG и векторизации. Центр Компетенций предоставляет готовые пайплайны для векторизации внутренних документов (Confluence, Jira, кодовые базы) и API для создания RAG-систем. Командам не нужно самим разбираться с чанкингом и выбором эмбеддинг-моделей.

  3. Federated-модель разработки. Центральная команда создает платформу и лучшие практики, а продуктовые команды (спицы, spokes) используют эти инструменты для создания своих решений. Они обладают экспертизой в домене, а платформа дает им нужные инструменты.

  4. Фокус на образовании. Регулярные внутренние митапы, воркшопы и курсы по промпт-инжинирингу, дизайну агентов и инструментам платформы.

Технологии и лучшие практики:

  • AI Gateway: Portkey, Martian или самописные решения на базе API-шлюзов вроде Kong.
  • Инструменты для трейсинга и отладки: Langfuse, Helicone. Они обязательны для понимания, почему AI-система приняла то или иное решение.
  • Платформа для хостинга моделей: Использование Ollama для локального запуска open-source моделей и vLLM для их высокопроизводительного хостинга.

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

Полезные материалы:

- В целом интересен процесс внедрения ai помощников в рабочие процессы, особенно для решения технических задач. Повышение качества предлагаемых решений.

AI-помощники — это не просто чат в IDE. Это глубоко интегрированная система, работающая на нескольких уровнях жизненного цикла разработки.

Процесс внедрения по шагам:

  1. Супер-автокомплит с контекстом всего проекта. Базовый уровень. Вместо стандартного Copilot используются решения вроде Copilot Enterprise или собственные, fine-tuned модели (например, CodeLlama или Llama 3.1), обученные на всей кодовой базе компании. Они знают ваши внутренние фреймворки и архитектурные паттерны.

  2. Агенты для генерации кода по требованию (Scaffolding). Разработчик не пишет boilerplate-код. Он в комментарии или отдельном файле описывает требования к новому компоненту или API-эндпоинту. Агент, построенный на CrewAI или AutoGen, самостоятельно создает файлы, пишет базовую логику, тесты и документацию, следуя принятым в проекте конвенциям.

  3. Автоматизированный дебаггинг. При падении теста в CI/CD запускается агент-дебаггер. Он анализирует stack trace, читает код, смотрит историю изменений в Git и предлагает конкретный Pull Request с исправлением. Этот процесс моделируется как граф в LangGraph, где агент итерируется, пока тесты не пройдут.

  4. AI-ревьюер на Pull Request'ах. AI-агент выступает первым ревьюером. Он не просто проверяет стиль кода (как линтер), а ищет потенциальные архитектурные проблемы, нарушения DRY, предлагает лучшие реализации, ссылаясь на внутреннюю базу знаний и Architectural Decision Records (ADRs).

Технологии и лучшие практики:

  • Мультиагентные системы: CrewAI и AutoGen для оркестрации совместной работы нескольких специализированных агентов (тестировщик, документатор, рефактор).
  • Контекст: LlamaIndex для создания RAG-системы по кодовой базе, документации и задачам в Jira. Качество контекста напрямую определяет качество помощи.
  • Интеграция в IDE: Создание кастомных плагинов для VS Code / JetBrains, которые тесно интегрированы с внутренними AI-сервисами.

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

Полезные материалы:

- Хотим в целом встроить AI в разработку, чтобы это получалось эффективно на длинной дистанции

Эффективность на длинной дистанции достигается не покупкой модного инструмента, а построением самоулучшающейся системы. Ключевая идея — Data Flywheel (маховик данных).

Стратегические столпы для долгосрочного успеха:

  1. Маховик данных для Fine-Tuning. Каждое взаимодействие с AI-помощником — это ценнейший датасет. Когда разработчик принимает, отклоняет или редактирует предложенный код, это сигнал. Эти данные собираются и используются для регулярного fine-tuning'а небольших, специализированных open-source моделей (например, Mistral, Llama 3.1). Со временем такая модель становится на порядок лучше любой generic-модели для вашей кодовой базы.

  2. Композитные, специализированные агенты. Вместо одного гигантского агента-помощника создается общество агентов.

    • Агент-FrontendExpert знает все о вашем React-компонентном фреймворке.
    • Агент-DatabaseSchemaExpert знает все о схеме данных и правилах миграции.
    • Агент-SecurityAnalyst проверяет код на уязвимости. Сложные задачи решаются их совместной работой, оркестрируемой через AutoGen или CrewAI.

  3. Метрики и наблюдаемость (Observability). Вы не можете улучшать то, что не измеряете. Внедрите инструменты вроде Langfuse, чтобы отслеживать:

    • Acceptance Rate: как часто разработчики принимают AI-предложения.
    • Time to Resolve: насколько быстрее решаются задачи с помощью AI.
    • Bug Introduction Rate: не стали ли AI-инструменты причиной роста числа багов. Эти метрики показывают реальную эффективность.

  4. AI-Friendly архитектура. Код должен быть понятным не только для человека, но и для машины. Это означает: четко определенные API, хорошая модульность, исчерпывающая документация и тесты. Чем проще агенту понять ваш код, тем лучше он сможет с ним работать.

Что может пойти не так: Погоня за краткосрочными победами в ущерб стратегии. Например, использование облачных моделей без сбора данных для fine-tuning. Это дает быстрый результат, но лишает вас конкурентного преимущества в будущем.

Полезные материалы:

- Как выстроить процессы использования AI-инструментов в команде разработки так, чтобы предотвратить неконтролируемое копирование AI-кода, рост тех.долга и архитектурные ошибки?

Главный принцип: AI — это мощный junior-разработчик, а не всезнающий архитектор. Он предлагает, а человек решает. Ответственность всегда на человеке.

Процессы для безопасного внедрения:

  1. Принцип Владелец кода. Разработчик, который нажимает git commit, несет 100% ответственность за добавленный код, независимо от его происхождения. Он обязан понимать каждую строчку, сгенерированную AI, и быть готовым ее защищать на код-ревью.

  2. Контекст превыше всего (Context is King). Чтобы AI не предлагал чужеродный код, его нужно заземлить (grounding) в контекст вашего проекта. В системный промпт каждого AI-помощника через RAG-систему должны подаваться:

    • Стандарты кодирования (coding standards).
    • Архитектурные принципы и ADRs (Architectural Decision Records).
    • Примеры удачного кода из вашей кодовой базы. Это на порядок снижает риск получения плохого совета.

  3. Автоматизированные архитектурные ограждения. Не полагайтесь только на дисциплину. Внедряйте в CI/CD статические анализаторы, которые следят за соблюдением архитектурных правил. Например, проверка, что код из слоя presentation не делает прямых запросов к слою data-access. Такие ограждения ловят ошибки как человека, так и AI.

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

  5. Используйте AI для исследования, а не только для генерации. Продвигайте паттерн, когда разработчик просит AI не написать ему код для X, а предложить три способа сделать X, описав плюсы и минусы каждого. Это стимулирует критическое мышление и обучение.

Что может пойти не так: Команда начинает воспринимать эти процессы как бюрократию и ищет обходные пути (например, использует обычный ChatGPT в соседнем окне вместо интегрированных, context-aware инструментов). Бороться с этим можно только одним способом: делать внутренние инструменты настолько удобными и полезными, чтобы обходные пути стали не нужны.

Полезные материалы:

- Недостаточная скорость адаптации команды. Не интерес к пробам

Сопротивление изменениям — естественная реакция. Оно редко бывает связано с самим AI, а чаще — со страхом, скепсисом или неудобством. Бороться с этим нужно не приказами, а созданием правильной среды.

Стратегии преодоления сопротивления:

  1. Найдите и поддержите чемпионов. В любой команде есть 2-3 энтузиаста, которым всегда интересно новое. Дайте им лучшие инструменты, время на эксперименты и попросите поделиться результатами на демо. Успех коллеги вдохновляет гораздо сильнее, чем речь менеджера.

  2. Снижайте цену входа. Инструмент должен быть под рукой, в один клик в привычной IDE. Никто не будет пользоваться системой, если для этого нужно открыть отдельный сайт, залогиниться и скопировать 200 строк кода для контекста. Интеграция решает.

  3. Решайте реальную боль, а не выдуманную. Не нужно проводить общий тренинг Что такое LLM. Лучше организовать воркшоп по автоматизации рефакторинга легаси-модуля X с помощью нашего нового AI-ассистента. Польза должна быть мгновенной и очевидной для конкретных задач команды.

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

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

Полезные материалы:

- Сложность внедрения из-за потока бизнес задач, неправильное применение с точки зрения усложнения, а не оптимизации

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

Правильный подход — начинать с оптимизации внутренних процессов.

  1. Сначала наденьте маску на себя. Не пытайтесь сразу создать AI-фичу для клиента. Вместо этого используйте AI, чтобы ускорить вашу работу. Это высвободит время, которое потом можно будет потратить на бизнес-задачи.

  2. Определите и автоматизируйте рутину (Toil). Попросите команду составить список самых скучных, повторяющихся и рутинных задач, которые они делают каждый день.

    • Написание однотипных unit-тестов.
    • Генерация документации для API.
    • Написание миграций для базы данных.
    • Анализ логов для поиска причины ошибки. Это идеальные кандидаты для автоматизации с помощью AI. Они низкорисковые, а эффект от них легко измерить в сэкономленных часах.

  3. Внедряйте AI на узких участках. Не пытайтесь автоматизировать весь процесс разработки сразу. Внедряйте AI-инструменты в конкретных точках, например:

    • Pre-commit hook: AI предлагает осмысленное сообщение для коммита на основе дифа.
    • CI/CD pipeline: AI генерирует release notes на основе выполненных задач в Jira.
    • IDE action: AI рефакторит выделенный кусок кода по одному клику.

  4. Измеряйте и показывайте результат. Каждая успешная автоматизация должна быть оцифрована. Например: Мы сэкономили 15 часов разработки в этом спринте, автоматически сгенерировав тесты для модуля X. Это лучший аргумент для бизнеса, чтобы выделить больше времени на подобные инициативы.

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

Полезные материалы:

- Низкий процент внедрения

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

Диагностика и план действий:

  1. Проблема: Низкая ценность (Low Value).

    • Симптомы: ChatGPT справляется лучше, предложения глупые и нерелевантные, проще написать самому.
    • Причина: AI-инструмент не имеет достаточного контекста о вашем проекте. Он работает как универсальный помощник, а не как эксперт по вашей кодовой базе.
    • Решение: Инвестируйте в RAG (Retrieval-Augmented Generation). Создайте качественную базу знаний из вашего кода, документации, ADRs и даже обсуждений в Slack. Чем лучше контекст, тем выше ценность.

  2. Проблема: Низкая доступность (High Friction).

    • Симптомы: Слишком сложно пользоваться, нужно открывать еще одно окно, я постоянно забываю про этот инструмент.
    • Решение: Глубокая интеграция в существующие рабочие процессы. Инструмент должен быть под рукой: в IDE, в CLI, в интерфейсе Pull Request'а. Успех — это когда использование AI требует меньше усилий, чем его неиспользование.

  3. Проблема: Неподходящая культура (Wrong Culture).

    • Симптомы: Боюсь, что меня заменят, нам за это не платят, у нас нет на это времени.
    • Решение: Это самая сложная часть. Требуется работа с командой:
      • Безопасность: Четко донесите, что AI — это инструмент для повышения эффективности, а не для замены людей.
      • Мотивация: Поощряйте эксперименты. Выделяйте время на пробы и инновации (например, пятница — день автоматизации).
      • Лидерство: Покажите пример. Менеджеры и техлиды должны сами активно пользоваться AI-инструментами.

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

Полезные материалы:

- Разрозненные тулы и подходы

Это состояние называется AI-анархия. Оно естественно на ранних этапах, но губительно в долгосрочной перспективе. Проблемы: небезопасность (API-ключи на ноутбуках), перерасход средств, дублирование усилий и отсутствие единых стандартов.

Решение — централизованная AI-платформа.

Ключевой элемент этой платформы — AI Gateway. Это не просто прокси, а умный слой между вашими разработчиками и моделями.

Функции AI Gateway:

  1. Абстракция моделей. Разработчики отправляют запросы к псевдонимам (например, fast-responder или smart-coder), а Gateway решает, на какую реальную модель (OpenAI, Claude, Llama 3.1) отправить запрос. Это позволяет менять модели под капотом без изменения кода приложений.

  2. Централизованное управление промптами. Gateway может автоматически добавлять в каждый запрос системный промпт с правилами компании или контекстом проекта, обеспечивая единообразие и качество ответов.

  3. Безопасность и аудит. Все API-ключи хранятся в одном месте. Все запросы и ответы логируются, что позволяет анализировать использование и выявлять аномалии.

  4. Управление затратами. Gateway отслеживает расходы по командам и проектам, устанавливает лимиты и предотвращает неожиданные счета.

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

После создания Gateway вы начинаете строить на нем единый инструментарий для всей компании: общий плагин для IDE, общий CLI-инструмент, общие GitHub Actions. Это создает целостную и управляемую экосистему.

Технологии для реализации:

  • Готовые решения: Portkey, Martian, Helicone.
  • Самостоятельная разработка: Комбинация API Gateway (например, Kong, AWS API Gateway) и кастомной логики на Python/Go.

Полезные материалы:

- Кто тот кто контролирует то что натворил ИИ и какая у него должна быть квалификация?

Ответственность за действия AI многоуровневая, но финальное слово всегда за человеком.

Уровни контроля и ответственности:

  1. Разработчик (The Pilot).

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

  2. Техлид / Архитектор (The Reviewer).

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

  3. Команда AI-платформы (The Toolsmiths).

    • Ответственность: Отвечает за качество и надежность самих AI-инструментов. Они не контролируют результат в каждом конкретном случае, но отвечают за то, чтобы инструмент в принципе давал релевантные и безопасные рекомендации.
    • Квалификация: MLOps / AI Engineers. Эксперты в RAG, fine-tuning, эвалюации моделей и построении надежных AI-систем.

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

Полезные материалы:

- Пора ли менеджеру уметь писать код?

Нет, но пора менеджеру уметь взаимодействовать с технологией на новом уровне. AI-инструменты меняют саму суть этого вопроса.

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

Современный ответ (эпоха AI): Менеджеру по-прежнему не нужно писать production-ready код. Но теперь у него есть возможность и, более того, необходимость самостоятельно, с помощью AI, выполнять задачи, которые раньше требовали привлечения разработчика.

Что должен уметь менеджер:

  1. Прототипирование идей. Вместо документа с описанием фичи менеджер может с помощью AI-ассистента создать простой, но рабочий прототип UI или небольшой скрипт для демонстрации логики. Это делает обсуждение с командой на порядок более предметным.

  2. Анализ данных без SQL. Менеджер может разговаривать с базой данных на естественном языке, задавая вопросы вроде покажи мне отток пользователей по когортам за последний квартал. AI переведет это в SQL-запрос, выполнит его и вернет результат.

  3. Понимание технического контекста. Менеджер может спросить у AI-ассистента, интегрированного с кодовой базой: объясни простыми словами, за что отвечает сервис X или какие части системы затронет изменение Y.

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

Полезные материалы: