Дайте агенту карту, а не энциклопедию

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

· 3 мин чтения

В феврале 2026 года инженер OpenAI Райан Лопополо описал эксперимент. Команда пять месяцев строила внутренний продукт, где весь код — логику, тесты, CI, документацию — писал Codex. Люди только ставили задачи и проверяли. Итог: около миллиона строк кода и примерно 1500 принятых изменений от команды из трёх, а затем семи инженеров. По их оценке, это примерно в десять раз быстрее, чем вручную.

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

Ошибка: один большой файл с правилами

Для агентов принято класть в проект файл вроде AGENTS.md — инструкцию «как у нас всё устроено». Команда сначала сделала один большой такой файл. Он провалился предсказуемо:

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

Решение: оглавление плюс папка документов

AGENTS.md сократили примерно до 100 строк. Теперь это оглавление: что где лежит и куда смотреть дальше. Сами знания живут в папке docs/ по темам:

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

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

Главное правило: чего агент не видит, того не существует

Для агента существует только то, что лежит в репозитории. Решение, о котором договорились в Slack, обсуждение в Google Docs, договорённость в чьей-то голове — всего этого для него нет. Ровно как для нового сотрудника, который пришёл через три месяца.

Поэтому команда постоянно переносила знания в репозиторий. Договорились в чате об архитектурном принципе — записали в docs/.

Как следить, чтобы документация не протухла

  • Отдельные проверки в CI смотрят, что документы на месте, связаны ссылками и правильно оформлены.
  • Регулярно запускается агент-«садовник». Он ищет документы, которые больше не соответствуют реальному коду, и открывает исправления.
  • Правила вкуса («используем общие утилиты, а не пишем свои», «не угадываем структуру данных, а проверяем на границе») записаны явно и проверяются механически. Раньше команда тратила каждую пятницу, пятую часть недели, на уборку за агентами. После того как правила стали проверяться автоматически, большинство исправлений проверяются за минуту и принимаются сами.

Как применить у себя

Даже если у вас не миллион строк, а один агент для домашних дел:

  1. Сократите главный файл инструкций до оглавления. Если он больше пары экранов — это симптом.
  2. Разложите знания по отдельным файлам по темам. Агент прочитает нужный, когда понадобится.
  3. Всё, о чём договорились устно или в чате, запишите туда, где агент это увидит.
  4. Раз в неделю просите агента найти, что в инструкциях устарело и противоречит тому, как всё устроено сейчас.
  5. Если одно и то же замечание вы делаете агенту в третий раз — это правило, его пора записать. А если его можно проверить скриптом, пусть проверяет скрипт.