Агент пишет код. А кто проектирует работу?

Codex, Claude Code, GitHub и Linear: собираем среду, в которой агент доводит задачи до результата

Сергей Авдейчик · DOBROVOLA · 15 сентября 2026 года

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

Иногда — да. А иногда агент просто очень деятельно провёл время.

Разговор об этом идёт уже не только среди любителей новых инструментов. Мартин Фаулер описывает agentic programming — разработку, в которой человек направляет агента и проверяет его работу. Эдди Османи предлагает думать не об отдельном запросе, а о цикле выполнения и проверки. Роберт Мартин вместе с Джастином Мартином показывает многоагентный процесс, где написание кода окружено специализированными проверками. Это разные подходы, а не единый манифест. Но вопрос у них общий: как организовать работу, когда код производит не только человек? [1] [2] [3]

И вот здесь начинается самое интересное для студента. Можно учиться получать красивые ответы. А можно научиться строить маленькую инженерную систему, которая превращает замысел в проверяемый результат.

В предыдущих материалах мы обсуждали Software 3.0 и путь от разговора к блюпринту, исследованию, техническому заданию и приёмке. Теперь идём дальше: замысел уже понятен — как организовать саму разработку? Связанный материал о проверяемой работе приведён в источниках. [23]

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

1. Рабочая среда — это не окно Codex

Когда меня спрашивают, где работает мой агент, ответ «в Codex» оказывается слишком коротким. Это примерно как сказать, что инженер работает в текстовом редакторе. Верно, но из картины исчезли проект, требования, коллеги, испытания и само изделие.

В моей схеме у проекта есть два репозитория и пространство задач в Linear.

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

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

Linear хранит состояние работы: какую веху выполняем, что поручено, что заблокировано, где доказательства результата и какое принято решение. В самой платформе вехи объединяют задачи внутри проекта; превращение этой структуры в маршрут для агентов — уже наша организация работы. [4]

Codex или Claude Code — инструмент выполнения внутри этой среды. Сегодня один, завтра другой. Если вся логика проекта жила исключительно в исчезнувшей сессии, мы потеряли не инструмент, а управление проектом.

Я предлагаю такое разделение: документы отвечают на вопрос «что и почему строим», репозиторий приложения — «что построено», Linear — «что происходит сейчас». Задачи и вехи задают крупное направление движения. AGENTS.md, CLAUDE.md, роли и скиллы — ручки более тонкой настройки: как действовать и что проверять на выбранном участке. Ни один слой не заменяет остальные. Два репозитория не являются единственно возможной архитектурой хранения. Для маленького упражнения допустимо начать с двух разделов одного репозитория. Но границу между замыслом и исполнением лучше сохранить с первого дня.

Схема 1. Среда больше инструмента.

>

Блюпринт и ТЗ в project-docs → веха и задачи в Linear → работа агента → изменения и проверки в project-app → решение человека.

>

Комментарии в Linear связывают поручение, результат и следующий шаг. Codex и Claude Code находятся внутри этого процесса, а не заменяют его.

Как не получить три конкурирующие правды

Не копируйте одно и то же требование в пять мест. В задаче укажите конкретный раздел ТЗ и его версию. В запросе на слияние изменений — pull request, дальше PR — укажите задачу. В комментарии с результатом — PR и проверенный коммит.

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

2. Что на самом деле получает модель

Слово harness можно перевести как «обвязка». Это программная часть вокруг модели: она передаёт контекст, организует вызовы инструментов и возврат результатов, поддерживает цикл работы. В инженерном разборе OpenAI хорошо видно: модель и агентный цикл — не одно и то же. [5]

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

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

В опубликованном OpenAI разборе Codex исходный запрос включает базовые инструкции, сообщения разработчика о среде и настройках, пользовательский контекст из файлов проекта и сведения о скиллах, затем текущую задачу. Это описание конкретного устройства, опубликованное 23 января 2026 года, а не обещание неизменного порядка для всех будущих клиентов. [5]

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

У Codex и Claude Code похожие цели, но не одинаковые механизмы

В Codex проектные инструкции собираются из AGENTS.md и, при наличии, AGENTS.override.md. Учитываются пользовательские настройки и путь от корня проекта к текущему рабочему каталогу; более локальные инструкции добавляются позже. Не надо ожидать, что все файлы во всех подпапках заранее попадут в контекст. Документация отдельно описывает предел объёма и формирование цепочки инструкций при запуске. [6]

Claude Code использует CLAUDE.md, проектные правила и память. Документация прямо отделяет их от принудительно исполняемой конфигурации. Файлы в родительских каталогах загружаются при старте, инструкции из вложенных каталогов могут подключаться по мере чтения соответствующих файлов. Поддерживаются импорты вида @путь; наличие файла само по себе ещё не доказывает правильность его подключения. [7]

Схема 2. Два разных контура.

>

Контекст модели: инструкции платформы → подключённые правила проекта → текущая задача → прочитанные материалы и результаты инструментов.

>

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

>

Это концептуальная схема, а не универсальная таблица приоритетов. У каждого клиента свой механизм загрузки. Технические границы не являются ещё одним абзацем промпта.

Инструкция, полномочие и ограничение — три разные вещи

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

Поэтому правило в AGENTS.md не заменяет настройки доступа. Anthropic описывает защиту как сочетание поведения модели, ограничения среды и контроля доступных ресурсов. Документ, который агент читает, тоже может содержать вредоносные указания: доступный источник не обязательно является доверенной инструкцией. [8]

Для учебного проекта я рекомендую отдельные тестовые данные, минимально необходимые доступы и запрет автоматического выпуска без согласованной проверки. В GitHub можно требовать PR, проверки и ревью перед слиянием; доступность конкретных правил зависит от тарифа и типа репозитория. Важно проверить и возможные обходы правил администратором или сервисной учётной записью. [9]

Ещё тонкость: локальный sandbox не следует автоматически считать защитой внешнего MCP-инструмента. Удалённый сервис должен сам проверять свои права и допустимые операции. Эта граница отдельно отмечена в разборе Codex. [5]

3. Сначала стартовый пакет. Не конституция на двести страниц

Мой обычный путь начинается не с команды «создай приложение». Сначала я передаю текстовой модели утверждённый блюпринт, ТЗ и свои предпочтения проектирования. В моей практике это часто GPT в режиме Pro. Прошу изучить актуальную документацию выбранной агентной платформы и подготовить стартовый комплект файлов.

Ключевое слово — стартовый.

Мы пока не знаем всех будущих проблем. Пытаться заранее написать идеальные инструкции на весь проект — примерно как до первого занятия составить инструкцию на каждую возможную ошибку студента. Получится много текста и мало полезных ориентиров.

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

Этот подход не привязан к Python

Универсальны замысел, границы задачи, порядок работы, доказательства результата и правила остановки. Меняются язык, структура приложения и команды проверки.

Для Python в профиле стека могут быть pytest и ruff, принятые правила типов и расположения модулей. Для TypeScript — менеджер пакетов, команды проверки типов, тестирования и сборки. Запись pnpm test имеет смысл только тогда, когда соответствующий сценарий действительно определён в проекте. Копирование чужого файла не создаёт отсутствующую инфраструктуру.

Поэтому я разделяю ядро процесса, профиль стека и адаптер платформы. Это рекомендация по устройству нашего пакета, не встроенная терминология Codex.

Схема 3. Что переносится между проектами.

>

Ядро: источники требований, роли, передача работы, приёмка.

>

Профиль стека: язык, зависимости, структура, команды запуска и тестов.

>

Адаптер платформы: обнаруживаемые файлы инструкций, формат скиллов, настройки агентов и инструментов.

>

При переходе с Python на TypeScript не нужно заново изобретать управление работой. Но команды и структуру надо проверить заново.

Минимальная раскладка может выглядеть так:

workspace/
  project-docs/                 # отдельный Git-репозиторий
    blueprint.md
    specifications/project.md
    milestones/M1.md
    decisions/
    agent-design/roles/
    agent-design/skills/
  project-app/                  # отдельный Git-репозиторий
    AGENTS.md
    CLAUDE.md
    PROJECT_CONTEXT.md
    STACK.md
    src/
    tests/
    .gitignore

PROJECT_CONTEXT.md — наша карта входа: адреса репозиториев, версии документов, активная веха, способ доступа. STACK.md — реальные команды и соглашения. Каталоги agent-design/roles и agent-design/skills — наши исходные материалы, а не волшебные имена, которые автоматически читает любой агент.

Поручение модели, собирающей пакет

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

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

Поручение агенту, который разворачивает пакет

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

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

4. Как писать AGENTS.md, роли и скиллы без магии

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

Общие инструкции отвечают: «Какие правила действуют постоянно?» Роль — «За какой результат Вы отвечаете сейчас?» Скилл — «Как выполнить повторяющуюся процедуру?»

Тонкий AGENTS.md

Вот учебная заготовка. Ссылки и команды в реальном проекте должны вести к существующим материалам.

# Работа в проекте

Перед началом прочитайте PROJECT_CONTEXT.md и STACK.md.
Работайте только по назначенной задаче текущей вехи.
Сверьте версию ТЗ и критерии приёмки в Linear.

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

Не добавляйте незапрошенный функционал и рефакторинг.
Не публикуйте секреты. Не выполняйте выпуск без разрешения.

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

Не нужно перечислять здесь все эндпоинты приложения. Файл должен помогать найти нужные правила, а не конкурировать с ТЗ.

Для Claude Code можно сделать небольшой CLAUDE.md, который подключает общую основу, а ниже содержит только отличия клиента:

@AGENTS.md

# Особенности Claude Code
Перед началом проверьте доступность нужных инструментов.
Роль и задачу получите из стартового поручения.

Такой импорт поддерживается Claude Code. После настройки проверьте загруженный контекст средствами клиента; не считайте сам факт сохранения файла доказательством его применения. [7]

Роль — не список всех достоинств идеального программиста

Для исполнителя достаточно ясного назначения: реализовать согласованную задачу, ограничить изменения её рамками, воспроизвести проверки и предъявить результат.

У руководителя другая работа: сопоставлять реальное продвижение с целью вехи, обнаруживать пробелы в доказательствах и выдавать конкретные корректировки. Не «быть самым опытным senior principal staff architect», а проверять определённые вещи.

При необходимости оба могут обращаться к специализированным помощникам. Один умеет исследовать код, другой — проверять тестовые сценарии, третий — искать риск нарушения контракта API. Но количество ролей оправдывается работой, а не красотой диаграммы.

На дату проверки Codex поддерживает проектные определения пользовательских агентов в .codex/agents/*.toml; Claude Code — в .claude/agents/*.md с конфигурационным заголовком. Это разные форматы. Наш текст роли нужно явно передать сессии или оформить в соответствующий адаптер. [12] [13]

Скилл: когда, с чем и до какого результата

В обеих платформах скилл строится вокруг SKILL.md. Описание помогает выбрать процедуру, а подробности подключаются по необходимости. Для проектного размещения документация Codex указывает .agents/skills/, Claude Code — .claude/skills/. Совместимость идеи не означает идентичность всех дополнительных полей и способов подключения. [10] [11]

Пример собственной процедуры:

---
name: verify-delivery
description: Проверка результата задачи перед передачей человеку.
---

Вход: задача, критерии приёмки, проверяемый коммит,
перечень изменённых файлов и результаты CI.

1. Сопоставьте каждый критерий с проверяемым доказательством.
2. Проверьте основной, пустой и ошибочный сценарии.
3. Сверьте изменения с границами задачи.
4. Используйте разрешённые команды из STACK.md.
5. Отделите дефекты от непроверенных предположений.

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

Не исправляйте код в рамках этого скилла.
Не меняйте критерии и не выполняйте слияние или выпуск.

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

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

5. Одна веха — один понятный результат

Возьмём учебное приложение ReadingLab. Студент отмечает занятия: дата, тема, длительность. Хотим добавить отчёт за выбранный период. В этом примере запись занятий уже существует; первая рассматриваемая веха касается только отчёта.

Плохая веха: «Разработать систему аналитики учебной активности».

Хорошая: «Пользователь открывает отчёт за период и видит корректные данные, включая честное отображение пропусков».

Теперь задача перестала быть мешком возможностей. Мы можем назвать её границы. Например, сейчас делаем экран и расчёт; рекомендации модели, экспорт PDF и сравнение с другими студентами оставляем за пределами вехи.

Внутри достаточно нескольких последовательных задач: согласовать контракт и примеры; реализовать расчёт и выдачу данных; подключить экран; провести итоговую проверку сценария. Число задач — инструмент управляемости, не культ маленьких карточек. Если задача всё равно необъятна, уменьшите веху.

Как выглядит карточка, по которой можно работать

Условная задача READ-12:

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

>

Основание: утверждённый раздел ТЗ и версия набора примеров.

>

Границы: без рекомендаций, экспорта и изменения хранения исходных записей.

>

Критерии: период трактуется как полуинтервал [начало, конец) в согласованном часовом поясе; учитываются только записи текущего пользователя. На примере «20 минут, 35 минут, длительность не указана» результат — 55 известных минут и одна запись с неизвестной длительностью. Пропуск не превращается в ноль. Пустой период — нормальный пустой отчёт, а не ошибка.

>

Доказательства: тесты расчёта и границ периода, проверка изоляции данных пользователей, воспроизведение экрана, ссылка на PR и коммит.

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

Не путать «тесты зелёные» с «задача решена»

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

У каждой проверки свой вопрос. Сотня тестов вспомогательных функций не компенсирует отсутствие проверки основного сценария. А скриншот красивого экрана не доказывает правильность суммы.

Схема 4. От задачи до поставки.

>

Критерий → пример с ожидаемым результатом → изменение кода → проверка конкретного коммита → PR → решение человека → слияние в main → проверка согласованной среды.

>

Следующую веху подробно планируем по принятому результату предыдущей. Слияние и развёртывание — разные события.

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

6. Непродуктивное кодирование: когда движутся файлы, но не продукт

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

Я называю это непродуктивным кодированием: активность вокруг кода подменяет продвижение к принятому результату.

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

Поэтому я смотрю не на число коммитов. Я спрашиваю: что стало доступно пользователю? Какой риск уменьшился? Что мешает закончить задачу? Сколько времени и повторных запусков потребовал принятый результат?

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

Инструкции меняются и внутри вехи

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

Я предлагаю маленький цикл: найти конкретный эпизод → определить причину → изменить нужный элемент среды → повторить проверку.

Агент принимает пропуск длительности за ноль? Сначала проверьте контракт данных и пример ожидаемого результата. Возможно, нужно исправить ТЗ и тест, а не общую роль. Агент запускает тяжёлую проверку после каждого изменения? Возможно, нужен согласованный порядок быстрых и полных проверок. Агент читает старое ТЗ? Исправляйте карту источников и способ выбора версии.

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

Убедитесь, что изменения действительно применены. Codex документирует построение цепочки AGENTS.md при запуске; для работающей сессии нельзя просто предположить, что новый файл уже заменил старый контекст. Перезапуск или предусмотренное клиентом обновление контекста должны быть частью процедуры. [6]

7. Руководитель и исполнитель: разделяем внимание, а не рисуем должности

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

Я называю их руководителем и исполнителем. Это собирательные роли. Исполнитель может вызвать помощника для ревью, руководитель — специалиста по тестированию. Паттерн не требует ровно двух моделей и не запрещает субагентов.

Но он требует ясной границы: исполнитель продвигает реализацию; руководитель проверяет продвижение и качество оснований.

Удобный начальный вариант — две отдельные сессии. Руководитель получает текущую веху и задачу, читает источники, формулирует поручение. Исполнитель выполняет его и предъявляет результат. Руководитель проверяет, возвращает конкретные замечания или рекомендует передать работу человеку.

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

Общая память процесса — комментарии в Linear

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

Я предлагаю короткий протокол комментариев — это наша договорённость, не встроенный стандарт Linear:

ПОРУЧЕНИЕ / версия 2
Задача: READ-12. ТЗ: версия и раздел.
Цель и границы: ...
Критерии: ...
Контрольная точка и условия остановки: ...

РЕЗУЛЬТАТ / ответ на поручение версии 2
Ветка, PR, проверяемый коммит: ...
Что изменено: ...
Команды и фактические результаты проверок: ...
Что не проверено и почему: ...
Блокеры и следующий шаг: ...

ПРОВЕРКА / того же коммита
Подтверждено: ...
Дефекты с воспроизведением: ...
Корректировка либо рекомендация человеку: ...

Не нужно переносить туда весь журнал терминала. Храните короткое резюме и ссылки на доступные доказательства. Если коммит изменился после проверки, прежняя рекомендация не становится автоматически действительной для нового кода.

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

Схема 5. Контроль без второго исполнителя.

>

Человек задаёт цель и принимает результат.

>

Руководитель → поручение в Linear → исполнитель → PR и доказательства в Linear → проверка руководителя → решение человека.

>

Оба агента могут привлекать специализированных помощников. Руководитель не исправляет продукт незаметно для исполнителя и не принимает работу вместо человека.

Что именно проверяет руководитель

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

Например: «Тест суммы проходит, но неизвестная длительность не проверена. Воспроизведите пример из ТЗ. Не меняйте API целиком: исправьте обработку пропуска и добавьте необходимую проверку». Это полезнее, чем «усиль качество, действуй профессионально».

Есть и предел делегирования. Второе мнение модели — не независимая истина. Руководителю стоит самостоятельно открыть изменения и основания, а не читать только самоотчёт исполнителя. Человек при приёмке должен суметь объяснить, как достигается функция и чем это подтверждено.

8. Длинный цикл: сначала ручной, потом автоматический

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

Позже можно добавить временной ритм — например, проверку раз в 15, 30 или 60 минут. Это пример политики надзора, а не обещание, что любой интерфейс поддерживает любое расписание.

Просто написать «проверяйте исполнителя каждые полчаса» недостаточно. Нужны настоящий планировщик, работающая среда, доступ к результатам исполнителя и канал передачи корректировок. Руководитель не получает доступ к другой закрытой сессии по одному названию роли.

Документация OpenAI различает запланированные задачи в веб-интерфейсе и настольном приложении; для локальной работы важны доступность компьютера и файлов. CLI и IDE не следует автоматически приписывать тот же интерфейс управления расписаниями. Проверяйте актуальные возможности своего клиента и аккаунта. [14]

В Claude Code документирован /loop, в том числе с заданным интервалом. Это сессионный механизм: выполнение зависит от жизни сессии, занятости агента и правил планировщика; возможны задержки, повторяющиеся задания имеют срок действия. Это не таймер реального времени. [15]

Учебный пример для отдельной сессии руководителя с уже настроенными доступами:

/loop 30m Проверьте новые доказательства по READ-12 в Linear
и связанный PR. Код не меняйте. Сопоставьте прогресс
с критериями. Оставьте корректировку только при новом
дефекте, блокере или отклонении от цели.

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

Отдельно проверьте доставку команды: комментарий в Linear не обязательно немедленно прервёт работающего исполнителя. Можно договориться читать новые указания на контрольных точках либо подключить поддерживаемый событийный механизм. Для аварийной остановки нужен реальный управляющий канал, а не надежда, что агент вовремя заметит комментарий.

Автоматический руководитель полезен, когда уменьшает Вашу нагрузку. Если Вы уже следите и за исполнителем, и за руководителем, и за их спором, усложнение пока не окупилось.

9. Для любопытных: OpenAI Symphony

Здесь стоит заглянуть за пределы ручного переключения между чатами. У OpenAI есть Symphony — не Symfony, PHP-фреймворк, а другой проект с похожим названием.

Репозиторий Symphony содержит спецификацию и экспериментальную реализацию оркестратора; авторы позиционируют его как инженерное превью для доверенных сред. Это материал для изучения и адаптации, а не обещание универсальной производственной системы. [16]

Идея: оркестратор получает подходящую задачу из трекера, готовит отдельное рабочее пространство, запускает агента и отслеживает жизненный цикл работы. В спецификации разделены настройки исполнения и текст задания; их можно хранить в версионируемом WORKFLOW.md. Предусмотрены управление конкурентностью, повторные попытки и сверка состояния. [17]

В примере workflow важную часть обмена с Linear выполняет сам агент через доступные инструменты. Это не означает, что один файл WORKFLOW.md автоматически подключит Ваш аккаунт и все права. Пример требует осмысленной настройки интеграций. [18]

Схема 6. Оркестратор и руководитель — не одно и то же.

>

Оркестратор: выбрать допустимую задачу → выделить рабочее пространство → запустить → наблюдать состояние → повторить или завершить.

>

Руководитель-агент: проверить смысл результата → найти отклонение → предложить корректировку.

>

Эти функции можно сочетать. Наличие планировщика само по себе не даёт содержательной проверки продукта.

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

Перед использованием чужого workflow проверьте состояния, переходы, разрешения и условия передачи человеку. В частности, успешное завершение работы агента может означать готовность к человеческой проверке, а не автоматическое слияние и выпуск. Для нашей методики эта разница принципиальна. [17] [18]

10. Что действительно меняется: публикации и наблюдения

Я постоянно работаю с Codex и Claude Code и наблюдаю, как меняется не только модель, но и среда вокруг неё. По моему опыту, обновления обвязки всё чаще позволяют передавать агенту более длинный участок работы. Это авторское наблюдение, а не измеренная статистика частоты релизов.

Есть и проверяемые сигналы направления. 10 сентября 2026 года OpenAI представила публичную бету Agents API: управляемое исполнение с Codex harness и инфраструктурой для длительно работающих агентов. Это отдельный продуктовый анонс, не новая команда существующего CLI. Заявления о длительности работы относятся к описанию вендора, а не к нашему испытанию студенческого проекта. [19]

25 мая 2026 года Anthropic опубликовала разбор containment — ограничения того, до чего агент вообще может добраться. Важен сам инженерный акцент: длительная работа требует не только удачных указаний, но и заранее устроенных границ среды. [8]

Более ранние материалы OpenAI о harness engineering от 11 февраля и Anthropic о разработке длинных приложений от 24 марта 2026 года показывают предпосылки этого подхода: среда, обратная связь и организация продолжительной работы становятся самостоятельной инженерной задачей. Это полезный фундамент, но его не стоит выдавать за публикации последних четырёх месяцев. [20] [21]

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

Три свежих голоса — и один полезный более ранний

Мартин Фаулер, 21 мая 2026 года. В заметке Agentic Programming он различает работу с агентом под осмысленным контролем разработчика и подход, при котором человеку неинтересен полученный код. Для нашего курса это важная граница: делегировать реализацию не значит перестать понимать систему. У Фаулера остаются значимыми проверка, понимание и направление работы. [1]

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

Эдди Османи, 7 июня 2026 года. В Loop Engineering фокус переносится на организацию повторяемого цикла: выполнение, оценка, сохранение состояния и следующий шаг. Это близко к нашей идее длинной работы по вехе. Однако из статьи не следует, что любое число автономных циклов полезно: цикл должен производить проверяемое продвижение, а сложность управления должна окупаться. [2]

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

Роберт Мартин и Джастин Мартин, июнь 2026 года. Публичное описание шестого выпуска Agentic Discipline показывает Swarm Forge: разные этапы задания, реализации, очистки, архитектурной проверки и контроля качества. Открытое описание даёт содержательный пример распределения компетенций; полная видеозапись доступна отдельно. [3]

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

Кент Бек, 23 апреля 2026 года — более ранняя оговорка. В Nobody Wants Agents он описывает неприятный эффект: хотел изменить программу, а получил работу по координации нескольких агентов. Это личный разбор конкретного опыта, не универсальный запрет мультиагентности. Но он задаёт отличный критерий: инструмент должен помогать получать результат, а не создавать новую нагрузку ради собственного обслуживания. [22]

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

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

11. Автономность увеличивает цену неясного замысла

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

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

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

Схема 7. Оставить свободу реализации, убрать неопределённость результата.

>

Нечёткая цель → много несопоставимых трактовок → трудно принять работу.

>

Ясная цель + границы + примеры + проверки → несколько допустимых реализаций → проверяемый выбор.

>

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

Поэтому центр тяжести разработки смещается. Всё важнее уметь описать приложение, исследовать варианты, составить ТЗ, декомпозировать работу, подготовить контекст и устроить проверку.

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

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

12. Небольшой эксперимент вместо большой веры

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

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

Это не даст научно строгого вывода из двух запусков: задачи различаются, а поведение моделей вариативно. Но даст осмысленную отправную точку. Дальше можно повторить опыт на нескольких сходных задачах и проверить, сохраняется ли эффект.

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

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

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

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

Источники и маршруты дальнейшего чтения

Ссылки проверены 15 сентября 2026 года. Возможности клиентов меняются; перед настройкой сверяйте документацию своей версии. Период свежих публикаций для этой статьи — 15 мая — 15 сентября 2026 года. Более ранние материалы отмечены отдельно. Даты справочных страниц — даты проверки, если дата публикации не указана.

Как меняется работа разработчика

[1] Martin Fowler — Agentic Programming. 21.05.2026. https:/​/​martinfowler.com/​bliki/​AgenticProgramming.html

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

[2] Addy Osmani — Loop Engineering. 07.06.2026. https:/​/​addyosmani.com/​blog/​loop-engineering/​

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

[3] Robert Martin, Justin Martin — Agentic Discipline 6: Swarm Forge Demonstration. Июнь 2026. https:/​/​cleancoders.com/​episode/​agentic-discipline-6

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

Собрать рабочую среду

[4] Linear — Project milestones. Документация. https:/​/​linear.app/​docs/​project-milestones

Почему стоит прочитать: позволяет превратить слово «веха» в конкретную структуру задач и не путать процент в интерфейсе с приёмкой продукта.

[5] OpenAI — Unrolling the Codex agent loop. 23.01.2026; базовый материал. https:/​/​openai.com/​index/​unrolling-the-codex-agent-loop/​

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

[6] OpenAI — Custom instructions with AGENTS.md. Документация. https:/​/​learn.chatgpt.com/​docs/​agent-configuration/​agents-md

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

[7] Anthropic — How Claude remembers your project. Документация. https:/​/​code.claude.com/​docs/​en/​memory

Почему стоит прочитать: объясняет CLAUDE.md, импорты, локальные правила и отличие контекста от исполняемых ограничений.

[8] Anthropic — How we contain Claude across products. 25.05.2026. https:/​/​www.anthropic.com/​engineering/​how-we-contain-claude

Почему стоит прочитать: переводит безопасность из пожелания «пусть агент ведёт себя хорошо» в устройство доступов и изоляции.

[9] GitHub — About protected branches. Документация. https:/​/​docs.github.com/​en/​repositories/​configuring-branches-and-merges-in-your-repository/​managing-protected-branches/​about-protected-branches

Почему стоит прочитать: помогает технически закрепить порядок ревью и проверок перед изменением основной ветки.

[10] OpenAI — Build skills. Документация. https:/​/​learn.chatgpt.com/​docs/​build-skills

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

[11] Anthropic — Extend Claude with skills. Документация. https:/​/​code.claude.com/​docs/​en/​skills

Почему стоит прочитать: позволяет адаптировать процедуру под Claude Code, не предполагая полной взаимозаменяемости конфигураций платформ.

[12] OpenAI — Subagents. Документация. https:/​/​learn.chatgpt.com/​docs/​agent-configuration/​subagents

Почему стоит прочитать: объясняет, как логическую роль превратить в реально настроенного специализированного агента.

[13] Anthropic — Create custom subagents. Документация. https:/​/​code.claude.com/​docs/​en/​sub-agents

Почему стоит прочитать: помогает задать отдельный контекст, назначение и инструменты помощника; формат следует проверять под используемый клиент.

Автоматизировать только понятный процесс

[14] OpenAI — Scheduled tasks. Документация. https:/​/​learn.chatgpt.com/​docs/​automations?surface=app

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

[15] Anthropic — Run prompts on a schedule. Документация. https:/​/​code.claude.com/​docs/​en/​scheduled-tasks

Почему стоит прочитать: объясняет /loop, ограничения сессионного расписания, задержки и прекращение повторяющихся запусков.

[16] OpenAI — Symphony, официальный репозиторий. Инженерное превью. https:/​/​github.com/​openai/​symphony

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

[17] OpenAI — Symphony Specification. https:/​/​github.com/​openai/​symphony/​blob/​main/​SPEC.md

Почему стоит прочитать: позволяет изучить состояния, рабочие пространства, повторные попытки и контракт WORKFLOW.md независимо от языка реализации.

[18] OpenAI — Symphony: пример WORKFLOW.md. https:/​/​github.com/​openai/​symphony/​blob/​main/​elixir/​WORKFLOW.md

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

Понять направление — без обещаний магии

[19] OpenAI — Introducing the Agents API. 10.09.2026. https:/​/​openai.com/​index/​introducing-the-agents-api/​

Почему стоит прочитать: свежий пример того, какую часть длительного исполнения вендор переносит в управляемую платформу.

[20] OpenAI — Harness engineering: leveraging Codex in an agent-first world. 11.02.2026; базовый материал. https:/​/​openai.com/​index/​harness-engineering/​

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

[21] Anthropic — Harness design for long-running application development. 24.03.2026; базовый материал. https:/​/​www.anthropic.com/​engineering/​harness-design-long-running-apps

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

[22] Kent Beck — Genie Lessons: Nobody Wants Agents. 23.04.2026; более ранний авторский опыт. https:/​/​newsletter.kentbeck.com/​p/​genie-lessons-nobody-wants-agents

Почему стоит прочитать: помогает заметить момент, когда управление агентами стало новой проблемой вместо решения старой. Автор указывает спонсорство разбираемой сессии компанией Augment Code.

[23] Сергей Авдейчик — Вы получили ответ. А кто организовал работу? 12.09.2026. https:/​/​dobrovola.dev/​ru/​writing/​from-ai-answers-to-verifiable-work

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