Why AI-augmented squads keep building the same thing twice
Operating production-grade service catalogs at scale, the signal is consistent: when AI tooling lands in an engineering organisation, velocity goes up and so does duplication. Squads ship more features per sprint. They also build the same thing twice.
A DX Annual panel in May 2026 described this from the engineering leader side. Tim Bozarth from Microsoft, Nancy Wang from 1Password, and Taroon Mandhana from Atlassian outlined how enterprises are restructuring around AI capability: smaller squads, shorter planning horizons, AI-augmented engineers. These are genuine structural responses to real changes in how quickly software can be written.
Late in the panel, Mandhana added: "We're seeing patterns of duplication and tech debt increasing as people quickly produce features. The maintainability of the code is suffering. It's prompted us to go back to standardised approaches and more right-of-code quality checks." The panel named the symptom but moved on. The cause of the duplication - why AI-augmented squads keep building the same thing twice even as pace increases - got no answer.
The structural argument and what it leaves open
The panel's org design recommendations are worth exploring. Smaller squads reduce coordination overhead. AI-augmented engineers can produce working code quickly enough that the old argument for long planning cycles has weakened considerably. Bozarth's model - "you form a team around a specific question, give them 8 weeks, then decide whether to continue" - matches how AI-assisted iteration actually works, where feedback loops have compressed from weeks to days. The structural advice is right.
What the org design conversation consistently skips is the question of what AI tools can see when they help a squad build something. Duplication and tech debt are framed as consequences of speed - and they are, partly. Speed is the mechanism; missing context is the cause. An AI coding tool asked to help build a notification service will help build one. It has no way of knowing that a notification service already exists in the service registry two teams over unless that service is explicitly visible in the context it's operating from. It won't ask around. It won't draw on institutional memory. It builds what the context available to it doesn't contradict.
Duplication at this scale has an infrastructure and knowledge cause. The org design changes the panel recommends are right - but they make the context problem more acute, because more squads are building things simultaneously with less shared institutional memory. This raises the stakes for the context infrastructure underneath.
What machine context actually needs to look like
The information AI agents need to avoid duplication is the same information a senior engineer would draw on before starting a new service: who owns adjacent services, what the dependency graph looks like, what services in the system do similar things, what SLO commitments exist for services the new work might extend or replace, which teams would be affected by adding a new node to the dependency graph.
An experienced engineer holds most of this in memory, or knows exactly who to ask. In an 8-week squad with AI-assisted velocity, some of that context may exist within the team - but the AI tools doing the build work don't have access to it unless it's been made explicit. The tools operate on what's been provided: the local codebase, the instructions, whatever retrieval is wired into the workflow. If the service catalog isn't wired in, the tools are building without a map of what already exists.
Keeping these dimensions accurate - ownership, dependencies, deployment state, SLOs - is the prerequisite for AI-assisted development to scale across multiple squads without compounding duplication into the codebase.
The catalog's role shifts when AI tools enter the build workflow. A human-browsable portal with stale records is an inconvenience for a platform engineer looking something up. That same stale record is a failure surface for an AI agent that reads it as current truth. The agent doesn't triangulate from surrounding context the way a person does. It reads what's there. If a service isn't in the catalog, or the ownership record is eighteen months out of date, the agent reasons and builds accordingly.
Time-bounded squads and the catalog dependency
Bozarth's 8-week squad model makes the catalog dependency particularly visible. A squad formed for eight weeks around a specific question may not have built up institutional knowledge of what the organisation has already shipped. Engineers on the squad may be coming from different parts of the stack, with limited visibility into what other teams built in recent cycles. Without accurate, machine-readable catalog data in the retrieval chain, the squad and its AI tools are starting from incomplete context.
Across a year with multiple cycles of 8-week squads working through the same engineering organisation, this compounds. Each cycle builds at speed. Each cycle's AI tools operate on the context available in that cycle. With accurate catalog data wired in, a squad can see what the organisation has already built and work from it - extend a service, adopt a dependency, reuse what's already running. Without it, each cycle starts from the immediately visible horizon. The tech debt Mandhana described accumulates from the sum of those gaps.
The same velocity gains that make AI-augmented squads productive also make the duplication visible faster. The catalog dependency doesn't go away when squads get faster - it gets more load-bearing.
The infrastructure argument the org design conversation is missing
The framing in the panel - reducing approval chains, delegating more decision authority, letting small teams move with autonomy - addresses the human coordination problem correctly. The platform team's job in that same environment is to provide the infrastructure that lets those squads move fast without compounding each other's work. For AI-augmented squads operating at the speed Tim, Nancy, and Taroon described, that infrastructure starts with the service catalog.
The catalog work that makes AI agents accurate across squads is the same work that keeps on-call rotations correct and dependency changes tracked. Those were human friction problems before AI entered the workflow - the engineer who had to ask around, the incident routed to the wrong team. What changes with AI in the loop is the rate at which gaps in the catalog produce wrong outcomes. A missing ownership record that generated mild friction in the human layer produces duplication at the pace AI tools enable.
Mandhana said the duplication and tech debt are prompting Atlassian to go back to standardised approaches and right-of-code quality checks. That is a reasonable response to the symptom. The infrastructure response is to address the context layer before the code is written: a catalog that AI agents can query, maintained accurately enough that what gets built in week one of a squad's 8-week sprint reflects what the engineering organisation has already built. That's what the AI-native org conversation is actually pointing at, without naming it directly - and doing it with eyes open means treating the catalog as operational infrastructure, not documentation housekeeping.
