Як Deepgram масштабує Claude Code: durable code, MCP і support triage за хвилини

Deepgram має широкий engineering surface: inference, SDKs, APIs, billing, infrastructure, integrations і voice applications. За публічним кейсом компанія свідомо змістила operating model від «інженер пише кожен рядок» до «інженер задає поведінку, контекст і acceptance, агент виконує, система та людина перевіряють». Це важливий production зсув: швидкість генерації сама по собі не є цінністю, якщо review, tests і incidents ростуть ще швидше.

Внутрішній cohort analysis Deepgram використовував durable code як сигнал — код, який не був швидко замінений. Anthropic/Deepgram повідомляють 4–10× вищий durable-code output у regular/power users, але також приблизно 9× вищий churn у найважчих користувачів. Саме цей контрсигнал робить кейс корисним: компанія не зробила висновок «AI пише більше — знижуємо контроль», а підняла вимоги до test coverage AI-generated code.

Engineering trigger — issue, specification, bug, migration task або failing test. Input: repository state, task contract, coding standards, architecture context, allowed skills, scoped MCP servers, test commands і protected-path policy. Claude Code планує зміни, редагує в isolated branch/worktree, запускає deterministic checks і готує diff/PR. Output — candidate change з verification evidence; production release не є частиною мовної відповіді й не успадковується від write access до repository.

Support trigger — customer incident, наприклад spike errors або unexpected behavior. Центральний agent отримує case identity та може запустити паралельних read-only workers, які збирають evidence зі Slack, DevRev, Notion, GitHub, Asana і Grafana. Workers повертають findings, central agent синтезує root cause і draft response. Якщо треба змінити customer record, надіслати відповідь або торкнутися production, action проходить human/policy approval.

• Trigger → issue/spec/failing test або customer incident.
• Input → repository/case identity + approved context + skills + MCP allowlist + acceptance criteria.
• AI → plan, inspect, generate, execute checks, parallelize read-only investigation.
• Integrations → GitHub, Slack, DevRev, Notion, Asana, Grafana та Deepgram developer tooling.
• Output → verified candidate code або evidence-backed incident diagnosis; consequential write окремо approve.

Deepgram документує CLI з built-in MCP server, docs MCP endpoint і skills repository для agentic developer tools. Це зручно, бо agent отримує структурований доступ до офіційних APIs і документації замість випадкового scraping. Але MCP connection — це capability, а не автоматичний trust. У production потрібно фіксувати server identity/version, exposed methods, read/write scope, credentials, network destination і owner; organization-scoped allowlist має бути частиною release envelope.

Shared `SKILL.md` або plugin repository перетворюється на execution-adjacent control plane. Зміна інструкції може вплинути на багато агентів одразу, тому skill update має проходити code review, provenance check, regression eval і staged promotion. Якщо agent здатний сам редагувати skill, який визначає його майбутню поведінку, потрібна незалежна approval boundary; інакше система дозволяє результату одного run непомітно переписати правила наступних.

Публічний кейс Deepgram описує внутрішній Deephive-style pattern, де центральний сильніший agent координує паралельних дешевших/read-only workers для пошуку доказів у різних системах. Така архітектура добре масштабує investigation, бо кожен worker має вузький source scope, а центральний agent не мусить послідовно читати все. Найважливіше — read-only за замовчуванням: діагностика не повинна одночасно мати право змінювати production або customer state.

Production flow: `incident ID → identity/account match → parallel evidence fetch → timestamp/source normalization → hypothesis → cross-source verification → root-cause confidence → draft response/remediation → human approval → permitted action → authoritative verification`. Якщо два workers суперечать одне одному, система не «усереднює» відповідь, а позначає conflict. Якщо telemetry stale або account match неоднозначний, агент abstain/escalate замість красивого, але неперевіреного diagnosis.

Deepgram прямо підкреслює, що кожна production change має human sign-off і кожен deliverable має одну відповідальну людину. Водночас agentic workflow достатньо глибокий, щоб планувати, змінювати код, запускати інструменти, паралелити research і self-verify — тому reproduction оцінено як A4: висока автономність усередині bounded environment без передачі остаточної production authority.

Практична межа проста: agent може зробити багато роботи до decision point, але не може сам змінити definition of done. Tests, security policy, protected branches, required reviewers і production postconditions існують поза його текстовим контекстом. Якщо модель може редагувати CI, відключити тест або змінити власні agent instructions так само легко, як application code, «human sign-off» швидко стає декоративною галочкою.

4–10× durable code — внутрішня метрика Deepgram із cohort analysis, а не randomized independent study. Вона цікавіша за lines-of-code, бо намагається врахувати, чи survived change у codebase, але все одно може залежати від досвіду developer, task mix, team, model access і selection effects. Аналогічно 95% Claude-written code на найпродуктивнішій команді показує operating style, а не те, що 95% generated code автоматично якісне.

Для власного rollout потрібні paired metrics: accepted PR throughput, reviewer minutes, escaped defects, rollback rate, churn/rework після 7/30 днів, test coverage delta, incident rate і cost per verified merged change. Support flow міряється time-to-evidence, time-to-correct-diagnosis, customer correction rate, false-root-cause rate і unsafe-action attempts. Якщо throughput росте, але defect/rework budget з'їдає виграш, система лише швидше виробляє технічний борг.

Failure modes: stale branch, flaky test, MCP server drift, poisoned skill, repository instruction injection, wrong customer/account, telemetry lag, partial tool timeout, duplicate ticket action, provider outage, overlong loop. Controls: SSO, organization-scoped MCP allowlists, isolated workspaces, branch protection, required CI, secret/network restrictions, read-only support workers, exact-action approval, idempotency key, authoritative reconciliation, model/skill versioning, audit trace і scoped kill switches.

Frequency — постійна: coding tasks і PRs протягом робочого дня, support incidents event-driven, research bursty. Cost = Claude Enterprise seats/usage + inference/tool calls + MCP/observability infrastructure + CI compute + skills maintenance + reviewer time + incident reserve. Route-by-task корисний, але дешевший model tier не має отримувати high-impact step лише через budget pressure. Оптимізуйте cost per verified outcome, а не токени на один prompt.

Eval suite: repository tasks різних мов, failing tests, protected files, ambiguous specs, malicious README/issue text, broken MCP, expired credential, partial write, duplicate retry; support — wrong account, conflicting logs, stale dashboards, prompt injection у ticket, no-evidence case. Deterministic graders перевіряють tests, schemas, permissions, changed paths і postconditions; human/model graders — material correctness, root-cause support та quality handoff. Production incidents стають permanent regression cases.

Rollout: `read-only coding analysis → branch-only changes → required CI/review → limited agent parallelism → support read-only investigation → approved customer draft → narrowly bounded reversible actions`. Потрібні existing test discipline, branch protection, identity, source inventory, MCP registry і accountable owners. Якщо codebase не має executable tests, спочатку інвестуйте у verification harness; видавати агенту більшу автономність без oracle — це просто автоматизувати впевненість.