# 42 года потерянной продуктивности: как Miro и AWS просто стали отправлять баги по адресу - Site: VeraPoint News - Section: Новости - Date: 2026-05-11 - Canonical: https://verapointmedia.com/news/how-miro-uses-amazon-bedrock-to-boost-software-bug-routing-accuracy-and-improve-time-to-resolution-from-days-to-hours/ - Markdown: https://verapointmedia.com/news/how-miro-uses-amazon-bedrock-to-boost-software-bug-routing-accuracy-and-improve-time-to-resolution-from-days-to-hours.md - Summary: Как Miro и AWS вылечили «пинг-понг» с багами между 100 командами, используя арендный ИИ и поиск по документации вместо дообучения нейросетей. И почему это сработает не у всех. - SEO title: Miro и Amazon Bedrock: AI для маршрутизации багов между командами - SEO description: Как Miro использует Amazon Bedrock, чтобы отправлять баги в правильные команды. Разбор практического AI-кейса без дообучения модели. - Target queries: Miro Amazon Bedrock; AI маршрутизация багов; Amazon Bedrock кейс; AI для поддержки разработки; автоматизация triage багов - Tags: #miro #awsbedrock #bugmanager #rag #enterpriseai #маршрутизация - Image: https://verapointmedia.com/static/content-assets/news/how-miro-uses-amazon-bedrock-to-boost-software-bug-routing-accuracy-and-improve-time-to-resolution-from-days-to-hours/cover.webp ## Sources - https://aws.amazon.com/blogs/machine-learning/how-miro-uses-amazon-bedrock-to-boost-software-bug-routing-accuracy-and-improve-time-to-resolution-from-days-to-hours/ - https://news.google.com/rss/articles/CBMi4AFBVV95cUxOeVNsUTQtQTVodEFfUFhlcG5lX0pUWlQyZlJTOWw0YUNwcXpVNWpiXzBGTEV2azRmQnhENG5pYzJtUS1qNEtCTmg3U01IeVE5eDlIZ3Nxc3JHZkE0d3FZN0ttZHR2OUprS2RuZ3FHTmZ0M1NwbjZhZnVfNy1NQ0RjRFhWQjB3ajVlbXA1c3dObGZ4THA0ZWxJNFZ0U3dVYkRmV0JNa0dZUXh6Yl9Bc2hpUVlMdjRvZkhGNkJielVXelJTSjVyM0dqRDJXU0VzcVRrS3BHeFBUZVVpODY5WW40dg?oc=5 - https://news.google.com/rss/articles/CBMiuAFBVV95cUxOV3VtMzFKVG5zNEwwMnpFRDMtRHptOEMwZzZPeHJ4bG9Mb3plVXIxWENFVlBMUXhWWDlEZXU3RVd2ajZMZXZiZDhXMk1FT2xoc05xaHpCLTZxUU43cms1WkhjOTk4YlFiYXo5MkxfSFZKcVhCOGNYejhNU0JGTWZSYUtFdU1tQ1k5VGYxb2NPMDVHN1hqbDVvYWdBVjhiTVF2OUJqekxlZ29tcnE3ZG9yWkVmZkVVcEFE?oc=5 - https://news.google.com/rss/articles/CBMipgFBVV95cUxPbUNNVnJfVUZHWTlaeXR6N1EyUVV6dWFJNlhQbUZEc0lPUk80dU9BSi1VOWFIblVjb0s1NDRFdEU0d2pwRDhROUVwampFU2UxMnBaelhocGtRVXgzWlVTb3VteVZYMEVBUTJ5Zlg4YURpZTA5cko2czhDdWVfSHlzbi1rUm11MjFOYnNQTmRuQWQzeUNuWmNyOVIwZnFwTE1pT2Y0eXVn?oc=5 --- В блоге AWS Machine Learning обещают «AI-powered innovation workspace», где 95 миллионов пользователей превращают хаос в порядок. А по факту получается 42 года потерянной продуктивности ежегодно — только на то, чтобы понять, чей это баг. 368 000 человеко-часов в год уходят на переписку вида «это не наше» между почти сотней команд. Баг приходит в Jira со скриншотом кривого прямоугольника и видео на 40 секунд — и начинается пинг-понг: команда А отправляет команде Б, та возвращает обратно. SLA горят, разработчики тратят жизнь не на код, а на бюрократию. И вот тут появляются Philipp Pavlov, Dmytro Romantsov, Evgeny Mironenko и Gowri Suryanarayana — инженеры Miro — вместе с AWS PACE, прототипно-облачной командой-ускорителем Amazon. Они сделали то, что звучит до смешного просто: научили ИИ просто отправлять баги по правильному адресу. ## Обещали красивую картинку, а получился хаос на 42 года Знаете, как это работает в большой компании с почти 100 командами, как у Miro? Приходит баг-репорт. В идеале — сразу к тем, кто за это отвечает. На практике — это рулетка. Баг улиткой ползёт по отделам. Команда А качает плечами: «это не наше, это к команде Б». Команда Б: «да вы что, это вообще В». Перепривязка (по-нормальному это называется маршрутизацией, но мы-то знаем, что это просто перекладывание ответственности), потеря времени, контекст переключился, разработчик злой, SLA горят. Они сами признают: значительный процент багов не укладывается в SLA именно из-за неверной маршрутизации. Получается, люди тратят жизнь не на код, а на бюрократию. 42 года в год — ну да, конечно, «эффективная разработка». ## А что, если просто перестать гадать? Вы открываете Jira в понедельник утром. Там висит тикет с заголовком «Всё сломалось» и скриншотом, где какой-то зелёный прямоугольник торчит криво. Ещё там видео на 40 секунд, где пользователь судорожно тыкает в доску. Раньше вы бы потратили полчаса жизни, чтобы посмотреть это видео (и испортить себе зрение), потом ещё двадцать минут на то, чтобы понять, что за зелёный прямоугольник и кто вообще в компании отвечает за зелёные прямоугольники — лазя по Confluence, GitHub и старым чатам. Теперь эту работу делает не вы, а Nova Pro. Это такая модель внутри Amazon Bedrock — Bedrock, если кто забыл, это когда вы не держите у себя в подвале серверы с искусственным интеллектом, а арендуете его у AWS по вызову, как такси. Nova Pro умеет смотреть не только на текст, но и на картинки с видео. Она говорит: «Ага, это артефакт на холсте, пользователь держит Ctrl и тянет за уголок». И уже на этом этапе экономит вам глаза и нервы. Но главное — дальше. Потому что понять, что сломалось, это ещё полбеды. Надо понять, кто чинит, и не ошибиться. Раньше вы лезли в Confluence, потом в GitHub, потом спрашивали в слаке «ребят, а кто у нас Canvas Engine сейчас поддерживает?» и получали ответ через три часа, потому что все на митинге. За это время баг уже успевал обрасти комментариями «ping», «есть апдейты?» и лёгкой паникой. Теперь система использует RAG — я специально проверила, это Retrieval Augmented Generation, что по-русски значит «сначала поищи в свежих документах, потом отвечай». Вместо того чтобы надеяться, что языковая модель помнит, как у вас была организована работа три месяца назад (спойлер: не помнит), она лезет в Amazon Bedrock Knowledge Bases — базу, где лежат актуальные Jira-тикеты, пулл-реквесты, README и даже те самые Confluence-страницы, которые вы никогда не обновляете. И вот тут происходит магия, от которой у меня чуть не падает челюсть. Система не просто находит похожий баг. Она берёт Claude Sonnet 4 — это более взрослая и размеренная модель, которая не паникует — и скармливает ей всё: описание бага, видео, похожие кейсы, текущую оргструктуру. Claude думает (ну, симулирует размышление) и выдаёт: «Это к команде Canvas Engine, вот три похожих случая прошлого месяца, вот вероятная причина». Без дообучения. То есть если завтра ваша команда «Playground» сливается с «Core Experience», не нужно месяц собирать размеченные данные и переучивать нейросеть. Просто меняете документ в базе знаний — и всё. Система уже знает, что «Playground» больше не существует, и шлёт баги новому коллективу. Серьёзно? Да, серьёзно. Никакого «а мы это в модели не учили». Получается, экономия не только в часах, но и в ответственности. Вы больше не тот человек, который по голове получит, если баг уйдёт не туда. ИИ взял вину на себя. Ну, почти. ## Ага, и правда заработало. Шесть и пять Результаты они озвучивают смелые: в 6 раз меньше перепривязок багов между командами. В 5 раз быстрее время решения — с дней до часов. Цифры впечатляющие. Источник — официальный блог AWS Machine Learning, с реальными инженерами Miro: Philipp Pavlov, Dmytro Romantsov, Evgeny Mironenko, Gowri Suryanarayana. Это не выдуманные персонажи. Но тут я прислушиваюсь к своему внутреннему скептику. Он шепчет: «Подождите, а почему тогда у всех не так?» ## А если в документации сплошной туман? Смотрю на это решение и вижу, где швы могут лопнуть. Во-первых, RAG — это не волшебная палочка, а зеркало вашей базы знаний. Если у вас в Jira сплошной хаос, тикеты называются «фикс бага №3», а в Confluence документация устарела на два года — модель подтянет этот мусор и выдаст «интеллектуальный» ответ типа «отправьте это Unknown Team». Бред на входе — бред на выходе, только теперь с AI-штампом одобрения. Во-вторых, организационная амнезия. Да, система не требует дообучения, но она требует актуальных, структурированных описаний зон ответственности. Если при слиянии двух команд никто не обновил документ «кто за что», BugManager будет упорно слать баги в несуществующий отдел. Это не технический баг — это организационный, но он убивает всю красоту решения. В-третьих, деньги. Каждый вызов этих умных моделей стоит токенов. Miro — компания с 95+ миллионами пользователей и, видимо, бюджетом на такие эксперименты. Для небольших команд или стартапов такая архитектура с несколькими LLM и огромными базами знаний может оказаться дороже, чем нанять ещё одного тимлида, который будет вручную разруливать. И ещё один нюанс, про который в пресс-релизе умалчивают: false positives. Система может уверенно отправить сложный баг команде джунов, которым это не по зубам, потому что похожий текст когда-то встречался в их репозитории. Или, наоборот, отфильтровать реальный баг как шум. Никто не отменял проверку человеком. ## А мне-то что, я не из Miro? Если вы CTO, техлид или просто человек, который устал от «пинг-понга с багами», вот что здесь можно взять прямо сейчас. Во-первых, это не монолитная чёрная магия, а конструктор. Amazon Bedrock (аренда LLM), Knowledge Bases (хранилище контекста), Nova Pro (для картинок/видео), Claude Sonnet (для размышлений) — всё это складывается как кубики LEGO. Хотите повторить — берите и собирайте, AWS выложили архитектуру в открытый доступ. Во-вторых, отказ от дообучения — это как перестать каждый раз заново обучать сотрудника, когда меняется оргструктура. Раньше при смене команд нужно было собирать labelled data (размеченные вручью примеры), ждать переобучения модели, проверять точность. Теперь — поменял документ, и система уже в курсе. Гениально в своей простоте, если, конечно, ваши документы не врут. В-третьих, мультимодальность — это low-hanging fruit. Баги со скриншотами и видео раньше обрабатывались вручную, потому что текстового описания «всё сломалось» недостаточно. Теперь модель Nova Pro видит то же, что и вы. Для многих команд это самый простой способ сократить время triage (это когда вы решаете, куда баг отправить и насколько он срочный). В-четвёртых, посчитайте свои «42 года». Если в вашей компании баги постоянно перепривязываются, попробуйте прикинуть, сколько человеко-часов уходит на бюрократию. Результат может удивить — или расстроить. ## Честно: без прикрас Я смотрю на эту историю и вижу действительно классную инженерную работу. Проблема была реальная, решение — прагматичное. Miro избавились от позора, когда баги гуляли по компании неделями. Но за красивыми цифрами (6x, 5x) стоят важные условия. Это работает, только если ваши базы знаний — не помойка. Если Jira у вас — кладбище тикетов, а Confluence — болото устаревших планов, сначала приведите это в порядок. Иначе вы потратите кучу денег на Bedrock, чтобы ИИ гениально маршрутизировал баги в никуда. И всё-таки, когда я вижу «42 года потерянной продуктивности», мне не смешно. Это реальные разработчики, которые могли бы писать фичи, а вместо этого раз в неделю объясняют коллеге из соседнего крыла, что «этот баг не мой, отстань». Теперь у них появился шанс просто чинить. Или отдыхать. Или хотя бы не злиться в десятый раз на одно и то же письмо. ## Материалы - [AWS Machine Learning Blog] How Miro uses Amazon Bedrock to boost software bug routing accuracy and improve time-to-resolution from days to hours | Amazon Web Services: https://aws.amazon.com/blogs/machine-learning/how-miro-uses-amazon-bedrock-to-boost-software-bug-routing-accuracy-and-improve-time-to-resolution-from-days-to-hours/ - [news.google.com] supporting context: https://news.google.com/rss/articles/CBMi4AFBVV95cUxOeVNsUTQtQTVodEFfUFhlcG5lX0pUWlQyZlJTOWw0YUNwcXpVNWpiXzBGTEV2azRmQnhENG5pYzJtUS1qNEtCTmg3U01IeVE5eDlIZ3Nxc3JHZkE0d3FZN0ttZHR2OUprS2RuZ3FHTmZ0M1NwbjZhZnVfNy1NQ0RjRFhWQjB3ajVlbXA1c3dObGZ4THA0ZWxJNFZ0U3dVYkRmV0JNa0dZUXh6Yl9Bc2hpUVlMdjRvZkhGNkJielVXelJTSjVyM0dqRDJXU0VzcVRrS3BHeFBUZVVpODY5WW40dg?oc=5 - [news.google.com] supporting context: https://news.google.com/rss/articles/CBMiuAFBVV95cUxOV3VtMzFKVG5zNEwwMnpFRDMtRHptOEMwZzZPeHJ4bG9Mb3plVXIxWENFVlBMUXhWWDlEZXU3RVd2ajZMZXZiZDhXMk1FT2xoc05xaHpCLTZxUU43cms1WkhjOTk4YlFiYXo5MkxfSFZKcVhCOGNYejhNU0JGTWZSYUtFdU1tQ1k5VGYxb2NPMDVHN1hqbDVvYWdBVjhiTVF2OUJqekxlZ29tcnE3ZG9yWkVmZkVVcEFE?oc=5 - [news.google.com] supporting context: https://news.google.com/rss/articles/CBMipgFBVV95cUxPbUNNVnJfVUZHWTlaeXR6N1EyUVV6dWFJNlhQbUZEc0lPUk80dU9BSi1VOWFIblVjb0s1NDRFdEU0d2pwRDhROUVwampFU2UxMnBaelhocGtRVXgzWlVTb3VteVZYMEVBUTJ5Zlg4YURpZTA5cko2czhDdWVfSHlzbi1rUm11MjFOYnNQTmRuQWQzeUNuWmNyOVIwZnFwTE1pT2Y0eXVn?oc=5 ## Что читать дальше - [AI в бизнесе](/topics/ai-business/) - [Как бизнесу использовать AI-агентов](https://verapointmedia.com/guides/kak-biznesu-ispolzovat-ai-agentov-bez-samoobmana/) - [AWS AIDLC workflows](https://verapointmedia.com/tools/awslabs-aidlc-workflows/) - [AI-агенты](/topics/ai-agents/)