Три решения, из которых доживает одно
На встрече решили три вещи. Через два дня никто не помнит вторую. Первую помнят, потому что по ней уже начали работать. Третью — потому что она была последней. Вторая была самой важной: именно там договорились, что схему меняем не сейчас, а после релиза, и именно её через неделю нарушат — не со зла, а потому что единственным её носителем была чья-то память.
Дальше знакомая последовательность. Кто-то пишет в чат «мы вроде решили иначе». Кто-то поднимает запись на сорок минут и не находит момент. Кто-то говорит «давайте просто соберёмся ещё раз» — и созвон, который был нужен один, случается дважды.
Это не проблема дисциплины. Это проблема формата: разговор — плохое хранилище, а стенограмма — плохой указатель. Между ними и живёт вся ниша AI-помощников для рабочих встреч, и разница между хорошим и бесполезным решается здесь.
Что именно теряется у разработчика
У технических встреч свой набор потерь, и он отличается от общего «не записали задачи». Вот он, по видам.
| Что прозвучало | Что осталось через два дня | Чем оборачивается |
|---|---|---|
| Технический контекст: почему сервис вообще устроен так | Ничего. Контекст был в разговоре и умер вместе с ним | Через полгода новый человек «упрощает» то, что стояло там намеренно |
| Архитектурное решение: берём B, а не A | Помнят выбор, не помнят причину | Спор повторяется целиком, с теми же аргументами и тем же исходом |
| Обсуждение бага: воспроизводится только при холодном старте | Строчка в трекере «падает иногда» | Следующий разработчик проходит тот же путь диагностики заново |
| TODO, сказанное вслух: «я поправлю ретраи» | Обещание без владельца и срока | Всплывает на демо, когда исправлять поздно |
| Зависимость: нельзя выкатывать, пока не мигрирует биллинг | Помнит один человек — тот, кто это сказал | Выкат в пятницу и откат в субботу |
| Договорённость со смежниками: они дают поле в ответе к четвергу | Устная договорённость без следа | В четверг выясняется, что «мы такого не обещали» |
| Вопрос на investigation: надо посмотреть, как это ведёт себя под нагрузкой | Забыт первым: у него нет ни исполнителя, ни формы | Тот же вопрос всплывает на ревью архитектуры через месяц |
| Ссылки и названия: дашборд, тикет, имя очереди, версия библиотеки | «Скинь ещё раз ту ссылку» | Двадцать минут в переписке вместо десяти секунд поиска |
И девятая потеря, которая дороже всех остальных вместе: переключение контекста. Разработчик выходит из встречи с оперативной памятью, забитой чужой задачей, и полчаса собирает обратно свою. Если после встречи ему предстоит ещё и вручную оформить решения в задачи — эти полчаса превращаются в час.
Почему стенограммы недостаточно
Первое, что делает почти любой инструмент, — записывает разговор и отдаёт текст. Это полезно и решает ровно одну задачу: «докажи, что это прозвучало». Всё остальное не решает, и вот почему.
- Часовая встреча — это девять-десять тысяч слов. Их не перечитывают. Стенограмма без разметки — архив, куда обращаются, только когда уже случился спор.
- Решения не звучат как решения. В тексте они выглядят как «ну давай так тогда», «окей, тогда после релиза», «да, наверное». Поиск по слову «решили» их не находит, потому что этого слова там нет.
- Важное распределено по разговору. Вариант предложили на пятой минуте, отвергли на двадцатой, вернулись к нему на сороковой. Ни один фрагмент по отдельности не содержит решения — оно есть только у встречи целиком.
- Распознавание тише всего ошибается на именах. Названия сервисов, очередей, библиотек, фамилии — текст остаётся связным, и подмена не видна глазом. Зато потом она не находится поиском: вы ищете имя сервиса, а в стенограмме записано похожее слово.
- Резюме одним абзацем — не лучше. «Обсудили архитектуру, договорились о следующих шагах» не помогает через два дня ровно так же, как не помогает стенограмма, только читается быстрее.
Что должно оставаться вместо фразы «нужно изменить API»
Вот тест на полезность любого AI-помощника для технических встреч. Возьмите реплику, которая на созвоне прозвучала так: «слушайте, нам всё равно придётся менять API». Посмотрите, что инструмент сохранил.
Бесполезная запись: «Нужно изменить API». Формально верно, и через две недели непонятно ничего: какой API, зачем, кто и к какому сроку.
| Что должно остаться | В этом примере |
|---|---|
| Что изменить | Добавить поле status в ответ /orders |
| Зачем | Клиент опрашивает второй эндпоинт, чтобы узнать то же самое, — лишние запросы на каждом заказе |
| Кто делает | Тот, кто сказал это вслух, а не «команда» |
| К какому сроку | До релиза 12-го: дальше замораживаем контракт |
| От чего зависит | Нельзя раньше, чем смежники выкатят миграцию |
И шестое, без чего первые пять — просто красивый пересказ: доказательство. Ссылка на минуту разговора, где это прозвучало. Разница принципиальная: запись с цитатой можно проверить, запись без цитаты неотличима от того, что модель придумала. На технических встречах это решает — «мы договорились» без ссылки на реплику быстро превращается в спор о том, кто что помнит.
Нет цитаты — нет факта. Всё, что помощник утверждает про вашу встречу, должно открываться в один клик до конкретной реплики. Инструмент, который выдаёт красивый список решений без ссылок на разговор, экономит вам пять минут сегодня и стоит недели доверия послезавтра, когда одно из «решений» окажется выдуманным.
meeting → context → decision → task
Полезный помощник — это не «диктофон с ИИ», а конвейер из четырёх переходов. Их стоит различать, потому что ломается обычно ровно один.
MEETING ──▶ CONTEXT ──▶ DECISION ──▶ TASK
│ │ │ │
разговор что это что из что теперь
как есть значит этого сле- делать и кто
и о чём дует отвечает
│ │ │ │
стенограмма темы, решения, дифф: создать
с тайм- участники, обещания, задачу, сдвинуть
кодами предмет, риски, срок, завести
термины вопросы материал
│ │
каждое — предлагается
с цитатой человеку, а не
применяется молча
meeting → context. Речь превращается в текст с разделением на говорящих и временем каждой реплики. Здесь же стоит развилка про имена собственные: инструменту либо разрешено править текст, либо нет. Разрешать опасно — модель начинает «улучшать» формулировки, и выдуманное исправление хуже расслышанного неверно.
context → decision. Самый сложный переход, и именно на нём экономят. Разметить фрагмент — дёшево: риск, вопрос, предложение и обещание слышны в нескольких репликах подряд. А вот решение по фрагменту установить невозможно в принципе: в окне слышно «давайте возьмём B», а от B отказались двадцатью репликами позже. Значит, решения и итоговые обещания требуют прохода по всей встрече целиком — иначе система будет уверенно сообщать о решениях, которых не принимали.
decision → task. Последний переход — тот, где помощник трогает вашу рабочую систему, и потому он обязан быть предложением, а не действием. Правильная форма — дифф: «было — станет», ссылка на цитату и кнопка «отклонить» рядом с кнопкой «применить». Задача создаётся из обещания и поручения; решение задачей не становится — «выбрали вариант A» это знание, а не работа, и превращать его в тикет значит придумывать команде дела.
Сценарий: обычный технический созвон
Пятьдесят минут, четверо. Обсуждают, почему очередь захлёбывается на пиках.
- На седьмой минуте кто-то называет причину: ретраи без экспоненциальной паузы, каждый сбой умножается сам на себя.
- На пятнадцатой предлагают вариант A — увеличить партиции. На двадцать второй его отвергают: упрётся в порядок сообщений.
- На двадцать восьмой принимают вариант B — очередь мёртвых сообщений плюс пауза с ростом. Это и есть решение, и оно неустановимо ни по одному отдельному куску разговора.
- На тридцать пятой возникает риск: если писем в очереди мёртвых накопится много, алерт никто не читает.
- На сороковой — вопрос на investigation: как поведёт себя потребитель, если пауза вырастет до минуты.
- На сорок пятой — обещание: «я подниму дашборд к четвергу».
- И зависимость под конец: выкатывать только после миграции биллинга.
Что должно остаться после такой встречи: одно решение с причиной и отвергнутой альтернативой (это важнее самого решения — иначе вариант A вернётся через месяц), один риск, один открытый вопрос с формулировкой, одна задача с владельцем и сроком, одна зависимость и ссылка на дашборд. Семь строк вместо девяти тысяч слов — и каждая с адресом минуты, где она прозвучала.
Что остаётся на практике без инструмента: сообщение в чате «мы решили сделать DLQ» и полное отсутствие всего остального.
Что делает AI, а что по-прежнему делает команда
Граница здесь важнее возможностей, потому что от неё зависит, будет ли инструмент полезен или станет генератором мусора в трекере.
| Делает AI | Делает команда |
|---|---|
| Слушает и помнит дословно | Принимает решения |
| Размечает: где решение, где риск, где вопрос | Выбирает, что из этого действительно важно |
| Держит доказательство на каждое утверждение | Проверяет доказательство, когда цена ошибки высока |
| Предлагает изменения в трекере и календаре | Применяет или отклоняет их |
| Находит, где эта тема обсуждалась раньше | Понимает, почему тогда решили иначе |
И отдельно: AI-помощник на встречах не пишет код и не должен. Это другой класс инструментов, у него другое место в рабочем дне и другие метрики качества. На встрече код не пишут — на встрече договариваются, зачем он будет написан.
Как это устроено в Whisperer
Whisperer слушает рабочий созвон без бота-участника: звук берётся с вашего компьютера, поэтому площадка значения не имеет — Zoom, Meet, Teams, что угодно. Дальше начинается то, ради чего всё затевалось.
- Стенограмма с тайм-кодами и разделением на говорящих. Имена людей проходят через проверку по словарю встречи — он собирается из участников, подписей говорящих, которые правил человек, и имени владельца аккаунта: подставить можно только известное имя и только если расслышанное на него похоже. Правки «по вкусу» модели запрещены: она не переписывает текст вообще, поэтому расслышанное неверно остаётся видимым, а не превращается в правдоподобную выдумку.
- Два прохода понимания вместо одного. Дешёвый проход по окнам разговора достаёт то, что слышно во фрагменте: утверждения, предложения, вопросы, риски, проблемы, идеи, поручения и позиции участников. Проход по встрече целиком достаёт то, что во фрагменте установить нельзя: темы, решения, итоговые обещания и договорённости о следующей встрече.
- Ни одного объекта без доказательства. Утверждение без ссылки на реплику не сохраняется вовсе; слабые извлечения отбрасываются по порогу уверенности; дубликаты схлопываются, а на каждый вид объектов есть потолок — сотня «решений» из часовой встречи вреднее пустого списка, потому что выглядит богато и ей верят.
- Экран «что изменит встреча». Предложения приходят диффом: видно прежнее состояние и будущее, рядом цитата и кнопка «отклонить». Кнопки «применить всё» нет намеренно. Событие в календаре, удаление и закрытие задачи не применяются автоматически ни при каких настройках: они затрагивают людей за пределами вашего аккаунта или уничтожают то, чего система не создавала.
- Возврат к контексту позже. Поиск по встречам и по репликам, «кто какую позицию занимал», «какие решения приняты по этой теме», сведение одной темы по всему архиву и цитаты-доказательства к любому из этих ответов. Это же доступно внешнему ассистенту — Claude Desktop или Cursor — через MCP, если разбирать архив удобнее оттуда.
- Память между встречами. Факты встречи проецируются в контекст, который доступен на следующих разговорах, — почему это отдельная задача и чем она отличается от размера окна модели, мы разбирали в статье почему AI забывает.
Честно про границы: разбор встречи и поиск по ней — платные возможности, бесплатный тариф даёт 60 минут распознавания в месяц и стенограмму. Понимание — самая дорогая стадия конвейера, у часовой встречи это десятки тысяч токенов на каждое окно, и делать вид, что это бесплатно, было бы нечестно по отношению к тем, кто платит. Есть и режим, в котором не сохраняется вообще ничего: ни стенограммы, ни разбора — для разговоров, которых не должно остаться.
И то, чего Whisperer не делает: не пишет за вас код, не выносит архитектурных решений и не заменяет письменное ADR там, где оно нужно. Он доводит разговор до состояния, из которого писать такой документ занимает пять минут, а не полтора часа с перематыванием записи.
Общая картина по классу инструментов — в опорном разборе: AI meeting assistant: что это, как работает и зачем нужен.
Частые вопросы
Чем AI-помощник на встречах отличается от обычной транскрибации?
Транскрибация отвечает на вопрос «что было сказано». Помощник должен отвечать на вопрос «что из этого следует»: где решение и какая у него причина, что стало обещанием, какой вопрос остался открытым и что теперь менять в трекере. Стенограмма при этом никуда не девается — она остаётся доказательной базой.
Нужно ли пускать бота в рабочий созвон?
Нет, если инструмент берёт звук с вашего компьютера. Тогда в списке участников никто лишний не появляется и согласование с площадкой не требуется. Предупредить коллег о записи всё равно нужно — это вопрос уважения и часто закона, а не техники.
Как AI отличает решение от предложения?
По охвату. Предложение, риск или вопрос слышны в нескольких репликах подряд, а решение устанавливается только по разговору целиком: в середине встречи вариант могли принять, а к концу отвергнуть. Поэтому решения извлекаются отдельным проходом по всей стенограмме, а «решения», найденные внутри фрагмента, отбрасываются.
Создаются ли задачи автоматически?
По умолчанию нет: изменения приходят предложениями с прежним и будущим состоянием и с цитатой из разговора, а применяет их человек. Автоматически можно разрешить только создание своих задач в трекере; календарные события, удаления и закрытие задач остаются ручными при любых настройках.
Подходит ли это для технических встреч с жаргоном?
Да, но ждать безошибочного распознавания жаргона не стоит: словарь встречи исправляет имена людей, а не названия библиотек. Помогает другое — модели запрещено переписывать стенограмму, поэтому неверно расслышанный термин остаётся заметным искажением, а не превращается в гладкую выдумку, и рядом всегда есть цитата с тайм-кодом, по которой слышно, как было на самом деле.
Можно ли работать с архивом встреч из своей среды разработки?
Да, через MCP: внешний ассистент вроде Claude Desktop или Cursor получает доступ к поиску по встречам, решениям и цитатам. Это удобно, когда контекст нужен там, где вы пишете код, а не в отдельной вкладке.
Что дальше
Есть простая проверка, стоит ли инструмент вашего времени. Возьмите последнюю техническую встречу и попробуйте ответить на три вопроса: какое решение приняли, почему отвергли альтернативу и кто что пообещал. Если для ответа приходится поднимать переписку или спрашивать людей — вы уже платите за отсутствие такого инструмента, просто платите временем команды.
Хороший AI-помощник разработчика не пишет код вместо команды. Он помогает команде не забыть, зачем этот код вообще пишется.
Проверить проще всего на своём же созвоне: заведите аккаунт — 60 минут в месяц бесплатны — и проведите с ним ближайшую техническую встречу. Потом откройте разбор и посмотрите на одну вещь: сходится ли список решений с тем, что вы помните, и открывается ли каждое из них до реплики, где оно прозвучало. Если сходится — у вашей команды появилась память, которая не зависит от того, кто присутствовал.