Claude Code vs Codex vs Gemini CLI: як обрати coding agent

Claude Code, Codex і Gemini CLI можуть читати репозиторій, пропонувати зміни та запускати інструменти, але рішення команди визначає не лише модель. Важливіші межі робочої директорії, правила підтвердження команд, спосіб передавання інструкцій, доступні інтеграції, формат неінтерактивного запуску та доказ того, що патч справді розв'язав задачу.

Почніть із Claude Code, якщо ваш pilot потребує детально налаштованих permission modes, hooks і командного CLAUDE.md; із Codex — якщо потрібен явний sandbox та approval policy разом з AGENTS.md і єдиним локальним або хмарним workflow; із Gemini CLI — якщо цінні відкритий код, GEMINI.md, extensions і наявний Google Cloud або Gemini Code Assist контур. Це гіпотези для тесту, а не рейтинг якості чи безпеки.

Перший шар — model і context assembly: які файли агент знаходить, як враховує repository instructions і що робить після ущільнення контексту. Другий — tools: shell, редагування, пошук, web та MCP. Третій — authority: що дозволено читати, змінювати, виконувати й надсилати в мережу. Четвертий — execution surface: інтерактивний terminal, CI або віддалена задача. П'ятий — evidence: diff, команди перевірки, логи, citations і reviewer decision.

Не переносіть властивість одного шару на весь продукт. Сильна відповідь моделі не доводить безпечного виконання shell; наявність sandbox не доводить коректності патча; підтримка MCP не означає, що довільному серверу можна довіряти. Порівняльна таблиця має фіксувати конкретну версію клієнта, режим автентифікації та policy, інакше результати неможливо відтворити.

Claude Code документує permission modes, allowed і disallowed tools та окремий небезпечний прапорець пропуску підтверджень. Codex задає sandbox і approval policy, щоб відокремити читання, запис у workspace, network access та ескалацію команд. Gemini CLI має approval modes, workspace trust і sandboxing, але точна поведінка залежить від конфігурації та платформи. Назва режиму не є доказом ізоляції — проведіть негативні тести.

У disposable репозиторії попросіть агента прочитати файл поза workspace, записати в сусідню директорію, виконати мережевий запит, побачити секрет середовища й запустити destructive command. Очікуваний результат задайте до тесту: deny, prompt або виконання лише в контейнері. Не використовуйте реальні ключі; canary secret має бути фіктивним, а filesystem — відновлюваним.

Claude Code читає CLAUDE.md, Codex використовує AGENTS.md, а Gemini CLI — GEMINI.md. Усі три механізми корисні для команд збірки, архітектурних меж і критеріїв готовності, але текстова інструкція не замінює технічний control. Заборонений каталог додатково захистіть permissions; обов'язковий тест — CI gate; форматування — детермінованим formatter.

Для MCP, hooks, skills або extensions застосовуйте allowlist, pinned version, мінімальні credentials і owner. Спочатку підключіть один read-only інструмент у тестовому середовищі та збережіть журнал викликів. Інтеграція, що може створити issue, змінити cloud resource або надіслати повідомлення, потребує окремого підтвердження й idempotency, навіть якщо агент упевнено пояснює дію.

Складіть 12–20 задач із вашого backlog: локальний bug fix, зміна через кілька файлів, новий тест, refactoring без зміни поведінки, документація, dependency investigation і задача, де агент має відмовитися через нестачу контексту. Зафіксуйте стартовий commit, інструкції, дозволи, time budget і доступні tools. Кожний інструмент запускайте в окремому worktree або контейнері.

Reviewer не повинен бачити бренд до verdict. Вимірюйте accepted task rate, regression rate, кількість людських виправлень, час до перевіреного patch, tool failures, permission prompts, непотрібний churn і вартість прийнятої задачі. Окремо оцінюйте типи робіт: один середній бал приховає, що агент добре пояснює код, але слабко дотримується локальних conventions.

Безпечний потік починається з issue contract: scope, заборонені області, acceptance checks і rollback. Агент працює в ізольованій гілці, показує plan для ризикової зміни, запускає дозволені перевірки та формує handoff із diff summary, виконаними командами, невирішеними ризиками й джерелами. CI повторює перевірки в чистому середовищі; code owner вирішує, чи merge дозволений.

Не давайте coding agent постійні production credentials або право самостійно merge і deploy лише заради швидкості. Для фонових задач встановіть max runtime, budget, concurrency, network allowlist і kill switch. Логи мають показувати версію клієнта, commit, policy, tool calls і результат gate без збереження секретів чи зайвого вмісту приватного коду.

Запишіть primary tool для кожного класу задач, допустимі дані, обов'язковий review, дозволені integrations, fallback і owner. Врахуйте не тільки підписку або tokens, а й setup, перевірку, невдалі спроби, підтримку policy та migration cost. Якщо команді потрібні два агенти, розділіть workload явно, а не дозволяйте випадковий вибір розробника для high-risk задач.

Перезапускайте скорочений eval після зміни моделі, permission semantics, sandbox, тарифу або repository stack. Rollback означає pinned попередню версію клієнта й policy або тимчасове повернення до human-only workflow. Так вибір залишається керованим інженерним рішенням, а не довічною ставкою на назву продукту.

Не порівнюйте CLAUDE.md, AGENTS.md і GEMINI.md за кількістю рядків. Спочатку створіть vendor-neutral policy matrix із конкретними ресурсами та діями: read у repository, write у визначених каталогах, запуск test runner, package install, network egress, доступ до environment variables, git commit і зовнішній side effect. Для кожної клітинки зафіксуйте очікувану реакцію deny, ask або allow, а потім реалізуйте той самий намір у нативній конфігурації кожного агента. Це відділяє реальну межу повноважень від різниці синтаксису.

Проганяйте contract tests, а не лише happy path. Нешкідливий probe має спробувати запис поза дозволеним каталогом, звернення до неallowlisted host, читання canary variable та виклик забороненого tool. Збережіть client version, effective configuration, command, decision і side-effect check. Якщо policy prompt очікувався, але headless run завис або виконав дію, результат є failure. Text instructions лишаються корисним контекстом, однак enforcement доводять тільки фактичним deny, sandbox boundary або зовнішнім CI control.

• Версіонуйте одну policy matrix поруч із трьома vendor-specific конфігураціями.
• Позначайте кожне правило як instruction, approval, sandbox або external enforcement.
• Повторюйте negative probes після оновлення клієнта чи permission semantics.
• Не передавайте реальні secrets у тест: використовуйте canary без привілеїв.

Неінтерактивний режим змінює ризик: людина не бачить проміжний plan і не може відповісти на permission prompt. Створіть adapter для кожного CLI, який приймає однаковий task contract і повертає нормалізований envelope: exit status, final message, patch, test results, tool log, elapsed time та policy violations. Wrapper не повинен перетворювати невизначене підтвердження на allow; timeout, parse failure і відсутній patch є окремими результатами, а не нульовим score.

У CI запускайте кандидатів із одного immutable base commit у disposable середовищах. Спочатку policy probes, потім task suite, далі чистий незалежний test job без agent credentials. Promotion вимагає acceptance checks, відсутності заборонених змін і reviewer verdict; середній score не може компенсувати витік canary або небезпечний side effect. Для rollback зберігайте попередню версію CLI, конфігурацію й adapter image, але не кешуйте довгоживучі токени. Так команда може повторити вибір після зміни продукту без переписування самого evaluation contract.

• Розрізняйте agent exit status, test verdict і reviewer verdict.
• Повторюйте недетерміновані задачі та звітуйте розкид, а не лише найкращий run.
• Redact logs до збереження, але залишайте policy decision і hash артефактів.
• Блокуйте promotion при будь-якому critical authority failure незалежно від якості patch.

Наявність CLAUDE.md, AGENTS.md або GEMINI.md у репозиторії ще не доводить, що конкретний run отримав правильний набір правил. Для відтворюваного pilot створіть instruction manifest: шлях до кожного файла, його scope, owner, revision, hash, очікуваний пріоритет і класи задач, до яких він належить. Перед запуском adapter зберігає client version, стартову директорію, discovered instruction files та effective policy поруч із commit. Якщо клієнт не показує повний effective context, додайте нешкідливі contract probes, що перевіряють видиму поведінку, але не приписуйте їм здатність розкрити прихований prompt.

Окремо тестуйте конфлікти: правило кореня проти вкладеного каталогу, user instruction проти repository policy, застарілий файл у сусідньому worktree і конфігурацію, успадковану з домашнього або системного рівня. Очікуваний winner визначте до run за документацією конкретного клієнта; неоднозначність, недоступна provenance або різний результат між двома однаковими середовищами є finding. Текстові правила керують поведінкою, але заборона network, secret access, merge чи deployment усе одно має enforcement у sandbox, CI або зовнішній policy layer.

• Зберігайте hash instruction manifest разом із patch і test evidence.
• Розрізняйте discovered, expected та behaviorally observed instructions.
• Перевіряйте nested scope і конфлікти на disposable fixture, а не production repository.
• Блокуйте порівняння, якщо кандидати отримали різний task contract або приховані глобальні правила.

Фінальний transcript не є достатнім доказом coding-agent run: він може не містити effective permissions, tool failures, змін поза git або незалежного test verdict. Для кожної спроби формуйте reproducibility packet із base commit, task fixture, instruction і policy hashes, client та model identifiers настільки, наскільки продукт їх надає, sandbox image, дозволеним network profile, patch, redacted tool log, test outputs і reviewer verdict. Невідомий або provider-managed model snapshot позначайте unknown; не вигадуйте точну версію за назвою продукту.

Повторюйте вибір на чистому середовищі з тим самим packet, але з новими короткоживучими credentials. Спочатку підтвердьте, що task fixture і policy еквівалентні, потім відтворіть negative probes, patch generation та незалежні checks. Не вимагайте byte-identical diff від недетермінованого агента: контрактом є дотримання authority boundary і прийнятний outcome за тими самими acceptance criteria. Якщо повтор уже неможливий через зміну hosted model або feature surface, позначте evidence як historical, запустіть новий candidate evaluation і не переносіть старий verdict на поточний продукт.

• Відокремлюйте agent report, machine test evidence і human acceptance.
• Redact secrets до архівації та зберігайте лише мінімально потрібні logs.
• Порівнюйте outcome distribution на кількох runs, не обирайте найкращу спробу постфактум.
• Повторна оцінка потрібна після зміни client, model surface, policy semantics або sandbox image.

Headless interfaces відрізняються: Claude Code підтримує non-interactive запуск через print mode, Codex має `exec` і потік JSONL events, а Gemini CLI повертає JSON або streaming JSON та документує exit codes. Не порівнюйте один final message із повним event stream і не вважайте валідний JSON доказом правильного patch. Спочатку adapter кожного кандидата має перетворити native output на спільний result envelope: run ID, base commit, client version, termination class, changed paths, patch hash, заявлені checks, tool failures, policy decisions, usage fields лише коли вони доступні, і посилання на сирий redacted artifact.

Валідуйте envelope JSON Schema до будь-якого scoring, але зберігайте три незалежні verdicts: transport verdict показує, чи процес завершився та output розібрався; verification verdict належить чистому test job; acceptance verdict — reviewer або policy gate. Exit code 0 і schema-valid response можуть співіснувати з порожнім diff, неповним завданням чи regression. Невідомий exit, обрізаний stream, перевищений turn limit, timeout і відсутнє обов'язкове поле мають окремі стани, а не перетворюються на generic failure або штучний нульовий score.

• Pin adapter schema version і CLI version у кожному evidence packet.
• Зберігайте native event type та невідомі поля для діагностики, не відкидаючи їх мовчки.
• Не приймайте agent-reported `tests passed` без незалежного machine verdict.
• Redact prompt, tool output і paths за policy до довготривалого зберігання.

У першій фазі coding agent отримує read-only checkout або disposable worktree, короткоживучий credential без production scope, обмежений network profile і право створити лише patch та result envelope. Permission prompt, на який ніхто не може відповісти у headless run, повинен завершуватися deny або явним blocked outcome, а не автоматичним розширенням прав. Не копіюйте інтерактивний режим `auto approve` у CI без негативних probes: sandbox, approval policy і workspace trust — різні control layers, а доступний прапорець не є рекомендацією його вмикати.

У другій фазі новий job без agent credential застосовує patch до того самого base commit, перевіряє allowlist шляхів, lockfile policy, generated files, tests, static analysis і secret scan. Лише після незалежного verdict окремий identity з мінімальною владою може створити draft pull request; merge, release, deployment і зовнішні записи залишаються наступними authorization gates. Rollback видаляє disposable workspace, відкликає короткоживучий token, закриває або revert-ить draft change та повертає pinned adapter image. Така межа дозволяє порівнювати automation fit без припущення, що headless execution має отримати повноваження delivery pipeline.

• Generation job не має merge, release або production credentials.
• Verification job не довіряє agent transcript і запускає checks із чистого checkout.
• PR creation є окремою дозволеною дією з idempotency key та audit identity.
• Будь-який authority violation блокує promotion незалежно від якості diff.