Часть 1 короткой серии материалов о реорганизации PubHub с использованием разработки при поддержке ИИ. В этой части рассматриваются принятые решения и результаты; технические детали описаны в сопутствующей серии статей «ИИ для жизненного цикла разработки ПО (SDLC)».
В начале 2026 года требования безопасности вынудили команду PubHub провести реорганизацию на новом стеке, причем планом отводилось девять месяцев. Проект был запущен примерно через пять с половиной месяцев благодаря разработке с помощью ИИ: 12 инженеров выполнили объем работы, эквивалентный труду примерно 20 специалистов.
PubHub — это инструмент публикации, лежащий в основе контента для разработчиков Cisco DevNet: документации по API, учебных лабораторий, центров разработки (DevCenters) и микросайтов, предназначенный как для создающих его команд, так и для использующих его разработчиков. Авторы контента полагаются на него ежедневно. Никто не просит переписывать то, что уже работает, и никто не прощает ошибок, ломающих рабочий процесс публикации.
Отдел информационной безопасности и команда Security Insight сделали обязательным соответствие PubHub стандартам безопасности Cisco, а существующее приложение в его текущем виде не могло их обеспечить. Обеспечение соответствия требованиям означало переписывание кода на Golang. Работа началась в апреле 2026 года, и по утвержденной оценке завершение планировалось на конец декабря.
PubHub — это внутренний инструмент, а не продукт, который Cisco продает, поэтому ничто здесь не является рекламным ходом. Используемые инструменты ИИ (Claude, Copilot и Cursor) являются коммерчески доступными, а не кастомными разработками.
Для кого это предназначено
- Руководители инженерных отделов, решающие, меняет ли разработка с помощью ИИ график настолько, чтобы перепланировать работу.
- Команды, столкнувшиеся с вынужденным переписыванием кода и желающие узнать порядок внедрения, который доказал свою эффективность.
- Владельцы продуктов и программ, подозревающие, что ускорение инженерных процессов создает узкое место с их стороны. Так оно и есть.
Ручная работа показала, как делать не надо
В прошлом году команда начала пилотный проект миграции вручную, так, как начинается большинство переписываний кода. Но редизайн — это не перевод текста. Каждый модуль заставляет принимать решения о том, что сохранить, что перепроектировать, а от чего отказаться.
Пилотный проект был свернут после ранней проверки концепции (PoC): трудозатраты вручную оказались слишком высокими, чтобы завершить работу в таком темпе. Это сняло один вопрос: ручное преобразование было тупиковым путем.
Главная победа ИИ-среды разработки — понимание старой системы
Следующими в ход пошли Cursor и VS Code. Вместо чтения устаревшего кода строка за строкой команда поручила ИИ-среде разработки сгенерировать подробную архитектуру и справочник по дизайну компонентов для существующего приложения. Ранний прототип нового PubHub был создан в Cursor на основе этого справочника, а не вручную.
Евгедневный прирост скорости кодирования был реальным, но постепенным: более быстрая навигация, меньше переключений контекста, меньше трений. Скорость набора текста никогда не была узким горлышком.
Агенты появились в июне, и график выполнения задач изменился
Следующий сдвиг пришел извне. Новое руководство DevNet и OSPO задало вектор развития агентского опыта (Agentic eXperience, AX), подталкивая каждую команду создавать продукты с помощью ИИ-агентов, в частности Claude. PubHub стал испытательным полигоном; Claude присоединился к его рабочему процессу в июне 2026 года.
ИИ-среда разработки пишет функцию или класс по запросу. Агент читает требования, пользовательские истории и спецификацию, а затем разрабатывает функцию полностью, включая тестовые сценарии.
Тестирование — это этап, на котором при переписывании кода обычно срываются сроки: перенесение модуля, а затем дни доказательств его соответствия старому. Теперь инженеры проверяли и исправляли сгенерированные тесты вместо того, чтобы писать их сами. ИИ-управляемый фреймворк сравнивал старую и вновь сгенерированную документацию, а автоматизация на базе ИИ и Playwright заменила ручное тестирование интерфейсов.
График сгорания задач наглядно это показал: модули, на разработку которых уходила неделя, стали сдаваться за считанные дни.
Ускорение кода переместило узкое место вверх по потоку
Когда инженерные процессы ускоряются, узкое место смещается вверх по потоку. Более быстрой разработке требуются соответствующие по темпу требования и приемочное тестирование. Без того и другого команда просто начинает ждать раньше.
В случае с PubHub руководитель направления документации DevNet устранил это узкое место: он собирал запросы на функционал, определял требования к каждому из них и тестировал каждый готовый элемент. Формально эта роль относилась к бизнес-стороне, но на практике это была работа опытного менеджера продукта.
Руководитель документации также использовал ИИ для написания более детальных и согласованных запросов на функции. Инженерный отдел ускорялся за счет Claude, требования уточнялись с помощью ИИ, и ни одна из сторон не ждала другую.
Присутствие имело решающее значение. Руководитель документации участвовал в каждом шаге разработки, а не только на этапе передачи в начале и приемки в конце. На вопросы находились ответы в тот же день, двусмысленность устранялась до того, как превращалась в переделку, а отклонения выявлялись тогда, когда исправление стоило дешево. Команды часто называют такой подход опциональным. В проекте PubHub он стал несущей конструкцией.
Проектирование на основе рабочих процессов, а не с чистого листа
Команда дизайнеров работала параллельно, обновляя требования по ходу реорганизации. Интерфейс создавался на основе сгенерированных ИИ дизайнов, опирающихся на детальные пользовательские истории реальных рабочих процессов, что задавало для дизайнов четкий стандарт. Инструмент, который удовлетворяет требованиям ИБ, но разочаровывает пользователей, не может считаться успешной миграцией.
Перенос срока на основе фактов, а не энтузиазма
К середине лета показатель пропускной способности стал достаточно высоким, чтобы перенести целевой срок с конца декабря на конец августа. Это было непростое решение: ошибка стоила бы команде доверия к любым последующим оценкам. Поэтому программное руководство опиралось на факты, а не на энтузиазм, отслеживая производительность на протяжении нескольких спринтов перед принятием обязательств.
Новый PubHub вышел в продакшен в середине сентября 2026 года, вскоре после пересмотренного целевого срока и примерно на три с половиной месяца раньше первоначального декабрьского плана.
Как разработка с помощью ИИ повлияла на график
Девять месяцев запланированной работы были выполнены примерно за пять с половиной: сокращение графика на 39% по сравнению с собственной оценкой команды, сделанной до внедрения ИИ.
- Трудозатраты: Девять запланированных месяцев при участии 12 инженеров составляют 108 человеко-месяцев. Команда справилась с этим объемом примерно за 66.
- Численность персонала: Сентябрьский релиз в прежнем темпе потребовал бы около 20 инженеров. Разработка с помощью ИИ покрыла объем работы еще примерно восьми специалистов, и ни один новый сотрудник не был нанят.
- Качество: С момента выхода в продакшен у PubHub не было серьезных проблем. Масштабное покрытие автоматизированными тестами позволило сделать разработку одновременно быстрой и стабильной.
Оговорка: Claude появился в июне, а не в апреле, поэтому первые два месяца работа шла в до-искусственном темпе. Прирост пропускной способности в 1,64 раза — это усредненный показатель по всему проекту; после июня он был выше.
Четыре урока для других команд
- Требование соответствия нормативам — отличный стимул. Реархитектура откладывалась в течение нескольких циклов планирования. Требование убрало отсрочку как вариант, и результат превосходит то, что дала бы добровольная переработка.
- Применяйте ИИ в разных областях, а не в какой-то одной. Направление со стороны организации открыло двери, но именно применение на разных участках определило отдачу: понимание устаревшего кода, написание кода, тестов, требований и дизайн. Ни один единственный сценарий использования не обеспечил бы такого результата.
- Перепланируйте работу, когда меняются факты. Самым простым путем было бы сохранить декабрь и выглядеть героями в сентябре. Объявление более раннего срока вернуло время по календарю каждой команде, ожидавшей PubHub.
- Оставляйте место для новых возможностей. Переработка не была простой миграцией один к одному. Вместе с ней была внедрена автоматическая проверка документации на соответствие лучшим практикам, поэтому проверки, которые раньше отнимали у лидов дни ручного чтения, теперь запускаются при каждой сборке.
Выражаем благодарность тем, кто этого заслуживает
- Архитектор: сформировал проект реорганизации.
- Технический лид: руководил разработкой и реализацией.
- Управление программой: перепрогнозирование опиралось на данные.
- Руководитель направления документации: подготовил усовершенствованные с помощью ИИ запросы на функции и проверил созданное командой.
- Команда дизайна: установила требования и сформировала интерфейс с учетом пользовательских сценариев.
Инструменты ускоряют работу хороших команд, но не заменяют их. Решения о том, что пересоздать, что отбросить и насколько доверять новому темпу, принимали инженеры, знавшие систему.
Далее: Инженерная составляющая ИИ для жизненного цикла разработки ПО (SDLC)
Серия материалов «ИИ для SDLC» описывает внедрение в четырех публикациях:
- Код-ревью: как проверка справляется с ситуацией, когда ИИ пишет код быстрее, чем люди успевают его прочесть.
- Тестирование: проектирование фреймворков, сравнение старой и новой документации, а также автоматизация интерфейсов с помощью Playwright.
- Генерация кода и эволюция IDE: от среды разработки, пишущей функцию, до агента, создающего функциональность на основе пользовательской истории.
- Дизайн интерфейсов: генерация и доработка интерфейсов на основе письменных пользовательских историй.
PubHub запущен, соответствует требованиям, и создавать решения на его основе стало быстрее. Команды, публикующие через него контент, отмечают гораздо более удобный и интуитивный инструмент. Чего они не замечают: бэкенд под капотом полностью новый. Следующая часть статьи «Перерождение PubHub» продолжит рассказ с этого момента.
