Як Braintrust перетворює customer feature request на preview branch за хвилини з Codex

У B2B product development customer request часто проходить довгий шлях: support/sales формулює сигнал, PM уточнює, engineering оцінює, задача потрапляє у backlog, а клієнт бачить перший working artifact через дні або тижні. Частина цього процесу потрібна для пріоритизації, але частина — просто висока ціна експерименту. Якщо дешевше швидко побудувати ізольований preview, команда може перевірити ідею до того, як зробить її roadmap commitment.

Braintrust описує саме такий зсув із Codex. Замість покрокового prompting інженер може написати test, що демонструє проблему, створити sandbox і дозволити Codex шукати рішення. Customer feature request швидко перетворюється на preview branch, який можна показати клієнту. Це не скасовує product judgment; навпаки, робить judgment дешевшим, бо він спирається на working evidence.

Trigger — підтверджений customer feature request, reproducible bug або hypothesis, для якої корисний working prototype. Input — normalized request, repository snapshot, acceptance test/expected behavior, coding conventions, dependency lock, allowed tools і sandbox boundary. Сирий customer text не повинен напряму ставати privileged instruction: його спершу класифікують як requirement evidence.

AI stage — codebase exploration, plan, implementation, tests і local iteration. Integrations — issue/customer-feedback surface, Git repository, sandbox/preview environment, CI/eval tooling та observability. Output — preview branch із diff, test results, assumptions і unresolved risks. Це candidate artifact, не production change.

• Trigger → customer request, reproducible issue або product experiment.
• Input → request + repository SHA + acceptance test + scope + sandbox policy.
• AI → investigate, implement, run tests, iterate, summarize evidence.
• Integrations → feedback/issue source, Git, sandbox, CI/evals, preview environment.
• Output → branch/preview + verification report + explicit human decision point.

Репродукований flow: `customer signal → dedup/eligibility → requirement normalization → acceptance test → isolated branch/worktree → Codex execution → deterministic tests → preview deploy → customer/internal review → product decision → optional normal PR path`. Ключовий 80/20-контроль — acceptance test до автономної роботи. Без нього агент оптимізує те, що сам зрозумів, а команда потім героїчно перевіряє, чи проблема була взагалі та.

Кожний run має release envelope: base SHA, task ID, test version, agent/model revision, tool scopes, dependency state і preview URL. Якщо main змінився, branch не можна механічно merge-нути лише тому, що preview сподобався клієнту; потрібні rebase/replay та повторна verification.

A4 виправданий для sandbox task: агент може сам обирати файли, редагувати код, запускати tests і повторювати спроби до bounded budget. Людина не має підтверджувати кожен read або test run. Але authority різко закінчується на merge, external side effect, secret access, schema migration або contract/API change.

Customer preview теж не є approval. Клієнт може сказати «саме це», але PM/engineering усе одно перевіряє maintenance cost, compatibility, security, support burden і strategic fit. Швидкий prototype знижує information cost, а не переносить governance до першого користувача, який голосніше попросив.

Failure modes: request двозначний; acceptance test неповний; branch базується на stale SHA; agent змінює більше scope; tests проходять, але preview ламає compatibility; tool timeout стався після branch push; customer text містить prompt injection; generated dependency має security issue. Policy має блокувати network/secrets за замовчуванням, allowlist tools, обмежувати files/commands і фіксувати trajectory.

Після uncertain write спочатку читається authoritative Git/preview state. Повторний push/preview creation використовує idempotency key. Якщо agent budget вичерпано, output — partial progress + failed checks + next recommended action, а не вигаданий «done». Critical test failure або scope escape переводить run у human escalation.

На рівні одного founder цей workflow виглядає як суперсила; на рівні команди виникають queueing, branch explosion, preview infrastructure, CI minutes, review capacity і duplicate requests. Потрібен intake dedup, concurrency limits per repository, TTL для preview environments, task priority і automatic cleanup. Інакше компанія швидко автоматизує створення не коду, а смітника з 400 гілок.

Cost model: `Codex/model inference + sandbox compute + repository/context IO + preview infrastructure + CI/tests + observability + human review + rework + cleanup`. Основна метрика — `cost per accepted verified experiment`, а не lines of code. Додатково: time request→preview, preview→decision, acceptance rate, defects after merge, rollback rate і human review minutes.

Dataset формується з historical feature requests: clear, ambiguous, duplicate, impossible, security-sensitive, multi-service, UI-only, API-contract і no-change-needed. Для кожного задаються expected eligibility, allowed scope, acceptance tests і severity. Deterministic graders перевіряють build, unit/integration tests, lint/types, dependency policy та diff boundaries; human/model graders — requirement fidelity, maintainability і unsupported assumptions.

Окремо потрібні trajectory evals: чи агент читав недозволені files, чи намагався обійти failing test, чи зробив network call без потреби, чи повторив write після timeout. Production/preview incident мінімізується до regression case. Це прямо відповідає Braintrust-підходу: production traces можуть ставати test cases, а evals мають передувати deploy.

Rollout: `offline historical tasks → sandbox read-only → low-risk bugfixes → preview branches without customer exposure → selected customer previews → normal PR integration → broader intake`. Promotion gate: acceptance tests stable, scope escape zero для critical slices, preview cleanup reliable, human review не росте швидше за throughput, а merged defect rate не гірший baseline.

Почніть із 30–50 historical requests, де відомо, що вважалося правильним результатом. Побудуйте intake normalization і test-first template, дайте agent окремий worktree/container без production secrets, збирайте trace і повну собівартість. Лише після цього підключайте live customer requests. Кейс Braintrust цікавий не тим, що «AI пише код», а тим, що working preview стає дешевою одиницею product discovery.