Engineering teams in 2027

There's a conversation I keep having with our design partners at incident.io. It starts when I ask "what are you doing with AI internally?" and lands in a similar place every time.

The shape of how their engineering teams work is changing fast. Not in vague "AI is transforming everything" ways, but in concrete, repeatable patterns. Different companies are building the same things. The frontier teams are six to twelve months ahead of the average, and they're describing the same future.

This is my attempt to write down what I'm seeing. It's anchored in conversations with companies that are visibly investing in this — some via our design partner program, others via public posts from teams like Ramp and Stripe about what they've built — extrapolated to where I'd expect most engineering organisations to be by the end of 2027. It's also actively shaping what we're building for AI SRE at incident.io, which I'll come back to at the end.

If you're working inside one of these teams and think I've got something wrong, I'd love to hear it.

Companies are building their own AI infrastructure

The rationale for companies like Ramp or Stripe — and increasingly anyone with a meaningful developer enablement function — is something like this:

1. Our largest expense is developer time.
2. Most of the automatable engineering work happens during build.
3. We already have a large enablement team.
4. So the biggest ROI investment in AI is making our developers faster.

Once a leadership team accepts that argument, the same two pieces of in-house infrastructure tend to follow.

Tailored code agents

The first is a code agent that's been tailored to fit the company's environment. Ramp have built Inspect in-house. Stripe have Minions. Plenty of other companies are getting to the same place by adopting Cursor or Claude Code and investing heavily in making them work with their stack — the choice of build-vs-buy on the agent itself is less important than the work around it.

The shape is consistent either way: take a frontier model and a code harness, hook it into a development environment that can boot the company's stack near-instantly, plug it into the surfaces developers already use (Slack, the ticketing system, the deploy tooling), and feed it rich documentation of how the codebase works. The thing companies are actually building is the environment and the integrations, not necessarily the agent.

That work is much more tractable than building, say, an autonomous SRE — code agents have a built-in feedback loop (does it compile, do the tests pass, does the change run locally) that lets them grade themselves. Companies like Anthropic have done most of the hard part. The remaining ~20% is environment-specific: getting your particular stack to where an agent can verify its own changes is real engineering, but it's engineering with enormous ROI.

It's one of the reasons companies like Modal are growing so fast on the back of their sandbox offering — once you've accepted you want a tailored code agent, the next thing you want is a cheap environment for it to iterate in, and you'd rather buy that than build it.

By 2027 most companies above a certain size will have a code agent that's been tailored to their environment — whether built in-house or bought and adapted. It will be more capable inside their codebase than any off-the-shelf agent, because the work around it will have grown up with the company's specific conventions.

MCP gateways

The second piece of infrastructure is what I keep hearing called an "internal MCP gateway".

Last year the move was "everyone should use AI", and most companies stood up an applied-AI team to make that happen. What those teams have produced this year, mostly, is a centralised place where all the company's AI tools can be accessed through a single interface.

Practically that looks like a repository of internal AI-native APIs, each exposed over MCP, rolled up behind a single endpoint with identity and access control in front of it.

The access control is the interesting bit. Most companies arrive at the gateway by way of an "oh dear" moment — "we probably shouldn't have given the GTM team production access" — and end up needing a system that can compose tools without losing audit and permissioning. Once you have that, the cost of adding new internal AI capabilities collapses. Anyone with an idea for an AI-powered feature can ship one by adding an MCP endpoint and a key.

Third-party MCPs are tricky. Companies want to plug the products they use (Linear, Datadog, etc.) into the same gateway, which is giving rise to products like obot.ai and Docker's MCP gateway, both aiming to expose aggregates of MCP services with solid permissioning and audibility. I expect that piece to commoditise quickly, probably folded into one of the cloud providers within the year.

By 2027 most companies will have a portfolio of internal AI capabilities behind a centralised MCP gateway with identity and access control. This raises the bar for any product you sell into them — customers will expect it to plug into their gateway and to play nicely with everything else they've built around it.

That infrastructure lives in developer environments

Once a company has built tailored code agents and an MCP gateway, the question becomes how to drive usage. The most natural answer — and the one I keep seeing — is to bring the infrastructure to where developers already are.

That means terminals and IDEs. Claude Code or Cursor connected directly to the company's MCP gateway, with documentation that controls how those tools should be used, and the in-house code agent available as the default harness.

There's a self-reinforcing dynamic here. The teams building this infrastructure are themselves developers. They notice opportunities in their own workflows, and they have the means to ship them. Once one team integrates the gateway into their IDE, the others want it too, and the gateway becomes the connective tissue of how developers work.

This has a second-order effect on the products developers buy. Historically, software invested heavily in tailored user experiences — bespoke UIs, custom workflows, "log into our dashboard". With AI in the loop, two things have shifted:

1. The cost of building new surfaces has dropped — an agent can write the integration.
2. The valuable thing isn't the UI any more. It's the ability to compose information across the tools you already have.

Interacting with a product inside the environment where you already have your context and fluency is now a better experience than a custom UI for that product. Customers will increasingly expect tools to be present wherever they're working — in Linear when they're triaging tickets, in their IDE when they're building features, in Slack when they're coordinating.

By 2027 customers will increasingly expect tools to be present wherever they may be working. The place to be present is not your own UI any more — it's wherever the user's attention already is.

Products will be expected to interoperate

We're not the only people on this journey. By 2027 most companies will be using a suite of agentic products that each "own" a process. Customer interactions: Fin. Code changes: Cursor, or a tailored in-house agent. Production: whoever wins the AI SRE category. Sales: something we haven't yet seen consolidation around.

What this means for the products in that stack is they have to play well with each other. A real example from a recent conversation about Fin, on a flow Intercom would like to see work end-to-end:

1. Fin sees a spike in customer queries that look like an outage. It asks our system: "is this a known incident?"
2. We say no. Fin escalates: "should this be one?" Our agent decides yes and declares it.
3. The investigation runs, and our system tells Fin what to put on the status page.
4. Fin decides which customers to notify, based on the comms we share.

These interactions need more than raw API primitives. Fin doesn't want to assemble an incident picture from six different endpoints — it wants tools at the right level of abstraction: "is this a known issue?", "what's the current status?", "what should we tell customers?". Products will need to be compiling the ways customers want to use them from other agent systems, and building tools at the right level of abstraction for those systems to be effective.

The competitive pressure here is also real. Customers seeing huge ROI from Fin or their coding agents will be encouraged to consolidate onto tools that integrate better with them. This is either an opportunity for vendors to become one of the consolidation survivors, or a risk that ground is ceded to competitors who lean into the ecosystem faster.

By 2027 customers will use a suite of agentic tools and expect the products they buy to be connected natively into them, with strong handovers in both directions. The most important interface your product has will not be its UI — it will be the MCP contract that other people's agents use to consume your work.

Humans direct, agents do

The last theme is the one I'm least sure about, but it's coming fast and you can feel it.

Where the idea of AI taking real-world actions was laughable, as people experience more positive AI interactions they are learning to trust them. Something that caught me off-guard at an Intercom fireside on incident response was saying "obviously no one would ever have AI send public status page updates!" and having both Intercom and the crowd say "really? that actually feels ideal."

For engineering work specifically, code agents are getting good enough to author and ship fixes without a human reviewing every line. Once that lands, the limiting factor in incident response stops being "who's writing the fix?" and becomes "did we correctly diagnose what to fix?". The thing humans direct, increasingly, is the what and the why. Agents handle the how.

By 2027 customers will expect more of their tools to act rather than suggest, and where they used to be amazed by the idea of autonomous diagnosis, they'll start becoming frustrated if a product can't "just fix it".

What the team looks like

Most teams picture themselves the way they did three years ago: a group of humans collaborating in Slack, GitHub, on-call rotations, the usual. That picture is wrong now in two specific ways, and most companies haven't redrawn it.

The first change is that every developer on the team is now paired with their own agent. Claude, Cursor, Codex, whichever one they've adopted. The unit of collaboration is no longer a human alone — it's a human-and-their-agent.

The second is that around those pairs sit a small number of centralised, specialist agents. One per major domain: customer interactions, code changes, production. Each one really good at one thing, and connected — through the company's MCP gateway — into the rest of the team's tools.

The work flows between them via handoffs, mediated by the human's agent. The specialist production agent finishes a diagnosis. The human's IDE agent picks it up, pulls the context, drafts a fix. The human reviews and ships. The customer support agent sees the relevant incident and decides what to tell affected customers. Each specialist does the part it's actually best at, the human's agent does the coordination work between them, and the human stays the authority on what gets shared and shipped.

If you buy that picture, a few things follow for engineering teams today:

• Stand up your MCP gateway. This is going to be load-bearing for how your developers work with AI. The earlier you have it, the more leverage every later investment gets.
• Choose your specialist agents deliberately. You'll consolidate onto a small number of vendors, possibly one per domain. The ones you pick should be the ones that interop best with the rest of your stack, not just the ones with the slickest demo.
• Move into the surfaces where developers already work. Internal tools should expect to show up in the IDE, the terminal, and Slack alongside whatever dashboard they have — usually via an MCP endpoint into the gateway. For tools you're buying, push the vendor on how they plug into where your developers actually spend their time, not just how slick their own UI is.
• Push your vendors on their agentic story. The competitive pressure here is real. The products that win 2027 are the ones that play well with everything else in your AI stack, and the ones that don't will be replaced by ones that do.

This is happening faster than most engineering leaders I speak to think it is. The frontier companies are already living in 2027 in pockets — Ramp's developers with Inspect, Stripe's with Minions, a handful of others I'm not at liberty to name. Most of the industry is six to twelve months behind, and that gap is closing.

It's also the picture we're building for at incident.io with AI SRE: a desktop app that bridges centralised investigations into developer IDEs, an MCP that lets a customer's coding agent pick up an investigation and author the fix, handoffs between specialist agents mediated by the human's agent. I gave a talk at the Background Agents Summit walking through how we've put it together — Collaborating with background agents — if you want to see what these ideas look like when they meet a real product.

The teams that adapt fastest are the ones that take the new picture seriously and start redrawing now.