🎯 О чём этот конспект: Разбор новейших возможностей экосистемы OpenAI для разработчиков: GPT-5.4, десктопного приложения Codex и концепции «Harness Engineering». Видео демонстрирует переход от простого автодополнения кода к полной автономности AI-агентов, способных самостоятельно писать, тестировать и развертывать миллионы строк кода.

👤 Кому будет полезно: Вайбкодерам, техлидам и разработчикам, использующим Cursor, Windsurf или API OpenAI для автоматизации создания IT-продуктов.

✨ Что получите: Понимание того, как структурировать репозиторий для максимальной эффективности AI-агентов, готовые метрики «агентной читаемости» (Agentic Legibility) и методику исключения человека из рутинного цикла написания кода.

1. Новые возможности GPT-5.4 и экосистемы Codex

Контекст: OpenAI представила модель GPT-5.4 и обновленное приложение Codex, которые знаменуют переход к третьему этапу разработки: «Агентному делегированию». Теперь AI не просто помогает писать код (pair programming), а берет на себя управление целыми рабочими процессами. Основной фокус сместился на создание среды, в которой агент может работать автономно, используя нативные инструменты ОС и облачные песочницы.

Выгода: Сокращение потребления токенов и задержек (latency) при сохранении производительности уровня GPT-5.3, а также возможность управления сотнями инструментов без перегрузки контекста.

Как применить:

• Шаг 1: Использование Computer Use Agent (KUA) — [GPT-5.4 API] — Используйте нативную способность модели управлять браузером и интерфейсом ОС. Вместо поиска координат по скриншотам, модель теперь может исполнять JavaScript-код прямо в REPL браузера для мгновенного взаимодействия с элементами.
• Шаг 2: Прогрессивное раскрытие инструментов (Progressive Disclosure) — [Tool Search API] — Если у вас сотни инструментов (tools), не пихайте их все в системный промпт. Используйте функцию Tool Search: агент будет видеть только названия категорий (namespace) и запрашивать описание конкретного инструмента только тогда, когда он ему реально нужен.
• Шаг 3: Hosted Shell — [OpenAI API] — Вместо локального выполнения команд, используйте контейнеризированную среду Hosted Shell от OpenAI. Это дает агенту полноценный Bash, но в безопасной, изолированной песочнице с настраиваемыми белыми списками доменов.

Результат: Агент получает доступ к полноценному компьютеру и терминалу с минимальными рисками безопасности и максимальной эффективностью контекста.

2. Метрики агентной читаемости (Agentic Legibility Score)

Контекст: Чтобы AI-агент мог эффективно работать в вашем проекте, репозиторий должен быть «читаемым» для него. Авторы ввели 7 ключевых метрик, по которым можно оценить готовность кода к автономной работе агентов. Это позволяет выявить «бутылочное горлышко», где агент спотыкается и требует вмешательства человека.

Выгода: Позволяет превратить «грязный» репозиторий в среду, где агент может самостоятельно фиксить баги и внедрять фичи с первой попытки (one-shot).

Как применить:

• Шаг 1: Проверка Bootstrap Self-Sufficiency — Убедитесь, что проект можно поднять одной командой (например, make setup). Агент не должен гадать, какие переменные окружения нужны.
• Шаг 2: Создание Task Entry Points — Опишите четкие точки входа для задач в файле agents.mmd или README.md. Агент должен знать, как запустить билд, линтинг и тесты.
• Шаг 3: Настройка Validation Harness — Создайте автоматизированную систему проверки. Если агент не может сам запустить тесты и увидеть результат, он не сможет закрыть задачу.

Чек-лист 7 метрик:

1. Самодостаточность загрузки (Bootstrap).
2. Понятные точки входа для задач.
3. Наличие тестового полигона (Validation Harness).
4. Автоматический линтинг и форматирование.
5. Наличие карты репозитория (Repository Map).
6. Структурированная документация.
7. Наличие записей о принятых архитектурных решениях (ADR).

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

3. Методика Harness Engineering: 100% кода от AI

Контекст: Райан из OpenAI поделился опытом создания продукта объемом в 1 миллион строк кода, где ни одна строчка не была написана человеком. Это стало возможным благодаря Harness Engineering — проектированию «обвязки» вокруг кода. Вместо написания функций, инженеры пишут правила, тесты и ограничения (guardrails), которые заставляют агента выдавать идеальный результат.

Выгода: Увеличение производительности одного инженера в 3–10 раз. Команда не растет в численности, но растет в скорости выпуска продукта.

Как применить:

• Шаг 1: Борьба с AI-слопом (AI Slop) — Если вам не нравится код, который пишет AI, не исправляйте его руками. Напишите правило для линтера (например, на базе ESLint), которое запрещает такой паттерн.
• Шаг 2: Использование файлов agents.mmd — Создавайте файлы инструкций в каждой папке модуля. Если информация специфична для модуля — она должна лежать там, а не в глобальном промпте.
• Шаг 3: Создание Агентов-Рецензентов (Reviewer Agents) — Настройте отдельного агента, чья единственная задача — проверять PR на соответствие безопасности или стилю кода. Основной агент-разработчик обязан будет исправить все замечания этого рецензента перед мерджем.

Пример структуры инструкции в репозитории:

# Agent Instructions for /services/auth
- Always use the 'InternalCrypto' library for hashing.
- Never use 'md5' for passwords.
- Run `npm run test:auth` after any change.
- If tests fail, analyze logs and retry once before asking human.

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

4. Концепция Symfony и автоматизация очереди задач

Контекст: Symfony — это оркестратор, который управляет очередью задач (например, из Linear или GitHub Issues). Он автоматически создает Work Trees (изолированные копии кода), запускает агентов для выполнения задачи, прогоняет тесты и выставляет Pull Request. Человек подключается только на финальном этапе для нажатия кнопки «Merge».

Выгода: Полное исключение человека из процесса «открыл терминал — написал код — запустил тесты». Инженер превращается в менеджера продукта и архитектора.

Как применить:

• Шаг 1: Использование Git Worktrees — [Codex App] — Используйте функцию Worktrees в Codex App. Это позволяет агенту работать над 5 разными задачами одновременно в разных папках, не мешая вашему основному рабочему пространству.
• Шаг 2: Автоматизация Standup — Настройте скрипт, который просит Codex проанализировать историю Git за последние 24 часа и выдать саммари для ежедневного митинга.
• Шаг 3: Интеграция с Slack/Linear — Используйте навыки (Skills) для подключения Codex к вашим мессенджерам. Агент может сам мониторить обсуждения архитектуры и обновлять agents.mmd на основе принятых в чате решений.

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

FAQ

В: Что такое "AI Slop" и как с ним бороться?

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

В: В чем преимущество Git Worktrees для вайбкодинга?

О: Worktrees позволяют держать несколько веток проекта открытыми одновременно в разных директориях. Для AI-агента это означает возможность выполнять длительные задачи (например, рефакторинг) в фоне, пока вы или другие агенты работаете над фичами в других ветках, не опасаясь конфликтов в файловой системе.

В: Как использовать agents.mmd файлы?

О: Это файлы с инструкциями для AI, которые лежат прямо в папках проекта. В корне лежит глобальный agents.mmd с общими правилами, а в подпапках — локальные, уточняющие специфику конкретного модуля. Это позволяет агенту получать только нужный контекст для текущей задачи, не перегружая память.

В: Что такое "Progressive Disclosure" в контексте инструментов (Tools)?

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

В: Можно ли использовать эти методы в старых (Brownfield) проектах?

О: Да, авторы рекомендуют начинать с изоляции отдельных бизнес-доменов. Выделяйте часть старого кода, описывайте для него интерфейсы и создавайте локальную документацию (docs subtrees) с правилами. Постепенно внедряйте линтеры и авто-тесты, чтобы агент мог безопасно работать в этой "очищенной" зоне.

Конспект создан на основе видео «OpenAI Build Hours: Codex & API» канала OpenAI. Все права на оригинальный материал принадлежат авторам. Источник: https://www.youtube.com/watch?v=rhsSqr0jdFw