1 Company Background

Airbnb was founded in 2008 by Brian Chesky, Joe Gebbia, and Nathan Blecharczyk. The original pitch was absurdly simple — rent out an air mattress in your apartment during a design conference when hotels were sold out. That idea grew into one of the largest travel platforms in the world, with more than 8 million active listings in over 220 countries and regions, and more than 5 million hosts who earn income by renting space to travelers.

What makes Airbnb different from a hotel chain, an airline, or even a platform like Booking.com is the shape of the business. Airbnb owns no properties. It does not employ the people who clean the rooms, answer the doors, or set the prices. Every one of its listings is a unique home offered by an independent host, and every booking is a transaction between two people who may never meet. Airbnb’s job is to be the layer in the middle that makes those transactions happen.

That middle-layer position turns out to be an enormous AI problem. Every night, millions of potential guests are trying to figure out where to go, and millions of hosts are trying to figure out what to charge. Neither side fully knows what they want, and neither side can be expected to. The guest has a vague idea of a trip; the host has a vague sense of what similar homes nearby are charging. Airbnb’s job is to turn those two vague signals into a specific match at a specific price on a specific date — hundreds of thousands of times a day.

2 The Big Idea: Two Sides, One Platform

Every business in this course so far has had one primary customer. Netflix has subscribers. Spotify has listeners. Uber has riders (yes, drivers matter, but the business problem is framed around getting a rider a ride). Airbnb is structurally different. Airbnb has two customers who need completely different things from the same platform — and the platform only works when both sides get what they need.

Now here is the twist that shapes the rest of the chapter: neither side of the Airbnb marketplace fully knows what it wants. That might sound strange — aren’t people who visit a travel website the ones with an idea of where they want to go? Sometimes. But often, no.

Exploratory users introduce an even harder problem for any recommendation system: if the user doesn’t know where they want to go, how is the system supposed to know what to suggest? This is a classic problem in recommender systems, and it shows up whenever a user has very little history for the system to learn from.

On the host side, the parallel is nearly exact. A host has a home, a calendar, and an approximate sense of what to charge. But they don’t know what a Thursday in early October will actually be worth three months from now — nobody does. Markets move. Big events pull demand forward. Weather shifts bookings around. A host trying to price by intuition is guessing against information the platform already has in aggregate. That is the supply-side version of the same fundamental problem: the person on this side of the marketplace does not fully know what they want (or what they should charge), and the platform is better positioned to help them figure it out than they are on their own.

3 The AI Factory at Airbnb

We introduced the AI Factory framework in Chapter 3 with Spotify and applied it again with Uber in Chapter 4. The same five steps organize Airbnb’s AI systems too — data, model, prediction, decision, value — with one important twist. Airbnb runs parallel AI Factories: one on the guest side, one on the host side, both drawing from the same underlying data layer, and in the last few years, a third running inside the engineering organization itself.

Each track has its own data, its own model, and its own deployment surfaces — but they share a foundation. Every search a guest does becomes training data for the destination recommender, but it is also evidence about demand that feeds Smart Pricing. Every booking a host accepts teaches Smart Pricing about what prices clear the market, but it is also a signal the destination recommender uses to infer where travelers actually want to go. The two factories compound each other. The more guests Airbnb has, the better it can price for hosts. The better prices hosts offer, the more guests convert. This is the marketplace flywheel, and AI is what keeps it spinning.

Part III of this chapter looks at a third, newer use of AI at Airbnb: not customer-facing at all, but pointed at Airbnb’s own engineering organization. That will raise a different set of questions — but the fundamental framework stays the same.

Part I4 Data: The Language of Travel Intent

Here is a problem. A user opens the Airbnb app. They have done four things in the last three months: booked a home in Lisbon, searched twice for “Tokyo” without booking, clicked on a listing in Mexico City, and opened the app today without typing anything. What does that tell you about where they want to go next?

A human looking at that list can probably spot a pattern — an adventurous traveler who likes cities, maybe thinking about somewhere warm. But a machine cannot reason that way unless the data is structured to let it. The central insight in Airbnb’s destination recommendation system is that a user’s actions can be treated the way a language model treats words.

But not every action carries the same meaning. A booking three years ago and a search three minutes ago are both data points, but they say very different things about what a user wants right now. Airbnb’s system is explicitly designed to pull two different kinds of signal out of the same behavioral sequence.

On top of these behavioral sequences, Airbnb layers contextual signals — things like what time of year it is. A user’s long-term pattern might say “beach destinations,” but if they’re searching in December, the model should probably weight warm-weather beaches over Cape Cod. The current date is an input to the model in the same way a word’s position in a sentence is an input to a language model.

5 Model: Embeddings, Transformers, and Region/City Prediction

Once you’ve decided to treat user actions as tokens, you need a way to represent each token as something a model can actually do math with. Spotify’s chapter introduced the answer: embeddings.

Once each action is an embedding, the model processes the whole sequence of actions with a transformer — the same class of architecture that powers modern language models like the ones behind ChatGPT and Claude. The technical details are beyond the scope of this course, but the business intuition is straightforward: a transformer is very good at looking at a sequence and figuring out which parts of it matter most for predicting what comes next. When the user’s history is “booked Lisbon two years ago, searched Tokyo three times last week, clicked Mexico City yesterday,” the transformer learns which of those actions deserves the most weight in predicting today’s destination.

But there is one more wrinkle. The model is not just trying to predict a city. It is trying to predict geography at multiple levels at once.

6 From Dormant Users to Autosuggest: Closing the Prediction–Decision Gap

Here is a training-data puzzle worth sitting with. Airbnb wants the destination model to work for everyone — not just the user who just searched five times in the last week, but also the user who booked once in 2024 and hasn’t logged in since. If you train the model only on users who are currently active, you get a model that is great at the obvious case and useless for the harder, more valuable case of bringing back a lapsed user. If you train it only on dormant users, you can’t serve the active ones well. Airbnb’s answer is to design the training data to include both.

Once the model is trained, Airbnb has a predicted region and a predicted city for each user. But a prediction is not a decision. What should the business actually do with it?

Airbnb has deployed the destination model in two places so far, and the two deployments illustrate opposite ends of the user-intent spectrum:

• Autosuggest. When a user taps the search bar, the system shows a ranked list of suggested destinations before they’ve typed anything. This is the active user case — someone who just opened the app is in a decision-making moment, and the right three suggestions can shave real time and friction off the trip-planning process. Airbnb reports that this feature drives the largest booking gains in regions where English is not the primary language — suggesting it is especially helpful for users who have a harder time typing and spelling unfamiliar destination names.
• Abandoned-search emails. When a user searches but doesn’t book, Airbnb sends a follow-up email featuring listings in destinations the model predicts the user is most likely to want — not necessarily the exact destination they searched. This is the dormant-user case: the user has shown some interest and then left, and the email is an attempt to re-engage them with something a little broader than what they searched for.

Part II7 Dynamic Pricing and Lead Time

Now flip the marketplace around. A host has just listed a two-bedroom apartment in San Diego. They need to decide what to charge for every single night on their calendar — not just tonight, but six months from now, twelve months from now. Prices that are too high leave the calendar empty. Prices that are too low leave money on the table. And the “right” price for a Thursday in early October is different in July than it is in September, because the market keeps moving.

One of the most important variables in dynamic pricing has nothing to do with the listing itself. It has to do with time — specifically, when a booking is made relative to the check-in date.

8 Why Pure ML Wasn’t Enough: Hybrid Models & Demand Aggregations

Here is where the Smart Pricing story gets interesting — and where it connects directly back to Uber. The obvious move for a company like Airbnb is to throw a powerful machine learning model at the problem. Collect every feature you can find about each listing and each check-in date, train a huge model to predict the optimal price, and deploy it. Airbnb’s data science team considered exactly that approach, and rejected it.

The reasons were specific. With millions of listings, each with its own characteristics, and each checkin date getting booked at most once, the data is desperately sparse at the individual-listing level. The prediction problem has three dimensions at once (listings × check-in dates × lead days), which makes it computationally unwieldy. And perhaps most importantly, Airbnb’s team had good domain intuition about the shape of the lead time distribution — they could see that bookings tended to accumulate in a pattern that matched a well-known family of statistical distributions. A pure ML approach would ignore all of that intuition.

But there’s still one problem left. Airbnb has millions of listings, and each one is unique. Even with a hybrid model, trying to fit five parameters for every individual listing would run into the same sparsity wall — most listings simply don’t have enough bookings to estimate reliable numbers. The workaround is an idea that should feel familiar from Spotify.

9 The Prediction–Decision Gap on the Host Side

Smart Pricing takes the predicted lead time distribution for each cluster, combines it with information about the specific listing and the specific check-in date, and produces a suggested nightly price. That suggestion gets displayed in the host’s calendar view. The host can accept it, override it, or ignore it entirely.

That single design choice — suggest, don’t set — is worth pausing on, because it’s a live example of a tension this course has been tracking since Chapter 2.

That design choice does not make the ethical questions go away. When Smart Pricing suggests lowering a nightly rate to match an apparent market softening, the host is under real pressure to accept — the alternative is a dark calendar. The suggestion is not a command, but it is not neutral either. A suggestion from an algorithm that sees the entire market is hard to argue with from a position of seeing just your own property. We’ll return to this in §11.

Part III10 LLMs for Test Migration: 1.5 Years to 6 Weeks

The first two parts of this chapter looked at AI systems Airbnb built to serve its customers. This third part is different. It is about a system Airbnb built to serve itself — and it is the clearest example in this course so far of how generative AI is actually being integrated into companies that already have deep ML capability.

The problem: Airbnb had about 3,500 React component test files written with a testing framework called Enzyme, which had gone out of fashion. They needed to rewrite those test files using a newer framework called React Testing Library. The tests had to preserve the original testing behavior — you can’t just throw out tests without losing coverage of the code. Engineers originally estimated this rewrite at about 1.5 years of engineering time if done by hand. In 2025, Airbnb completed it using a pipeline built around a large language model in six weeks.

That is not a small result, and the underlying mechanics matter more than the headline number. To understand what Airbnb actually did, you first need a clear distinction between the kind of AI we’ve been discussing in this course and the kind of AI that handled this migration.

Why was this problem a good fit for an LLM and not for the kind of custom model built in Parts I and II? Three reasons. First, the task is code, not behavior — there’s an enormous amount of public JavaScript code in the world that an LLM has already been trained on. Second, the task is generative, not predictive — the output is a new test file, not a score or a ranking. Third, the task has an objective correctness check — the migrated test either passes or fails when you run it. You don’t need a human to rate the output; the machine can tell immediately whether it worked. That third property is crucial, and it led directly to the most important design decision in the whole project.

The pipeline: the LLM is the engine; the workflow is the engineering

Here is the part that business students should pay closest attention to. Airbnb’s engineers did not just hand 3,500 files to a language model and hope for the best. They built an automated pipeline around the model that looked more like a factory than a chatbot. The structure was roughly:

1. Break the job into small, checkable steps. Each file was pushed through a sequence of distinct stages — refactor the Enzyme code, fix any issues in the test framework, fix linting and type errors, then mark complete. Each stage had a validation check: did the output actually work?
2. When a step fails, retry with better context. If a stage failed, the system automatically re-prompted the LLM — this time including the specific error message and the most recent broken version of the file. Most files that failed the first attempt succeeded within about 10 retries.
3. For the hard cases, give the model more to work with. On complex files, the prompts grew to include up to 50 related files from the same project — sibling test files written in the right style, the source code of the component being tested, examples of well-written tests. Prompts ballooned to 40,000–100,000 tokens each.
4. Run the loop at industrial scale. Files ran in parallel, progress was tracked by automatically inserting a comment into each file recording its migration status, and engineers could re-run any specific step against any specific subset of files. After the first bulk run, 75% of files were done in four hours.
5. Chip away at the long tail. For the remaining 25%, the team ran a “sample, tune, sweep” loop: look at a handful of stuck files, figure out the common issue, update the prompts to fix it, re-run everything. Four days of this got them to 97%. The last 3% were fixed by hand.

The business math

Now the arithmetic. The original estimate was 1.5 years of engineering time. The actual cost was six weeks of engineering time plus the LLM API bill. Airbnb reports the total came in at a fraction of the original estimate. But a careful student should not just celebrate the headline number — they should think about what those six weeks of engineer time were spent on. Almost none of it was “writing tests.” It was building the pipeline, tuning the prompts, reviewing the failures, and fixing the last 3% by hand. The LLM did the typing. The engineers did the architecting.

11 Responsible AI at Airbnb

Every chapter in this course circles back to the same basic question: what happens when the algorithm is wrong, or right in a way the business didn’t intend? Airbnb’s version of this question is especially sharp because it touches three different constituencies — guests, hosts, and now the engineering organization itself.

On the guest side: geographic bias and the filter bubble

The destination recommender is trained on guests’ past bookings. If a user has only ever booked in Europe, the model will tend to recommend European destinations. That might be exactly what the user wants. But it might also narrow their world in ways neither they nor Airbnb would choose deliberately. A destination model that learns from past behavior will systematically underweight places where the user has never been — which is, by definition, where exploration would actually take them.

A subtler version of the same issue is geographic coverage. Airbnb reports that autosuggest drives the biggest booking gains in regions where English is not the primary language — which is great, but also tells you that the feature was helping users in non-English markets more than users in English-speaking ones. That might be equity; it might also mean the underlying dataset was tilted toward English-language markets in a way that made the baseline worse there. A responsible team monitors for both.

On the host side: whose margin is Smart Pricing optimizing?

There is a structural reason to ask this question. Airbnb’s revenue depends on completed bookings. Lower prices produce more bookings. A pricing algorithm that very slightly biases toward “lower” produces more bookings at every individual decision, produces more revenue for Airbnb, and produces slightly less revenue per night for each host. None of this requires bad faith from anyone. It just requires that the objective function the algorithm optimizes is aligned with the platform’s interests rather than the hosts’. Asking whose interests a suggestion serves is one of the most basic questions of responsible AI, and it’s a question hosts have a legitimate right to ask.

On the pricing side: price discrimination

Dynamic pricing at scale raises a broader question that airlines have been living with for decades: is charging different prices to different people for the same service fair? At Airbnb, two guests booking the same home for the same dates will generally see the same price — but prices move dramatically across dates, and hosts in certain neighborhoods may be nudged toward systematically different price curves than hosts in other neighborhoods. When the data reflects a city’s history, the algorithm can reflect that history too. A responsible pricing team monitors for this, particularly at the intersection of neighborhood demographics and dynamic pricing suggestions.

On the engineering side: the LLM’s code was correct, but was it right?

The test migration in §10 is a governance story in miniature. The engineers built validation into every stage — a test either passes or it doesn’t, a file either compiles or it doesn’t. That worked because the task had hard, objective correctness checks. Not every LLM deployment does. When a generative model is used to draft a customer email, summarize a legal document, or write code that will ship to production, the question “did it work?” becomes much harder to answer mechanically. The discipline Airbnb applied to this project — validation at every step, automated retries, human review of the long tail — should be the default assumption for how LLMs get deployed in serious business contexts. It is not how they are currently deployed in most companies.

12 Competitive Advantage: The Two-Sided Data Moat

Why can’t a competitor just copy all of this? Airbnb’s engineering team has published detailed descriptions of every system in this chapter. The models are not secret. The architectures are not proprietary. And yet the advantage compounds.

• Two-sided data, not one-sided. Hotels.com knows about rooms. Booking.com knows about commoditized supply. Social platforms know about users. Airbnb knows about both sides of a matching problem at once — millions of unique homes and hundreds of millions of guests interacting with them. Both streams of data feed every model in this chapter, and neither stream can be bought or shortcut by a competitor.
• Every interaction is training data for multiple systems. A single search session teaches the destination recommender about travel intent, the clustering algorithm about which homes compete for similar audiences, and Smart Pricing about how demand is evolving. The marginal cost of generating this compound signal is zero; it happens automatically, on every visit.
• Mature AI infrastructure makes new AI cheap to add. Part III of this chapter is only possible because Parts I and II already exist. Airbnb’s engineers knew how to build validation pipelines, monitor model behavior, and run tuning loops because they had been doing it with predictive models for a decade. A newcomer can buy an LLM subscription tomorrow; they cannot buy that decade of institutional learning.
• The flywheel runs in both directions. More guests make the destination recommender smarter, which converts better, which brings more hosts, who supply more listings, which attracts more guests. Competitors trying to break into either side face a cold-start problem of their own: they can’t serve guests well until they have hosts, and they can’t attract hosts until they have guests.

The moat is not the algorithm. It is the data, the infrastructure, the organizational learning, and the compounding feedback loop between two sides of a marketplace that reinforce each other. Everything else is copyable. That combination is not.

13 Summary Table & Discussion Questions

AI Factory model: Airbnb mapped

Key vocabulary introduced in this chapter

Discussion questions

These work well as written assignments or in-class discussion prompts. Questions 2, 3, and 7 tend to generate the most debate.

1. Two sides, one platform — advantage or risk? Is Airbnb’s decision to optimize for both sides of its marketplace simultaneously a competitive advantage or an ethical risk? Take a position and defend it using specific evidence from the destination recommender, Smart Pricing, or both.
2. Whose margin is Smart Pricing optimizing? When Smart Pricing suggests a lower price to a host during a quiet period, whose interests is that algorithm actually serving? Argue it through — is it the host’s, Airbnb’s, the guest’s, or some combination? Would a host-first version of the algorithm look different?
3. Who was underserved before the model? Airbnb’s destination recommender performs best in regions where English is not the primary language. What does that tell you about which users were underserved before the model existed — and what does it say about how Airbnb should measure the success of a recommender like this?
4. When is interpretability worth losing accuracy? Smart Pricing could have used pure ML and likely would have been somewhat more accurate than its hybrid approach. Instead, Airbnb chose a hybrid that gave up some raw accuracy in exchange for interpretability. Where is the line? Pick a business context where a manager should insist on interpretability even at a real cost to accuracy, and one where they shouldn’t.
5. Travel intent as text. Airbnb treats user actions as “tokens” the way a language model treats words. What are the risks of borrowing a framework designed for text and applying it to human travel intent? Where could this abstraction break — and what would the failure mode look like in the product?
6. 1.5 years to 6 weeks. Airbnb’s engineers originally estimated the test migration at 1.5 years of work. They finished it in 6 weeks with LLMs. What should managers conclude from that number — and what should they not conclude? Under what conditions would you generalize this result to other teams or other kinds of work, and when would you resist?
7. Filter bubble or personalization? The destination model learns from a user’s past bookings. A user who has only ever booked in Europe will see mostly European recommendations. Is the model personalizing correctly — or narrowing the user’s world? Argue both sides.

MIS 432 · AI in Business · Case Study · For classroom discussion purposes.