# Том Чант: «Агентный кодинг завершает цикл между генерацией и проверкой»

Источник: https://www.youtube.com/watch?v=ajfQWhGQGLE
Канал: freeCodeCamp.org
Опубликовано: 10.11.2026

---

Разработка программного обеспечения переживает фундаментальную трансформацию: привычные сниппеты из поисковиков уступают место полноценным программным агентам, способным автономно исследовать кодовые базы, править десятки файлов, запускать тесты и управлять внешними сервисами. В масштабном курсе от freeCodeCamp руководитель образовательного направления платформы Scrimba Том Чант на практических примерах разбирает принципы агентного кодинга на базе OpenAI Codex и аналогичных систем, обучая разработчиков сохранять контроль над качеством кода, архитектурой и безопасностью.

## 🤖 От автодополнения к автономии: концепция агентного кодинга
[[JUMP:0:00]]

Эволюция написания кода прошла путь от поиска решений на Stack Overflow до вставки подсказок из ChatGPT в конце 2022 года [0:55]. Агентный кодинг представляет собой принципиально иной подход: искусственный интеллект встроен непосредственно в редактор кода и обладает автономией для чтения файлов, редактирования архитектуры, вызова консольных команд и запуска проверок в непрерывном цикле [1:21]. Понятие «агентности» подразумевает способность системы принимать самостоятельные решения на основе обратной связи от собственных действий: агент компилирует код, видит ошибки компилятора или упавшие тесты, рефлексирует над выводом и повторяет попытку до успешного завершения [1:47].

Человеческий фактор не теряет актуальности, а становится критическим звеном цепочки [2:01]. Агенты склонны допускать скрытые ошибки, создавать раздутый и трудноподдерживаемый код, а в худших сценариях — непреднамеренно разглашать секреты компании или ломать бизнес-логику [2:13]. Задача инженера меняется: вместо ручного набора символов фокус смещается на постановку задач, ограничение прав доступа и валидацию правок [2:38].

На рынке сформировалась целая экосистема инструментов: помимо OpenAI Codex и Anthropic Claude Code, популярность удерживают GitHub Copilot, Devin, Windsurf и Cursor [3:04]. Архитектурно агенты делятся на три категории:

*   CLI-агенты: функционируют непосредственно в терминале и ориентированы на опытных разработчиков [3:44].
*   IDE-агенты: интегрируются в среды разработки вроде Visual Studio Code, сочетая визуальный интерфейс с близостью к файлам проекта [3:58].
*   Десктопные и веб-клиенты: абстрагируют техническую рутину, упрощая прототипирование для продакт-менеджеров и дизайнеров [4:11].

Инструментарий начинает стандартизироваться, поэтому паттерны работы с Codex оказываются напрямую применимы и к альтернативным моделям [3:31]. При первых генерациях ключевым инструментом разработчика становятся диффы (diffs) — визуальное сравнение удаленных красных и добавленных зеленых строк, позволяющее мгновенно перехватывать нежелательные изменения [7:42].

## 📝 Анатомия эффективного промпта и коммент-промптинг
[[JUMP:9:34]]

Агенты по умолчанию стремятся дописывать новый код, а не модифицировать существующий [11:37]. Это часто нарушает базовый принцип разработки DRY (Don't Repeat Yourself), приводя к дублированию слушателей событий и разрастанию исходников [11:25]. Проблема решается устранением двусмысленности в инструкциях [11:50].

Для построения качественного промпта Том Чант предлагает универсальный трехчастный каркас:

*   **Task (Задача):** предельно четкое определение функционала, который необходимо реализовать [12:04].
*   **Context (Контекст):** указание на модули, файлы или архитектурные соглашения, которые модель обязана учесть [12:04].
*   **Output (Вывод):** требования к качеству архитектуры, читаемости, модульности и отсутствию дублирования [12:04].

Такой структурированный запрос вынуждает модель объединять общую логику и минимизировать лишние абстракции [13:24]. Фокусироваться следует не только на внешнем поведении интерфейса, но и на чистоте создаваемой кодовой базы [14:44].

Если требуется сохранить единый стиль реализации, эффективнее прибегать к технике коммент-промптов непосредственно в коде [15:26]. Codex опирается на локальный контекст файла [16:43]. Вместо абстрактных описаний в чате достаточно разметить эталонный метод комментарием `// Model function`, а над изменяемым методом оставить служебную инструкцию вида `// TODO(AI): refactor to match the model function using async/await` [17:35]. Подобный маркер не является строгим системным правилом фреймворка, но служит общепринятой конвенцией, сигнализирующей человеку и модели о запланированной задаче [18:56].

## 📑 Сохранение контекста и архитектурные правила: файл AGENTS.md
[[JUMP:19:48]]

Интерактивный диалог с агентом создает две фундаментальные проблемы. Первая — изоляция истории чата: при передаче репозитория коллеге все неявные архитектурные решения (выбор цветовой палитры, структуры BEM для стилей, запрет определенных библиотек) теряются [20:42]. Напарник и его ИИ-ассистент не смогут определить, какие фрагменты кода возникли из осознанной инженерной воли, а какие стали случайной фантазией модели [21:23]. Вторая проблема — деградация контекста: при разрастании сессии ранние требования забываются или обрезаются компрессией [22:28].

Решением выступает файл спецификаций `AGENTS.md` [23:34]. Во многих системах его инициализация доступна по слэш-команде `/init`, сканирующей кодовую базу и формирующей опорный файл [23:48]. Содержимое `AGENTS.md` прикрепляется к каждому пользовательскому запросу с наивысшим приоритетом [25:09]. 

Файл содержит критическую вводную информацию:

*   Название проекта, тип стека и команды запуска [24:29].
*   Базовую структуру папок и правила именования модулей [24:42].
*   Обязательные архитектурные паттерны и ограничения по библиотекам [24:42].

Концепция `AGENTS.md` поддерживается кросс-платформенно инструментами вроде Devin, Cursor и Windsurf [26:26]. В проектах поддерживается строгая иерархия контекстных файлов [28:21]:

1.  Глобальный скоуп (`~/.codex/AGENTS.md` в домашней директории пользователя) — задает правила для всех репозиториев на машине разработчика [27:30].
2.  Проектный скоуп (`AGENTS.md` в корне репозитория) — регламентирует текущий проект [27:05].
3.  Папочный скоуп (например, `/server/AGENTS.md`) — переопределяет правила для изолированного подмодуля [27:18].

При возникновении противоречий агент отдает безусловный приоритет файлу, расположенному ближе всего к редактируемому исходнику [28:21].

## 🧭 Plan Mode: проектирование перед генерацией
[[JUMP:28:50]]

Когда предстоящая доработка носит масштабный характер, затрагивает неочевидные связи или допускает несколько вариантов реализации, прямой запуск генерации грозит разрушением архитектуры [30:20]. Для этого предназначен режим планирования (Plan Mode), активируемый слэш-командой `/plan` или переключателем в графическом интерфейсе [30:48].

В режиме Plan Mode агент лишен права редактировать рабочие файлы [29:02]. Вместо этого он генерирует документ `current_plan.md` внутри скрытой служебной папки `.agent/plans/`, предлагая подробный сценарий действий [31:13]:

*   Выбор механизма персистентности (например, использование `localStorage` вместо необоснованного развертывания внешней базы данных) [31:39].
*   Определение граничных условий и лимитов (например, отображение строго пяти последних просмотренных сущностей) [32:03].
*   Список затрагиваемых и создаваемых файлов для предварительной оценки объема диффа [32:29].

Инженер получает возможность скорректировать план до написания первой строчки кода [33:31]. В разобранном на лекции примере блога о космосе и экологии [29:42] Том Чант обратил внимание на упущенный краевой случай: что произойдет, если пользователь прочитал статью, а администратор позже удалил ее из общего каталога? [33:19] Модель по запросу внесла корректировку в план, заложив молчаливую фильтрацию устаревших идентификаторов в локальном хранилище [34:51], и лишь после этого получила разрешение на реализацию функционала [35:05].

## 🛠️ Создание кастомных навыков (Skills) для кодовой базы
[[JUMP:36:35]]

По мере усложнения проекта типовых системных подсказок становится недостаточно. Навыки (Skills) представляют собой переиспользуемые изолированные надстройки над промптами, обеспечивающие стабильность повторяющихся рабочих процессов [37:32]. Они размещаются в директории `.agent/skills/<название-навыка>/` и состоят из управляющего описания `skill.md` и сопутствующих исполняемых скриптов [37:44].

Вызов навыка осуществляется через меню команд по символу `$` или `/` [38:25]. Навыки делятся на две категории:

*   **Процедурные утилиты:** пример простого навыка — `file tree`, сканирующий репозиторий скриптом `generate_tree.js` и фиксирующий 29 папок и 66 файлов в структурированный `tree.md` [38:53].
*   **Опинионированные экспертные навыки (Opinionated Skills):** концентрируют знания о внутренних соглашениях команды, которые большая языковая модель не способна угадать интуитивно [39:33].

Для генерации сложных инструкций используется системный инструмент `Skills Creator` [41:22]. Шаблон спецификации качественного навыка включает четыре блока:

*   **Task & Purpose:** назначение инструмента (например, рефакторинг легаси-кода под внутрикорпоративный стандарт) [41:49].
*   **Inspect / Capture:** явные ссылки на эталонные файлы в кодовой базе (например, `server/src/modules/` за исключением сомнительных папок), откуда модель обязана считать архитектурные паттерны [42:03].
*   **Constraints:** строгие запреты (не модифицировать файлы вне переданного аргумента) [42:28].
*   **Invocation:** формат вызова (передача аргументов через командную строку) [42:42].

Подобный навык позволяет автоматически приводить обфусцированные спагетти-файлы вроде фейковых платежных сервисов к читаемому виду без потери бизнес-логики [44:14]. Второй сценарий — диагностический навык `stylist-dev`, куда кодируются зафиксированные версии зависимостей и платформенные ограничения [47:43]. В практическом задании такой навык за минуту выявил несовместимость библиотеки `sqlite3`: в системе по ошибке оказалась версия `6.0.1`, тогда как проект требовал строго зафиксированную `5.1.7` [49:40].

## 🧪 Стратегии тестирования: Characterization Tests и TDD
[[JUMP:50:33]]

Скорость генерации кода порождает иллюзию надежности, однако передача написания тестов агенту без жесткого надзора несет скрытую угрозу [1:04:59]. В курсе рассматриваются две практики на базе тестового фреймворка Vitest [50:57].

### Тесты характеризации (Characterization Tests)
[[JUMP:53:09]]

В сложных энтерпрайз-приложениях бизнес-правила часто нарастают хаотично. В продемонстрированном виджете записи к стоматологу мистеру Смайлсу действовали нетривиальные ограничения: клиника закрыта по воскресеньям, по пятницам действует укороченный день, по субботам нет обеденных перерывов, а слоты квантуются строго по 15 минут [51:37]. Логика функции `getAvailableSlots` в `scheduler.js` оказалась предельно запутанной [52:43].

Тест характеризации создается не для проверки «идеальной» логики, а для фиксации текущего фактического поведения системы перед проведением опасного рефакторинга [53:09]. 

Алгоритм развертывания:

1.  Убедиться в ручном режиме, что функционал стабилен и не содержит явных багов [53:34].
2.  Поручить агенту сгенерировать заведомо проходящие тесты, фиксирующие вызовы функции (с заморозкой тестовых дат на фиксированную неделю в будущем, чтобы исключить падения из-за устаревания таймстампов) [54:00], [55:58].
3.  Прописать в `AGENTS.md` жесткое правило: при любом редактировании файла `scheduler.js` автоматически выполнять `npm test` [58:46], [59:00].
4.  Выполнить рефакторинг кода: 35 сгенерированных тестов гарантируют, что внутренние перестановки не сломали ни один скрытый краевой случай [59:54].

### Ловушка «самопроверки» и Test-Driven Development (TDD)
[[JUMP:1:01:13]]

Если попросить агента одновременно написать новую фичу (например, скидочный промокод `smile15` на 15%) и покрыть ее тестами, возникает системный сбой [1:02:46]. При покупке на $276.97 скидка 15% дает сумму $235.4245 [1:03:41]. Агент округлил итог до $235.42 и сам для себя написал тест, проверяющий именно это значение [1:03:55]. ИИ самовольно принял финансовое решение: рассчитывать скидку на общую корзину или построчно по позициям, как округлять доли цента в бухгалтерском учете [1:04:07]. В масштабах крупного маркетплейса расхождение в один цент ведет к миллионным дисбалансам [1:04:19].

Единственно верный подход — классический цикл TDD (Test-Driven Development) [1:08:30]:

1.  Человек формулирует строгую спецификацию: скидка рассчитывается строго от общей суммы корзины и математически округляется вверх до двух знаков после запятой [1:06:07].
2.  Агент генерирует падающий тест (фаза Red), отражающий заданные правила, кейсы с нулями, отрицательными числами и чувствительностью к регистру [1:08:16], [1:08:58].
3.  Разработчик валидирует структуру теста [1:06:34].
4.  Агент пишет имплементацию в коде до тех пор, пока все 51 тестовый сценарий не завершатся зеленым статусом [1:09:36].

## 🛡️ Безопасность, переменные окружения и Git-гигиена
[[JUMP:1:11:09]]

Агенты любят писать сотни строк кода за считанные секунды [1:12:11]. Попытка закомитить гигантский дифф из 800 строк, где одновременно меняются стили футера, центрирование логотипа и логика доставки, парализует последующий код-ревью [1:12:39].

Правило Git-гигиены для агентного кодинга: одна атомарная задача — один небольшой коммит с понятным описанием [1:13:31]. Все управляющие файлы (`AGENTS.md`, `components.json`) должны версионироваться в общем репозитории команды [1:14:25]. Если в проекте параллельно возникает специфичный `CLAUDE.md`, разрешение потенциальных конфликтов между стандартами должен брать на себя владелец репозитория [1:14:38], [1:15:29].

Критическую опасность представляет утечка учетных данных [1:15:58]. Агенты имеют доступ ко всей файловой структуре рабочего пространства, включая `.env` [1:18:07]. Пытаясь починить сборку, модель может взять API-ключ из конфигурации и захардкодить его напрямую в открытый скрипт или скомпрометировать через `console.log()` в логи сервера [1:18:19], [1:18:45].

Для защиты конфиденциальных данных необходимо соблюдать комплекс мер:

*   Никогда не вставлять сырые секреты и пароли в окно чата с моделью [1:19:25].
*   Ограничивать финансовые лимиты и время жизни сервисных токенов на стороне провайдеров [1:19:38].
*   Строго контролировать `.gitignore`, предотвращая попадание любых дублирующих файлов вроде `.env.local` в удаленный репозиторий [1:22:13].
*   Удалять закомментированные фрагменты кода: модель продолжает считывать закомментированные секреты как часть контекста [1:21:47].
*   Лично проверять финальный дифф перед отправкой коммита в удаленную ветку [1:20:16].

## ⚙️ Управление контекстом, пермишены и config.toml
[[JUMP:1:22:54]]

Для тонкой настройки окружения внутри Visual Studio Code используется официальное расширение Codex [1:24:01]. В конфигурации модели разработчику доступны уровни рассуждений (Reasoning Effort) от Light до Ultra [1:24:40]. Для повседневных операций достаточно режимов Light и Medium; выбор более «тяжелых» моделей или форсирование скорости генерации резко повышает потребление токенов без ощутимой прибавки в типовых задачах [1:25:06].

Контекстное окно современных флагманских моделей достигает одного миллиона токенов (один токен приблизительно равен четырем символам) [1:27:47]. При исчерпании лимита агент запускает автоматическое усечение: компрессию (сворачивание всей предыдущей переписки в сжатый абстракт) либо прямое отсечение ранних сообщений диалога [1:28:39]. Данный процесс необратим и приводит к потере важных инструкций [1:29:19]. Рекомендуется придерживаться правила: «одна сессия — одна изолированная задача» с очисткой контекста командой `/clear` или перезагрузкой сессии через Developer Reload Window [1:31:34], [1:31:58].

Управление свободой действий агента осуществляется через три базовых профиля прав доступа [1:34:25]:

*   **Ask for Approval:** безопасный режим. Агент читает и создает файлы, но запрашивает подтверждение на удаление данных, установку пакетов или консольные манипуляции [1:35:02].
*   **Approve for Me:** оптимальный рабочий баланс. Система не отвлекает вопросами при рутинных правках, запрашивая разрешение только при операциях за пределами рабочей папки, деструктивных Git-командах или удалении больших массивов данных [1:35:15].
*   **Full Access:** полное снятие ограничений, категорически не рекомендуемое для повседневного использования [1:35:28].

Глубокая кастомизация прав и системных параметров Codex выполняется через файл `config.toml`, который по умолчанию располагается в глобальной директории `~/.codex/config.toml` [1:36:20].

```toml
# Пример базовой конфигурации config.toml
approval_policy = "on-request" # Запрос подтверждения только для рискованных действий
sandbox_mode = "workspace"     # Ограничение доступа пределами открытого проекта
default_model = "5.4"          # Переопределение модели по умолчанию для экономии бюджета
effort = "medium"              # Глубина рассуждений
verbosity = "medium"           # Подробность вывода
personality = "pragmatic"      # Прагматичный тон ответов
```

При переопределении параметров важно помнить: если учетная запись Codex входит в корпоративную организацию (Organization Account), административные политики безопасности компании имеют высший приоритет и не могут быть подавлены локальным файлом [1:42:24]. Если же локальный проект в VS Code помечен средой как «недоверенный», проектный `config.toml` игнорируется до тех пор, пока путь к репозиторию явно не пропишут в секции доверенных в глобальной конфигурации [1:43:16].

## 🔌 Model Context Protocol (MCP) и рефакторинг UI с помощью shadcn
[[JUMP:1:43:50]]

Агенты принципиально ограничены рамками своей когнитивной модели и не имеют прямого доступа к внешнему миру [1:43:57]. Индустриальным стандартом для решения этой проблемы стал открытый протокол Model Context Protocol (MCP), который часто называют «USB-C для искусственного интеллекта» [1:44:21]. MCP стандартизирует подключение к базам данных, браузерным движкам автоматизации (Playwright) и компонентным реестрам [1:44:09], [1:50:18].

Цикл работы MCP (MCP Loop) прозрачен:

1.  Пользователь формулирует задачу (например, исправить кривой интерфейс канбан-доски) [1:44:46].
2.  Агент определяет, какой внешний инструмент ему требуется, и отправляет вызов инструмента на MCP-сервер [1:44:46].
3.  Сервер выполняет команду и возвращает структурированный ответ прямо в контекстное окно [1:44:58].
4.  Агент анализирует вывод и либо запрашивает следующий инструмент, либо завершает работу [1:44:58].

Наглядной демонстрацией возможностей MCP в курсе стал рефакторинг канбан-доски на React [1:45:24]. Приложение страдало от хаотичных UI-стилей: несогласованные скругления углов, обрывочные пунктирные границы карточек, несоразмерные кнопки и поломанные тени [1:45:37]. Вместо попыток заставить модель изобретать дизайн заново через случайный CSS, Codex подключили к MCP-серверу компонентной библиотеки shadcn [1:46:17].

Интеграция регистрируется в секции MCP-серверов в `config.toml`, а в корень фронтенд-проекта добавляется управляющий `components.json` [1:47:37], [1:48:04]. Через прямой запрос к реестру shadcn агент за 26 секунд извлек спецификации 61 готового UI-компонента [1:48:30]. Получив подробный промпт на замену нестандартных элементов интерфейса, Codex примерно за 6 минут пересобрал верстку приложения [1:49:11], устранив визуальный мусор и сохранив исходную цветовую гамму проекта [1:49:38].