What Happens When the Moat Moves?

Host Intro (Gene Kim)

Fantastic. So I met the two speakers who are coming up when they came to this conference two years ago. And when they told me what they were working on early this year, I got so excited because I think their work is so visionary and exciting and paints the way for the future.

So they're from Hilton, founded 100 years ago, today has 28 brands with over $12 billion in revenue. Matt Klosterman is the Senior Director of Mobile Software Engineering, and Jeremy Kooistra is the Senior Director of Website Software Engineering. So I think it's safe to say that between the two of them, a significant portion of Hilton revenue flows between their two teams.

So in the Vibe Coding book, we talked a lot about how AI is blurring the roles between the functional boundaries and roles within the organization. And when I heard what these guys were working on, it blew my mind. They took some of the work they heard from Jess Amado, a VP at Capital One, around how AI could help with requirement specification, and ran with it into places that I never imagined were possible. So I think this just shows that this community is a community that is experimenting, innovating, but most importantly, sharing and collectively pushing the frontiers of performance.

So without further ado, Matt and Jeremy.

Matt Klosterman

All right. Thank you, Gene.

Lately, I've heard Gene talk about this idea of what happens when the bottleneck moves. What I also think about is what happens when the moat moves.

In the past, if you had a specialized skill set — like say you were an iOS developer or an Android developer — there was a deep moat around your work. The tools and technologies are really unique, and there's a steep learning curve to get started. And now agents are making it much easier for people to start doing specialized work like that. So what happens when that moat moves?

Today, Jeremy and I are going to share some of our experience from inside the Hilton digital organization, and we're going to share what's happened as we've tried to expand deliberately who can contribute to our code bases.

My name's Matt Klosterman. This is Jeremy Kooistra. Jeremy leads Hilton's web engineering organization. I lead our iOS and Android developers. Each of our groups has about 40 developers, and together our teams build the experiences that millions of people use every day to shop, book, and manage their stays with Hilton.

To put that work into context, here's the scale of the business that our work supports. Hilton spans more than 9,400 hotels, 1.4 million rooms, operates in 144 territories, and has over 260 million Hilton Honors members. What that means is that every time we try something new, it's more about just the one thing that works — it's finding how to scale it afterwards.

So over the last 18 months, Jeremy, our peers, and I have been working through two questions: How is AI going to change the way we work? And then how are we going to scale across our teams and more organizations in Hilton?

A significant moment in our work came last year when Jeremy and I went to ETLS in Las Vegas. We arrived at ETLS and we had four things on our mind. We thought our developers are going to become more T-shaped. We thought we would see non-developers start to do prototyping, and that our developers would help them take that work and harden it and take it to production. We thought traditional IDEs were becoming obsolete. And we thought even though coding agents that were CLIs were becoming really popular, that we'd also see new interfaces emerge for developers to do their work — and non-developers.

So as we were at ETLS last year, our perspective started to change a little bit more, and three things happened that made us think we needed to aim for a new target and also act with more urgency.

The first thing that happened is Jeremy and I went to a pre-conference Vibe Coding for Leaders workshop that Gene Kim and Steve Yegge put on. And a weird thing happened. We went into the workshop, and Jeremy gets up and starts demoing while I'm still trying to get set up. I'd been using Claude Code for months, and he had never even done anything before. So the takeaway for me is that the familiarity with the tools was not the advantage that I thought it was going to be.

Second, what we heard is that agents were getting to the point that they weren't just for small tasks. We should start thinking about them as doing larger, more complex tasks than we thought, and it was going to happen a lot faster than we expected.

The third thing that happened is that we heard that we needed to think about agents as kind of virtual employees or teammates, and we need to start thinking about them having their own identities and access and a defined role in our operating model.

So those three things came together, and as we left Las Vegas last year, we were thinking something slightly different. We were thinking about this idea of: what if normal conversation starts to become an interface for the way our teams work going forward? What if we start seeing these powerful agents just working alongside our teams every day, all day? How will that change how work begins and who can direct it?

And we're starting to see signs of that now with technologies like GroqBot, Claude, OpenAI's products, and others. And the reality is that Jeremy and I's teams are not ready for that world yet. But we see it as a change that's coming, and we see it as an organizational readiness challenge as much as it is a technical challenge.

So next, I'm going to pass it to Jeremy and have him talk about how we are approaching getting our organization ready for a world like that.

Jeremy Kooistra

Thanks, Matt.

So when we went back to our teams and saw how they were approaching AI in their work, we saw four different mindsets.

Mindset one was, "I'm not interested. Keep AI away."

Mindset two was, "I don't know what I would do with it."

Mindset three was, "I understand it, and we're going to go really fast."

Then the fourth mindset is, "We need to rethink the work we're doing because of AI."

We saw numbers one and two very common in Hilton at the time. Mindset three is a bit of a trap. It's comfortable, it's familiar, and you're going faster, so it feels like you're doing well. What we found in the last year is you can get far more out of it if you go to mindset four — if you rearrange how you're working around AI.

To do that, we did workshops at Hilton. The idea of the workshop was to bring people in that weren't necessarily developers, give them access to our tools and our code, and see what they could do. We've run 14 workshops, 233 participants across 15 disciplines. I'm happy to say we've gotten people contributing that normally would not have.

What we had to do in the workshops to make them work is we had to give people access — we had to give them the tools and actual access to our code. We had to give them structure, so a bounded box where they could experiment and not mess things up or be afraid to break production. And then we had to give them permission. This was probably the most important. We had to let them use the tools, but also we had to encourage them to work differently than they had before.

Underpinning all of this, within our workspaces — these were repos that held our code, agents, skills, orchestration, documentation — the idea being this context could help non-developers actually make changes and be successful in our code. We also built in work cycle tracking and knowledge capture, so as questions were asked and answered, as mistakes were made and corrected, that could be put back in the workspace and the next person through wouldn't encounter it.

Early on in these workshops, not long after ETLS last year, we started to see some surprising things. People were getting much further along than we thought they would. We had a mobile intern that took an iOS feature and moved it to Android in a week. We had a technology VP that took a web feature and moved it to iOS and Android in a couple of weeks. A product leader that was able to take the requirements all the way to MRs in a couple of weeks. And then we had a tech executive join one of our workshops. He had his iOS and Android feature running before any of the engineers in the room. His last programming experience was in COBOL.

I'm going to give it back to Matt. He's going to talk about how our mobile developers reacted to seeing this.

Matt Klosterman

Thanks, Jeremy.

So it made our developers uncomfortable, and it made me uncomfortable. It was kind of twofold for me, right? Like, as someone helping us move AI adoption forward, it was pretty cool — it's neat seeing these people accomplish things in hours or days that they've never been able to do before. But when your background is something specialized like iOS or Android development, it makes you uncomfortable.

We had this specialized knowledge, this used to take a really steep learning curve to get acclimated to, and people were doing stuff very quickly, sometimes in less than an hour. That deep moat that I talked about — it now seemed to be moving.

We knew that the specialized knowledge still mattered, but we were seeing these weird things where who started the work or even who finished the work seemed to be changing. And so my biggest worry was: What does that mean for my team? Where is their value going forward? What should they think about evolving their roles as more people come into their world?

So there are two kinds of paths that I had in mind. One: if you're a mobile developer and this is happening, you could think about going deeper into the platform architecture, making our mobile platform more capable. Or you could think about broadening your horizons, and you could think about working across more parts of the system that you hadn't worked on before. So I needed a way to gradually introduce a new path and an expanded view for my team.

Earlier this year, we were setting 2026 objectives at Hilton, and I knew as I was setting an AI objective, I didn't want to just measure how much they were using AI or how much code they were doing that was AI-driven or AI-created versus their own. I wanted to find something that actually changed their behavior and aligned with what I thought the future would be.

So what we were starting from is we had product teams that had one iOS and one Android developer on each team. And the goal I set was: think of yourself as an agentic mobile developer. Your goal is going to be to look at the work on your team and see if you can drive the work for iOS if you've been an Android developer — using agents — or vice versa. And I wanted them to avoid checking the box, just doing it and going back to what they did before. So the actual objective was: contribute user-facing changes monthly to both iOS and Android. And the stretch goal was to get good enough at that that you could lead a value stream across both platforms — that you could be the person that's driving that work with agents and moving the iOS native implementation and Android native implementation together at the same time.

If this worked, the benefits would be big. If you're a developer, the benefit is you're expanding your reach, you're expanding your horizon in this really uncomfortable situation that we kind of find ourselves in as technologists right now. And for Hilton, the benefit is we get more value streams with the same developers that we have today.

So as I presented these goals to developers, I told them they had a choice. They could either check the box, or they could embrace the uncertainty and see this moment in time as an opportunity to expand their reach and grow their impact.

So seven months later, we can share the initial results.

Before this year, less than 7% of my team had ever contributed code to production across both platforms. Now every mobile developer on my team has shipped to production on both iOS and Android. That increased reach from the developers allows us to go into 2027 planning for 25% more value streams than we did going into this year in 2026.

So let's look deeper at this change in behavior.

First, when did every developer start switching over and contributing to both platforms instead of just one? What this shows is over the last year — it looks at if you're an Android developer, have you ever contributed to iOS? Or if you're an iOS developer, have you ever contributed to Android? You can see that steady state in the past there at the beginning of the year. And what we saw is that as we went further through the year, set the objective, and gave our developers support, we saw this grow more and more throughout the year. And in mid-July, we reached a point where every single developer had contributed to both platforms in production. I was pretty amazed at this result, because really my internal goal for myself was for us to get to this point by September, and we got there by mid-July.

But was this just checking the box? Were they making the contribution and going back to what they were doing? And the answer is they weren't.

So this graph has a target of 50% instead of 100%. What it's looking at is the share of our merge requests that are what I call non-home MRs. So if you're an iOS developer and you contribute to Android, this shows up as a non-home MR. What we see over the last year is that as we move forward, we got closer to this 50/50 split we're aiming for. The band we've been aiming for is 40 to 60% — a healthy range of the split between platform MRs. As we got to June and July, it was around 40% of the team getting there. And in August and September, we crossed over that bottom 40% and we're into the target band, and it seems like this is still accelerating and getting closer to our end target of closer to a 50/50 split.

But this is a team-wide view, and that could still hide a lopsided distribution. So this next view looks at it on a per-developer basis, and it asks the question: each month, how many of the developers are operating in that target range that we're looking for? In June and July, we got to about 40% of developers operating that way. In the last two months, in August and September, we're up to about 60%.

So taken together, what these three charts show is that all the developers have crossed over and been able to work on both platforms this year. Non-home work has become a material share of what our teams are doing instead of just a one-off experiment. And the majority of the developers have begun operating across platforms every month.

I'm really surprised at how quickly we got here, and I'm so proud of the team for achieving this.

But it also comes from more than just setting an objective and giving the developers a coding agent. We'd actually spent years trying to create conditions for our teams to work across platforms.

We see this as an example of the 2025 DORA finding that AI acts as an amplifier. For the past four years, we were already working on modernizing our app architecture and the way our teams were structured. As we modernized our architecture over the last few years, we had built out a robust design system, higher-level reusable UI patterns on top of that design system, and a unidirectional data flow based on The Composable Architecture. And so our developers have already been in a mode where they're working at this higher-level shared architecture between our iOS and Android implementations, with the more native details farther below the abstractions. And what we've seen is that this also helps the agents work across the platforms more successfully and with more consistency.

Like I said, we've also been evolving how our teams are structured over the last few years. Originally, we started with separate iOS teams and separate Android teams. And a few years ago, we switched and took a Team Topologies lens to our feature teams, and we made them stream-aligned teams working across different parts of the customer journey. Those teams had two iOS developers, two Android developers, a product owner, a designer, and a tester. And what we found over time is that our teams performed even better if they were leaner. So we moved to leaner teams than that and more teams. And where we've been in a steady state is one iOS developer, one Android developer, a product owner, and a tester.

What's been constant as we made these team changes is the culture that the developers work in. The iOS and Android developers — and really the rest of the team — start together and finish together. The iOS developer and Android developer start at the same time, they create merge requests, they align on their approach, and they compare notes and make sure they're following each other's path.

So what AI is allowing us to do is take that further. Instead of the developers just aligning with each other, they're now able to use AI to drive alignment across both of the platforms themselves.

And in 2027, we want to push this even further. Our goal going into next year is to end 2027 with more than twice as many value streams for Hilton that we support than we went into 2026 with.

We don't think we're going to be able to reach that just by expanding the way our developers work. We also think we're going to need to expand the way our non-developers work.

Jeremy and I are not just accepting that the moat is moving around our teams and our developers — we're actively trying to move that moat ourselves.

So now I'm going to hand it back to Jeremy and let him talk about how we are building off the excitement we're seeing with non-developers in the workshops to try to get there.

Jeremy Kooistra

All right. So we've talked about our reusable paths, the workspaces. Matt talked about the shift our developers are going through, and we talked about how our workshops are starting to bring non-developers and business users in to do some of the work. I want to show an example of this that's out live in production.

This is an example from our team in Asia Pacific. They had a need — for the Japanese market only — to add a link to the mobile app that would let users book a rideshare with DiDi. How this normally would've worked is they would've written up the requirements, put together a business justification, and handed it over to the centralized team to be worked. Depending on how busy they were, other projects, it may have been a while before that change was made — or it may never have gotten made.

What we did: we gave them a workshop, we gave them a workspace, we showed them how to use it, and then we partnered them with a developer who they could ask questions to or tap on the shoulder if they needed help troubleshooting. I'm happy to say they put it out — it's live. But I'm more excited that we built a new value stream out of people that hadn't been contributing previously.

If we take a step back and look, we see the business flow I described: write up your requirements, prioritize, hand off — probably delays at all of those steps. On the other side, we see the business team as central, asking questions as needed to a developer, getting support, and then using our workspace and agents to cycle the work through.

Now that we've shown we can do that, we have to look at what it's going to take to scale this across other teams. We know we have to help our developers adapt more than they have so far. Other disciplines need to adapt as well to help with the changes that are coming. We need to start as a team to build up our recognition of good AI answers and poor AI answers, and then we need to improve the UI for the business users — right now it's very technical and difficult to understand for them. Matt's going to talk a little bit more about what we're looking at there.

Then on the operating model side, we need to get more cycles run — we just need more people doing more work through it to help improve the system. We need to break down those silos that have built up around web, mobile, and our backend. And then as delivery accelerates, we have to keep our eye on the engineering fundamentals. To Matt's point, that's what's made this work so far.

All right. I'm going to hand it back to Matt, and he will talk about where we're going from here — especially around the UI.

Matt Klosterman

All right. Thanks, Jeremy.

Jeremy said we want to improve the builder experience as we expand who can contribute to our systems. What we're seeing in our workshops and beyond is that the traditional tools that we're used to as technologists don't really speak to people who aren't technologists and don't have a technology background. Even further, the rituals and automation that we're all used to and we've built over the last decade or more also seem really foreign to people who haven't been in this world for the last decade or more.

So we've been asking: What if?

What if the builder experience could look more like conversations around intent? What if readiness to ship could look more like a checklist? And what if that was in a UI that's multiplayer instead of single player?

That's the next challenge that we're taking on.

What we're doing is we're placing a very lightweight user interface on top of our agents and workspace. And in that workspace and in that UI, we're relying on an approach based on linked intent development. We were introduced to this a couple of months ago — linked intent development from Jess Amado — and we were kind of blown away. It was the first spec-driven approach that we saw that really resonated with us, and we saw how it could add rigor but still allow us to shape the agile culture that we really cared about.

So at the very highest level, the way we're thinking about this and what we're trying to do next is really two views. There's the technologist view that our teams are used to — it has more of the detailed requirements, the acceptance criteria, our test cases, our code. Then there's more of a guided workflow that's more intended for our people who are not from a technology background — it's more focused on intent, readiness, and action items. And our developer enablers and our business teams can work together in the same place.

That's what we're working on next, and that's where we need your help.

If you're exploring structured requirements and formal methods to raise the bar on AI-produced software, if you're opening your platforms to contributors who have not been developers in the past, or if you're preparing your teams for less specialization — we would love to hear from you. We feel like we're just getting started, and we would love to compare notes and learn from each other. Thank you.