---
id: "lib-2026-10-01-multi-agent-spec-driven-development-on-openspec"
type: "library"
title: "Multi-agent spec-driven development on OpenSpec"
title_original: "Мультиагентный spec-driven development на OpenSpec"
lang: "RU"
org: "Гриненко про (Yandex speaker)"
source_type: "Podcast"
date: "2026-10-01"
week: "2026-W41"
url: "https://nosov.ai/library/lib-2026-10-01-multi-agent-spec-driven-development-on-openspec/"
original_url: "https://www.youtube.com/watch?v=nntQKlHS-z4"
tier: "B"
tier_name: "Useful, limited"
tier_reason: "A detailed practitioner walkthrough with a live demo by a Yandex engineer after three months of use, with concrete roles and token figures but no baseline or comparative measurement."
summary_basis: "transcript"
original_minutes: "156"
tags: ["ai technology", "business transformation", "spec driven development", "multi agent"]
---

# Multi-agent spec-driven development on OpenSpec

Original title: Мультиагентный spec-driven development на OpenSpec

Tier B (Useful, limited): A detailed practitioner walkthrough with a live demo by a Yandex engineer after three months of use, with concrete roles and token figures but no baseline or comparative measurement.

Summary based on the full transcript.

## In short

A 156-minute Russian-language episode of the podcast "Grinenko pro" (1 October 2026) in which Kir Belevich of Yandex describes how he has built software for three months with a multi-agent pipeline on OpenSpec, a spec-driven development tool. His goal is to stop reading code diffs while keeping a quality guarantee: he writes two sentences of intent, approves specification documents, and agents in fixed roles do the rest. The second half is a live demo building a small Markdown editor. The host presses him on evidence, and Belevich concedes the setup reflects his practice rather than a measured optimum.

## Key numbers

- about 90%: share of reviewer blockers caused by missing edge-case tests
- about half a billion: tokens used per month, roughly 95% of them cache reads
- 10 rounds: longest observed back-and-forth between reviewer and implementer agents

## What it reports

- The specification is the single source of truth; code is treated as secondary and in principle regenerable in another language.
- OpenSpec runs in three steps (propose, apply, archive) producing proposal.md, delta specs with SHALL/MUST requirements and Given/When/Then scenarios, design.md and tasks.md.
- Four roles: an orchestrator that only routes, a planner that writes artifacts, an implementer that must complete every task item, and a reviewer that compares spec against implementation.
- He started with one human approval at the end, then added a second gate right after the proposal.
- About 90% of reviewer blockers are missing edge-case tests; he attributes this to the implementer drifting late in long sessions.
- Ping-pong of up to 10 rounds between reviewer and implementer occurs.
- Models from three vendors cross-check each other: Sonnet or Opus as planner, a cheaper fast model as implementer, a GPT model as reviewer.
- Monthly usage is about half a billion tokens, roughly 95% cache reads.

## How they got it

One practitioner's account of his own daily workflow in Cursor over about three months, followed by a live build on screen. The digest is based on cleaned YouTube auto-captions, in which some model names are garbled.

## Limits

- No single-agent baseline or cost comparison; the host calls model and prompt choice "a matter of faith" and Belevich agrees.
- Single developer, small projects; team-scale use is discussed but not shown.
- Error rates are recollections, not logged statistics.

## Why it matters for companies

The pattern moves human effort from reading code to approving written intent and specifications at two gates. For a company building internal tools with agents, that maps onto familiar governance: a requirements sign-off and a design sign-off. The independent reviewer with fresh context is the part most worth copying, since it catches the gaps a long single session misses. The lack of any baseline means teams should measure their own defect and cost rates before adopting it.

## Key passages in translation

> Я не хочу больше вычитывать код. Я не хочу смотреть на див. Я не хочу быть вот этим ревьювером кода

"I don't want to proofread code any more. I don't want to look at the diff. I don't want to be that code reviewer."

> Оркестратор - это маршрутизатор. Он не задумывается над тем, что написали. Он не исследует это как задачу. Он не исследует код, он не принимает никаких решений.

"The orchestrator is a router. It does not think about what was written. It does not investigate it as a task. It does not investigate the code, and it makes no decisions."

> реализатор - это, наверное, самый впитывающий очень много контекста сабагент, и он начинает плыть, ну, даже уже относительно своих инструкций под конец.

"The implementer is probably the sub-agent that absorbs the most context, and towards the end it starts to drift, even from its own instructions."

> вот reviewer может найти какой-нибудь кейс. Это, наверное, процентов 90 вот этих блокеров.

"The reviewer can find some edge case. That is probably about 90 percent of these blockers."

> У меня их там под пол миллиарда выходит за месяц в целом, но вот подавляющая часть из них - это кэш-рид.

"I end up with close to half a billion a month in total, but the overwhelming majority of them are cache reads."

> у тебя никакой жизни и токенов не хватит, поэтому всё равно оно как будто бы остаётся вопросом веры.

"You would not have enough life or tokens for it, so it still remains, in a way, a matter of faith." (the host, on testing every combination of models and prompts)

Original: https://www.youtube.com/watch?v=nntQKlHS-z4