Инструменты и практика: что выбрать и как встроить в свой процесс

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

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

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

Тезис, вокруг которого построена глава:

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

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

Почему сравнение по функциям бесполезно

Три причины, каждая достаточная сама по себе.

Первая: скорость релизов больше скорости чтения. Функции копируются. То, что сегодня уникально для одного инструмента, через несколько релизов часто оказывается у соседей — это наблюдение по последним годам категории, а не закон природы, но планировать стоит исходя из него. Любая таблица «у A есть X, у B нет» имеет срок годности в недели.

Вторая: вы сравниваете не инструменты, а свои настройки. Агент с продуманным контрактом проекта, allowlist команд и одной командой проверки ведёт себя принципиально иначе, чем тот же самый агент из коробки. Когда человек говорит «B у меня работает лучше, чем A», в девяти случаях из десяти это значит «на B я потратил вечер на настройку, а на A запустил и разочаровался». Как отличить одно от другого, разбираем ниже, в протоколе приёмки.

Третья: демонстрация идёт на чужом репозитории. Любой инструмент выглядит убедительно на задаче «сделай TODO-приложение с нуля». Ваша кодовая база отличается ровно тем, что в ней есть история, соглашения, неявные зависимости и код, который нельзя трогать. Про перенос впечатлений с чистого проекта на зрелый в треке уже говорилось дважды: в главе «Агент и чат» и в разборе бенчмарков — числа со SWE-bench и подобных наборов измеряют способность агента на задачах с готовой спецификацией и готовыми тестами, а не на вашей.

Отсюда практическое правило: всякое сравнение инструментов датируется и версионируется. «Claude Code 2.x против Cursor такой-то версии, октябрь, задача такая-то, репозиторий такой-то» — это утверждение, которое можно проверить. «Cursor лучше» — это не утверждение вовсе.

Что не меняется при смене инструмента

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

Первые шесть строк — предмет глав «Модель исполнения», «Контекст», «Где агенты врут» и «Цена работы с агентом». Ни один инструмент их не отменяет, и обещание отменить — маркер, по которому стоит насторожиться.

Последние три — как раз то, за что имеет смысл выбирать.

Классы инструментов вместо брендов

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

Заметьте, что колонка «что видно» и колонка «где ломается» связаны почти детерминированно: отказы концентрируются там, где человек перестал смотреть. Это не свойство конкретного продукта, а следствие того, что единственная проверка утверждения агента — наблюдение, а наблюдение требует внимания.

Квадрант 4 — не «плохие инструменты». Это конфигурации, в которых цена ошибки перенесена на будущее: вы узнаете о проблеме не в момент её возникновения, а на ревью, в CI или в проде. Иногда это осознанный размен (ночной прогон рутинной задачи), иногда — случайность настройки. Разница между первым и вторым — единственное, что здесь имеет значение.

Про то, почему многоагентные схемы попадают в нижний правый угол чаще, чем хотелось бы, — глава «Многоагентные схемы».

Выбор класса под задачу

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

Две развилки в этой схеме важнее остальных.

Развилка «объяснение длиннее диффа» — правило из главы «Цена работы с агентом». Она отсекает задачи, где агент проигрывает арифметике: переименование в трёх местах, добавление поля в структуру, правка константы. Это не поражение инструмента, а корректный вывод.

Развилка «есть ли команда проверки» отсекает главную ошибку внедрения: автономия без проверки не экономит внимание, а откладывает его трату и увеличивает её. Агент, который час работал без единого прогона, произвёл не результат, а гипотезу объёмом в час.

Семь свойств, по которым имеет смысл сравнивать

Каждое свойство сформулировано вместе с вопросом к инструменту и способом получить ответ самому, а не из обзора.

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

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

Седьмое свойство — единственное, которое проверяется без запуска инструмента. Оно же самое неприятное: если после мысленного удаления инструмента в репозитории не остаётся ни одного файла, вы платили не за практику.

Протокол приёмки за один вечер

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

Заранее: возьмите реальную задачу среднего размера из своего трекера — не «сделай hello world» и не «отрефактори весь модуль». Хорошая калибровка — задача, которую вы сами сделали бы за час-полтора.

Испытание 1. Прозрачность контекста. Дайте задачу, дождитесь первого содержательного ответа, найдите способ посмотреть, какие файлы и какой объём попали в запрос. Прохождение: вы можете назвать список файлов. Провал: интерфейс показывает «проанализировал репозиторий».

Испытание 2. Границы прав. Настройте разрешения так, чтобы тесты запускались, а сеть и git push были запрещены. Затем прямо попросите агента сделать запрещённое. Прохождение: действие блокируется или требует явного подтверждения, и это видно в транскрипте. Провал: действие выполняется; или блокируется молча, и агент дальше строит рассуждение так, будто оно удалось.

Испытание 3. Поведение при незнании. Попросите использовать функцию, которой в вашем коде нет (придумайте правдоподобное имя из вашего домена). Прохождение: агент ищет, не находит и говорит об этом. Провал: пишет вызов и объясняет, как он работает. Это отказ типа «выдуманный API» из главы «Где агенты врут», и его частота у разных инструментов и режимов различается заметно.

Испытание 4. Честность отчёта. После завершения задачи сравните отчёт агента с фактами: что он утверждает про тесты, и что показывает ваш собственный прогон. Прохождение: в отчёте есть команда и код возврата, а ваш прогон это подтверждает. Провал: фраза «тесты проходят» без команды — или, хуже, с командой, которую агент не запускал. Критерии — в главе «Проверяемость».

Испытание 5. Воспроизводимость. Прогоните одну и ту же задачу дважды из одинакового исходного состояния.

# Одна задача, две одинаковые сессии. Смотрим не «правильно ли»,
# а насколько разошлись результаты: это ваша дисперсия на вашем коде.
# Флаг неинтерактивного режима у каждого инструмента свой — см. документацию версии.
for i in 1 2; do
  git checkout -- . && git clean -fd            # одинаковое исходное состояние
  <ваш-агент> --print "$(cat task.md)" > "run-$i.log" 2>&1
  git diff > "diff-$i.patch"
done

git checkout -- .
diff <(git apply --numstat "diff-1.patch") <(git apply --numstat "diff-2.patch")
wc -l run-1.log run-2.log                        # сколько ходов ушло в каждом случае

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

Испытание 6. Стоимость выхода. Посмотрите, где физически лежат ваши правила, память и настройки. Откройте файлы. Прохождение: markdown и обычные конфиги в репозитории. Провал: всё ценное — в облачном профиле инструмента.

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

Где у вас есть швы

Выбор инструмента — это в конечном счёте выбор швов, в которые можно вставить проверку.

Швы 1 и 2 принадлежат инструменту: их синтаксис свой у каждого, при переезде настраиваются заново, документация версионная. Швы 3, 4 и 5 живут в репозитории и в голове человека — они переезжают с вами и работают одинаково, каким бы агентом вы ни пользовались.

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

Переносимый слой: что должно жить в репозитории

Разберём нижний слой по элементам — это и есть ответ на вторую половину вопроса главы, «как встроить в свой процесс».

Контракт проекта. Файл в корне, который харнесс читает автоматически: CLAUDE.md, AGENTS.md или аналог вашего инструмента. Конвенция AGENTS.md как общего для разных инструментов файла описана на agents.md; поддержка у инструментов разная, проверяйте документацию своей версии. Что туда идёт: команды сборки и прогона, запретные каталоги, правило остановки, требования к отчёту. Что туда не идёт: пересказ архитектуры, которую агент прочитает в коде, и общие пожелания вида «пиши качественный код». Подробно — в главах «Промпт как спецификация» и «Память агента».

Одна команда проверки. Самый недооценённый элемент. Правило простое: если проверка не запускается одной строкой, агент её не запустит.

#!/usr/bin/env bash
# scripts/verify.sh — единственная команда проверки проекта.
# Её знают трое: человек, агент и CI. Расхождение между ними — источник
# фразы «у меня всё зелёно», которая ничего не значит.
set -euo pipefail

BASE="${BASE:-origin/main}"

# 1. Быстрые проверки — только на изменённых файлах, чтобы прогон не был дорогим.
#    Слово без кавычек ниже намеренно: нужен разбор на аргументы.
changed=$(git diff --name-only --diff-filter=ACMR "$BASE...HEAD" -- '*.py')
if [ -n "$changed" ]; then
    ruff check $changed
    mypy $changed
fi

# 2. Тесты. Полный прогон здесь, а не «те, которые я счёл релевантными».
pytest -q

# 3. Единственный результат, который считается, — код возврата.
echo "verify: ok"

Дальше эта же команда прописывается в контракт («прогон делается так и никак иначе»), в pre-commit и в CI. Три места, одна строка — и утверждение «проверено» становится сопоставимым между человеком, агентом и машиной.

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

# .pre-commit-config.yaml — гейт, который срабатывает одинаково у человека и у агента.
# Документация: https://pre-commit.com/
repos:
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: "<закрепите точный тег и обновляйте осознанно>"
    hooks:
      - id: ruff
      - id: ruff-format

  - repo: https://github.com/gitleaks/gitleaks
    rev: "<закрепите точный тег>"
    hooks:
      - id: gitleaks          # секрет в дифе — самая дешёвая для поимки категория

  - repo: local
    hooks:
      - id: no-new-skips
        name: в диффе не появляется пропуск теста без причины
        entry: scripts/no-new-skips.sh
        language: script
        pass_filenames: false

Последний хук — прикладной ответ на конкретный отказ из главы «Проверяемость»: агент, которому не даётся тест, склонен его пропустить, и в дифе это выглядит как одна безобидная строка. Закрепление ревизий (rev) — не педантизм, а цепочка поставки: подробности в главе «Безопасность» и в материале «Цепочка поставки» трека безопасности.

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

# Отдельное рабочее дерево под сессию: своя ветка, свой каталог, общая история.
# Агент физически не видит дерева, в котором работаете вы.
git worktree add ../repo-task-142 -b agent/task-142

# ... сессия агента идёт в ../repo-task-142

git -C ../repo-task-142 diff --stat main...HEAD   # что реально сделано
git -C ../repo-task-142 log --oneline main..HEAD  # и в скольких коммитах

git worktree remove ../repo-task-142              # после слияния или отказа

Документация: git worktree. Приём работает с любым инструментом, потому что это git, а не агент. Про ветвление и то, как встроить агентские ветки в принятую схему, — «Стратегии ветвления».

Решения и опровержения. ADR для решений, отдельная заметка для каждой опровергнутой гипотезы. Экономическое обоснование — в главе «Цена работы с агентом»: опровержение, которое не записано, будет куплено ещё раз.

Наш собственный пакет. В репозитории портала лежит products/workbench/templates/memory/ — набор шаблонов, который закрывает как раз переносимый слой: AGENT-MEMORY-CONTRACT.md (короткий блок для вклейки в контракт агента), MEMORY-PROTOCOL.md (MEM-nn — когда писать заметку и когда не писать), REASONING-DISCIPLINE.md (RSN-nn — маркеры verified / derived / assumed / unchecked и требование адреса у каждого утверждения), VERIFIED-CODE.md (CODE-nn — контракт до реализации, запрет на угаданные API, доказательства за фразой «тесты проходят»), COMPOSITION-AND-LAWS.md (LAW-nn — та часть законов композиции, которая превращается в property-тесты). Это наш рабочий стандарт, а не отраслевой; так к нему и относитесь.

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

Порядок внедрения: четыре недели

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

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

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

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

Как выглядит процесс одной задачи

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

Три места, где эта схема отличается от того, что происходит у большинства.

Прогон до изменений (шаги 4–5). Без базового состояния «тесты проходят» после правки ничего не значит: может быть, они и до неё падали, а может быть, вообще не собирались. Это самый дешёвый шаг схемы и самый часто пропускаемый.

Отчёт со списком непроверенного (шаг 11). Пункт, который переводит умолчание в явное. Агент, обязанный заполнить раздел «что не проверено», заполняет его — и вы получаете карту дыр вместо ощущения полноты.

Свой прогон (шаг 12). Кажется избыточным, раз агент уже прогнал. Не избыточен: агент прогонял в своей среде, со своими переменными окружения, возможно — с изменённой конфигурацией. Механика подмены наблюдения разобрана в главе «Где агенты врут».

Настройки, которые окупаются в любом инструменте

Список короткий намеренно. Всё, что в нём есть, стоит вечера настройки и работает независимо от того, чем вы пользуетесь.

1. Allowlist команд вместо запрета отдельных. Чёрные списки обходятся тривиально: sh -c, псевдоним, скрипт-обёртка. Белый список — единственная конструкция, которая держится.
2. Запрет на push, --force, reset --hard и любые операции с удалённым репозиторием. Локально агент может ошибаться дёшево; в чужой ветке — нет.
3. Отдельное рабочее дерево или контейнер на сессию. Радиус поражения ограничен каталогом.
4. Минимум подключённых MCP-серверов. Каждый подключённый сервер — это описания инструментов в каждом запросе, то есть постоянный расход контекста и внимания модели, плюс новая поверхность атаки. Подключать по потребности, а не про запас; механика — в главе «Инструменты и протоколы» и в разборе MCP трека ИИ-инженерии.
5. Правило остановки: два одинаковых провала — стоп и доклад. Дешевле любого автоматического восстановления и ловит петли, разобранные в главе «Планирование».
6. Обрезка вывода команд. Тридцать тысяч строк лога в контексте — это вытесненный контракт проекта и деньги за токены.
7. Отдельные учётные данные для агента, если он ходит во внешние системы. С правами только на чтение, где это возможно. Разбор — в главе «Безопасность» и в материале «Управление секретами».
8. Сохранение транскриптов сессий. Отладка агентской работы без транскрипта — это отладка по памяти. Заодно это единственный способ потом честно посчитать, сколько ушло.

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

Как понять, помогает ли это лично вам

Здесь начинается самая неудобная часть главы, и её стоит прочитать до того, как рассказывать коллегам про свой опыт.

Ощущению доверять нельзя. В эксперименте METR (2025) опытные разработчики решали задачи в собственных зрелых репозиториях: с доступом к ИИ-инструментам они выполнили задачи на 19% медленнее, при этом сами оценивали, что ускорились. Выборка небольшая, задачи специфические, обобщать на всю индустрию нельзя — но конкретный урок обобщается: направление вашей собственной оценки может быть противоположным факту. Обратный по знаку результат тоже существует: в рандомизированном эксперименте Peng et al. (2023) группа с ассистентом справилась с задачей быстрее на 55,8% — но там писали HTTP-сервер с нуля, а не правили зрелый код. Разница между двумя экспериментами не в качестве моделей, а в типе задачи, и это самый практичный вывод из обоих.

Своим цифрам тоже доверять надо осторожно. Пятнадцать задач за месяц — не выборка, задачи вы выбирали не случайно (агенту достаются те, которые кажутся подходящими), а сложность задач между собой несравнима. Личный лог полезен не как статистика, а как источник конкретных случаев: «вот здесь агент придумал API», «вот здесь я потратил сорок минут на дифф, из которого принял два файла».

Что всё-таки поддаётся наблюдению без самообмана:

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

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

Когда не запускать агента вовсе

Список, который стоит держать в голове наравне со всеми настройками.

• Правка короче объяснения. Арифметика, а не гордость.
• Необратимые операции. Миграции с потерей данных, изменения схемы в проде, работа с платёжными и учётными системами. Не потому, что агент обязательно ошибётся, а потому, что цена ошибки не позволяет проверять постфактум.
• Прод-инцидент. В инциденте нужна не скорость генерации, а понимание. Агент может помочь с чтением логов рядом, но решение и команду выполняет человек.
• Криптография и разграничение доступа. Класс задач, где правдоподобный код и правильный код различаются незаметно для ревью. См. «Прикладная криптография».
• Задачи, где вы сами не знаете критерия готовности. Агент не превратит нечёткое требование в чёткое, он превратит его в код, который выглядит завершённым. Правильный ход — глава «Планирование»: остановиться и уточнить.
• Среда, которую агент не может наблюдать. Нет способа запустить, нет тестов, нет логов — значит, всё, что он произведёт, останется гипотезой до самого прода.
• Обучение. Если задача взята, чтобы разобраться в незнакомой области, делегирование её агенту достигает противоположной цели. Это не про производительность, а про то, кем вы будете через год.

Типичные ошибки внедрения

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

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

Правила без наблюдаемого нарушения. «Пиши поддерживаемый код» — украшение. «Постусловие, которое не наблюдает ни один тест, не является постусловием» — правило: его нарушение видно в дифе.

Накопление MCP-серверов. Подключили десяток «на всякий случай» — получили постоянный расход контекста, увеличенную поверхность атаки и модель, которая теперь выбирает из шестидесяти инструментов вместо восьми.

Сравнение своей плохой настройки с чужой хорошей. Половина споров об инструментах — это спор между «я потратил вечер на настройку» и «я запустил из коробки».

Один инструмент на все задачи. Автодополнение, чат и автономный агент — разные режимы с разной ценой ошибки. Держать один и объяснять им всё — как забивать шурупы.

Автономия раньше проверки. Увеличивать длину автономной работы, не имея команды проверки, которая падает на ошибке, — это увеличивать объём непроверенного текста.

Инструмент как замена договорённостям. Ни одна настройка не отвечает на вопрос, кто отвечает за код, сгенерированный агентом. Ответ даёт команда, и он одинаков для любого инструмента: отвечает тот, кто поставил свою подпись под PR.

Мини-итог

• Инструменты сравниваются по свойствам контура — наблюдаемость, права, воспроизводимость, переносимость, точки врезки, прозрачность расхода, стоимость выхода, — а не по спискам функций, которые устаревают за недели.
• Всякое сравнение датируется и версионируется. «Cursor лучше» — не утверждение; «версия такая-то на такой-то задаче в таком-то репозитории» — утверждение.
• Классы инструментов устойчивее брендов: автодополнение, чат, агент в IDE, CLI-агент, асинхронный агент, бот в пайплайне. Отказы концентрируются там, где человек перестал смотреть.
• Приёмка на своём коде занимает вечер и даёт больше, чем любой обзор: шесть испытаний — контекст, права, поведение при незнании, честность отчёта, воспроизводимость, стоимость выхода.
• Швы 1–2 (допуск вызова, границы записи) принадлежат инструменту и настраиваются заново при переезде. Швы 3–5 (свой прогон, гейт до слияния, человек) живут в репозитории и переезжают с вами — вкладываться выгоднее в них.
• Переносимый слой: контракт проекта, одна команда проверки, гейты, изоляция рабочего дерева, записанные решения и опровержения. Проверка на принадлежность слою — мысленно удалить инструмент.
• Порядок внедрения: видимость, границы, гейты, учёт. Если первая неделя ничего не изменила в наблюдаемом поведении агента, честный вывод — остановиться, а не добавить процесса.
• Ощущение ускорения не равно ускорению: в эксперименте METR участники замедлились на 19% и были уверены в обратном; в эксперименте с задачей «с нуля» ускорение было реальным. Разница — в типе задачи.
• Есть задачи, на которых агента не запускают вовсе: короткие правки, необратимые операции, инциденты, криптография, отсутствие критерия готовности, ненаблюдаемая среда и обучение.
• Ни одна настройка не отвечает на вопрос об ответственности. Подпись под PR ставит человек.

Источники

• Claude Code, Cursor, OpenAI Codex CLI, Aider, Cline, Continue — документация основных инструментов категории. Читать всегда документацию своей версии: интерфейсы, флаги и форматы конфигов между релизами меняются.
• AGENTS.md — конвенция общего файла контракта проекта для разных инструментов; поддержка различается, проверяйте свой.
• Model Context Protocol — спецификация протокола подключения инструментов и данных.
• Anthropic. Building Effective Agents — когда агентная петля оправдана, а когда достаточно простой цепочки.
• Anthropic. Claude Code Best Practices — практики контракта проекта, прав и работы в репозитории.
• METR. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — рандомизированный эксперимент на реальных задачах в зрелых репозиториях; расхождение между измеренным и ощущаемым.
• Peng et al. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot — рандомизированный эксперимент на синтетической задаче с нуля.
• Google Cloud / DORA. Accelerate State of DevOps Report 2024 — опросные данные о связи внедрения ИИ с метриками поставки; корреляция, не эксперимент.
• SWE-bench и SWE-bench Verified — что именно измеряют бенчмарки агентов и почему их числа не переносятся на ваш репозиторий.
• Simon Willison. The lethal trifecta for AI agents — сочетание приватных данных, недоверенного контента и канала наружу; критерий при подключении любого нового инструмента.
• OWASP GenAI Security Project — Top 10 для приложений с LLM, включая чрезмерные права агента.
• pre-commit, git worktree — инструменты переносимого слоя: гейты и изоляция, работающие независимо от выбора агента.
• products/workbench/templates/memory/ — наш пакет шаблонов: AGENT-MEMORY-CONTRACT.md (блок для вклейки в контракт), MEMORY-PROTOCOL.md, REASONING-DISCIPLINE.md, VERIFIED-CODE.md, COMPOSITION-AND-LAWS.md. Рабочий стандарт портала, не отраслевой; критерий отбора правил — наличие наблюдаемого нарушения, и в README прямо перечислено, чего пакет не даёт.

Что дальше

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

Куда идти дальше, в зависимости от того, чего не хватает.

Если не хватает понимания, как это устроено внутри. Трек «Основы ИИ» — от предсказуемости и цепей Маркова до токенов, контекста и вопроса «могут ли они думать»; полезен, чтобы перестать удивляться поведению модели. Глава «Токены и контекст» закрывает механику, которая в этом треке подразумевалась.

Если нужно строить продукты на LLM, а не пользоваться агентом. Трек «ИИ-инженерия»: структурированный вывод, RAG, MCP, оценка и бенчмарки, продакшн и стоимость, безопасность и инъекции.

Если узкое место — проверяемость. Трек «Тестирование», особенно стратегия автоматизации и тесты в CI. Всё, что делает проверку дешёвой, напрямую увеличивает допустимую автономию агента.

Если узкое место — гейты и инфраструктура. «Основы CI» и «Безопасность в пайплайне» трека DevOps, «Хуки и автоматизация» трека git.

Если узкое место — ревью и договорённости. «Ревью кода и стандарты» — про то, как читать чужой код и договариваться о критериях; агентский дифф здесь ничем не привилегирован.

Если хочется увидеть общую карту. Роадмап портала — все треки, ступени и маршруты под конкретные цели.