Локальний vs cloud coding agent: де безпечно делегувати код

Локальний coding agent працює поруч із розробником у checkout, IDE або terminal і зручний для дослідження, швидкої ітерації та задач, де людина постійно уточнює напрям. Cloud або background agent отримує bounded task, піднімає віддалене середовище, працює асинхронно й повертає branch, diff або pull request. Це різні operating models, навіть коли всередині використовується та сама модель.

Для невизначеної зміни з частим steering почніть локально. Для чітко описаної, відтворюваної задачі з детермінованими checks cloud execution може звільнити developer time і паралелізувати backlog. Не передавайте задачу в cloud лише тому, що вона довга: спочатку доведіть, що environment можна відтворити, credentials звузити, а результат незалежно перевірити.

Локальний agent бачить актуальний, інколи брудний workspace: незбережені рішення, локальні services, caches і developer credentials. Це дає багатий контекст, але змішує task із персональним середовищем. Cloud agent зазвичай стартує з pinned repository revision у свіжому ephemeral environment. Його контекст чистіший і відтворюваніший, проте приватні dependencies, services та нестандартний toolchain треба підготувати явно.

Interaction теж різниться. Локальний loop допускає короткі уточнення до ризикової команди; асинхронний run потребує сильнішого task contract до старту. Handoff локального агента може лишитися неформальним terminal transcript, а cloud workflow природно тяжіє до branch або pull request. В обох випадках потрібен однаковий доказовий пакет: base SHA, diff, виконані checks, невирішені ризики та owner рішення.

• State → live workspace або pinned clean revision.
• Isolation → локальні OS controls або ephemeral remote runner.
• Secrets → успадковане середовище або task-scoped secret set.
• Network → developer context або explicit firewall/allowlist.
• Interaction → synchronous steering або asynchronous contract.
• Handoff → local diff або reviewable branch/PR із evidence.

Перед делегуванням зафіксуйте repository і base revision, дозволений file scope, очікувану поведінку, acceptance commands, заборонені зміни, потрібні fixtures, max runtime та формат handoff. Додайте приклад failure і поясніть, коли agent має зупинитися: missing dependency, contradictory requirement, migration без rollback або test, який не можна відтворити. Issue title без цих меж — не task contract.

Repository instructions на кшталт AGENTS.md, CLAUDE.md або Copilot instructions допомагають, але не є enforcement. File permissions, sandbox, branch protection, required checks і code-owner review повинні підтверджувати текстові правила. Setup environment версіонуйте як код і перевіряйте окремо: якщо bootstrap випадково бере latest dependency, одна задача може пройти сьогодні й упасти завтра без зміни patch.

Локальний agent часто успадковує більше, ніж потрібно: shell history, SSH agent, cloud profile, package tokens і доступ до внутрішньої мережі. Cloud agent може мати окремий secret namespace та firewall, але це не робить його автоматично безпечним. Дайте лише read token до конкретного package registry або тестового service, обмежте TTL і scope, забороніть production credentials та перевірте, що значення не потрапляє у diff, logs або generated artifact.

Network allowlist формуйте з dependency manifest і task need, а не з усіх адрес, які agent попросив під час trial-and-error. Prompt injection може бути в issue, dependency documentation, test fixture або retrieved web page. Write-capable external tools відокремте від code generation: створення ticket, зміна feature flag чи deploy мають власний policy check, idempotency key, approval і postcondition read.

Agent може повідомити, що tests пройшли, але reviewer повинен бачити command, environment, exit status і artifacts. Після handoff незалежний CI повторює lint, typecheck, unit/integration tests, security scans та інші acceptance checks у чистому середовищі. Не дозволяйте patch одночасно послабити test, required workflow або policy, якою він сам себе перевіряє, без окремого review.

Оцінюйте final-state correctness, а не кількість змінених рядків чи тривалість run. Для database change перевірте forward і rollback migration; для UI — semantic assertions та доступність, а не лише screenshot; для dependency update — lockfile, license і advisory status; для bug fix — regression test, який падає до patch і проходить після нього. Невідтворюваний зелений transcript не є доказом готовності.

Локальний режим краще підходить для discovery, debugging із живим local state, архітектурної зміни з частими рішеннями та sensitive code, який policy забороняє передавати у віддалене execution environment. Cloud режим доречний для bounded bug fix, test coverage, documentation, dependency investigation і повторюваного maintenance, якщо bootstrap стабільний, task data дозволені, а branch або PR є прийнятним handoff.

Не делегуйте автоматично production incident mitigation, irreversible data migration, secret rotation або change, де acceptance залежить від неявного judgement одного експерта. Agent може підготувати evidence, plan чи patch у sandbox, але authority лишається в окремого owner. Hybrid flow часто найкращий: людина локально досліджує невизначеність, формує contract, cloud agent виконує bounded implementation, CI та reviewer незалежно перевіряють.

Візьміть 15–25 закритих задач різних класів, відновіть їхній стартовий commit і задайте однакові acceptance checks. Для локального та cloud flow фіксуйте setup time, time to reviewable patch, accepted-task rate, reviewer minutes, regressions, permission denials, secret/network exceptions, reruns і повну вартість прийнятого результату. Blind review зменшує упередження до бренду або красивого session log.

Rollout починайте з read-only analysis і documentation, далі PR-only low-risk code changes, потім окремі task classes після проходження regression suite. Merge і deploy залишаються за людиною або незалежним policy gate. Rollback — вимкнути cloud delegation для slice, відкликати task credentials, закрити незлиті branches і повернутися до перевіреного local/manual flow; уже виконані зовнішні side effects потребують reconciliation, а не git revert.