Отлично, вот емкие тезисы и инсайты из встречи, структурированные для специалиста.
Это центральная идея для работы со сложными задачами, снижающая галлюцинации и повышающая контролируемость.
-
Этап 1: Планирование (Thinking).
- Инструмент: Модель с большим контекстом и хорошими "рассуждающими" способностями (например, Gemini в Google AI Studio).
- Процесс: В модель загружается максимально полный контекст проекта (с помощью утилит типа Repa Mix или кастомных скриптов, которые собирают нужные файлы в один текстовый блок).
- Задача для LLM: "Не пиши код, а сформулируй план изменений. Укажи, какие файлы нужно затронуть и что в них сделать".
- Результат: Markdown-файл с планом, ключевыми фрагментами кода и, возможно, диаграммами в формате Mermaid. Этот план ревьюится человеком.
-
Этап 2: Исполнение (Acting).
- Инструмент: Агентская система (Claude Code, Cursor).
- Процесс: План с первого этапа подается агенту.
- Задача для LLM: "Вот детальный план. Не думай и не планируй, просто последовательно выполни все шаги".
- Преимущество: Разделение ответственности (как тимлид и джун) резко снижает вероятность того, что агент "уйдет не туда" и начнет выдумывать.
- Проси LLM задавать уточняющие вопросы. Включать в промпт фразу: "Какие вопросы у тебя остались? Что тебе неясно или двусмысленно?". Это лучший способ проверить, как модель поняла задачу, и вовремя скорректировать ее понимание.
- Итерация через редактирование первого промпта. Вместо того чтобы исправлять ошибки в чате ("ты тут ошиблась, переделай"), нужно возвращаться к самому первому сообщению, дополнять его уточнениями и перезапускать генерацию. LLM склонны "оправдывать" свои предыдущие шаги (механизм последовательности), и правки в чате работают хуже, чем "чистый" перезапуск с улучшенным промптом.
- Диктовка > Текст. Использование voice-to-text утилит (например, Superwhisper) для надиктовывания промптов. Речь позволяет выдать гораздо больше контекста и деталей, чем при написании текста, что значительно улучшает качество результата.
- Многоуровневые спеки проекта. Создавать и использовать как контекст несколько уровней документации, сгенерированных с помощью LLM:
- Продуктовая документация (use cases).
- Техническая документация (общая архитектура, модули).
- Схемы таблиц БД (часто самый важный контекст, т.к. из структуры данных следует все остальное).
- Контекстные
README.mdдля модулей. Для каждого модуля в проекте можно сгенерировать специальный README.md с кратким саммари его назначения и структуры, оптимизированным для LLM. Агента можно научить (через rules) всегда сначала искать и читать такой файл при работе с модулем.- Нюанс: Есть гипотеза, что генерация саммари одной моделью, а использование этого саммари другой — может быть эффективнее, так как это усредняет и снижает системные ошибки (bias) каждой отдельной модели.
- LLM генерирует только текст. Сама нейросеть не умеет выполнять команды, менять файлы или вызывать API.
- "Observer" (Наблюдатель) — ключевой компонент. В AI-инструментах (Code Llama, Cursor) есть слой "машинерии" (программный код), который парсит вывод LLM:
- Видит код -> применяет изменения к файлам.
- Видит команду терминала -> выполняет ее.
- Видит вызов инструмента (MCP/Tool) -> обрабатывает его.
- MCP (Tool Use) работает через
JSON, а не код.- LLM не генерирует код для вызова API, т.к. это нестабильно и небезопасно.
- Вместо этого она генерирует JSON-объект, соответствующий заранее определенной схеме (OpenAPI schema) для конкретного инструмента.
- Надежность генерации JSON обеспечивается механизмом constrained decoding, когда на каждом шаге генерации модель может выбрать только те токены, которые валидны для текущей точки в JSON-схеме.
- "Observer" перехватывает этот JSON, отправляет его на "MCP-сервер", тот выполняет детерминированный, заранее написанный код, и возвращает результат.
- Этот результат вставляется обратно в контекст LLM для следующего шага.
- "Агентность" — это способность LLM в связке с "Observer'ом" выполнять цепочку действий, где следующее действие зависит от результата предыдущего, создавая иллюзию автономной деятельности.
- Качество ретривера контекста — главный диффeренциатор. Успех AI-инструмента напрямую зависит от того, насколько хорошо он умеет автоматически находить и подавать в промпт релевантные фрагменты кода.
- Экономический трейд-офф. Компании-разработчики балансируют между качеством (больше контекста = лучше результат) и стоимостью (больше контекста = дороже API-вызов). Из-за этого качество инструментов может "плавать" (пример: Cursor, который стал экономить на контексте). Code Llama здесь в выигрыше, т.к. они владельцы модели и могут демпинговать для себя.
Вот что мы упустили в предыдущем сообщении:
Это не просто "контекст", а способ "программирования" поведения агента. Обсуждалось два уровня правил:
- Стиль кода (Coding Standards): В rules можно и нужно прописывать гайдлайны команды. Например: "Всегда пиши тесты", "Старайся использовать функциональный стиль", "Не используй X библиотеку". Это позволяет поддерживать консистентность кода.
- Методология разработки (Development Methodology): Можно заставить агента следовать определенному процессу. Ключевой пример — Test-Driven Development (TDD). Правило может звучать так: "Прежде чем писать код реализации, напиши тесты, покажи их мне на утверждение, и только после моего одобрения пиши код, который заставит эти тесты пройти".
В саммари было объяснено, как работают MCP, но не был сделан акцент на их главном практическом применении для разработчика.
- Борьба с API-галлюцинациями: Самая частая проблема LLM — выдумывание несуществующих методов или использование синтаксиса устаревших версий библиотек. Использование MCP-инструмента (в примере MCP ToolContext 7), который подгружает актуальную документацию по запросу, — это главный способ решения этой проблемы. Агента можно через rules заставить всегда обращаться к этому инструменту перед использованием любой внешней библиотеки.
Подчеркивалась важность правильной последовательности в освоении техник.
- Сначала ручной "Plan & Act": Прежде чем пытаться настроить систему с несколькими субагентами (один планирует, другой исполняет), необходимо освоить этот процесс вручную. То есть самому взять план из Google AI Studio и скормить его агенту в Code Llama.
- Зачем это нужно: Это помогает понять логику процесса, его сильные и слабые стороны. Автоматизация (субагенты) — это следующий, более продвинутый шаг, который будет успешен только после освоения ручного аналога.
Это важный ментальный сдвиг, который помогает интегрировать AI в работу опытных инженеров.
- AI-кодинг как репликация корпоративных процессов: Вместо хаотичной генерации кода ("vibe coding"), предложенный воркфлоу (планирование, ревью плана, исполнение, разделение ответственности) — это, по сути, воспроизведение проверенных временем инженерных практик, которые существуют в больших компаниях (работа тимлида/архитектора и разработчика). Мы просто заменяем некоторых участников процесса на AI-инструменты, сохраняя при этом структуру и контроль.