Модули 2.9–2.10: воркфлоу и финальный проект

Ведущая: Привет-привет! С вами AIStudy — бесплатный курс про искусственный интеллект, который можно слушать за рулём, в метро или на кухне. Записывать ничего не нужно: примеры кода, шаблоны и чек-листы лежат на сайте.

Ведущий: Привет! Это шестой, последний выпуск трека «Кодинг с агентами». Сегодня сразу два модуля: продвинутые воркфлоу, то есть приёмы для тех, кто уже работает с агентом каждый день, и финальный проект, где всё собирается в практику.

Ведущая: Последний выпуск! Значит, сегодня экзамен?

Ведущий: Скорее повторение пройденного на живом примере. Без оценок, зато с мини-проверкой в конце. И с разговором о том, что делать дальше.

Ведущая: Какой план?

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

Ведущая: Поехали!

Ведущий: Поехали!

Ведущая: Часть первая. Тесты как задание. Мы весь трек повторяли, что агента нужно просить конкретно. Как сделать ещё конкретнее?

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

Ведущая: То есть тест работает как техническое задание на языке примеров?

Ведущий: Именно. И помнишь принцип из первого выпуска трека: дайте агенту способ самому проверить свою работу? Тесты — как раз такой способ. Цикл такой. Вы пишете тест. Агент пишет реализацию. Запускаем: красный или зелёный? Если красный, агент чинит, и так по кругу. Когда всё зелёное, вы вместе наводите порядок в коде, а тесты стерегут, чтобы ничего не сломалось. Разработчики называют это «красный, зелёный, рефакторинг». Просто теперь в цикле ещё и агент.

Ведущая: Приведи пример.

Ведущий: Урок берёт проверку адреса электронной почты с бизнес-правилами. Вы пишете восемь тестов. Обычный адрес принимается. Адрес с плюсом и меткой тоже. Адрес без «собаки» отклоняется. Без домена после неё, с двумя «собаками», с пробелами — тоже. Заглавные буквы приводятся к строчным. И одноразовые почтовые домены отклоняются.

Ведущая: А дальше?

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

Ведущая: А как это выглядит в командной работе?

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

Ведущая: Звучит почти слишком хорошо. В чём подвох?

Ведущий: Тесты пишете вы, и они должны быть точными. Урок так и говорит: чем точнее тесты, тем точнее код агента. И не ждите идеала с первого раза: красный тест — это обратная связь, а не провал. Агент читает ошибку и правит. А плохой вариант урок описывает так: просто сказать «напиши валидатор» и надеяться на удачу.

Ведущая: Что задают на дом?

Ведущий: Валидатор телефонного номера. Шесть-восемь тестов: правильный формат, отклонить номер без кода страны, отклонить лишние пробелы, мало цифр, привести к нормальному виду без пробелов и дефисов. Отдайте тесты агенту, запустите. Если красные, покажите ему ошибку и повторяйте до зелёного.

Ведущая: Часть первая одной фразой?

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

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

Ведущая: Урок начинает именно с этого. Типичный день ревьюера: в очереди около двадцати запросов на слияние, в каждом двести-пятьсот строк. А искать надо ошибки, уязвимости, нарушения стиля, проблемы со скоростью. Результат: ревью поверхностное, ошибки уходят в продакшн.

Ведущий: И что предлагают?

Ведущая: Предварительное ревью агентом, до человека. Агент берёт типовую работу, а человек сосредоточивается на архитектуре и бизнес-логике. Готовые инструменты урок перечисляет: CodeRabbit, Sourcery, встроенное ревью у Claude Code, оно же работает как действие в GitHub, и ревью в Copilot. А потом показывает, как собрать своё без внешних сервисов.

Ведущий: Что агент проверит надёжно, а что нет?

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

Ведущий: Как это встроить в работу?

Ведущая: Двумя способами. Первый локальный: хук в гите, который перед каждым коммитом отдаёт агенту изменения и просит найти ошибки, уязвимости, нарушения стиля и мёртвый код. Если нашлась серьёзная уязвимость, коммит останавливается. Второй в общей автоматике: при открытии запроса на слияние запускается проверка, и агент оставляет комментарий. Код обоих вариантов лежит в уроке.

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

Ведущая: Дайте контекст. Базовый шаблон: проведи ревью, смотри на безопасность, скорость, читаемость и тестируемость, ответ в таком-то формате. Лучше с контекстом: что за система, какая нагрузка, сколько живёт кэш, что именно проверить и в каком порядке важности. Например: гонки между кэшем и базой, правильный сброс кэша, утечки памяти, утечка приватных данных. И приоритет: безопасность выше скорости, скорость выше чистоты кода.

Ведущий: Есть живой пример?

Ведущая: Любимый. Функция получения пользователя с кэшем, в которую авторы урока заложили шесть ошибок. Нет проверки входного номера. Нет обработки сбоев базы. Номер подставляется прямо в запрос, это та самая инъекция. Кэш растёт без границ. Функция отдаёт объект целиком, вместе с паролем. А при обновлении пользователя кэш не сбрасывается. Хорошее ревью агента находит всё это и предлагает исправления. И ещё отмечает, что хорошего: идея кэша верная, получение и обновление разведены по функциям.

Ведущий: Погоди. А если агент сам написал код и сам же его проверяет?

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

Ведущий: И как это сделать?

Ведущая: Два способа. Попросить запустить отдельного помощника с чистым контекстом: он получает только изменения и требования, не верит комментариям в коде и ищет крайние случаи, гонки данных, проглоченные ошибки и расхождения со схемой базы. Или две параллельные сессии: в одной автор реализует и гоняет тесты, в соседней вкладке или отдельной рабочей копии ревьюер получает только разницу и спецификацию и пишет замечания. Замечания возвращаются автору.

Ведущий: А последнее слово?

Ведущая: За человеком. Урок говорит прямо: ревью агента не заменяет человеческое. Агент не знает бизнес-контекста и не отвечает за продакшн. Опасный антипаттерн: «агент сказал, что всё хорошо, значит, сливаем». Агент ловит тактику, человек отвечает за стратегию. А для самопроверки: добавьте в код намеренную уязвимость и посмотрите, поймает ли её ваша настройка.

Ведущая: Часть третья. А если запустить сразу пять агентов? Это же в пять раз быстрее!

Ведущий: Не так быстро. Урок сначала описывает проблему: один агент как узкое место. Пять независимых частей проекта и неделя на всё. Один агент делает их по очереди. Решение: несколько агентов параллельно, каждый на своём модуле.

Ведущая: Как это устроено?

Ведущий: Схема называется DevSquad. Один менеджер, обычно Claude: он понимает весь проект, раздаёт задачи и собирает результаты. Несколько исполнителей делают узкие куски: бэкенд, интерфейс, инфраструктура. А синхронизация идёт через файлы, общий репозиторий или небольшой сервис статусов.

Ведущая: Покажи на примере.

Ведущий: Приложение со списком дел, три дня на рабочую версию. Менеджер пишет план. Бэкенд: модели, операции со списком, вход по токену, миграции базы. Интерфейс: компоненты, подключение к API, хранение состояния. Инфраструктура: контейнеры, автоматическая проверка, скрипт выкладки. У каждой части свой срок и точки сверки: в такое-то время бэкенд готов, интерфейс подключается; на второй день всё работает вместе.

Ведущая: А агенты?

Ведущий: У каждого своя сессия, свой промпт и своя папка. Бэкенд обязан выложить описание API для интерфейса. А узнают друг о друге агенты тремя способами. Общие файлы и гит: менеджер смотрит, какие файлы уже появились, все подтягивают свежие изменения. Общий файл статуса: что готово, что в процессе, что блокирует, когда следующая сверка. И продвинутый вариант: маленький сервис, у которого агенты спрашивают статус остальных. Для начала хватает файла.

Ведущая: Когда это вообще оправдано?

Ведущий: Урок даёт два списка. Оправдано: проект большой, как ориентир урок называет порядка пяти тысяч строк; нужны разные компетенции; жёсткие сроки; разные языки; три разработчика и больше; задачи независимы, когда спецификация готова. Не нужно: проект маленький, порядка тысячи строк; задачи связаны, и бэкенд ждёт описание API, которого ещё нет; быстрый прототип; один разработчик; один язык; или управление агентами заберёт больше времени, чем даст выигрыш.

Ведущая: Прямо как с людьми.

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

Ведущая: Чем всё это оркестрировать?

Ведущий: Три варианта. Самодельный скрипт, который запускает несколько сессий параллельно. OpenClaw: персональный ассистент, умеет держать несколько изолированных агентов, в том числе пишущих код, но для специальной оркестрации кода урок советует другие инструменты. И встроенные помощники Claude Code: специализированные агенты со своим контекстом, которых описывают в отдельных файлах. Вы говорите менеджеру: параллельно поручи бэкенд-агенту модели, интерфейс-агенту компоненты, а когда оба закончат, проверь, что API и интерфейс совместимы. И он запускает их сам.

Ведущая: И антипаттерн, конечно, есть.

Ведущий: «Мультиагенты для всего». Для проверки адреса почты завели трёх агентов: один проверяет, второй сохраняет, третий шлёт письмо. Итог: три сессии, три контекста, хаос синхронизации. Правило урока: маленькая задача — один агент за пять минут. Большой проект и критичные сроки — несколько параллельно. А когда контекст одного агента переполняется, несколько агентов как раз и спасают.

Ведущий: Часть четвёртая. По-моему, самая полезная в дороге: десять антипаттернов. Даже опытные люди их коллекционируют.

Ведущая: Идём по списку, а ты пробуй узнать себя. Первый: просьба без контекста. «Напиши функцию для обработки данных». Какие данные, в каком формате, что с ошибками? Агент гадает. Урок показывает «напиши парсер CSV»: получается читалка без обработки ошибок. Лечение: требования, пример вызова, что делать с пустым файлом и сломанной кодировкой.

Ведущий: Узнаю себя. Дальше.

Ведущая: Второй: нет файла контекста проекта. Агент не знает, это REST или GraphQL, какая база, какой фреймворк, где модели, как называть вещи. Лечение: файл AGENTS.md с архитектурой, стеком, структурой папок, соглашениями, бизнес-правилами и командами. Бизнес-правила в примере: пользователей удаляют логически, даты в одном часовом поясе, адреса почты в нижнем регистре. А в запросе пишете: прочитай этот файл для контекста.

Ведущий: Третий?

Ведущая: Слишком большие задачи. «Напиши весь API магазина: двадцать запросов, десять моделей, авторизация, права, кэш, логирование, срок сегодня вечером». Контекст переполняется, качество падает. Лечение: микрозадачи. Утром модели, днём авторизация, вечером товары. Каждая в свою сессию.

Ведущий: Четвёртый?

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

Ведущий: Пятый?

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

Ведущий: Шестой, наверное, про тесты.

Ведущая: Игнорирование тестов. «Я проверил вручную, работает». Через две недели коллега меняет функцию, ломаются пять крайних случаев, и никто не знает. Лечение то, с чего мы начали: тесты до кода.

Ведущий: Седьмой?

Ведущая: Загрязнение контекста. Слишком долгая сессия: старое смешивается с новым, агент начинает ошибаться, забывает, что уже сделал, и переписывает готовое. Лечение: новая сессия на каждую крупную задачу. А по руководству Anthropic урок называет четыре способа испортить контекст. Первый: сессия «всё в одну кучу». Сначала стили, потом миграция, потом тесты авторизации. Очищайте контекст между несвязанными задачами.

Ведущий: Второй способ?

Ведущая: Бесконечные правки поверх ошибок. Агент ошибся, вы написали «не работает», он ошибся снова, и вы спорите в том же окне. Тут правило двух попыток: если агент дважды ошибся в одной задаче, не пишите третью правку в ту же сессию. Откатитесь к контрольной точке или очистите контекст и напишите один чистый запрос с учётом того, что вы узнали из ошибки.

Ведущий: Это надо повесить на холодильник.

Ведущая: Третий: раздутый файл правил, больше двухсот строк. Агент перестаёт соблюдать даже важные запреты. Удаляйте всё, что агент умеет сам, а узкие правила выносите в отдельные файлы. И четвёртый: бесконечная разведка в основном окне. «Изучи, как устроена вся система биллинга», он читает сорок файлов, и на код места не остаётся. Поручайте чтение большого объёма субагенту.

Ведущий: Осталось три.

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

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

Ведущий: Как всё это удержать в голове?

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

Ведущий: Одной фразой?

Ведущая: Дайте агенту контекст и критерии, делите работу на части, проверяйте результат и не копите длинные сессии.

Ведущая: Часть пятая. Финальный проект. Что будем делать руками?

Ведущий: Три урока. Первый: подготовить проект, чтобы агент мог в нём разбираться и вносить правки. Второй: решить три задачи разной сложности. Третий: сравнить результаты. Начнём с подготовки.

Ведущая: Какой проект брать?

Ведущий: Урок предлагает три варианта: простой API на Express, бэкенд на Python с FastAPI или фронтенд на React. Подойдёт и учебный репозиторий из первого трека. Главное, чтобы это был живой репозиторий с настоящим кодом.

Ведущая: И что настраивать?

Ведущий: Пять шагов. Первый: файл AGENTS.md. Что за проект, из каких частей, стек, как запустить, правила кодирования: новые маршруты асинхронные, ошибки обрабатывает общий обработчик, входные данные проверяются, коммиты на английском, в запросе на слияние описываем задачу, решение и как проверить. Второй: файл CLAUDE.md, подробная инструкция для Claude Code. Прочитать AGENTS.md, поставить зависимости, запустить тесты, как работать с кодом, частые задачи: добавить маршрут, починить баг, отрефакторить. Общие правила: не менять настройки базы напрямую и всегда проверять, что новый код не ломает тесты.

Ведущая: А остальные три?

Ведущий: Третий: MCP-серверы для чтения файловой системы и работы с GitHub. Урок предупреждает: старый пакет для GitHub объявлен устаревшим, берите официальный сервер. Токен давайте с минимальными правами и храните в файле окружения, а не в коде. Четвёртый: хуки гита, чтобы перед коммитом запускался линтер, то есть проверка стиля. Пятый: правила для Cursor в актуальном формате, отдельной папкой правил: стиль, структура, что сделать перед коммитом, тесты, безопасность. Например, никогда не писать в лог пароли и токены.

Ведущая: То есть почти весь трек в одном репозитории.

Ведущий: Ровно. Файл контекста, правила, MCP, хуки. И чек-лист готовности: оба файла на месте, зависимости стоят, тесты зелёные, линтер чистый, файл окружения создан, хуки включены, правила для Cursor написаны, токены добавлены. Всё отмечено, значит, проект готов.

Ведущая: Теперь задачи.

Ведущий: Простая, средняя и сложная, по оценке урока примерно полчаса, пятьдесят минут и час двадцать. Первая: баг. Интерфейс возвращает ошибку сервера при пустом теле запроса на создание товара, а должен вернуть ошибку запроса с понятным сообщением. Образец запроса к агенту: прочитай два файла, опиши проблему и ожидаемый результат, решай пошагово. Запусти тесты и найди падающий, пойми, откуда ошибка, добавь проверку, исправь, снова запусти тесты, проверь линтер. И после каждого шага показывай результат.

Ведущая: Заметь, даже в простом баге тесты и до, и после.

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

Ведущая: А сложная?

Ведущий: Рефакторинг. Монолитный серверный файл больше пятисот строк разделить на модули: настройки, маршруты, обработчики запросов, логирование, утилиты. Плюс новый маршрут проверки здоровья сервиса и описание типов. Запрос в духе «тесты сначала»: сначала создать новую структуру, не трогая старый код, написать тесты на каждый модуль, переносить код по частям, старый файл удалить в конце, запустить полный набор тестов. И главное условие: не ломать существующие маршруты. В примере понадобились три итерации, в основном из-за ошибок в подключении файлов друг к другу.

Ведущая: И что урок говорит про результат?

Ведущий: Честную вещь: даже если агент не решил всё с первой попытки, это нормально. Важно, что он ускорил процесс. Лучший результат получается из взаимодействия человека и агента. А если вы учитесь в команде, решайте разные задачи и обсуждайте, какие запросы сработали лучше.

Ведущий: Часть шестая. Последняя. Как понять, помог ли агент или мне просто показалось?

Ведущая: Измерить. Урок предлагает отчёт по каждой задаче. Засекайте время от начала работы до зелёных тестов. Считайте итерации: итерация — это круг «запрос, ответ агента, проверка». Смотрите линтер и покрытие тестами. И поставьте субъективные оценки от одного до десяти по четырём вопросам: скорость, качество, удобство, надёжность. Среднее и будет итоговой оценкой. Для сравнения прикиньте, сколько заняло бы без агента.

Ведущий: Оценка без агента — это же выдумка.

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

Ведущий: Что показывают два примера отчётов?

Ведущая: Первый разработчик быстро решает простые задачи, медленнее сложные, но выигрывает везде. Второй ускорился скромнее, зато выучил технику. На простых задачах разница почти не видна: он и сам быстро чинит такие баги. Настоящая польза на новой функции, где он точно описал требования, и агент написал почти весь код верно. Его вывод: когда вы точны в описании, агент точен в коде. На рефакторинге агент потерялся в архитектуре, нужны были уточнения, но учебная польза была огромной. И совет: используйте ИИ как учителя. Объясняя задачу агенту, вы сами лучше её понимаете.

Ведущий: Когда агент помогает, а когда мешает?

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

Ведущий: Давай оглянемся на весь трек.

Ведущая: В первом выпуске мы говорили, что ИИ действительно меняет в разработке, какие бывают инструменты и как выбирать. Потом три терминальных агента: Claude Code, Antigravity и Codex. Потом Cursor и другие помощники в редакторе. Дальше файл инструкций AGENTS.md и подключение инструментов через MCP, российские модели для разработчиков, и сегодня воркфлоу и практика. Сквозная нить везде одна: дайте агенту контекст, дайте способ проверки и не отдавайте ему ответственность.

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

Ведущая: И мысль, которую урок ставит в центр: ИИ не волшебство, а инструмент, как гит, докер или эс-кью-эл. Требует обучения, у него есть сильные стороны и ограничения, и он становится мощнее вместе с опытом. Последний совет: не ждите, пока он станет идеальным. Начните сейчас.

Ведущий: Давай проверим себя?

Ведущая: Три вопроса про себя. Первый: какую ближайшую функцию вы напишете через тесты, и какие три теста запишете первыми, чтобы агент точно понял задачу?

Ведущий: Второй: какой из десяти антипаттернов знаком вам лично, и что вы сделаете иначе в следующий раз?

Ведущая: И третий: какие три задачи из вашего проекта, баг, функцию и рефакторинг, вы возьмёте для финальной практики, и что будете замерять?

Ведущий: Теперь итог. Первое: тесты — спецификация для агента, а красный тест — обратная связь. Второе: ревью агента ловит тактику, а стратегию и ответственность держит человек, и ревьюер с чистым контекстом надёжнее автора. Третье: несколько агентов нужны только для больших проектов с независимыми частями, на маленьких накладные расходы съедают выигрыш. Четвёртое: главные ошибки — расплывчатые запросы, слишком большие задачи, слепое доверие и длинные сессии, а лечатся они контекстом, микрозадачами, тестами и свежей сессией. Пятое: практика ценнее теории. Подготовьте проект, решите три задачи, замерьте и сделайте выводы на своих цифрах.

Ведущая: Примеры кода, шаблоны, чек-листы и карточка самопроверки лежат в уроках на сайте. Свой отчёт сохраните в репозитории учебного проекта: урок считает его хорошим материалом для портфолио или собеседования. Если заметили неточность в уроке, нажмите кнопку «Обратная связь» на сайте: сообщение сразу попадёт авторам.

Ведущий: На этом трек «Кодинг с агентами» закончен. Спасибо, что прошли его с нами. В курсе есть следующие треки: следующий называется «OpenClaw — персональный AI»: готовые боты в мессенджерах и собственный шлюз OpenClaw на вашем компьютере. А если хочется попробовать разные нейросети в одном месте, без VPN и с оплатой рублями, это наш сервис arckep.ru. Ссылка в описании.

Ведущая: Спасибо, что слушали! Было здорово!

Ведущий: До встречи!

Ведущая: До встречи!