Glue Work is the New System Design: Why Alignment is the Premium Skill in the Age of AI

When the feature ships and nothing works

A familiar pattern in distributed retail backends: a pricing update lands in four days. The AI assistant scaffolds the service layer, the tests, even the OpenAPI spec. Green CI. Clean diff. The sprint demo goes well.

Then staging breaks in a way the test suite never surfaced.

The inventory service in eu-west-1 is still emitting events on the old schema. The cart service in us-east-1 has already migrated to the new one. The pricing microservice, built in a sprint, assumes both sides are synchronized. They are not.

Nobody wrote bad code. The failure lives in the gaps between the code. Three teams, two event contracts, one assumption that someone else already handled the migration window.

That is glue work. In 2026, it is most of what senior backend engineers actually do.

Why AI moved the bottleneck up the stack

For years, system design interviews trained engineers on the fun stuff: consistent hashing, connection pools, index selection. Mechanical sympathy at the silicon layer. That still matters. But it is not where most production weeks go anymore.

The recurring pain sits higher up:

• Which service owns the write path when two domains touch the same entity?
• Does this API call cross a region, and who pays for that latency in the SLA?
• When the ML pipeline publishes a new embedding format, who updates the search index, the cache invalidation, and the rollback plan?

AI assistants are very good at filling in a function body. They are mediocre at knowing that an OrderPlaced event has three consumers across two org charts, and one consumer team has not picked up a schema change notification.

The write path got faster. The coordination path did not.

graph TB
  subgraph us_east["us-east-1"]
    Cart["Cart service<br/>OrderPlaced v2"]
    Price["Pricing service<br/>schema v2"]
  end

  subgraph eu_west["eu-west-1"]
    Inv["Inventory service<br/>expects v1"]
  end

  Bus[(Event bus)]

  Price -->|"GET /price"| Cart
  Cart -->|"publish OrderPlaced v2"| Bus
  Bus -.->|"deserialize fail"| Inv

  style Inv stroke:#ef4444,stroke-width:3px,color:#fff
  style Bus stroke:#64748b,stroke-width:2px,color:#fff

Glue work is system design with humans in the loop

“Glue work” often gets dismissed as the boring tickets. Updating a runbook. Fixing a broken Jenkins job. Writing the Confluence page nobody reads.

Some of that is still true. But the glue work that actually moves systems is different. It is the architectural negotiation that happens before anyone opens an IDE.

Alignment, in this context, means getting explicit agreement on:

• Ownership boundaries. Who is the system of record for customer credit balance? If two services can write, you have a distributed systems problem whether you admit it or not.
• Contract stability. What fields are guaranteed on the webhook payload? What happens when you add one? AI-generated clients will compile against anything. Production will not.
• Failure semantics. If the downstream call times out after 800ms, do you retry, compensate, or fail the whole checkout? Three engineers can implement three different answers in the same afternoon if nobody aligned first.

This is system design. It just does not fit neatly on a whiteboard with boxes and arrows because the boxes are teams and the arrows are calendar invites.

The network tax of misalignment

Mechanical sympathy still applies here, just at a different layer.

Misaligned teams do not produce abstract “communication overhead.” They produce concrete network and runtime cost.

One team deploys a new recommendation endpoint that fan-outs to four internal services. Another team did not know. Their batch job now hammers that endpoint at 2 AM with unbatched requests. Each call holds a thread for 400ms waiting on cross-AZ hops. The connection pool on the catalog service drains. Checkout slows down at 2 AM, which is exactly when European traffic peaks because time zones are rude.

Nobody wrote a bug. The architecture was never jointly reviewed as a traffic pattern.

Or take data synchronization. One team switches from offset pagination to cursor-based pagination on the product feed API. Another team’s analytics pipeline still uses ?page=847. The API returns empty after page 200. The dashboard shows stale inventory for six hours until someone notices. Six hours of wrong business decisions because a contract changed without a consumer migration plan.

These are not people problems dressed up as tech problems. They are production incidents waiting in the gap between services.

sequenceDiagram
  participant Cart as Cart service us-east-1
  participant Price as Pricing service us-east-1
  participant Inv as Inventory eu-west-1
  participant Bus as Event bus

  Cart->>Price: GET /price (new schema v2)
  Price-->>Cart: 200 OK
  Cart->>Bus: OrderPlaced v2
  Bus->>Inv: deliver event
  Note over Inv: still deserializing v1
  Inv-->>Bus: poison / skip / stale state

AI makes the surface area worse, not better

This part is genuinely unsettling, and worth naming directly.

AI coding tools increase the rate at which new integration points appear. A developer can stand up a new Kafka consumer, a gRPC client, and a Redis cache invalidation hook before lunch. Each one is reasonable in isolation. Together they form a web of dependencies that nobody has drawn on a single diagram.

The generated code often looks production-ready. Typed interfaces. Retry logic. Structured logging. It compiles. It passes unit tests. What it cannot do is surface that the payments API was frozen pending a PCI audit, and a new client will hit a deprecated endpoint that returns 200 with an empty body.

More code, more edges, same number of hours in a design review meeting. That ratio is the problem.

PR volume doubles while RFC attendance stays flat. Teams build faster at the boundaries they have not agreed on.

What alignment looks like when you take it seriously

Teams that avoid these failures treat alignment as engineering work with deliverables, not vibes.

Write the contract before the code. Not a 40-page RFC. A half-page: inputs, outputs, error codes, idempotency key behavior, and who owns the rollback. AI can implement against that doc in minutes. Without it, you get four incompatible implementations.

Map the network path explicitly. Two questions worth asking on every design review: how many hops to the data, and does any hop cross a region? If the answer is “probably,” the design is not ready. Cloud latency is not free. Every extra hop is thread hold time, pool pressure, and a failure mode you have to handle.

Synchronize deploy windows for shared contracts. Schema changes on shared events get a named migration owner, a dual-write or dual-read period, and a date when the old version dies. This is boring. Boring prevents 3 AM pages.

Keep a living system map. Not a wiki page from 2023. A diagram someone updates when a new consumer appears. When AI can scaffold services in an afternoon, the map goes stale in a week unless ownership is assigned.

flowchart TB
  subgraph checklist["Pre-implementation alignment checklist"]
    direction TB
    A["1. Contract owner<br/>Named owner for the API or event contract"]
    B["2. Schema version<br/>Current version, migration window, sunset date"]
    C["3. Network hop count<br/>Hops to data, cross-region calls, expected latency"]
    D["4. Rollback owner<br/>Who runs rollback and where the runbook lives"]
    E["5. Downstream consumers<br/>Every service, job, and team that reads this contract"]
    A --> B --> C --> D --> E
  end

  START([Integration proposed]) --> A
  E --> READY{All fields agreed?}
  READY -->|Yes| IMPL[Start implementation]
  READY -->|No| ALIGN[Stop and align first]

  style READY stroke:#94a3b8,stroke-width:2px,color:#fff
  style ALIGN stroke:#ef4444,stroke-width:3px,color:#fff
  style IMPL stroke:#22c55e,stroke-width:3px,color:#fff

The skill that does not autocomplete

Index selection and pool sizing still matter. But the work that determines whether systems survive contact with production is increasingly this: getting five people to agree on what truth means, who writes it, and what happens when the network says no.

AI can generate the implementation. It cannot generate the organizational consensus that the implementation depends on.

For backend engineers growing into senior roles, the highest-leverage skill is often the least glamorous: draw the boundaries, write the contract, and run the meeting where two teams discover they have been building incompatible assumptions for three sprints. That skill does not autocomplete. It is also what keeps connection pools from draining at 2 AM because nobody knew about the batch job.

Glue work is the new system design. Engineers who get good at alignment ship systems that hold together. The ones who only optimize the write path keep wondering why fast code still fails in staging.