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

Pavel Veinik

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

AI на legacy-проектах и больших кодовых базах

- Везде, все что я видел про Claude и Codex - люди делают проекты с 0. Хоть кто то использует это в реальном проде на проектах уровня интерпрайз?

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

Детальный разбор механики работы:

  1. Codebase Indexing & RAG (Retrieval-Augmented Generation): Ключевая технология — это индексация всей кодовой базы (legacy и новой) для создания семантического поискового движка. Агент не читает весь код каждый раз. Он делает умный поиск по индексированной базе, чтобы найти релевантные фрагменты кода, документацию и историю изменений. Этот контекст подается в LLM вместе с запросом.

  2. Multi-Agent & Hierarchical Systems: В enterprise никто не использует одного супер-агента. Применяются иерархические системы:

    • Планировщик (Planner Agent): Декомпозирует высокоуровневую задачу (например, добавить 2FA-аутентификацию) на подзадачи.
    • Агенты-эксперты (Expert Agents): Специализированные агенты для конкретных областей: один по работе с базой данных, другой по фронтенду, третий — по API-шлюзу. Они получают подзадачи от планировщика.
    • Валидатор (Validator Agent): Агент, который запускает тесты, линтеры и проверяет код, написанный другими агентами, на соответствие стандартам.
  3. Tooling & API Integration: Агенты активно используют инструменты (tools) — это обертки над существующими API, CLI-утилитами, библиотеками. Например, агент не пишет SQL-запрос напрямую, а вызывает функцию userRepository.findUser(id), которая уже есть в коде. Это делает их работу безопасной и предсказуемой.

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

  • Индексация: Для кода отлично подходят специализированные инструменты вроде Sourcegraph или его open-source аналогов, которые строят граф кода. Для документации — классические векторные базы (Pinecone, Weaviate) с GraphRAG для извлечения связей.
  • Фреймворки для агентов: AutoGen от Microsoft и CrewAI стали де-факто стандартами для построения мульти-агентных систем. LangGraph используется для создания сложных, циклических взаимодействий между агентами.
  • Модели: Для enterprise-задач используются высокопроизводительные модели (GPT-4.5/5, Claude 3.5) через приватные эндпоинты (Azure OpenAI, AWS Bedrock), чтобы гарантировать безопасность данных. Для задач валидации или рутинного рефакторинга часто используются локально развернутые, дообученные open-source модели (fine-tuned Llama 3/4).

Что может пойти не так:

  • Эффект бабочки: Небольшое изменение, внесенное агентом, может сломать что-то в другой части системы. Решается обязательным прогоном полного набора регрессионных тестов перед коммитом.
  • Низкая релевантность контекста: Если RAG-система находит не те фрагменты кода, агент пишет ерунду. Лечится продвинутыми техниками реранкинга (Cohere Rerank) и гибридным поиском (ключевые слова + семантика).
  • Безопасность: Агент с доступом к инструментам — это потенциальная дыра в безопасности. Доступы строго ограничиваются через IAM-роли, а все действия аудируются.

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


- Работа с Легаси проектами. Работа с узловой (год) системой. Работа с демонами. Работа с контекстом между демонами и бэкендом и БД

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

Детальный разбор механики работы:

  1. Создание Цифрового двойника кодовой базы: Первый шаг — это не написание кода, а сбор контекста. Мы создаем всеобъемлющую базу знаний о проекте:

    • Код: Индексируем весь код с помощью инструментов, понимающих его структуру (Sourcegraph, ctags, LSIF).
    • Документация: Векторизуем всю имеющуюся документацию, тикеты из Jira, Confluence, переписки в Slack.
    • Схемы данных: Индексируем схемы БД, миграции, GraphQL/gRPC схемы.
    • Логи: Для работающих демонов и сервисов можно анализировать логи, чтобы понять паттерны их взаимодействия.
  2. Агент-аналитик (Analyst Agent): После создания базы знаний мы используем агента в режиме вопрос-ответ. Его задача — помочь человеку разобраться в системе, а не менять ее. Примеры запросов:

    • Где в коде демона X происходит запись в таблицу Y?
    • Построй цепочку вызовов от API-эндпоинта Z до отправки сообщения в RabbitMQ.
    • Какие поля из БД используются в этом UI-компоненте? Этот агент использует RAG и графовые запросы к цифровому двойнику.
  3. Агент-рефактор (Refactoring Agent): Когда понимание достигнуто, можно переходить к изменениям.

    • Создание тестов: Первое, что делает агент, — покрывает изменяемый участок кода тестами. Это золотой стандарт безопасности при работе с легаси.
    • Изолированные изменения: Агент вносит небольшие, атомарные изменения, постоянно прогоняя тесты.
    • Использование инструментов: Агент не пишет git commit сам. Он использует инструменты (tools), которые выполняют команды git, docker-compose up, pytest.

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

  • Инструменты для анализа кода: Для С/С++ отлично работает связка ctags + grep + семантический поиск. Для Java/C# — встроенные в IDE инструменты анализа, которые можно вызывать через CLI.
  • Платформы для RAG: LlamaIndex предоставляет мощные инструменты для построения сложных RAG-пайплайнов, включая рекурсивный ретривер и обработку разнородных источников данных (код, PDF, JSON).
  • Отладка и трассировка: Для понимания взаимодействия между демонами и бэкендом используются системы распределенной трассировки (OpenTelemetry). Агент может анализировать эти трейсы для поиска узких мест или ошибок.
  • Модели: Для анализа кода отлично себя показывают модели, специально дообученные на нем (например, StarCoder или CodeLlama-семейство), особенно если их дообучить (fine-tune) на вашей кодовой базе.

Что может пойти не так:

  • Слепые зоны: Если какая-то часть системы не попала в базу знаний (например, старый бинарный протокол обмена), агент будет о ней не знать и может сделать неверные выводы.
  • Сложность окружения: Агенту может быть сложно поднять и настроить локальное окружение для запуска тестов. Решается через devcontainer или другие инструменты контейнеризации.
  • Неверная интерпретация: LLM может неправильно понять старый, запутанный код. Человеческий контроль и code review остаются обязательными.

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


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

Это абсолютно верное наблюдение, и оно отражает зрелый подход к использованию AI. Иллюзия одной кнопки (агент, сделай всё хорошо) быстро проходит, когда сталкиваешься с реальностью enterprise-разработки.

Детальный разбор механики работы:

Модель человек-в-цикле (Human-in-the-Loop) является ключевой. AI-агент — это не замена инженера, а интеллектуальный напарник (pair programmer), который берет на себя рутинные, но трудоемкие задачи.

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

  1. Человек (Архитектор/Senior):

    • Понимание задачи: Глубоко анализирует бизнес-требования и технический контекст.
    • Декомпозиция: Разбивает большую задачу на небольшие, понятные, изолированные подзадачи. Например, не интегрировать новую платежную систему, а:
      1. Добавить поля provider и transaction_id в таблицу Payments.
      2. Создать DTO для ответа от API платежной системы.
      3. Написать метод в PaymentService для вызова API, используя созданный DTO.
    • Определение контрактов: Определяет интерфейсы, сигнатуры методов, структуры данных, которые агент должен реализовать.
  2. AI-агент (Исполнитель/Junior-Middle):

    • Реализация подзадачи: Получает на вход четко сформулированную, небольшую задачу и реализует ее. Например, напиши реализацию метода createPayment в классе PaymentServiceImpl, который использует RestTemplate для вызова POST /api/v2/payments.
    • Генерация бойлерплейта: Пишет тесты, Javadoc, обновляет OpenAPI-спецификации.
    • Поиск по кодовой базе: Быстро находит примеры похожей реализации в проекте, чтобы следовать существующим паттернам.

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

  • Фреймворки для декомпозиции: Задачи можно описывать прямо в коде в виде специальных комментариев или использовать таск-менеджеры, интегрированные с IDE. Агент читает задачу, выполняет ее и помечает выполненной.
  • Интеграция с IDE: Лучшие результаты достигаются, когда агент работает в контексте IDE (например, плагин для VS Code или IntelliJ IDEA). Он имеет доступ к AST (Abstract Syntax Tree), результатам статического анализа, может выполнять рефакторинги, предоставляемые IDE.
  • DSPy (Declarative Self-improving Language Programs): Этот фреймворк позволяет программировать пайплайны для LLM, а не просто писать промпты. Вы описываете, что хотите получить, а DSPy сам подбирает наиболее эффективную цепочку промптов и инструментов для решения задачи. Это идеально подходит для создания агентов-исполнителей.

Что может пойти не так:

  • Слишком крупные подзадачи: Если подзадача недостаточно детализирована, агент может поплыть и сгенерировать нерелевантный код. Правило простое: подзадача должна быть размером с типичный коммит.
  • Отсутствие обратной связи: Агент должен иметь возможность задавать уточняющие вопросы, если что-то непонятно. Это реализуется через интерактивный чат в IDE.
  • Игнорирование контекста: Важно, чтобы RAG-система агента была настроена на поиск в первую очередь внутри текущего модуля или пакета, чтобы он не притаскивал решения из совершенно другой части проекта.

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


- Как скормить AI легаси проект, чтобы разобраться в старой запутанной логике и эффективнее поддерживать его?

Этот процесс можно разбить на три этапа: Индексация, Анализ и Интерактивное исследование.

Детальный разбор механики работы:

  1. Этап 1: Индексация (Создание Базы Знаний) Ваша цель — создать для AI полное представление о проекте из разных источников. Это не просто закинуть код в модель, а построить структурированную базу знаний.

    • Семантическая индексация кода: Используйте инструменты, которые не просто разбивают код на куски, а понимают его структуру. Они создают эмбеддинги для каждого класса, метода, функции, сохраняя связи между ними.
    • Индексация документации и артефактов: Векторизуйте всю связанную информацию: README, Confluence, архитектурные диаграммы (используя мультимодальные модели для их чтения), тикеты в Jira, даже комментарии в коде.
    • Построение Графа Знаний (Knowledge Graph): Наиболее продвинутый шаг. Вы извлекаете из кода и текстов сущности (например, сервис аутентификации, таблица пользователей, API-ключ) и связи между ними (использует, записывает в, зависит от). Это позволяет отвечать на сложные вопросы о взаимосвязях.
  2. Этап 2: Анализ (Автоматическое документирование) Когда база знаний готова, вы запускаете агента-архивиста, который проходится по коду и генерирует новую, актуальную документацию.

    • Генерация Docstrings/Javadoc: Агент проходится по каждому методу без документации и генерирует ее, основываясь на коде и найденном контексте.
    • Создание PlantUML/Mermaid диаграмм: Агент анализирует цепочки вызовов между сервисами и генерирует диаграммы последовательности (sequence diagrams) или диаграммы компонентов.
    • Описание бизнес-логики: Агент может суммаризировать сложные бизнес-процессы, читая код и переводя его на человеческий язык.
  3. Этап 3: Интерактивное исследование (Диалог с кодом) Это самый важный этап для поддержки. Вы (или новый разработчик) можете задавать вопросы вашей базе знаний в режиме диалога.

    • Что делает этот код?: Выделяете фрагмент кода и просите агента объяснить его простыми словами.
    • Где еще используется этот метод?: Агент выполняет семантический поиск и показывает не только прямые вызовы, но и места, где используется похожая логика.
    • Если я поменяю эту переменную, что сломается?: Используя граф знаний, агент может предсказать потенциальное влияние изменений.

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

  • Инструменты для индексации:
    • Код: Sourcegraph, Bloop, Bloop-rs (Rust-based!).
    • RAG и Графы: LlamaIndex и Neo4j для построения графа знаний. Microsoft GraphRAG — отличный фреймворк для этого.
  • Мультимодальные модели: Claude 3.5 Sonnet или Gemini 2.5 Pro могут анализировать не только текст, но и диаграммы, скриншоты старого UI, что бесценно для легаси.
  • Локальные модели: Для сканирования кода внутри закрытого контура идеально подходят локально развернутые модели (Ollama + CodeLlama 4) с RAG-обвязкой, чтобы избежать отправки кода во внешние API.

Что может пойти не так:

  • Мусор на входе — мусор на выходе: Если код очень плохого качества, без комментариев и с нелогичными названиями, даже AI будет сложно в нем разобраться. Процесс будет итеративным.
  • Неполный контекст: Если у вас нет доступа к документации или истории задач, понимание AI будет ограничено только кодом, и он может упустить важные бизнес-причины тех или иных решений.
  • Высокая стоимость индексации: Создание и поддержание актуальной базы знаний для очень большого проекта требует значительных вычислительных ресурсов.

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


- Как втаскивать агентов в большой легаси проект?

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

Стратегия Лестница ценности:

  1. Ступень 1: Пассивный анализ и ответы на вопросы (Read-only)

    • Цель: Помочь разработчикам быстрее разбираться в коде, не давая AI прав на запись.
    • Реализация:
      1. Разворачиваем систему индексации кода (Sourcegraph/Bloop) и документации (RAG на LlamaIndex).
      2. Создаем чат-бота (в Slack или в IDE), который может отвечать на вопросы о кодовой базе. Где найти настройки для X?, Какой класс отвечает за Y?.
    • Польза: Снижается порог входа для новых сотрудников, ускоряется поиск информации. Риск — нулевой.
  2. Ступень 2: Автоматизация рутины (Low-risk writing)

    • Цель: Автоматизировать задачи, результаты которых легко проверить и которые не ломают основную логику.
    • Реализация:
      1. Генерация тестов: Создаем агента, который берет существующий метод и пишет для него юнит-тесты. Это идеальная задача: код тестов не попадает в продакшен-сборку, а их корректность легко проверить.
      2. Написание документации: Агент, который генерирует Javadoc/Docstrings/README.
      3. Линтинг и форматирование: Агент, который исправляет стиль кода по гайдлайнам.
    • Польза: Улучшается качество кода, повышается покрытие тестами. Риск — низкий.
  3. Ступень 3: Ассистируемый рефакторинг (Human-in-the-loop)

    • Цель: Помогать разработчикам вносить изменения под их контролем.
    • Реализация:
      1. Интеграция агента в IDE. Разработчик ставит задачу (Переименуй этот метод и обнови все его использования, Вынеси эту логику в отдельный сервис).
      2. Агент предлагает diff (изменения), который разработчик просматривает, правит и утверждает (apply).
    • Польза: Ускоряется рефакторинг и реализация небольших фич. Риск — средний, контролируется человеком.
  4. Ступень 4: Автономные агенты для подзадач (High-trust)

    • Цель: Доверить агенту полную реализацию небольшой, хорошо описанной задачи.
    • Реализация:
      1. В таск-трекере (Jira) создается тикет с определенным тегом (например, AI-ready).
      2. Агент-планировщик (Planner) забирает тикет, декомпозирует его.
      3. Агенты-исполнители пишут код, тесты.
      4. Агент-валидатор проверяет результат.
      5. В конце создается Pull Request, который ждет финального ревью от человека.
    • Польза: Значительное ускорение разработки типовых задач. Риск — высокий, митигируется обязательным Code Review.

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

  • Начинайте с малого: Выберите один модуль или сервис в вашем проекте для пилотного внедрения.
  • Безопасность прежде всего: Используйте приватные модели (Azure OpenAI, локальные через Ollama), чтобы код не утекал.
  • Измеряйте всё: Собирайте метрики — сколько времени сэкономил агент, насколько качественный код он производит, сколько его правок откатывают.

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


- Предстоит переписывать продукт с 25 летней историей. Хочу понять, как это можно сделать с использованием AI агентов

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

Стратегия Археолог и Архитектор:

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

Фаза 1: Археология (Исследование старой системы)

На этом этапе мы не пишем ни строчки нового кода. Наша цель — извлечь все знания из старой системы.

  • Агент-Документатор (Documentation Agent):

    1. Индексация: Сканирует весь старый код (даже на COBOL или Delphi), всю документацию, схемы БД.
    2. Генерация отчетов: Создает актуальное описание системы:
      • Переводит старый код на современный псевдокод или человеческий язык.
      • Генерирует ER-диаграммы для старой базы данных.
      • Рисует диаграммы потоков данных (data flow).
    • Интерактивный Q&A: Создает чат-бот, где можно спросить: За какую бизнес-логику отвечал модуль X?, Какие данные хранятся в таблице Y?.
  • Агент-Тест-Майнер (Test Mining Agent):

    1. Анализ логов: Анализирует продакшен-логи старой системы, чтобы понять, какие функции используются чаще всего, а какие — мертвый код.
    2. Генерация интеграционных тестов: На основе анализа API-вызовов или логов, агент создает набор тестов черного ящика (black-box tests). Эти тесты будут нашим золотым стандартом: новая система должна будет их проходить, чтобы доказать, что она сохранила старую логику.

Фаза 2: Архитектура и Реализация (Строительство новой системы)

Теперь, вооружившись знаниями, мы начинаем строить.

  • Агент-Архитектор (Architecture Agent):

    1. Проектирование: Вы, как человек-архитектор, проектируете новую микросервисную архитектуру.
    2. Генерация каркаса (Scaffolding): Агент по вашему описанию создает каркасы новых сервисов: структуру папок, Docker-файлы, CI/CD пайплайны, OpenAPI/gRPC спецификации.
  • Агент-Мигрант (Migration Agent):

    1. Транспиляция кода: Для некоторых частей старого кода возможна автоматическая транспиляция (например, из старой версии Java в новую, или из C# в Java). Агент делает черновую работу, которую потом дорабатывает человек.
    2. Перенос бизнес-логики: Разработчик берет сгенерированную документацию и тесты из Фазы 1 и ставит агенту задачу: Реализуй эту бизнес-логику в новом сервисе, используя современные паттерны. Код должен пройти вот эти тесты.
  • Агент-Валидатор (Validation Agent):

    1. Запуск тестов: Постоянно прогоняет тесты, сгенерированные на Фазе 1, на новой системе.
    2. Сравнение данных: Помогает написать скрипты для сравнения данных, выгруженных из старой и новой БД, чтобы убедиться в корректности миграции данных.

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

  • Итеративность: Не пытайтесь переписать всё сразу. Используйте паттерн Strangler Fig (Удушающая смоковница): постепенно заменяйте старые модули новыми сервисами, перенаправляя трафик.
  • Мультимодальность: Используйте модели, способные анализировать не только код, но и скриншоты старого интерфейса, чтобы помочь в переписывании фронтенда.
  • Контроль человека: AI — это мощный инструмент, но ключевые архитектурные решения и финальное ревью кода всегда остаются за человеком.

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


- Хочу настроить локальный агент на нашей кодовой базе, 1.5+MLoc на С и 700К на плюсах

Это отличная и реалистичная задача. Главные приоритеты здесь — производительность и безопасность (чтобы код не покидал ваш контур).

Архитектура локального агента:

Ваша система будет состоять из трех основных компонентов: Модель, Система Индексации (RAG) и Оркестратор.

  1. Модель (The Brain):

    • Выбор: Вам нужна модель, хорошо обученная на коде, особенно C/C++. Идеальные кандидаты на 2026 год:
      • CodeLlama 4 (70B или 120B): Новое поколение моделей от Meta, специально заточенное под код.
      • Mistral Code (Large): Очень мощные модели, часто конкурирующие с проприетарными.
      • Fine-tuning: Оптимальный вариант — взять одну из этих моделей и дообучить (fine-tune) ее на вашей собственной кодовой базе. Это улучшит ее понимание ваших специфических паттернов, библиотек и даже названий переменных.
    • Развертывание:
      • Ollama: Самый простой способ запустить модель локально на мощной машине (GPU обязателен, например, 2x NVIDIA RTX 4090 или A100/H100).
      • vLLM / TensorRT-LLM: Для максимальной производительности (throughput) и минимальной задержки (latency) используются эти библиотеки, которые оптимизируют исполнение модели.
  2. Система Индексации (The Memory):

    • Проблема: 1.5 MLoC не поместятся в контекстное окно ни одной модели. Поэтому нужна RAG-система.
    • Решение:
      1. Парсинг и чанкинг (Chunking): Код нужно разбить на осмысленные куски. Для C/C++ лучше использовать не наивное разбиение по строкам, а парсинг с помощью tree-sitter. Это позволит разбивать код на функции, классы, структуры.
      2. Эмбеддинги: Каждый кусок кода превращается в вектор (эмбеддинг). Для этого используются специализированные модели эмбеддингов для кода (например, jina-ai/jina-embeddings-v2-base-code).
      3. Векторная база данных: Все векторы сохраняются в локально развернутой векторной БД (Weaviate, Qdrant, Milvus). Они очень быстрые и оптимизированы для семантического поиска.
      4. Гибридный поиск: Лучшие результаты дает комбинация семантического (векторного) поиска и классического поиска по ключевым словам (BM25), который реализуется в большинстве векторных БД.
  3. Оркестратор (The Conductor):

    • Проблема: Нужно связать модель и RAG вместе.
    • Решение:
      • LangChain / LlamaIndex: Эти фреймворки предоставляют готовые компоненты для построения RAG-пайплайна. Вы описываете логику: получить запрос -> найти релевантные куски кода в векторной БД -> сформировать промпт -> отправить в модель -> получить ответ.
      • Агентская логика: Для более сложных задач (например, найди баг и исправь его) используется агентский фреймворк (AutoGen, CrewAI), который может выполнять несколько шагов, использовать инструменты (например, вызвать grep или gdb).

Пошаговый план внедрения:

  1. Железо: Подготовьте сервер с одним или несколькими мощными GPU (минимум 24 ГБ VRAM на каждый).
  2. Модель: Установите Ollama и скачайте модель (например, codellama:70b).
  3. Индексация: Напишите скрипт на Python с LlamaIndex, который будет:
    • Рекурсивно обходить вашу кодовую базу.
    • Использовать tree-sitter для умного чанкинга.
    • Генерировать эмбеддинги.
    • Сохранять их в локально запущенную Weaviate/Qdrant.
  4. API: Создайте простой API-сервер (на FastAPI), который будет принимать запросы, обращаться к оркестратору и возвращать ответы.
  5. Интеграция: Создайте плагин для VS Code / Emacs / Vim, который будет обращаться к вашему API.

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


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

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

Архитектура Фабрика Агентов:

  1. Централизованная База Знаний (Central Knowledge Base): Это ваш главный актив. Вы создаете RAG-систему не для одного проекта, а для всех ваших знаний.

    • Источники данных:
      • Документация: Официальная документация по всем CMS и фреймворкам, с которыми вы работаете (WordPress, Drupal, Laravel, Django, React, Vue...).
      • Внутренние проекты: Код ваших лучших, эталонных проектов.
      • Решенные проблемы: База знаний с описанием типовых проблем и их решений (например, статьи из вашего внутреннего блога или Confluence).
      • Плагины/Модули: Код и документация часто используемых плагинов и библиотек.
    • Технология: LlamaIndex отлично подходит для создания RAG на основе разнородных источников. Вы можете создать по одному индексу на каждый фреймворк.
  2. Специализированные Агенты (Specialized Agents): Вы создаете не одного агента, а команду из нескольких, каждый со своей ролью.

    • Агент-Оценщик (Estimator Agent):
      • Задача: Помочь в оценке новых проектов.
      • Как работает: Вы даете ему ТЗ на доработку чужого проекта. Агент сканирует код нового проекта, сравнивает его с вашей базой знаний и выявляет риски: В этом проекте на WordPress используется устаревшая версия плагина X, у которого известны уязвимости. Тема кастомная, без документации. Оценка трудозатрат должна быть увеличена на 30%.
    • Агент-Бутстрапер (Bootstrapper Agent):
      • Задача: Быстро стартовать новые проекты.
      • Как работает: Вы говорите: Создай новый проект на Laravel 12 с аутентификацией, интеграцией Stripe и админ-панелью на Vue 3. Агент, используя ваши внутренние шаблоны и лучшие практики из базы знаний, генерирует полный каркас проекта.
    • Агент-Поддержки (Support Agent):
      • Задача: Помогать в доработке существующих проектов.
      • Как работает: Когда приходит задача на доработку, агент сначала определяет стек (например, это Drupal 9 с модулем Commerce). Затем он подгружает нужный контекст из базы знаний (документацию по Drupal Commerce) и помогает разработчику писать код, предлагая релевантные хуки, API и примеры.

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

  • Мульти-RAG: Вместо одного большого индекса используйте несколько специализированных. Когда поступает запрос, сначала работает агент-роутер, который определяет, к какому индексу (WordPress, Laravel и т.д.) нужно обратиться.
  • Контекст проекта: Для каждого проекта, который вы ведете, создавайте отдельный, небольшой индекс с его кодом. Агент поддержки будет искать сначала в индексе конкретного проекта, а если не найдет ответа — то в центральной базе знаний.
  • Fine-tuning: Если у вас много проектов на одном и том же стеке (например, 50+ сайтов на WordPress), имеет смысл дообучить (fine-tune) небольшую модель (например, Llama 4 8B) на вашей кодовой базе. Это сделает ее экспертом именно в вашем WordPress.

Что может пойти не так:

  • Актуальность базы знаний: Документация устаревает. Нужно настроить автоматические скраперы, которые будут регулярно обновлять вашу RAG-систему новыми версиями документации.
  • Плохие примеры: Если в базу знаний попадет код из неудачных проектов, агенты начнут тиражировать плохие практики. Нужен процесс курирования — помечать, какие проекты считать золотым стандартом.
  • Раздувание контекста: Слишком много информации может запутать модель. Важно правильно настроить ретривер, чтобы он извлекал только самое релевантное.

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


- AI агент долго разбирается в легаси чтобы пофиксить баг или написать похожую фичу как в проекте

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

Детальный разбор механики работы:

Представьте, что контекстное окно модели — это ваш рабочий стол. Если он завален кучей бумаг, вы будете долго искать нужную. Задача — заранее положить на стол только те 2-3 документа, которые нужны для решения конкретной задачи.

Стратегия Фокусированного контекста (Focused Context):

  1. Многоуровневый RAG (Multi-level RAG): Вместо одного большого поиска по всей базе, мы делаем несколько последовательных, уточняющих поисков.

    • Шаг 1: Поиск по симптомам (Symptom-based Search): Берем текст бага из Jira (При нажатии на кнопку X всплывает ошибка Y). Делаем семантический поиск по кодовой базе, чтобы найти места, где упоминается кнопка X или ошибка Y. Это дает нам первоначальный набор подозреваемых файлов.
    • Шаг 2: Анализ графа вызовов (Call Graph Analysis): Для найденных файлов мы строим локальный граф вызовов. Какие функции вызывают эти методы? Какие методы вызывают они? Это помогает очертить границы проблемной области.
    • Шаг 3: Поиск похожих решений (Similarity Search): Агент анализирует код в проблемной области и делает еще один, более узкий семантический поиск: Найди в кодовой базе примеры, где уже исправлялись похожие ошибки или Найди примеры реализации похожих фич. Это нужно, чтобы агент следовал существующим паттернам.
  2. Агент-Триаж (Triage Agent): Этот агент работает до того, как задача попадет к кодеру. Его единственная цель — подготовить идеальный контекст.

    • Он выполняет многоуровневый RAG, описанный выше.
    • Он читает историю изменений в Git для подозреваемых файлов, чтобы понять, кто и когда их трогал.
    • Он формирует итоговый брифинг (prompt), который содержит:
      1. Текст задачи.
      2. Самые релевантные фрагменты кода (не более 5-7).
      3. Пример похожего коммита из прошлого.
      4. Указание на конкретные файлы, которые скорее всего нужно будет изменить. И только этот сжатый, сфокусированный промпт отправляется агенту-кодеру.
  3. Итеративная разработка (Iterative Development): Агент не пытается исправить все за один раз.

    • Шаг 1: Написать тест: Агент сначала пишет тест, который воспроизводит баг. Этот тест, естественно, падает.
    • Шаг 2: Предложить исправление: Агент вносит минимальное изменение в код, чтобы тест прошел.
    • Шаг 3: Валидация: Запускаются все связанные тесты, чтобы убедиться, что исправление ничего не сломало.

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

  • Реранкеры (Rerankers): После первого этапа поиска RAG-система может вернуть, например, 20 потенциально релевантрых документов. Чтобы выбрать из них топ-3, используется модель-реранкер (например, Cohere Rerank или bge-reranker), которая точнее оценивает релевантность именно к вашему запросу.
  • LangGraph: Этот фреймворк идеален для построения сложных, циклических цепочек мыслей, как у агента-триажа. Он позволяет агенту подумать, прежде чем действовать, выполняя несколько шагов поиска и анализа.
  • Контекстное сжатие (Contextual Compression): Техники, которые позволяют выжать из найденных документов только самую суть, удаляя все лишнее, прежде чем подать их в основную модель.

Что может пойти не так:

  • Неверная первая гипотеза: Если на первом шаге поиск по симптомам пошел не туда, вся остальная цепочка будет неверной. Решается наличием человеческого контроля — разработчик может подсказать агенту, куда смотреть.
  • Слишком сложная логика: Для багов, связанных с состоянием гонки (race conditions) или утечками памяти, семантического поиска по коду может быть недостаточно. Здесь требуются агенты, умеющие работать с инструментами для отладки (gdb, Valgrind).

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