AGENTS.md в SQLite: как опенсорс учит агентов правилам

Что случилось

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

Файл адресован не разработчикам-людям, а именно агентам — системам вроде Devin, Claude Code, GPT-инженеров и прочих инструментов, способных самостоятельно читать репо, писать код и открывать pull request'ы.

Что написано в AGENTS.md

Документ содержит две принципиальные позиции.

По коду:

SQLite не принимает код, созданный агентами. Точка. Изначально в тексте стояло уточнение «(пока)» — но его намеренно убрали. Сообщение к коммиту гласит: «Усилить формулировку об отказе от принятия кода, созданного агентами». Это не техническая оговорка — это осознанная позиция.

При этом проект допускает, что разработчики-люди могут рассмотреть лаконичный агентный PR как proof-of-concept — перед тем как переписать предложенное самостоятельно.

По баг-репортам:

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

Почему форум пришлось разделить

Параллельно с появлением AGENTS.md форум SQLite оказался завален огромным количеством ИИ-сгенерированных баг-репортов. Качество варьировалось от полезных до абсолютно нерелевантных. Объём оказался настолько большим, что проект был вынужден создать отдельный SQLite Bug Forum специально для таких обращений.

D. Richard Hipp — основатель и главный разработчик SQLite — лично занимается закрытием этих обращений, выпуская один коммит за другим.

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

Практический смысл для тех, кто строит агентные системы

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

Если вы строите агентные воркфлоу, которые взаимодействуют с опенсорс-проектами, вот что стоит учитывать:

• Читайте политики репозиториев перед запуском агентов. AGENTS.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md — всё это стало частью контекста, который агент должен получить до начала работы.
• Качество важнее объёма. Массовая генерация баг-репортов без воспроизводимых примеров — прямой путь к бану или игнору.
• Автономные PR без человека в петле — риск. SQLite прямо говорит: даже хороший агентный PR будет переписан вручную. Это сигнал о доверии, а не о качестве кода.
• Разграничивайте роли агента. Исследование → баг-репорт → воспроизводимый тест — это допустимая цепочка. Исследование → патч → PR без ревью человека — нет.

Пример правильного воркфлоу для баг-репорта в SQLite

1. Агент анализирует кодовую базу и находит потенциальную проблему
2. Агент формирует минимальный воспроизводимый тест-кейс (SQL + ожидаемый/реальный результат)
3. Человек проверяет тест-кейс вручную
4. Человек отправляет баг-репорт на SQLite Bug Forum
5. Патч как иллюстрацию — можно приложить, явно пометив как агентный

Итог

SQLite не против ИИ. Проект против бесконтрольного потока агентного контента, который создаёт нагрузку на мейнтейнеров без пропорциональной пользы. AGENTS.md — это попытка установить правила до того, как ситуация вышла из-под контроля.

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

---

*Разбираем ИИ-инструменты и автоматизацию в ContentRun Club.*