Хардкорный курс «Harness-инженер»

Открытая лекция.

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

Разберём устройство архитектуры Transformer, рассмотрим её сильные и слабые стороны и выясним, какие особенности механизма работы LLM приводят к галлюцинациям, потере контекста, нестабильности результатов и другим ограничениям. Разберём, какие архитектурные решения и приёмы работы с LLM позволяют минимизировать влияние ограничений модели и получать более качественные и предсказуемые артефакты.

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

Разберём ключевые возможности современных harness-инструментов и научимся использовать их не как «чат с дополнительными кнопками», а как инженерное окружение для разработки.

Рассмотрим конфигурацию, инструменты, skills и subagents, разберём реальные сценарии их применения, неочевидные возможности и типичные ошибки проектирования. Отдельное внимание уделим практикам, которые позволяют превратить набор AI-инструментов в управляемую систему.

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

Разберём протокол MCP и его роль в построении расширяемых AI-систем. Создадим собственный MCP-сервер и клиента, подключим их к агенту и посмотрим, как через MCP предоставлять модели новые инструменты и источники контекста.

Затем перейдём к hooks и базовой оркестрации: научимся управлять поведением агентов, автоматически выполнять необходимые действия на различных этапах работы и строить первые многошаговые AI-процессы.

Чем больше автономности получает AI-агент, тем сложнее становится понять, где именно он ошибся и почему.

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

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

Современные harness-инструменты умеют «запоминать» контекст, но простого механизма памяти недостаточно для полноценной работы с большим проектом. Как организовать техническую и продуктовую информацию так, чтобы агент действительно мог использовать её в работе?

Разберём архитектуру Second Brain для AI-разработки: как хранить справочную информацию, архитектурные решения, правила проекта, техническую документацию и продуктовый контекст; как структурировать знания и предоставлять агентам именно ту информацию, которая необходима для выполнения конкретной задачи.

Можно ли организовать разработку так, чтобы AI не «придумывал» реализацию на каждом шаге, а последовательно выполнял формализованную спецификацию?

Разберём Spec-Driven Development — один из наиболее активно развивающихся подходов к AI-assisted разработке. Поговорим о структуре спецификаций, жизненном цикле изменений и взаимодействии спецификаций с агентами, skills и оркестрацией. Разберём, как превратить спецификацию из обычного документа в исполняемый элемент процесса разработки, позволяющий сделать работу AI более предсказуемой и воспроизводимой.

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

Разберём, как проектировать спецификации для кодогенераторов, способных создавать не только инфраструктурный слой и API-контракты, но и доменные и прикладные компоненты системы.

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

Как понять, что новый skill действительно улучшил работу агента? Что произойдёт с качеством после смены модели или версии LLM? И как убедиться, что улучшение одного сценария не привело к регрессии в другом?

Построим систему измерения эффективности AI-окружения. Разберём eval-подходы, A/B-тестирование skills и агентов, автоматизированную проверку генерируемых артефактов и способы отслеживания регрессий. Отдельно рассмотрим, как использовать результаты реальных задач проекта для постоянного улучшения skills, агентов и самого процесса разработки.

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

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

Большинство демонстраций AI-разработки ограничиваются одним репозиторием или отдельным микросервисом. Но реальные enterprise-системы состоят из десятков и сотен компонентов, а задачи часто проходят через несколько сервисов, репозиториев и команд. Что произойдёт, если дать AI-оркестратору доступ ко всему необходимому контексту распределённой системы?

Разберём подходы к оркестрации разработки в multi-service и distributed environments: работу с несколькими репозиториями, межсервисными зависимостями, общим контекстом и согласованными изменениями.

В финале перейдём к концепции Dark Factory — максимально автоматизированного конвейера разработки, в котором AI берёт на себя всё большую часть пути от постановки задачи и спецификации до реализации, проверки и подготовки результата к поставке.