Як Cisco зробив Codex частиною enterprise engineering

Велика codebase карає за поверхневу автоматизацію. Дефект може вимагати навігації по C/C++ repository, повторного build/test cycle, understanding dependencies і змін у кількох компонентах. Якщо coding agent оцінюється лише за кількістю написаних рядків, він дуже швидко оптимізує неправильний показник.

Cisco використовує Codex у production engineering contexts: defect remediation, framework migrations і створення AI features. Найцінніший патерн у публічному кейсі — план як artifact, який агент генерує й виконує, а команда використовує для review. Це переводить роботу з режиму 'ось великий diff, удачі' у traceable task contract.

Trigger — approved defect ticket, migration batch, feature task або engineering maintenance request. Input — repository SHA, issue context, architecture constraints, coding standards, tests, dependency policy і allowed commands. AI stage: repository exploration, plan creation, implementation, build/test loop, failure analysis і candidate patch refinement.

Integrations — source control, CI/build system, test harness, static/security scanners, issue tracker і observability. Output — plan document, branch diff, test/build evidence, unresolved risks та pull request. Production deployment не є implicit output coding agent: це інший authority plane.

• Trigger → issue/migration/feature contract з owner і acceptance criteria.
• Input → pinned repository state + tests + allowed commands + dependency/security policy.
• AI → inspect → plan → edit → build/test → diagnose → iterate.
• Integrations → Git, CI, scanners, issue tracker; production credentials не потрібні для більшості coding tasks.
• Output → reviewable PR + executable evidence + exact unresolved failures.

A4 виправданий, коли агент може довго працювати самостійно: знайти affected files, внести серію змін, виправити failing tests і підготувати PR. Але autonomy закінчується там, де починається irreversibility: protected branch, release, schema/data migration, customer-facing infrastructure або security policy.

Branch protection, required checks, secret isolation і code owners не повинні бути інструкціями всередині prompt. Це independent controls. Якщо agent може змінити власний test gate, CI workflow або repository instructions і цим зробити свій PR 'зеленим', security boundary уже зламана, навіть якщо dashboard дуже оптимістичний.

OpenAI цитує Cisco engineering practice: Codex генерує і follows plan document, що допомагає reviewer зрозуміти процес і code. У production-відтворенні plan version фіксується разом із task ID, repository SHA, agent/model version і acceptance tests. Якщо план суттєво змінюється під час run, reviewer бачить delta й причину.

План не є доказом correctness. Він потрібен для inspectability: які hypotheses агент перевіряв, які files/tasks вважав in scope, де відступив від початкового contract. Deterministic tests і authoritative review все одно мають останнє слово.

Failure modes: main просунувся під час long run; dependency змінилась; tests flaky; build cache приховав defect; agent торкнувся out-of-scope files; static scanner недоступний; duplicate task створив другий PR; framework migration зламала runtime behavior без compile failure. Для stale branch agent не повинен blind-rebase і merge — потрібен revalidation cycle.

Ідемпотентність прив'язується до task + base SHA + intended change. Після workflow timeout система спочатку перевіряє branch/PR/CI state, а не створює дубль. Якщо partial migration already exists, наступний run має reconcile фактичний repository state і продовжити або запросити review.

Defect remediation може працювати як безперервна queue, migrations — batch campaigns, feature work — за issue. На масштабі головні constraints: CI capacity, test duration, reviewer bandwidth, repository contention і model context. Parallel agents корисні лише з isolation і ownership; інакше швидкість перетворюється на merge-conflict generator.

Cost model: `model inference + repository/context indexing + sandbox compute + build/test minutes + security scans + storage + orchestration + human review + rework + incident reserve`. Корисний KPI — cost per accepted verified change і lead time до merged/production-verified outcome. 10–15× throughput не переноситься на інший codebase без replay baseline.

Eval suite має містити historical defects, migrations, failing tests, hidden behavioral requirements, vulnerable dependency, stale base SHA, malicious repository instruction, flaky test, missing permission і no-change-needed tasks. Deterministic graders — build, tests, lint, security, diff scope; human/model graders — requirement fidelity, maintainability, omission severity. Окремо оцінюється trajectory: чи agent намагався відключити checks або розширити scope.

Rollout: `offline replay → suggestion-only → sandbox patch → PR with mandatory review → bounded A4 for selected repositories → larger queues → cross-repo campaigns`. Promotion зупиняється при critical security/control violation незалежно від aggregate pass rate. Incident перетворюється на permanent regression test.

Патерн підходить великим engineering organizations із сильним CI, historical issue corpus і дорогим repetitive maintenance: C/C++, platform migrations, large monorepos, security remediation. Поганий кандидат — repository без tests і ownership, де agent лише пришвидшить невизначеність.

Пілот: виберіть 50–100 закритих defects одного класу, replay на pinned commits, зафіксуйте pass rate, review minutes, escaped defects і compute/model cost. Потім дайте agent branch-only writes на live low-risk queue. Merge authority не передавайте, доки regression suite, stale-state handling і rollback не доведені на реальних failure cases.