ReadingResearchRadarInvestment frameworkAI Company Primary Sources
Sign in / Sign up
← Back to reading
NewsMaterial4 min readDisconfirmAI Editorial

Cisco Principal Engineer: AI Speeds Up Every Step, But Bottlenecks Keep Shifting to the Next

During the rewrite of its documentation publishing platform PubHub, the Cisco DevNet Platform Engineering team identified a recurring pattern: accelerating one development step shifts the bottleneck to the next. Principal Engineer Neelesh Pateriya documents the entire process—from understanding legacy code and streamlining requirements to building usable interfaces first, handing full features to AI, seeing review become the new bottleneck, and finally implementing machine-scale testing. He notes that the current bottleneck has shifted to the cross-repository context between steps.

2026-10-28 20:00 GMT+8

Cisco’s documentation publishing platform, PubHub, required a security-driven mandatory rewrite. In October 2026, Neelesh Pateriya, Principal Engineer for the DevNet Platform Engineering team, published an account detailing their approach. They did not start with an existing AI-first development playbook; instead, they iterated through trial and error. He summarized a pattern that ran throughout the entire process: every time they accelerated one step, the bottleneck shifted to the next.

The starting point was not writing code, but understanding the old system. PubHub had grown over many years across more than 15 repositories, written in Python, Node.js, Go, and React. Most of the engineers who originally wrote this code had long since left. Edge cases were hidden in the code, not documented anywhere. The team first used AI to read through the legacy repositories, generating architecture, workflow, and module documentation for each service, which was then reviewed by domain experts. Pateriya described this as AI’s first victory in the rewrite: understanding, rather than code generation.

With documentation of the old system in place, the team began writing requirements. The first drafts produced by AI looked good but kept growing longer—a single user story could run to dozens of pages, drifting from business needs into component design, data flows, and even the JSON structure of schemas. The team established a simple format: requirements should only state three things—what the business need is, who it is for, and how completion will be determined. Design belongs in separate design documents. Pateriya observed that AI makes long documents cheap; what is scarce is getting everyone to agree on what matters.

Sign in / Sign up
ReadingResearchRadarInvestment frameworkAI Company Primary Sources

When engineering needed interfaces, the UX team was still exploring AI. They reversed the conventional order: they first had AI generate a usable pilot interface directly from the requirements, and the UX team then used this as a baseline to expand the design. Early AI-generated interfaces looked correct but did not meet Cisco’s design standards. Consequently, the UX team encoded these design standards into AI skills and an MCP server. From day one, subsequently generated interfaces complied with standards, eliminating the need for rework.

Code generation tools upgraded during the project. Initially, there was code completion in VS Code and Cursor, which was helpful but not reliable enough. Once Claude Code became available, engineers began handing entire features—including tests—to agents to generate directly from requirements. Pateriya noted that given the size of the codebase (a new Go Core, a new Go Site Engine, and a new admin interface), handing over whole features rather than typing faster was where the greatest time savings came from.

However, the review process did not change: every change still required human review. Code arrived faster than humans could review it, so the bottleneck fell on the review stage. The team brought AI to the reviewer’s side as well: they built review skills for Go, Python, and React, plus two review agents—one that runs locally before an engineer opens a pull request, and one that reviews the pull request itself. These agents find issues and explain them, but the reviewers retain decision-making authority and approval rights.

Testing was the most anxiety-inducing part. PubHub publishes hundreds of documentation projects maintained by thousands of technical writers, API architects, engineers, and technical marketing engineers. If the new platform built or rendered content even slightly differently, someone would notice it on public pages. The team built two layers of safety nets using AI: a comparison framework that compares tens of thousands of pages generated by the rewrite against the production version page-by-page; and AI agents driving headless browsers to run complex UI workflows, significantly reducing manual testing volume. The result after launch was that no critical or high-severity issues have been reported.

Pateriya summarized this approach into seven practices: document legacy code first; keep requirements short; build a usable pilot before designing; hand whole features to AI; make security standards non-negotiable; equip reviewers with AI; and test at machine scale. He particularly emphasized the last point: expect bottlenecks to move, and re-plan when they do.

By launch, the team had built or adopted more than twenty skills and two review agents. However, Pateriya pointed out that now that nearly every step is faster than before, the bottleneck has fallen between the steps—in the context spanning more than 15 repositories and years of history, the line connecting requirements to design, code, review, and testing still lives in people’s heads. Their next step is to create a PubHub developer agent that understands the project’s architecture, history, rules, and open issues like a long-time team member does, pushing tickets to pull requests. But the rule remains unchanged: a person approves every change.

Sources

  • blogs.cisco.comCisco Blogs↗
Continue researching →