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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глобальный скоуп (~/.codex/AGENTS.md в домашней директории пользователя) — задает правила для всех репозиториев на машине разработчика .
Проектный скоуп (AGENTS.md в корне репозитория) — регламентирует текущий проект .
Папочный скоуп (например, /server/AGENTS.md) — переопределяет правила для изолированного подмодуля .

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

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

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

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

Выбор механизма персистентности (например, использование localStorage вместо необоснованного развертывания внешней базы данных) .
Определение граничных условий и лимитов (например, отображение строго пяти последних просмотренных сущностей) .
Список затрагиваемых и создаваемых файлов для предварительной оценки объема диффа .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Убедиться в ручном режиме, что функционал стабилен и не содержит явных багов .
Поручить агенту сгенерировать заведомо проходящие тесты, фиксирующие вызовы функции (с заморозкой тестовых дат на фиксированную неделю в будущем, чтобы исключить падения из-за устаревания таймстампов) , .
Прописать в AGENTS.md жесткое правило: при любом редактировании файла scheduler.js автоматически выполнять npm test , .
Выполнить рефакторинг кода: 35 сгенерированных тестов гарантируют, что внутренние перестановки не сломали ни один скрытый краевой случай .

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

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

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

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

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

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

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

Критическую опасность представляет утечка учетных данных . Агенты имеют доступ ко всей файловой структуре рабочего пространства, включая .env . Пытаясь починить сборку, модель может взять API-ключ из конфигурации и захардкодить его напрямую в открытый скрипт или скомпрометировать через console.log() в логи сервера , .

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

Никогда не вставлять сырые секреты и пароли в окно чата с моделью .
Ограничивать финансовые лимиты и время жизни сервисных токенов на стороне провайдеров .
Строго контролировать .gitignore, предотвращая попадание любых дублирующих файлов вроде .env.local в удаленный репозиторий .
Удалять закомментированные фрагменты кода: модель продолжает считывать закомментированные секреты как часть контекста .
Лично проверять финальный дифф перед отправкой коммита в удаленную ветку .

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

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

Контекстное окно современных флагманских моделей достигает одного миллиона токенов (один токен приблизительно равен четырем символам) . При исчерпании лимита агент запускает автоматическое усечение: компрессию (сворачивание всей предыдущей переписки в сжатый абстракт) либо прямое отсечение ранних сообщений диалога . Данный процесс необратим и приводит к потере важных инструкций . Рекомендуется придерживаться правила: «одна сессия — одна изолированная задача» с очисткой контекста командой /clear или перезагрузкой сессии через Developer Reload Window , .

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

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

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

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

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

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

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

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

Пользователь формулирует задачу (например, исправить кривой интерфейс канбан-доски) .
Агент определяет, какой внешний инструмент ему требуется, и отправляет вызов инструмента на MCP-сервер .
Сервер выполняет команду и возвращает структурированный ответ прямо в контекстное окно .
Агент анализирует вывод и либо запрашивает следующий инструмент, либо завершает работу .

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

Интеграция регистрируется в секции MCP-серверов в config.toml, а в корень фронтенд-проекта добавляется управляющий components.json , . Через прямой запрос к реестру shadcn агент за 26 секунд извлек спецификации 61 готового UI-компонента . Получив подробный промпт на замену нестандартных элементов интерфейса, Codex примерно за 6 минут пересобрал верстку приложения , устранив визуальный мусор и сохранив исходную цветовую гамму проекта .