Microservice teams in the AI era
AI tools now write much of the code in many teams. That makes code cheap, but not understanding, coordination or running a system in production. The team, not the tool, is still what owns a service.
Emerging practice. Unlike the patterns on this site, these ideas are still settling. Treat them as questions to test in your own organisation, not as rules.
The team is still the unit of ownership
Conway's Law still holds, and matters more
When code is cheap to write, what is left of lead time is deciding, coordinating across teams, reviewing and running the system. All of that follows how teams are organised. A team boundary that cuts across the work slows an AI-assisted team down just as much as any other.
A person stays accountable
An AI tool cannot be on call, explain a design decision in an incident review or answer for a service. You build it, you run it now means you own what you and your tools built, including the parts nobody on the team typed.
Cognitive load is still the limit, it just moves
Less effort goes into writing code and more into understanding, checking and operating it. A team can now produce more than it can understand. Size a team's scope by what it can run with confidence, not by how much it can produce.
Each team type, with AI in the loop
Stream-aligned teams
Smaller teams, or each team owns more. One team with AI help can build what used to take two, and can take on a wider slice of the product.
Watch for: Review, testing and on-call become the bottleneck. If a team cannot explain how its services behave under failure, its scope has grown past what it can run.
Platform teams
A new paved road for AI: approved tools and agents, guardrails, access to code and documentation, cost limits and checks on what the tools produce. Templates, APIs and docs now serve AI tools as well as people, so they need to be clear enough for both.
Watch for: A platform that only adds tools without a clear default way of working. Teams then pick their own, and every service is built a little differently.
Enabling teams
Coaching teams in AI-assisted ways of working: how to break work down, review generated code, write tests and prompts that pin down behaviour, and know when not to use AI.
Watch for: The usual enabling-team trap: becoming a permanent AI helpdesk instead of leaving teams able to work on their own.
Complicated-subsystem teams
New specialist areas appear around models, retrieval, evaluation and safety. Most product teams should use these as a service rather than build the expertise themselves.
Watch for: Every product team building its own version of the same AI plumbing, each slightly wrong.
Between teams: X-as-a-Service works better when the service is well described, because an AI tool can use a clear API, contract and example without a meeting. Unclear boundaries cost more, because a tool repeats the same mistake quickly and at scale. Consumer-driven contract tests catch the breakage that faster change brings. See Team Interaction Modes and Consumer-Driven Contract Testing.
What to watch for
Service sprawl
Creating a service is now cheap, so teams end up with more services than they can run. It is the old nanoservices problem, made faster.
Signs: Services with one endpoint, services nobody remembers creating, more services than engineers on call.
What helps: Draw boundaries around business capabilities, not around what was quick to generate. Give the platform's service template a short checklist for when a new service is worth it.
Ownership in name only
A team owns a service on paper, but nobody on it understands the code, because nobody wrote it. It surfaces during an incident.
Signs: Incident reviews that end with "we are not sure why it did that", and changes nobody wants to make.
What helps: Treat understanding as part of done: a reviewer who can explain the change, tests that describe the behaviour, and runbooks the team has used.
Review bottleneck
AI multiplies the code written, while review capacity stays the same. Either lead time grows, or reviews become rubber stamps.
Signs: Long queues of pull requests, very large changes, and approvals in seconds.
What helps: Smaller changes, automated checks before review, contract tests between services, and feature flags so unfinished work can ship safely.
A broken junior pipeline
If AI does the beginner-level work, people never build the experience the team will need from its senior engineers later.
Signs: Juniors who can generate a service but cannot debug one, and a few seniors on every incident.
What helps: Pair juniors on incidents and design reviews, and let them build some things by hand on purpose. An enabling team can help.
Questions to ask
- Could the team explain, without the AI tool, how each of its services fails and recovers?
- Has the number of services grown faster than the number of people on call?
- How long do changes wait for review, and how long does a review actually take?
- Does the platform give one clear, safe default way to use AI tools?
- Where will the team's next senior engineers learn what they need?
Try it in the Conway's Law lab: give layer teams AI tools and compare them with capability teams and a platform. Read teams and ownership for how product and platform teams split the work.