Developer Experience в Capital One: как масштабировать developer enablement для 14,000 разработчиков

Недавно послушал подкаст Software Engineering Daily с Кэтрин McGarvey, SVP of Developer Experience в Capital One. Она рассказала о том, как организовать developer enablement на масштабе 14,000 разработчиков, как измерять продуктивность, как балансировать между agility и compliance в регулируемой финансовой индустрии, и как Capital One внедряет AI-инструменты в enterprise-разработку. Вот основные моменты из разговора.

Опыт Кэтрин: от стартапов до enterprise

Кэтрин имеет уникальный опыт работы в разных средах: стартапы, консалтинг, defense-консалтинг, и теперь Capital One. Этот разнообразный опыт научил её важному уроку: “Нет одного правильного способа делать что-то”.

Ключевой вопрос, который она задаёт себе: “Что действительно важно для бизнеса и потребителей в том, как мы разрабатываем программное обеспечение?” Это помогает определить, что нужно стандартизировать, а где можно оставить гибкость.

В стартапах она работала от “нуля до одного” и “от одного до ста пользователей”, где долгосрочная архитектура имела меньше значения, чем выживание и получение первых клиентов. В Capital One же критически важно обеспечить устойчивость для миллионов клиентов, сохраняя при этом agility для адаптации к их обратной связи.

Что такое Developer Enablement?

Кэтрин различает developer productivity и developer enablement. Productivity фокусируется на throughput, скорости и качестве кода: “Команда выдаёт код с определённой скоростью? Достаточно ли высокое качество? Попадает ли он в руки пользователей достаточно быстро?”

Enablement же объединяет скорость разработки с пониманием того, что нужно пользователям. “Productivity без связи с ценностью — это умирающий продукт”, — говорит Кэтрин.

15-20 лет назад, когда появилась роль product manager, произошёл сдвиг к вопросу “строим ли мы правильную вещь?”. Developer enablement — это баланс между инструментами для ускорения разработки и информацией о том, что нужно пользователям, чтобы команды решали правильные задачи.

Важно, чтобы у каждой команды был голос клиента — это может быть дизайнер, product manager, или оба. Иногда это один человек, иногда несколько, в зависимости от сложности того, что вы доставляете. Но вам нужна эта связь с командой.

Команда должна быть достаточно маленькой, чтобы быть эффективной в решении конкретного outcome или доставке продукта. Комбинация маленькой команды, информации, необходимой для выполнения работы хорошо, и кого-то, с кем можно обсудить это, даёт им возможность не просто взять определение продукта и выполнить его, а понять его, обсудить и увидеть, как можно улучшить опыт в целом, а не просто доставить фичу.

Измерение успеха на масштабе 14,000 разработчиков

Один из ключевых вопросов — как измерять успех developer enablement на таком масштабе. Кэтрин отмечает, что в индустрии были большие движения вокруг DORA-метрик (throughput, recovery time) и SPACE framework (качественная сторона).

“Нет одного идеального ответа, но есть много хороших вещей, которые можно измерить”, — говорит она. Важно измерять правильные вещи, но понимать, что это не единственное, что нужно измерять.

Ключевые метрики

• Время между деплоями — показатель непрерывной доставки. Чтобы делать это хорошо, нужны отличное тестирование и качественные меры
• Время до первого коммита и время до 10-го коммита — для оценки onboarding. Важно, чтобы новые сотрудники знали, что их измеряют, так как это влияет на поведение
• Время от старта истории до деплоя в production — общий цикл разработки (от клика “Start” в Jira до production)
• Время окупаемости инвестиций — сколько дней нужно, чтобы функция стала ценной после разработки
• Качественные метрики — удовлетворённость разработчиков, использование инструментов, NPS

Важный момент: “Вы оптимизируете то, что измеряете”. Разработчики отлично умеют “играть” в метрики. Поэтому важно выбирать правильные метрики, которые не будут провоцировать неправильное поведение. Например, количество PR на разработчика — плохая метрика, так как можно просто делать множество мелких PR. Количество строк кода — ещё хуже, так как AI может генерировать много кода, но это не показатель ценности.

Кэтрин фокусируется на метриках, связанных с конкретными результатами: “Я предоставляю инструмент для code review — делает ли он code review лучше? Какой результат этих code review? Какой impact от доставки этого инструмента?”

Пример: измерение onboarding

Один из примеров, который Кэтрин приводит — это команды, фокусирующиеся на onboarding. Onboarding — это интересная вещь, когда вы нанимаете или люди переключаются между командами. Часть этого — даю ли я им правильную информацию? Указываю ли я им, куда идти, чтобы открыть для себя вещи? Даю ли я им правильное обучение и стартовые позиции, чтобы они могли коммитить код довольно быстро в своём путешествии?

Интересные метрики для измерения там — это время до первого коммита и время до 10-го коммита, которые действительно хороши и являются стандартами в индустрии для измерения этого хорошо. Но также есть ожидания — знает ли человек, который присоединяется, что есть ожидание на измерение этих вещей? Потому что если вы знаете, что вас измеряют, это изменит ваше поведение.

Это также влияет на retention и удовлетворённость работой, потому что если вы были наняты для коммита кода на каком-то уровне по вашей job family, идеально вы хотите начать показывать, что вы можете это делать, потому что это даёт вам уверенность, что вы понимаете пространство. Есть также внутреннее беспокойство о том, что “я хочу продемонстрировать ценность”, а также удовлетворённость тем, что работа даёт мне то, что я ожидал.

Agility в регулируемой индустрии

Capital One работает в высокорегулируемой финансовой индустрии, где критически важны безопасность и compliance. Как при этом сохранить agility? Это был один из вопросов, который заинтересовал Кэтрин и привёл её в Capital One.

Стратегия Capital One: “Сделать правильное действие простым по умолчанию”. Все практики, платформы, сервисы и модели работы построены так, чтобы лучшие практики были поведением по умолчанию.

Вместо того чтобы требовать от разработчиков выбирать между множеством опций (“Какую базу данных использовать?”), компания предоставляет рекомендуемое решение. Если оно не подходит — есть процесс исключений и одобрений, но по умолчанию путь простой и правильный.

Стандартизация vs гибкость

Когда что-то должно быть стандартизировано по всей компании, Capital One стандартизирует и требует от всех команд соответствия этому стандарту. Это создаёт миграционную работу время от времени, но даёт большой эффект, так как можно встроить контролы и лучшие практики в стандарт, что требует меньше работы от команд разработки.

Когда нет стандарта, появляются разные инструменты. Capital One быстро устанавливает стандарт, задаваясь вопросом: “Каким должен быть стандарт здесь?” Критерии для стандартизации:

• Высокая leverage — много инструментов приходит, что увеличивает работу по security review
• Открытые стандарты — например, в telemetry много стандартизировано, что упрощает выбор инструментов
• Быстро меняющиеся области — в LLM и AI пространстве Capital One стандартизирует на критериях успеха и абстракциях, а не на конкретных моделях, чтобы не застрять на одном подходе

“Чем больше вы привязываетесь к одной модели или одному подходу, тем больше вы загоняете себя в угол”, — говорит Кэтрин о быстро меняющемся мире AI.

Процесс обнаружения и стандартизации

Когда нет стандарта, появляются разные инструменты. Capital One быстро устанавливает стандарт, задаваясь вопросом: “Каким должен быть стандарт здесь?”

Процесс обнаружения работает так: вы начинаете видеть пролиферацию инструментов или сервисов, которые похожи. И тогда вы понимаете, что есть overlap в возможностях. Обычно Capital One поручает команде выяснить, каков правильный ответ для этого случая.

Обычно это подхватывается, когда это видно как высокая leverage. Много инструментов приходит, что потенциально провоцирует больше работы на security reviews и другие вещи, просто потому что это увеличивает уровень осведомлённости, который нужно делать на одобрениях.

Также Capital One смотрит на вещи вроде: есть ли открытый стандарт? Например, в telemetry много стандартизировано в пространстве telemetry. Итак, выбор стандарта там упрощает мир для нас, и это может упростить, какой инструмент.

Lock-in в эпоху AI

Кэтрин отмечает интересный момент о lock-in в контексте AI и агентных workflows: “Как заблокированы вы будете, если теперь легко мигрировать, потому что у вас есть инструменты, которые позволяют автоматизацию?” Это открывает двери для Capital One, и они делают много этого абстрагирования и держат открытый ум в областях, где происходит большая инновация, и они хотят получать выгоду от этого, а не просто выбрать один и ждать.

AI и Enterprise разработка

Capital One внедрила LLM-powered coding assistant для всех разработчиков. Это был интересный процесс, который начался с вызова.

Преодоление страха

Год назад в индустрии было много страха и беспокойства: “Это заменит мою работу”. Capital One отлично справилась с этим на всех уровнях лидерства, включая CEO, который говорил: “Мы хотим получить lift в этом пространстве, мы хотим автоматизировать всё, что не является частью творческого решения проблем в разработке ПО. Давайте все попробуем инструменты и посмотрим, что работает”.

Подход к внедрению

Capital One прошла полный risk review, compliance review и все необходимые проверки, сделала POC, пилот и масштабировала. Компания начала отслеживать, кто получает пользу от инструмента, и создала Slack-каналы, где люди делились примерами использования и открытиями.

Этот подход — позволить коллегам делиться тем, что работает, а что нет — продолжает использоваться при внедрении других инструментов, так как это область с огромными изменениями.

Обучение использованию AI-инструментов

Кэтрин отмечает важный момент: люди могут недооценивать цикл обучения использованию этих инструментов. Особенно с агентными инструментами, где требуется новый способ мышления о разработке.

Год назад фокус был на “как хорошо промптировать”. Сейчас больше внимания на “как настроить planning mode эффективно, чтобы получить нужное поведение”. Обучение год назад уже не так актуально — всё меняется так быстро.

Capital One использует use case-based обучение: “Для этого типа задачи это лучший инструмент”. Компания становится более opinionated по мере использования разных подходов: “Этот инструмент отлично подходит для Spring Boot миграции, а этот — для генерации тест-кейсов”.

Измерение успеха AI-инструментов

Кэтрин категорически против измерения строк кода: “Худшие coding assistants или агенты могут производить наибольшее количество кода — это не мера ценности”.

Вместо этого Capital One смотрит на:

• Сколько предложений принято — интересная метрика
• Предоставляет ли инструмент ценность? — главный вопрос
• Создаёт ли он lift со временем? — throughput команды за год может показать impact
• Качество — продолжает ли оно оставаться на том же уровне или улучшается?
• Качественные метрики — используете ли вы инструмент? Предоставляет ли он ценность? Для чего вы его используете?

Если качество остаётся на том же уровне или улучшается, и команда может делать немного больше, это хороший результат. Идеально — делать больше интересной работы по программированию, а не миграций версий или разрешения NPM зависимостей.

Влияние на разных разработчиков

Для junior-разработчиков AI-инструменты предоставляют огромный lift в:

• Понимании кодовой базы
• Изучении новых языков и фреймворков
• Понимании существующего кода, dependency trees
• Базовых задачах: стиль, linting, форматирование — низкоуровневые вещи, но которые предоставляют большую ценность и эту консистентность для других

Кэтрин отмечает, что для junior-разработчиков также важно иметь “не осуждающего, психологически безопасного ассистента”, к которому можно задавать вопросы. Это особенно полезно для изучения кодовой базы и понимания того, как всё работает.

Для senior-разработчиков lift пока меньше, но появляется в новых инструментах, особенно в planning mode и возможности эффективно настраивать его. “Начинаем видеть зелёные ростки там”, — говорит Кэтрин.

Она отмечает, что это всё ещё ранние дни, и некоторые из этого зависит от качества модели, которую вы используете. Чем больше вы ожидаете от ответа, чтобы создать lift, тем больше вы можете ожидать от этого ответа, тогда как вы можете получить этот lift как немного более junior в вашей карьере от, возможно, менее отличного ответа, но достаточно хорошего, чтобы помочь вам понять, что вам может понадобиться сделать.

По мере того, как Capital One распаковывает некоторые из этих более новых инструментов в этом пространстве, они начинают видеть больше lift для senior-инженеров там. И Кэтрин думает, что концепция planning mode и возможность эффективно настроить planning mode также создаст большой lift.

Code Review и Guardrails

Один из интересных моментов, который Кэтрин обсуждает — это почему инженерия была “tip of the spear” для использования AI в рабочем месте. Частично это потому, что у инженерии есть встроенные guardrails вокруг того, что производится.

Если это код, который может быть скомпилирован, вы можете хотя бы скомпилировать его и убедиться, что он синтаксически правильный. Вы можете запустить его через unit tests. Предположительно, человек, вероятно, будет вовлечён в процесс review. Это, вероятно, пройдёт через несколько стадий, прежде чем когда-либо попадёт в production. И даже когда это попадает в production, вы можете делать canary-based rollout.

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

Так что это огромное преимущество для этого, потому что оценить результат сложно в большом количестве доменов, тогда как инженерия имеет некоторые встроенные способы сделать это.

Другая причина, почему инженерия — это tip of the spear, это потому, что инженеры исторически очень хороши в инвестировании своего времени в способы снятия работы с их тарелки, по сути, автоматизируя задачи и делая так, чтобы они могли тратить время на другие вещи, которые не обязательно являются этими рутинными задачами. И это суперспособность способа сделать некоторые из этого.

Другие 80% работы разработчика

Coding — это только 20% работы разработчика. Остальные 80% включают:

• Анализ проблем в production
• Деплой в production
• Покрытие тестами, предсказуемость pipeline
• Понимание клиентов, понимание фичи в Jira
• Написание документации

Централизованная модель, над которой работает Capital One, направлена на помощь здесь. Если вы думаете о вещах, которые не являются кодом, на которые разработчик тратит время, это может быть триажирование проблем в production. Это может быть получение кода в production в первую очередь, получение этого деплоя, покрытие тестами, предсказуемость их pipeline. И затем это может быть понимание клиентов, понимание того, что фича в Jira, и затем компания.

Capital One определённо смотрит на продуктивность, которая имеет значение для бизнеса, и AI-инструменты, которые поддерживают там. Так что вы можете представить, что у них есть довольно много разных вещей в игре, как POC, так и в использовании, которые доставляют их к точке, где они могут получить lift на AI и других аспектах этого.

Когда Кэтрин думает о том, как вы пишете свои docs и как вы можете улучшить это, определённо есть lift, который можно получить от AI-инструментов в этом пространстве, просто как пример.

Возможность на pipeline piece действительно захватывающая, потому что это о том, как мы обеспечиваем, что pipelines предсказуемы? Как мы помогаем с любыми ошибками или проблемами в деплое? И как мы, опять же, делаем так, чтобы селективные тесты запускались для каждого деплоя? Какие отличные инновации мы можем сделать там, чтобы помочь, что просто обеспечивает, что dev-команда не должна тратить много времени на их деплой.

И каждая часть этого SDLC действительно важна для Capital One, чтобы сосредоточиться на том, как мы делаем это более эффективным или более предсказуемым, или, по крайней мере, централизованным, так что инженерная команда не должна тратить много времени на это, потому что чем больше времени они тратят на другие аспекты SDLC, тем меньше времени они тратят на их код. И Capital One хочет вернуть их к коду при каждой возможности.

Будущее профессии разработчика

“Роль разработчика уже изменилась”, — говорит Кэтрин. В прошлом году разработчики научились быстро разбираться в кодовой базе, улучшать качество кода и увеличивать частоту доставки благодаря coding assistants.

Следующий шаг — агенты, которые делают работу за разработчика. Ценность человека в этом процессе — в суждении, понимании направления и способности чётко формулировать требования, а также в понимании кода достаточно хорошо, чтобы убедиться, что он идёт по правильному пути.

Кэтрин сравнивает это с прошлыми сдвигами: когда она перестала беспокоиться о memory leaks и размере загрузки — это были отличные дни. Текущий сдвиг кажется ещё большим, возможно, даже больше, чем переход от C к C++.

“Это меняет роль инженера и ожидания относительно того, где они проводят время”, — говорит она. Но есть разработчики, которые сопротивляются изменениям, потому что чувствуют потерю связи с тем, что происходит “под капотом”.

Её совет: “Если вы цените разрешение NPM зависимостей или миграцию с одной версии Java библиотеки на другую, то эта эволюция не для вас. Этот тип инженера может также любить отладку проблем, и это тоже меняется, но есть ещё область, где вы можете действительно наслаждаться преследованием больше ролей, которые соответствуют этим критериям”.

“Так что я думаю, если вы бросаете вызов этому, это, вероятно, потому, что вы любите какую-то часть работы, которая теперь может быть обработана способом, который не был раньше. Итак, идентифицируйте, где радость, и переключитесь на роль, где вы получаете эту радость, будет моим prompt там”.

“Это стоит увидеть, какой lift вы можете получить от этого. Это как, я говорю об этом, как иметь ваш открытый книжный тест и выбирать не использовать книгу. Это просто похоже, что вы просто упускаете эту большую возможность получить lift”.

В Capital One они поощряют свои инженерные команды получить весь lift. Они делают это с качеством, с их валидацией, с их проверками на месте, но они хотят дать своим командам весь lift. “Почему бы нам не? И другие там делают это. Итак, вы получаете выгоду от индустрии, быстро инновационной. Итак, это будет моим prompt — если есть страх, основанный на этом, как исследуйте и посмотрите, как быстро вы можете учиться и адаптироваться быстро”.

“И я думаю, что большинство инженеров, которые пришли с mindset, который вы назвали раньше, если я хочу автоматизировать вещи, которые мне больше не нужно делать, так что я могу выйти из того, чтобы делать что-либо, что не весело. Это та же группа, которая действительно продолжит пытаться учиться от каждого нового инновационного инструмента, выходящего здесь”.

Тестирование с AI

Кэтрин обсуждает возможности AI в тестировании: “Качественные и валидационные задачи, тестирование и другие вещи, есть так много, что мы можем получить lift от визуального тестирования и поведения клика через, которые более сложны для написания тех sort of feature level тестов, которые действительно легко для агентов и других вещей, чтобы сделать, что снова предоставит lift, но вам нужен некоторый баланс в уравнении сегодня”.

“Вы не хотите, чтобы агент писал все тесты и весь код, вы знаете, нет баланса в этой настройке. Так что выяснение этого по мере того, как мы продолжаем инвестировать в это пространство, действительно захватывающе”.

Пиковая продуктивность разработчика

Идеал для Кэтрин: “У меня есть идея, и я могу показать её пользователю в тот же день”. С точки зрения Capital One это означает: протестировано, валидировано, безопасно развёрнуто последовательно со всеми контролами и поведением на месте.

Очень мало касаний, где действительно нужен человек как часть этого процесса. Многое можно автоматизировать или валидировать с помощью новых инструментов: “У вас есть coding standards — давайте подтвердим, что вы их все выполнили. Давайте подтвердим, что вы прошли тесты. Давайте подтвердим, что все эти шаги произошли перед деплоем”.

Это то, к чему стремится agile-разработка — от идеи до пользователя максимально быстро, но с сохранением качества и безопасности. “Это то, ради чего всё это делается в конце концов”, — говорит Кэтрин.

Ловушки при измерении продуктивности

Кэтрин предупреждает о распространённых ошибках:

• Отслеживание каждого возможного метрика — может привести к неправильному поведению
• Метрики, которые провоцируют неправильное поведение — например, количество PR на разработчика (можно просто делать маленькие PR) или количество строк кода (AI может генерировать много кода)
• Слишком экстремальные quality bars — “никогда не иметь escape defect” или “никогда не иметь ошибку” — это слишком экстремально

Правильный подход: измерять то, что важно, и где ваша команда будет фокусироваться. Например, “давайте сделаем легко перейти от code review к production быстро” — есть много мер, которые можно сделать там.

Кэтрин интересует метрика “от старта истории до доставки истории” — это приближает к идеалу “идея создана и развёрнута в production перед пользователем”.

Важно не отслеживать календари или время в коде — это не даст правильной картины. Лучше, чтобы engineering managers тратили время на вопрос: “Используем ли мы наше время эффективно? Эффективны ли наши встречи?”

Кэтрин шутит: “Я не думаю, что разработчики когда-либо счастливы. Я не когда-либо, может быть, скажу это так. Я не когда-либо хочу быть ответственной за их счастье. Я действительно хочу быть ответственной за увеличение их времени в developer flow state или увеличение их времени в глубине в ремесле”.

Регулярно спрашивать и опрашивать и учиться, каковы самые большие вызовы и где они тратят свое время в качественном смысле, действительно даёт отличные инсайты о том, где Кэтрин может помочь улучшить этот developer experience.

“И худшее — это когда вы получаете сообщение об ошибке, которое вы не понимаете, вы не знаете, как действовать. Итак, это всегда некоторые из самых простых, чтобы помочь impact и сделать изменения вокруг”.

Discovery инструментов

Важный аспект developer experience — это self-service. Знают ли разработчики, где находятся инструменты? Могут ли они получить к ним доступ? Есть ли у них правильные разрешения, чтобы найти их? Знают ли они лучшие практики для этого инструмента?

Есть много вокруг этого knowledge share и этого discovery того, где есть impact. Особенно когда кто-то только начинает, и после того, как они были там какое-то время, всё ещё ли они способны найти это, когда им это нужно? Всё ещё ли это всплывает способом, который делает это легким для них, чтобы добраться до этих метрик, которые вы только что упомянули?

Все эти метрики отличные. И затем Кэтрин шутит, что она не думает, что разработчики когда-либо счастливы, но она хочет быть ответственной за увеличение их времени в developer flow state.

Советы для перехода в большую организацию

Кэтрин даёт советы для инженерных лидеров, переходящих в большую организацию:

1. Понять, как компания работает — нормы коммуникации, поведения, приоритизации. Кто общается и как часто? Что отслеживается? Как доставляются плохие новости? Что празднуется?

2. Использовать существующие паттерны — в большой компании, если вы можете прыгнуть на установленный паттерн или рутину, вы получите гораздо больше lift. Если вы хотите попробовать что-то совершенно новое, это будет намного сложнее.

3. Итерация на существующем — если вы можете идентифицировать рутину, которая уже существует, и прыгнуть на неё, добавить к ней или итерировать на ней, вы можете получить скорость изменений.

Большая компания не означает медленную — просто нужно работать с существующими системами, а не против них.

Культурные различия

Кэтрин отмечает, что этот совет будет верен при переходе от большой к большой компании тоже, просто разные. Каждая компания немного отличается в том, как она работает.

Первое, что вы действительно должны сделать, это понять, как эта компания работает. Каковы нормы вокруг коммуникации? Каковы нормы вокруг поведения? Каковы нормы вокруг приоритизации? Кто общается и как часто это общается? Что отслеживается? Что всплывает на каком уровне?

И получить чувство того, что важно для компании на этом, что это sort of metrics piece. Но затем также, каков стиль коммуникации? Как доставляются плохие новости? Это действительно интересный, чтобы получить реальное чувство, соответствует ли это тому, к чему вы привыкли, или отличается? И что действительно празднуется? Кэтрин думает, что это ещё один действительно хороший, чтобы понять этот культурный сдвиг.

И не следует предполагать, что большие компании — единственные, которые действительно празднуют. Кэтрин не думает, что это было правдой. И она прыгала вокруг немного company size wise. Большой просто означает, что если вы можете прыгнуть на установленный паттерн или рутину, вы получите гораздо больше lift. Если вы хотите попробовать что-то совершенно новое, это будет намного сложнее в большой компании. Но если вы можете идентифицировать рутину, которая уже существует, и прыгнуть на неё и sort of добавить к ней или итерировать на ней, тогда вы можете sort of действительно получить эту скорость изменений, происходящих также.

Заключение

Кэтрин заканчивает разговор на оптимистичной ноте: “Я думаю, что захватывающая вещь в этом пространстве — это то, что есть много вокруг того, куда мы направляемся как индустрия, что должно создать больше developer flow и developer joy в этом flow. И если вы ещё не видите это, или если вы работаете где-то, что не championing эту инновацию, определённо посмотрите вокруг, потому что есть много возможностей в этом пространстве, что я думаю, должно выделить и поощрить вас увеличить ваш skill set и действительно быть оценённым за ваше суждение и ваш опыт в этом пространстве”.

“И это то, что меня действительно захватывает о служении большой аудитории, которую мы имеем из разработчиков в Capital One. И я думаю, что это действительно захватывающее время, чтобы быть разработчиком”.

Читай также

• Mastra: TypeScript-фреймворк для AI-агентов - Обзор TypeScript-фреймворка для создания AI-агентов с обсуждением примитивов и MCP интеграции
• ElevenLabs UI: открытая библиотека компонентов для голосовых мультимодальных ИИ-агентов 2026 - Обзор ElevenLabs UI — открытой библиотеки React-компонентов для создания голосовых мультимодальных интерфейсов ИИ-агентов и ассистентов

Источник: Software Engineering Daily подкаст с Кэтрин McGarvey, SVP of Developer Experience в Capital One.