This is a summary of a longer piece on the WunderGraph blog. Read the full article here.
There's a common assumption in platform engineering right now: AI will speed everything up. LLMs write code faster. Implementation cycles shrink. Teams ship more.
That's true for the parts of the job that are already well-defined.
The bottleneck in GraphQL Federation development isn't implementation. It's alignment. And alignment is exactly what LLMs can't help with.
Where the Time Actually Goes
If you're running Federation at scale, you are probably familiar with this pattern. A frontend engineer needs a new field. The implementation is straightforward — maybe a few hours of work. But before a line of code gets written, someone has to answer a set of organizational questions:
- Which subgraph owns the type where this field belongs?
- Is that team in a position to add it right now?
- Does the proposed field name conflict with conventions in other subgraphs?
- Who needs to approve this before it's safe to compose?
None of these are technical problems. They're coordination problems. And in organizations running dozens or hundreds of subgraphs, they're expensive ones. Complex schema changes can take months, not because the code is hard, but because getting the right people aligned is.
The current toolset for this coordination: Slack threads, Miro boards, meetings, and platform engineers acting as human routers for every schema change request. It works until it doesn't.
LLMs Make This Worse Before They Make It Better
Here's the dynamic to pay attention to: as LLMs reduce implementation time, alignment becomes a larger fraction of total cycle time. If implementation drops from a week to a day, but coordination still takes three weeks, you haven't meaningfully accelerated anything.
The velocity problem in Federation isn't that engineers write code too slowly. It's that getting to "here's exactly what to build" — the right field name, the right type, the right subgraph, with sign-off from the right teams — is where time disappears.
LLMs accelerate the last mile. They don't touch the first three.
The Structural Issue Underneath
There's an architectural reason coordination is hard in Federation, and it's worth naming.
Federation composes the supergraph bottom-up: subgraph teams build independently, and the supergraph is whatever the composition layer produces. The consumer-facing API is a side effect of what teams happened to build.
GraphQL's original design principle was the opposite: the schema is a contract shaped around what consumers need. Federation, as commonly practiced, inverts this.
WunderGraph's response to this is an approach called Fission — designing the consumer-facing supergraph first, then decomposing that design into work for subgraph teams. Proposals start at the supergraph level. Affected subgraphs and their owners are identified automatically. Each team reviews and approves their portion before implementation begins.
This makes the coordination explicit and trackable rather than ad hoc.
What Agents Actually Need
The coordination problem gets more acute when you extend it to AI agents.
An agent working on behalf of a user needs to know what capabilities exist in the graph. If a capability is missing, it needs a way to request it. As Cloudflare has noted, it doesn't work to expose thousands of API endpoints to an agent; you need a structured, searchable graph.
Hub is designed with this trajectory in mind. The vision: an agent queries Hub via MCP to discover what capabilities exist, proposes a schema change if something is missing, and implements it once a human approves. AI handles what it's good at while humans retain judgment over API design decisions. Hub is the coordination layer between them.
The Practical Takeaway
If you're planning to use AI to accelerate your API development workflow, the investment that will actually move the needle isn't better code generation. It's better coordination infrastructure.
Federation solved the technical problem of decomposing a graph across teams. It left the organizational problem largely unsolved. That's the gap governance tooling fills.
LLMs will keep getting better at writing subgraph resolvers. The teams that compound that velocity are the ones that also solve alignment.
The full article goes deeper into Fission and the architecture of Hub. Read it on the WunderGraph blog.
Top comments (0)