Як Endava перебудовує software delivery навколо ChatGPT і Codex

Коли coding стає швидшим, вузьке місце просто переїжджає ліворуч: requirements, stakeholder alignment, architecture, design artifacts і handoffs починають гальмувати сильніше за саме написання коду. Саме так Endava описує свій перехід від isolated AI coding до agentic delivery model.

Практичний висновок для відтворення: не оптимізувати один IDE prompt. Треба визначити end-to-end task contract — від business intent до verified production artifact — і для кожної стадії явно задати source of truth, model authority, deterministic checks та owner, який має право завершити consequential step.

Trigger-и: discovery session, new requirement, architecture decision, technical debt item, incident follow-up або delivery task. Input: meeting transcripts, existing repositories, architecture standards, acceptance criteria, client constraints, tickets, approved patterns та operational evidence.

AI stage може включати requirements extraction, ambiguity detection, specification drafting, architecture diagrams, implementation plan, code/test generation і operational analysis. Output не повинен бути «готовим релізом»: це versioned decision/implementation packet із links до evidence, assumptions, unresolved questions, diffs, tests і explicit release status.

• Trigger → stakeholder meeting, ticket, incident або planned delivery increment.
• Input → approved project context + repo + standards + acceptance criteria.
• AI → analyze, specify, implement, test, explain.
• Output → reviewable artifacts in isolated branch/workspace, not direct production mutation.

OpenAI описує Endava pattern, де senior architects кодують свій point of view у Codex і junior engineers отримують guidance під час роботи. Це сильний multiplier, але production implementation має versionувати такі instructions так само серйозно, як application code.

Senior guidance не повинна бути єдиним security або compliance boundary: instruction file може застаріти, конфліктувати з current architecture або бути змінений у branch. Hard controls — permissions, secret isolation, CI, dependency policy, test gates, merge protection — мають жити поза model prompt.

A4 тут означає довгі multi-step tasks у sandbox/branch: agent може читати repo, створювати файли, запускати tests, refactor-ити й готувати PR. Але merge to protected branch, production deploy, customer-facing commitment, contractual interpretation та security exception — human/system authority.

Review surface має показувати не тільки diff. Потрібні task intent, acceptance criteria, touched systems, generated/modified tests, security scan results, source/instruction fingerprint і known uncertainties. Без цього HITL перетворюється на ритуальну кнопку Approve.

Головні failure modes: transcript неправильно інтерпретований; stakeholder ambiguity прихована; outdated architecture rule; agent змінив tests, щоб вони «погодились» із помилкою; dependency або secret потрапили в неправильний scope; long-running task продовжився після зміни base branch.

Контроль: immutable acceptance tests для critical behavior, protected CI/security config, branch isolation, stale-base check перед merge, dependency allowlist, secret/network restrictions і explicit no-answer/clarification path для ambiguous requirements. Якщо external side effect має unknown status після timeout — спочатку reconcile authoritative state, потім retry.

Eval corpus повинен містити normal feature work, ambiguous requirements, legacy code, cross-service changes, security-sensitive paths, stale base, flaky tests, adversarial repo instructions і tasks, де правильна відповідь — зупинитися та поставити питання. Graders оцінюють spec fidelity, architecture compliance, test quality, security policy, diff correctness, unnecessary churn і final system state.

Average pass rate недостатній. Wrong auth change, secret exposure, disabled test або unauthorized deploy — hard blocker незалежно від середньої якості. Кожен production incident мінімізується в reproducible task і назавжди входить у regression suite.

Agentic delivery може працювати постійно, але concurrency треба лімітувати за repo, service і blast radius. Queue policy повинна враховувати protected ownership: десять паралельних агентів, що торкаються одного migration boundary, створюють не leverage, а дуже дорогу форму merge-conflict генератора.

Full cost = model tokens + sandbox compute + CI + artifact storage + code review + security scans + failed/retried runs + evals + platform operations. Кращий denominator — cost per verified merged outcome або cost per accepted requirement package, а не «ціна одного prompt».

1) Вибрати один bounded workflow, наприклад requirements-to-spec. 2) Зафіксувати source hierarchy й acceptance contract. 3) Додати repo instructions як versioned guidance, не authority. 4) Запускати agent у isolated workspace. 5) Вимірювати spec/test/diff quality offline. 6) Додати PR-only writes із human merge. 7) Лише після stable regression history розширювати autonomy на довші tasks і кілька стадій delivery.

Підходить software/services organizations із повторюваними delivery workflows і сильними engineering controls. Не підходить команді, де CI ненадійний, ownership розмитий, secrets доступні всім, а definition of done живе виключно в голові найстаршого розробника.