В начале 2026 года команда Cisco PubHub получила обязательное предписание от InfoSec и Security Insight: привести приложение в соответствие со стандартами безопасности Cisco. Существующая версия этому не отвечала, и выполнить требования можно было только полной пересборкой на Golang. Планировали девять месяцев — с апреля по конец декабря 2026-го. В итоге новая версия вышла в продакшен в середине сентября, примерно на три с половиной месяца раньше плана, а весь объём работы занял около пяти с половиной месяцев. Ключевым ускорителем стала разработка с помощью ИИ: Claude, Copilot и Cursor — коммерческие инструменты, не внутренние сборки Cisco.
PubHub — внутренний инструмент, публикующая платформа контента Cisco DevNet: документации API, Learning Labs, DevCenters и микросегментов. Им ежедневно пользуются авторы и команды, которые создают материалы. Это не продукт, который Cisco продаёт, так что речь не о маркетинге, а о том, как ИИ-инструменты меняют сроки и нагрузку команды.
Ручная миграция не сработала ещё на пилоте
Годом ранее команда начала миграцию вручную — так обычно и начинаются переписывания. Пилот остановили после раннего proof of concept: трудозатраты оказались слишком высокими, чтобы уложиться в такие темпы. Главный вывод — переписывание не равно переводу. Каждый модуль требует решения: что сохранить, что переработать, что выбросить. Ручная конвертация не подходила.
ИИ-IDE сначала помогла понять старую систему
Следующим шагом стали Cursor и VS Code. Вместо построчного чтения легаси-кода команда поручила ИИ-IDE сгенерировать подробный справочник по архитектуре и компонентам существующего приложения. По этому справочнику с помощью Cursor собрали ранний PoC нового PubHub — уже не вручную. Ежедневный выигрыш был реальным, но постепенным: быстрее навигация, меньше переключений контекста, меньше трения. Скорость набора текста никогда не была узким местом.
Агенты в июне: модули пошли в дни, а не в недели
Перелом пришёл извне. Новое руководство DevNet и OSPO задало курс Agentic eXperience (AX) и потребовало от каждой команды строить с ИИ-агентами, в первую очередь с Claude. PubHub стал полигоном: Claude вошёл в рабочий процесс в июне 2026 года.
Разница между IDE и агентом принципиальна. ИИ-IDE пишет функцию или класс по запросу. Агент читает требование, пользовательские истории и спецификацию, а затем разрабатывает функцию целиком, включая тест-кейсы. Тестирование — то место, где переписывания обычно теряют график: портировать модуль, а потом дни доказывать, что он совпадает со старым. Теперь инженеры проверяли и исправляли сгенерированные тесты вместо того, чтобы писать их с нуля. ИИ-фреймворк сравнивал старую и новую документацию, а автоматизация интерфейса на Playwright заменила ручное тестирование UI. На графике сгорания задач это было видно: модули, которые раньше занимали неделю, стали закрываться за дни.
Узкое место уехало вверх по течению
Когда разработка ускоряется, узкое место смещается вверх. Быстрому коду нужны требования и приёмочное тестирование, которые поспевают за ним. Без этого команда просто раньше начинает ждать.
На PubHub это узкое место снял ведущий по документации DevNet: он приносил запросы на функции, определял, что нужно каждой, и тестировал каждую после сборки. Номинально роль сидела на стороне бизнеса, на практике это была работа опытного продакт-менеджера. Он же использовал ИИ, чтобы писать более подробные и связные запросы. Разработка ускорялась через Claude, требования заострялись через ИИ, и ни одна сторона не ждала другую.
Важнее всего оказалось присутствие: ведущий по документации участвовал в каждом шаге разработки, а не только в передаче задачи в начале и приёмке в конце. Вопросы получали ответ в тот же день, неоднозначность умирала до того, как превращалась в переделку, а дрейф ловили, пока исправление было дешёвым. Команды часто считают такое участие опциональным — на PubHub оно было несущим.
Дизайн от рабочих сценариев, а не с чистого листа
Команда дизайна работала параллельно, обновляя требования по ходу пересборки. Интерфейс вырос из ИИ-сгенерированных макетов, опирающихся на подробные пользовательские истории реальных сценариев, — у дизайна появился стандарт, которому нужно соответствовать. Инструмент, который проходит InfoSec, но раздражает пользователей, нельзя считать успешной миграцией.
Дату сдвинули по данным, а не по энтузиазму
К середине лета сигнал по пропускной способности стал достаточно сильным, чтобы перенести цель с конца декабря на конец августа. Решение было некомфортным: ошибка стоила бы доверия ко всем последующим оценкам. Поэтому управление программой держало команду на доказательствах, а не на воодушевлении, и отслеживало пропускную способность несколько спринтов, прежде чем фиксировать новую дату. Новый PubHub вышел в продакшен в середине сентября 2026 года — вскоре после пересмотренной цели и примерно на три с половиной месяца раньше исходного декабрьского плана.
Что ИИ-разработка сделала со сроками
Девять месяцев плановой работы уложились примерно в пять с половиной — сокращение графика на 39% относительно собственной оценки команды до внедрения ИИ.
- Трудозатраты: девять плановых месяцев на 12 инженеров — это 108 человеко-месяцев. Тот же объём команда закрыла примерно за 66.
- Численность: для поставки в сентябре прежними темпами понадобилось бы около 20 инженеров. ИИ-разработка покрыла работу примерно восьми дополнительных, и никто в команду не пришёл.
- Качество: с момента выхода в продакшен серьёзных проблем у PubHub не было. Плотное автоматическое покрытие тестами позволило совместить скорость и стабильность.
Оговорка: Claude появился в июне, а не в апреле, поэтому первые два месяца шли в прежнем, «доискусственном» темпе. Прирост пропускной способности в 1,64 раза — среднее по всему проекту; после июня он был выше.
Четыре урока для других команд
- Предписание о соответствии — хороший форсирующий фактор. Реархитектуру откладывали несколько плановых циклов. Мандат убрал возможность откладывать, и результат оказался лучше, чем у добровольной пересборки.
- Направляйте ИИ в несколько мест, а не в одно. Организационный курс открыл дверь, но отдачу решило размещение: понимание легаси, код, тесты, требования и дизайн. Ни одно применение по отдельности не вытянуло проект.
- Перепланируйте, когда меняются данные. Простой путь — оставить декабрь и выглядеть героями в сентябре. Объявленная более ранняя дата вернула календарное время каждой команде, ждавшей PubHub.
- Оставьте место для новых возможностей. Пересборка не была миграцией один к одному: вместе с ней вышла автоматическая проверка документации на соответствие лучшим практикам, так что ревью, которые раньше стоили ведущим дни ручного чтения, теперь идут на каждой сборке.
Что можно перенести в свою практику
Схема, сработавшая у Cisco, воспроизводима не инструментами, а порядком действий. Сначала ИИ-IDE строит карту старой системы — это дешевле, чем читать код построчно. Затем агент берёт на себя функцию целиком вместе с тестами, а человек проверяет результат. Параллельно снимается узкое место на стороне требований: без подробных запросов и быстрой приёмки ускоренная разработка просто раньше встанет в очередь. И последнее — дату двигают по нескольким спринтам измеренной пропускной способности, а не по ощущению, что «стало быстрее».
Автор отдельно подчёркивает: инструменты ускоряют хорошие команды, но не заменяют их. Решения о том, что переписать, что выбросить и насколько доверять новому темпу, принимали инженеры, знавшие систему. Для тех, кто строит инфраструктуру вокруг подобных инструментов, полезен и другой материал — про переход Cisco NFVIS с VMware ESXi на KVM, где миграция тоже шла под внешним требованием. А тем, кого интересует, как вендоры перекладывают сетевую автоматизацию на готовые открытые платформы, стоит посмотреть на Cisco N9000 с SONiC.
Частые вопросы
Что именно заставило Cisco переписать PubHub?
Обязательное предписание InfoSec и команды Security Insight привести приложение в соответствие со стандартами безопасности Cisco. Существующее приложение в текущем виде этим требованиям не отвечало, и выполнить их можно было только пересборкой на Golang.
Сколько времени заняла пересборка?
Планировали девять месяцев с апреля 2026 года до конца декабря. Фактически работа заняла около пяти с половиной месяцев, а в продакшен новый PubHub вышел в середине сентября 2026 года — примерно на 3,5 месяца раньше исходного плана.
Какие ИИ-инструменты использовали?
Claude, Copilot и Cursor — коммерчески доступные продукты, а не собственные разработки Cisco. Claude подключили к процессу в июне 2026 года по курсу Agentic eXperience, который задало новое руководство DevNet и OSPO.
Насколько выросла производительность команды?
Средний прирост пропускной способности по проекту — в 1,64 раза. Это среднее за весь срок: первые два месяца, до прихода Claude, шли в прежнем темпе, а после июня показатель был выше.
Сколько человек было в команде и сколько понадобилось бы без ИИ?
Работали 12 инженеров. Чтобы выпустить тот же объём в сентябре прежними темпами, понадобилось бы около 20 человек — ИИ-разработка покрыла работу примерно восьми дополнительных, при этом никто в команду не пришёл.
Пострадало ли качество от ускорения?
По словам автора, с момента выхода в продакшен серьёзных проблем не было. Плотное автоматическое покрытие тестами позволило одновременно ускориться и сохранить стабильность; тесты генерировал агент, а инженеры их проверяли и исправляли.
Что стало главным узким местом после ускорения разработки?
Требования и приёмочное тестирование. Узкое место снял ведущий по документации DevNet: он собирал запросы на функции, описывал, что нужно каждой, и тестировал результат, участвуя в разработке на каждом шаге, а не только на передаче задачи и приёмке.
Можно ли повторить этот подход в небольшой команде?
Да, порядок действий не зависит от размера: сначала карта старой системы от ИИ-IDE, затем агент разрабатывает функцию вместе с тестами под проверкой человека, параллельно налаживаются подробные требования и быстрая приёмка, а сроки пересматриваются по измеренным данным за несколько спринтов.
Что изменилось для тех, кто публикует контент через PubHub?
Бэкенд полностью новый, но авторы видят более удобный и интуитивный инструмент. Вместе с пересборкой появилась автоматическая проверка документации на соответствие лучшим практикам, которая теперь выполняется на каждой сборке вместо ручного чтения ведущими.
Где описаны инженерные детали?
В серии AI for SDLC — четыре материала: ревью кода при ИИ-генерации, тестирование (фреймворк, сравнение старой и новой документации, автоматизация интерфейса на Playwright), генерация кода и эволюция IDE, а также проектирование интерфейсов по пользовательским историям.
Источник: blogs.cisco.com