Разборы · Статья: · Видео: · 17:33
Промпт как платформа: почему ценность переезжает из кода в спецификацию
Разбор доклада основателя Resonate Доминика Торнова: если агенты научатся генерировать реализацию под любую инфраструктуру, продуктом становится не код, а спецификация — и как через детерминированную симуляцию заставить агента проектировать алгоритм, а не только его писать.
Смотреть на YouTube The Prompt is the Platform - Dominik Tornow, Resonate HQ
AI Engineer · 17:33
Главы видео — нажми, чтобы перейти к моменту 9
- 0:02 Тезис: первая платформа станет ненужной Не потому что плоха — просто её можно будет генерировать под конкретную инфраструктуру.
- 0:40 Повторное использование переезжает вверх Реюзать будем не готовую реализацию, а спецификацию, выводя из неё реализацию под задачу.
- 1:58 Ценность — в спецификации, а не в коде Продукт Resonate — уже не реализация сервера, а протокол, из которого выводятся реализации.
- 4:10 Одна абстрактная спека — много реализаций Спека не должна предполагать ни схему БД, ни KV-хранилище, ни модель консистентности.
- 5:20 Первая попытка провалилась Агент собрал сервер на Rust поверх Postgres — работал на happy path, ломался на конкурентности и сбоях.
- 7:00 Агента двигают вверх по цепочке Ему дают детерминированную симуляцию и задачу не строить продакшен, а найти корректный алгоритм.
- 8:35 Минимализм как финишная черта Три года ужимали протокол до двух объектов: durable promise и durable task.
- 9:38 NATS, stale reads и запретный плод Как выразить протокол через версионированный KV и научить агента жить со «свежими» и «протухшими» чтениями.
- 16:19 Агент закрывает разрыв От proof-of-concept в симуляторе — к конкретной спецификации и продакшен-реализации.
Коротко
Когда ИИ-агенты научатся генерировать реализацию под конкретную инфраструктуру, повторно использовать будут не библиотеку, а спецификацию — и ценность продукта переедет из кода в протокол. Главный приём доклада: дать агенту детерминированный симулятор, который честно воспроизводит редкие сбои и объясняет причину ошибки, чтобы агент проектировал корректный алгоритм, а не просто писал код.
Выжимка голосом
Самое ценное из разбора — за пару минут
Показать текст выжимки Скрыть текст выжимки
Озвучено синтезом речи · голос alena
Объясни проще
Суть без жаргона
Простыми словами
Resonate делает движок надёжного выполнения программ. Раньше они продавали готовый код, но считают, что скоро ИИ-агенты научатся сами писать такой код под любую инфраструктуру заказчика. Поэтому ценность переезжает с самого кода на его точное описание — спецификацию. Доклад показывает, как заставить агента не просто писать код, а находить правильный алгоритм: ему дают симулятор, который нарочно воспроизводит редкие сбои распределённых систем и подсказывает, почему решение оказалось неверным.
Как ребёнку
Представь, что ценным становится не сам торт, а подробный рецепт: любой повар или робот-повар испечёт торт на своей кухне. Автор говорит, что скоро так будет и с программами — важен рецепт, а не готовое блюдо. А чтобы робот-повар не ошибался, ему дают тренировочную кухню, где нарочно случаются мелкие поломки, и он учится готовить так, чтобы получалось надёжно даже тогда.
Аналогия — «это как…»
Это как перейти от продажи готовой мебели к продаже чертежей: покупатель на своём станке вырежет шкаф ровно под свою стену. А чтобы робот-столяр не халтурил, ему дают тренажёр, где доска иногда оказывается кривой, — и он учится собирать шкаф, который не развалится даже в таком случае.
Зачем это мне
Если код становится дешёвым и генерируемым, конкурентное преимущество переезжает на точные спецификации и на умение доказывать корректность. Это меняет то, за что платят инженерам и где живёт ценность продукта, — тема важна и для основателей, и для разработчиков распределённых систем.
Для тех, кто в теме
Resonate сводит durable execution к двум примитивам — durable promise и durable task — и генерирует таргет-специфичные реализации из одной абстрактной спеки. Ключевых приёма два: вставка concrete specification между абстракцией и кодом, и детерминированная симуляция с трейсами «запретного плода» (stale vs fresh read, скрытое актуальное значение), дающая агенту причинный сигнал для property-based отладки алгоритма под optimistic concurrency поверх NATS KV.
Оценка видео
Чем выше — тем больше пользы на минуту
средняя из 5
Тема генеративной инженерии и роли спецификаций — в самом центре повестки 2026 года.
Плотный доклад с реальной инженерной историей провала и решения, почти без воды.
«Симуляция как исполняемый дизайн» и «запретный плод» для агента — свежие и нетривиальные приёмы.
Идеи вдохновляют, но повторить подход трудно: нужен минимальный протокол и своя симуляционная среда.
Требует базового понимания распределённых систем: конкурентность, консистентность, optimistic concurrency.
Кому будет полезно
Чем выше оценка — тем больше пользы для профессии. Разверни — почему.
Для разработчиков распределённых систем 4.9 /5
Прямое попадание: детерминированная симуляция, optimistic concurrency, stale reads и трейсы причин — их ежедневная боль и инструменты.
Для AI-инженеров и разработчиков агентов 4.6 /5
Показан рабочий паттерн: как обогащённая, детерминированная обратная связь превращает агента из «писателя кода» в «проектировщика алгоритма».
Для архитекторов ПО 4.4 /5
Разделение абстрактной и конкретной спецификации и идея «спека как продукт» — это про то, как проектировать системы в эпоху генерируемого кода.
Для технических основателей и CTO 4.1 /5
Ставит стратегический вопрос: если реализацию можно сгенерировать, где теперь моат — и почему он переезжает в спецификацию и верификацию.
Для backend-разработчиков 3.7 /5
Полезно понять, почему сгенерированный код проходит базовые тесты, но падает на конкурентности и сбоях, — но многое здесь про нишу durable execution.
Для QA-инженеров и тестировщиков 3.5 /5
Детерминированная, воспроизводимая симуляция сбоев — сильная альтернатива flaky-тестам распределённых систем.
Инсайты
Нажми, чтобы раскрыть — то, что меняет взгляд на тему
01 Повторное использование переезжает вверх — от кода к спецификации 0:40
Классический реюз — взять готовую библиотеку. Тезис Resonate: реюзать будем спецификацию, а конкретную реализацию каждый раз выводить под свою инфраструктуру. Тогда общий код перестаёт быть активом, а активом становится точное описание.
02 Спецификация ценна ровно настолько, насколько она абстрактна 4:10
Чтобы из одной спеки родились разные реализации, она не должна предполагать ни реляционную БД, ни KV-хранилище, ни даже сильную или слабую консистентность. Любое протёкшее в спеку допущение реализации сужает круг таргетов, под которые её можно сгенерировать.
03 Симуляция — это не тест, а «исполняемый дизайн» 7:00
Симулятор здесь нужен не чтобы проверить готовый код, а чтобы агент нашёл сам алгоритм под частичным порядком и частичными сбоями. Продуктом этого шага становится не программа, а доказанно корректный алгоритм, из которого потом выводят спеку и реализацию.
04 Минимализм — это финишная черта, а не старт 8:35
Простой протокол из двух объектов — не то, с чего начали, а то, к чему пришли за три года, постоянно спрашивая: что ещё можно убрать, какую абстракцию стереть, какую связь разорвать. Простота — результат работы, а не исходное условие.
05 Агенту дают знание, запрещённое самому алгоритму 14:07
В проде код не знает, было ли чтение свежим или устаревшим, — и не должен на это опираться. Но симулятор записывает это в трейс и отдаёт агенту: «запретный плод» нужен не программе, а тому, кто её проектирует, чтобы объяснить причину ошибки.
Ключевые цитаты
Сильные фразы из видео — нажми тайм-код, чтобы услышать в оригинале
«В этот момент промпт становится платформой.»
«Наша ценность переезжает из реализации в спецификацию.»
«Продукт — уже не реализация. Продукт — это спецификация, протокол.»
«Спецификация должна быть абстрактной. Конкретной должна быть только реализация.»
«Минимализм и простота — это не точка старта. Это финишная черта.»
«Реализация должна быть корректной, когда инфраструктура ведёт себя не удобно, а легально.»
«Агент узнаёт не просто что система неверна. Он узнаёт, почему она неверна.»
«Промпт — это платформа, а спецификация — это продукт.»
Полезные советы
Что можно применить уже сегодня. Разверни совет — сколько займёт, что даст и что конкретно делать
1 Не прыгай из абстрактной спеки сразу в код
вечер перестанешь получать прототипы, которые проходят тесты, но падают в проде
Не прыгай из абстрактной спеки сразу в код
Разрыв между абстрактным описанием и конкретной реализацией слишком велик и для человека, и для агента. Вставь промежуточный артефакт — конкретную спецификацию с явными решениями под таргет.
Что делать
- 1 Возьми абстрактную спецификацию поведения без допущений о хранилище.
- 2 Выпиши явно таргет-специфичные решения: схему данных, индексы, запросы, границы транзакций.
- 3 Только после этого проси агента реализовать по конкретной спеке, а не по абстрактной.
2 Дай агенту детерминированную симуляцию до продакшена
несколько дней агент начнёт проектировать корректный алгоритм, а не только писать код
Дай агенту детерминированную симуляцию до продакшена
Симуляция воспроизводит нужные части инфраструктуры детерминированно, повторяемо и с возможностью заглянуть внутрь. Сломанный сценарий можно проиграть точь-в-точь и починить алгоритм против конкретной трассы.
Что делать
- 1 Смоделируй только те примитивы целевой платформы, от которых зависит корректность.
- 2 Управляй «сбоями» детерминированным генератором случайности, чтобы прогон был воспроизводим.
- 3 Дай агенту задачу построить симулированную реализацию, а не продакшен-систему.
3 Логируй «почему сломалось», а не только «что сломалось»
1 день отладка агентом станет причинной, а не гаданием по факту падения
Логируй «почему сломалось», а не только «что сломалось»
Агенты живут на обратной связи, но им нужна немедленная и однозначная: какое устаревшее значение вернулось, какая логика сработала, какая запись упала и какой инвариант из-за этого нарушился.
Что делать
- 1 На каждое чтение эмить событие трассы с типом (свежее или устаревшее).
- 2 Записывай скрытое актуальное значение, которого код не видел.
- 3 Отдавай эту трассу агенту при отладке, но не давай алгоритму на неё опираться.
4 Тестируй под легальным поведением, а не под удобным
полдня система перестанет ломаться на редких, но допустимых состояниях инфраструктуры
Тестируй под легальным поведением, а не под удобным
Устаревшее чтение из версионированного KV — не баг и не порча данных, а валидное поведение модели консистентности. Реализация обязана быть корректной именно тогда, когда целевая платформа ведёт себя легально, а не только удобно.
Что делать
- 1 Выпиши модель консистентности целевого хранилища: какие чтения и записи допустимы.
- 2 Заставь симулятор нарочно возвращать устаревшие версии по детерминированному расписанию.
- 3 Проверяй инварианты на этих «неудобных», но легальных трассах.
5 Спроси себя, где живёт твоя ценность
30 минут поймёшь, что защищать как продукт, если код станет генерируемым
Спроси себя, где живёт твоя ценность
Если реализацию можно многократно синтезировать из описания, то активом становится само описание и способность доказать корректность. Пересмотри, что в твоём продукте — реализация, а что — протокол и спека.
6 Сначала ужимай протокол, потом проси реализовать
долгая игра даже сложный распределённый протокол станет посильным для агента
Сначала ужимай протокол, потом проси реализовать
Пространство состояний даже простого конкурентного протокола огромно. Чем меньше примитивов и абстракций, тем меньше поверхность ошибок — и тем реальнее, что агент выведет корректную реализацию.
Что делать
- 1 На каждой проблеме спрашивай не «что добавить», а «что убрать».
- 2 Стирай лишние абстракции, свойства и связи между сущностями.
- 3 Держи ядро вокруг минимума объектов, на которых стоит вся система.
Сценарии применения
Как разные люди применяют это на практике
Я как Инженер распределённых систем
Проблема: редкие баги на конкурентности и сбоях всплывают только в проде и не воспроизводятся
Хочу: ловить эти состояния детерминированно и с понятной причиной
Поможет: разбор показывает паттерн DST: воспроизводимая симуляция сбоев плюс трасса причины ошибки
Я как Технический основатель
Проблема: боюсь, что агенты обесценят наш главный актив — кодовую базу
Хочу: понять, куда перенести конкурентное преимущество
Поможет: статья предлагает сместить ценность в спецификацию и верификацию, а не в конкретную реализацию
Я как AI-инженер
Проблема: агент бодро пишет код, который проходит базовые тесты и разваливается на краевых случаях
Хочу: научить агента находить корректный алгоритм, а не только его набирать
Поможет: видно, как исполняемый дизайн в симуляторе двигает агента из реализации в проектирование
Я как Архитектор ПО
Проблема: одну и ту же логику приходится переписывать под каждую инфраструктуру заказчика
Хочу: иметь один источник истины и выводить реализации из него
Поможет: разделение абстрактной и конкретной спеки даёт схему, как это организовать честно
Я как Backend-разработчик
Проблема: не понимаю, почему сгенерированный код падает именно на параллельных запросах
Хочу: разобраться в optimistic concurrency и устаревших чтениях
Поможет: на примере NATS KV объясняется, почему запись падает и как это ловить
Я как QA-инженер
Проблема: тесты распределённой системы flaky и не дают воспроизвести падение
Хочу: детерминированный и инспектируемый способ гонять сбойные сценарии
Поможет: подход с детерминированным генератором случайности делает баг повторяемым до трассы
Логика повествования
Как устроена аргументация видео — пройди по шагам
-
Предпосылка Реализацию скоро можно будет генерировать под задачу 0:40
Универсальные реализации заменяются заказными, собранными на лету как минимальное расширение уже имеющейся инфраструктуры.
-
Аргумент Значит, реюз переезжает вверх 1:02
Повторно используем не библиотеку, а спецификацию, из которой выводим реализацию под конкретный таргет.
-
Аргумент Ценность переезжает из кода в спецификацию 1:58
Продукт Resonate — уже не сервер, а протокол; из него выводятся и эталонная, и партнёрские реализации.
-
Аргумент Спека обязана быть абстрактной 4:10
Она не должна предполагать ни схему БД, ни KV, ни модель консистентности — иначе из неё не выведешь много реализаций.
-
Пример Прямой прыжок агента в код провалился 5:20
Сервер на Rust поверх Postgres работал на happy path, но ломался на конкурентности, сбоях процесса и сети.
-
Аргумент Вставка конкретной спеки помогла, но агент лишь строил, не проектировал 5:58
Явные решения по схеме, индексам и транзакциям дали продакшен, но дизайн вёл человек.
-
Пример Детерминированная симуляция вывела агента в проектировщика 14:07
Через «запретный плод» и причинные трассы агент находит корректный алгоритм под сбоями сам.
-
Вывод Промпт — платформа, спецификация — продукт 17:18
От одной абстрактной спеки: симуляция, конкретная спека, реализация — с агентом за рулём дизайна.
Подробный разбор
Полный разбор — разверни, если нужно глубже
Развернуть подробный разбор Свернуть подробный разбор
Стоит ли смотреть целиком
Да, если ты работаешь с распределёнными системами или строишь агентов, которые пишут код. Доклад короткий (17 минут), но плотный: это не абстрактный манифест про «ИИ изменит инженерию», а конкретная инженерная история — как попытка сгенерировать сервер напрямую провалилась, и что пришлось встроить в процесс, чтобы агент начал проектировать, а не просто печатать код.
Главная ценность — не в громком лозунге «промпт — это платформа», а в середине доклада: разбор того, почему сгенерированный код проходит базовые тесты и разваливается на конкурентности, и как детерминированная симуляция с причинными трассами («запретный плод») даёт агенту именно тот сигнал, который нужен для отладки распределённого алгоритма. Это переносимый приём, даже если ты никогда не притронешься к Resonate.
Чего в докладе намеренно нет
Торнов честно сужает тему: он говорит про спецификацию, а не про верификацию, и показывает подход на удобном домене — минимальном протоколе из двух примитивов. Поэтому воспринимай доклад как сильную демонстрацию направления, а не как готовый рецепт «замени инженеров агентами». Всё держится на трёх годах упрощения протокола и на своей симуляционной среде — то есть на большой работе людей, внутри которой агент оказывается мощным, но не автономным участником.
План внедрения
С чего начать — отмечай шаги, прогресс сохранится
Выполнено 0 из 5
Проверь себя
Ответь на вопросы, чтобы материал закрепился
-
1. Куда, по мысли доклада, переезжает ценность, если реализацию можно генерировать?
-
2. Почему первая попытка агента (сервер на Rust поверх Postgres) считается провалом?
-
3. Зачем между абстрактной спекой и кодом вставили «конкретную спецификацию»?
-
4. Какую роль играет детерминированная симуляция в этом подходе?
-
5. Что такое «запретный плод» в терминах доклада?
-
6. Почему устаревшее (stale) чтение из версионированного KV — не баг?
-
7. Как в докладе трактуют минимализм протокола?
Словарь терминов
Понять незнакомое простым языком
Показать 7 терминов Свернуть словарь
- Durable execution (надёжное выполнение)
- Способ запускать программы так, чтобы они переживали сбои процесса, сети и перезапуски и продолжались с места остановки, не теряя состояние.
- Durable promise / durable task
- Два базовых объекта протокола Resonate: «обещание» будущего результата и «задача», которые сохраняются надёжно и переживают сбои.
- Абстрактная и конкретная спецификация
- Абстрактная описывает поведение без допущений об инфраструктуре; конкретная фиксирует решения под конкретный таргет — схему, индексы, запросы, транзакции.
- Optimistic concurrency (оптимистичная конкурентность)
- Схема, где запись успешна, только если версия, которую ты прочитал, всё ещё актуальна; иначе запись отклоняется и надо повторить.
- Stale / fresh read (устаревшее и свежее чтение)
- Свежее чтение возвращает последнюю версию значения, устаревшее — более раннюю. В ряде моделей консистентности устаревшее чтение допустимо и не является ошибкой.
- Deterministic simulation testing (DST)
- Тестирование в смоделированной среде, где сбои и случайность управляются детерминированным генератором, поэтому любой прогон воспроизводится точь-в-точь.
- NATS
- Открытая система обмена сообщениями для распределённых систем; даёт очереди, key-value хранилище и отложенные сообщения как базовые примитивы.
Критический взгляд
Объективно: с какими тезисами можно поспорить и что преувеличено
Прогноз «в 2026 агенты тихо выведут из эксплуатации первую платформу» — сильное заявление
Это рабочая гипотеза одного вендора, а не наблюдаемый факт. Что реализацию сложных распределённых протоколов уже сейчас можно надёжно генерировать под произвольную инфраструктуру — пока не доказано на широком классе задач.
Подход показан на одном узком домене — durable execution
Протокол из двух примитивов и предсказуемая модель консистентности — удобный, но нетипичный случай. Обобщение на «любую инженерию» в докладе заявлено, но не продемонстрировано.
Формула «агент за рулём дизайна» преувеличивает автономию
По самому рассказу человек три года ужимал протокол, строил симуляционную среду и оставался в процессе проектирования. Агент силён внутри тщательно подготовленных людьми рамок, а не вместо них.
Рецепт трудно воспроизвести без предварительных вложений
Успех держится на минимальном протоколе (три года упрощения) и на своей DST-среде. Для команды без такого фундамента «дай агенту симулятор» — не готовый рецепт, а верхушка большой работы.
Верификацию задвинули ради спецификации
Автор сознательно смещает фокус со «как проверить корректность» на «как специфицировать». Но на масштабе именно доказательство корректности сгенерированных реализаций остаётся дорогим и нерешённым в общем виде.
Взгляни иначе
Новый угол, смежные области и потенциал на стыке — пища для размышлений
Если спека — продукт, то документация становится моатом
В мире генерируемого кода конкурентное преимущество переезжает в точность и полноту описания. Инвестиции в спецификации, схемы и модели поведения окупаются сильнее, чем ещё одна оптимизация реализации.
«Запретный плод» — это привилегированная информация как в машинном обучении
Давать наставнику сигнал, недоступный итоговой системе, — знакомый приём: privileged information и learning from a teacher в imitation learning. Тот же трюк из ML переносится на отладку алгоритмов агентами.
Детерминированная симуляция — не новинка Resonate
FoundationDB, TigerBeetle и antithesis годами строят системы через DST. Ценность доклада — соединить проверенную практику баз данных с генеративной инженерией и агентами.
Промпт-как-платформа значит версионировать спеки как код
Если из промпта/спеки рождается система, то ревью, версионирование и тесты переезжают на уровень спецификаций. Git-история описаний становится важнее истории самого кода.
Похожие разборы
Промпт — это всё ещё перфокарта: почему мы до сих пор учимся говорить с ИИ
Модели поумнели невероятно, но протокол общения с ними остался пакетным, как у перфокарт 1950-х: собери всю просьбу, отправь, жди ответ. Настоящий следующий шаг ИИ — не более умная модель за тем же окном ввода, а интерфейс, который сам участвует в разговоре и снимает лишнюю ношу с человека.
Читать → РазборМодель предлагает — платформа решает: инфраструктура надёжности для автономных ИИ-агентов
При переходе от чатботов к автономным агентам узкое место смещается с интеллекта модели на надёжность инфраструктуры вокруг неё. Модель должна лишь предлагать действия, а проверять, одобрять и исполнять их обязана детерминированная платформа — и именно она, а не лучший промпт, становится конкурентным преимуществом.
Читать → РазборSpec-driven development: спека до кода как способ приручить ИИ-ассистента
Spec-driven development — это писать требования и дизайн-документ в markdown до того, как ИИ-ассистент напишет хоть строчку кода: так модель получает контекст и не сходит с рельсов. Главный вывод — инструмент вроде Kiro лишь автоматизирует процесс, но ответственность, ревью и правка спек остаются на человеке.
Читать → РазборDomain-specific агенты: почему будущее за роем узких ИИ, а не за одним всемогущим
Компании пытаются интегрировать ИИ, навешивая на один большой агент всё больше MCP и skills — и упираются в раздувание контекста и хрупкость. Автор доказывает, что будущее за композицией: рой узких доменных агентов, каждый со своей моделью, инструментами и памятью, координируемых на обычном языке — это дешевле, безопаснее и масштабируется.
Читать →