Multi-agent spec-driven development on OpenSpec
Мультиагентный spec-driven development на OpenSpec
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·Original: about 156 minutes to listen
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 billiontokens used per month, roughly 95% of them cache reads
- 10 roundslongest observed back-and-forth between reviewer and implementer agents
As reported by the source.
Russian·Video·opens youtube.com
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
Russian original
Я не хочу больше вычитывать код. Я не хочу смотреть на див. Я не хочу быть вот этим ревьювером кода
"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."
Russian original
Оркестратор - это маршрутизатор. Он не задумывается над тем, что написали. Он не исследует это как задачу. Он не исследует код, он не принимает никаких решений.
"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."
Russian original
реализатор - это, наверное, самый впитывающий очень много контекста сабагент, и он начинает плыть, ну, даже уже относительно своих инструкций под конец.
"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."
Russian original
вот reviewer может найти какой-нибудь кейс. Это, наверное, процентов 90 вот этих блокеров.
"The reviewer can find some edge case. That is probably about 90 percent of these blockers."
Russian original
У меня их там под пол миллиарда выходит за месяц в целом, но вот подавляющая часть из них - это кэш-рид.
"I end up with close to half a billion a month in total, but the overwhelming majority of them are cache reads."
Russian original
у тебя никакой жизни и токенов не хватит, поэтому всё равно оно как будто бы остаётся вопросом веры.
"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)
Summary based on the full transcript. Read the original for the full argument and data.Watch the original on youtube.com