Як Notion використовує Codex для one-shot engineering

Notion описує engineering pattern, де Codex отримує чітку specification, релевантний codebase context і спосіб перевірити роботу, після чого автономно досліджує repository та повертає substantial implementation. Найпоказовіший приклад — перенесення AI voice input із mobile на web.

Цінність pattern не в one-shot магії. Вона в підготовці task environment: reference implementation, ясний desired behavior, acceptance mechanism і codebase conventions. Без цього довгий agent run лише довше генерує невизначеність.

Trigger — feature request, bug, research task або small product tweak. Для voice-input кейсу input включав mobile implementation як reference, опис desired web behavior і спосіб verify result. Agent спочатку дослідив mobile code, потім створив web implementation.

Production input envelope додає base commit, relevant directories, repository instructions, test commands, network/dependency policy і out-of-scope files. Output — branch/patch + test evidence + assumptions + unresolved issues. Це A4 для bounded engineering task, але merge/release лишається human/system authority.

Workflow: `feature intent → spec contract → reference code/context → isolated Codex run → repository exploration → implementation → tests/static checks → preview/manual verification → PR → human merge`. OpenAI case показує, що engineer може запускати кілька tasks паралельно й повернутися до finished work, але concurrency не скасовує ownership.

Кожен run має durable task ID, exact base SHA, max time/token/tool budget, allowed network, required checks і terminal states `PASS / NEEDS_REVIEW / BLOCKED / FAILED / UNKNOWN`. Без UNKNOWN timeout легко перетворюється на дубльовану роботу або blind retry.

OpenAI case підкреслює, що Notion engineers дають Codex task і спосіб check its work. Production lesson: agent повинен мати executable feedback loop, а не лише prose instruction. Reference implementation корисна, але її compatibility треба перевірити для target platform.

Clean worktree/sandbox із pinned dependencies, deterministic test commands і restricted secrets зменшує blast radius. Якщо feature потребує browser/device behavior, додайте test harness або preview artifact, інакше agent може пройти unit tests, але зламати реальний UX.

OpenAI повідомляє, що Notion engineers можуть запускати multiple tasks in parallel, а manager знову може ship code поряд із керуванням командою. Це змінює queue economics: bottleneck переміщується від typing code до task specification, verification, review та integration.

Concurrency policy має ліміти за repo/module, dependency graph і reviewer capacity. Два agents на незалежних components — leverage; п’ять agents на одній migration boundary — генератор merge conflicts. Scheduler повинен бачити ownership, active branches і risky overlaps.

Failure modes: reference mobile behavior не переноситься на web; agent копіює platform-specific assumption; stale base; instruction poisoning; tests недостатні; feature superficially works, але має accessibility/privacy regression; overnight research повертає unsupported claim.

Контролі: stale-base check, protected test/CI config, accessibility/security checks, preview/manual validation для UX, dependency/secret scanning, no production credentials і human merge. Tool availability не дорівнює authority: agent із write access до repo не отримує автоматично deploy rights.

OpenAI наводить конкретний voice-input case: задача, яку engineer оцінював приблизно у два тижні для двох людей, була зроблена Codex приблизно за 3–4 години й shipped next day. Це сильний deployment example, але не незалежний benchmark для всіх features.

Eval suite: historical small features, cross-platform ports, bugs, ambiguous specs, security-sensitive changes, stale dependencies і tasks requiring clarification. Metrics: accepted-task rate, severe regression rate, test adequacy, diff churn, human correction minutes, time to verified PR і cost per accepted change. Кожен escaped defect стає permanent regression case.

Codex може працювати як always-available engineering queue, але full cost = model usage + sandbox compute + CI + artifacts + review + failed trajectories + retries + security scans + platform operations. Parallel agents збільшують і throughput, і review/CI pressure.

Rollout: 10–20 historical small tasks → spec + executable acceptance → clean isolated worktree → trajectory/test evidence → PR-only writes → human baseline on accepted outcome → parallel queue лише після stable regression history. Якщо definition of done живе тільки в голові senior engineer, first move — materialize acceptance criteria.