# Expedia Stories from the Expedia Group Technology teams - Medium This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## The Context Tax of Agentic Development DevFeed: [The Context Tax of Agentic Development]() Original publisher: [Read original article]() Author: A Talhan Published: 2026-08-25T11:01:02Z Content type: opinion Language: en Sources: [Expedia]() Topics: [Agentic development](), [Development](), [networking](), [data]() Tags: [agentic](), [agentic-ai](), [agentic-development](), [agents](), [context](), [context-engineering](), [development](), [engineering-management](), [networking](), [software-engineering](), [teamwork]() ### AI overview An Expedia Group engineering team describes how hidden context can cause agentic development to accelerate technically plausible work aimed at the wrong system. Using AI Workbench's multi-environment model handling as an example, the article argues that context must be explicit and structured so humans and agents share the same understanding. ### Source excerpt Expedia Group Technology -- EngineeringMissing context used to slow a team down, with agents in the loop it speeds up the wrong work insteadPhoto by Harley-Davidson on Unsplash When we started using agents more seriously inside the team, the first bottleneck was not code generation -- It was context coordination. That sounds like a documentation problem, but it did not feel like one. It felt like a delivery problem. A human engineer who is missing context usually slows down. They ask someone, search through old notes, or wait for the next sync. An agent does not always slow down. It can keep moving and produce work that is technically plausible, well formatted, and aimed at the wrong reality. That is the agentic velocity trap: unclear context does not just delay work; it can accelerate the wrong work. Rick Fast recently wrote about the broader Expedia Group™ platform shift toward agent-friendly interfaces and operating surfaces. This is the ground-level version from one team: what did we have to change in our own planning loop so humans and agents could work from the same understanding? The problem was hidden context One of the clearest examples came from multi-environment handling in AI Workbench (our web console for machine learning (ML) artifacts and workload management). From the outside, an AI Workbench URL appeared to represent one backend environment. Under the hood, it was backed by another. A team saw their model in the UI, reasonably assumed it existed in the environment implied by the URL, and then hit "model not found" when downstream jobs queried that expected backend. Internally, the concrete case was a machine learning scientist team onboarding a model. It appeared in the .prodA AI Workbench URL, but that deployment was serving model registry prodB data rather than model registry prodA data. The platform services were not simply broken. The hidden semantic mapping was because of networking and access nuances. That distinction matters. A human team lost ## How Keras 3 Helped Modernise Expedia Group's Lodging Ranking Stack DevFeed: [How Keras 3 Helped Modernise Expedia Group's Lodging Ranking Stack]() Original publisher: [Read original article]() Author: Conor Worthington Published: 2026-08-11T11:01:02Z Content type: article Language: en Sources: [Expedia]() Topics: [Keras](), [recommendation systems](), [Latency](), [Inference Performance](), [Machine learning]() Tags: [data-science](), [features](), [framework](), [improvements](), [inference](), [keras](), [latency](), [llms](), [machine-learning](), [mixture-of-experts](), [model-training](), [neural-networks](), [ranking](), [recommendation-system]() ### AI overview Expedia Group describes modernising its lodging-ranking stack around Keras 3. The changes included rewriting parts of its pipelines, making model training 30% faster and reducing P99 inference latency by two-thirds. The article discusses limitations of the previous Keras 2, eager-training and combined-serving setup, along with the use of newer APIs and accelerator-oriented optimisations. ### Source excerpt Expedia Group Technology -- DataWhat happened when we treated a framework migration as an architecture modernisation -- and cut P99 inference latency by two-thirdsSt Paul's and millennium bridge, London Expedia Group™ has always been a market leader in providing personalised search experiences for travellers. As our ranking models evolved, we saw an opportunity not just to migrate to Keras 3, but to modernise the broader stack around it so we can better serve travellers. This led us to rewrite key parts of our pipelines that made model training 30% faster and cut P99 inference latency by two-thirds. Our main focus in this blog is to discuss our improvements to lodging ranking -- our service which handles users' search requests and returns a personalised property ranking on top of a lightweight candidate generator. This service is frequently retrained to improve customer experience as we get new signals over time. Example of personalised lodging ranking on Expedia search result page for a London search As such, our velocity to make changes needs to be fast, but more importantly we need to be able to build models which are state-of-the-art, enabling customers to easily find and book the most relevant property for their trip. The problem with Keras 2, eager training and combined serving The challenge was not that the old stack was broken. It was that it had gradually become a limiting factor. On the training side, we were carrying dependencies on older components and missing out on modern Keras APIs, new optimisers, new layers and cleaner support for accelerator-oriented training. On the serving side, we had a path that was simple and operationally familiar, but not especially well suited to aggressively optimised inference for heavier ranking architectures. This blockage on utilising new layers and optimisers has become more pronounced as LLMs see blistering amounts of innovation. Naturally, these new features are only available in Keras 3 or as separate backends from ou ## Focus on the Feature, Not the Fixture: GenAI powered GraphQL mocks DevFeed: [Focus on the Feature, Not the Fixture: GenAI powered GraphQL mocks]() Original publisher: [Read original article]() Author: Samuel Vazquez Published: 2026-07-31T11:01:02Z Content type: article Language: en Sources: [Expedia]() Topics: [GraphQL](), [genai](), [Large Language Model](), [API](), [Command-line interface]() Tags: [ai](), [api](), [artificial-intelligence](), [cli](), [developer](), [genai](), [graphql](), [llm](), [rust](), [schema](), [software-engineering](), [tools]() ### AI overview The article presents mockql-rs, a CLI that combines a GraphQL schema, query annotations, hints, and an LLM to generate contextual mock responses. It argues that GraphQL constrains the response shape while the LLM fills only annotated fields, reducing handwritten fixtures and allowing real and mocked fields to coexist. ### Source excerpt Expedia Group Technology -- EngineeringCombine a GraphQL schema, hints and a LLM to generate contextual GraphQL mock responsesPhoto by Samuel Vazquez somewhere in New Zealand A product developer on our navigation header team spent an afternoon hand-typing a 200-line GraphQL JSON mock response so they could keep building the UI while a resolver was pending to be implemented. The schema changed the next morning. We threw the mock away. That is the boring tax on every GraphQL prototype: mocks that drift, fixtures that rot, frontends blocked on backends, and demos slipping because nobody wanted to update the same mock data again. Mock data is just data. It should not be the most expensive part of trying an idea. GenAI + GraphQL: a match made in heaven Most tools that promise "AI generates an API" share the same flaw: the model invents a shape from scratch, and you spend the afternoon reshaping its output to match your actual types. GraphQL flips that. The selection set is the spec. The schema is the type system. Hand an LLM a query and it already knows the exact JSON it must return, field by field, type by type. That's the unlock: LLMs are bad at inventing shapes and great at filling them in, and GraphQL hands them a bounded shape for free. mockql-rs is what happens when you take that pairing seriously: mark what you want mocked directly in the query with a "@mock" directive: query LoyaltyRewards @mock { loyaltyRewards { heading @mock(hint: "Platinum member") { text } subtitles @mock(hint: "At least 4 items") { text theme } } } Annotate the field, add a hint, keep building. mockql-rs parses the operation, validates it against the schema, and prompts an LLM to fill in only the fields you annotated with "@mock". { "data": { "loyaltyRewards": { "heading": { "text": "Welcome back, Platinum Member" }, "subtitles": [ { "text": "2,450 points until your next reward", "theme": "HIGHLIGHT" }, { "text": "3 nights earned this quarter", "theme": "STANDARD" }, { "text": "Breakfast inc ## How Expedia Group Builds AI That Lasts at Scale DevFeed: [How Expedia Group Builds AI That Lasts at Scale]() Original publisher: [Read original article]() Author: Xavier Amatriain Published: 2026-07-14T11:01:01Z Content type: opinion Language: en Sources: [Expedia]() Topics: [Artificial Intelligence](), [AI Strategy](), [AI Development](), [Development](), [sdlc](), [Monitoring]() Tags: [agentic-ai](), [ai](), [data](), [evaluation](), [generative](), [governance](), [innovation](), [machine-learning](), [monitoring](), [recommendations](), [sdlc](), [software-engineering](), [tooling](), [use-cases]() ### AI overview Expedia Group describes a framework for building, deploying, and evolving AI systems that remain reliable and scalable over time. The article emphasizes principles covering business value, ownership, governance, evaluation, safe rollout, and monitoring, and describes Agentic Release tollgates that translate those principles into launch checks integrated with the SDLC. ### Source excerpt Expedia Group Technology -- InnovationA framework for how we build, deploy, and evolve AI systems for impact and scalePhoto by Florian Wehde on Unsplash There's an important distinction between Artificial Intelligence (AI) that just works today and AI that lasts at scale. Many companies optimize hard for the first one without ever asking whether they're building the second. Velocity without discipline and strategic direction is a liability, not an asset. The hardest part of building AI at scale isn't getting a model to work once. It's building systems that continue to work, scale beyond individual teams and use cases, and improve consistently over time. Today's AI systems do more than just predict and optimize. They converse, reason, and increasingly take action. An autonomous system making decisions on a traveler's behalf creates a very different set of expectations around reliability, governance, and accountability. As AI takes on more of those roles, the principles behind how these systems operate matter more than ever. At Expedia Group™, we have spent years applying AI and machine learning across the traveler journey from personalization, ranking, and recommendations, to fraud prevention, customer support, and, more recently, generative and agentic AI experiences. That depth of experience is what led us to develop a set of machine learning and AI principles to guide how we build, deploy, and evolve AI systems across the company. The goal is simple: make sure the systems we build create real business value, scale across the company, and operate safely. These principles define how we measure, design, govern, and operate the systems we use. From principles to practice Publishing principles is the easy part. The harder and more important work is turning them into operating mechanisms: recommendations, requirements, tooling, and release processes that teams actually use. At Expedia Group, we have started doing this through Agentic Release tollgates: a set of recommend ## Using LLMs to Analyze Spark SQL Plans: A Practical Approach to Debugging Long-Running Jobs DevFeed: [Using LLMs to Analyze Spark SQL Plans: A Practical Approach to Debugging Long-Running Jobs]() Original publisher: [Read original article]() Author: Sagibhuvana Published: 2026-06-30T11:01:01Z Content type: article Language: en Sources: [Expedia]() Topics: [Apache Spark](), [Large Language Model](), [debugging](), [Optimization](), [MCP]() Tags: [apache-spark](), [big-data](), [data-engineering](), [debugging](), [innovation](), [llm](), [llms](), [mcp](), [mcp-server](), [optimization](), [spark]() ### AI overview This article describes an automated workflow that uses large language models to analyze Spark SQL physical plans, identify performance anti-patterns, and suggest fixes for long-running jobs. It uses an open-source Spark MCP server to provide SQL execution metadata, plans, stage and task metrics, shuffle, spill, and I/O statistics. ### Source excerpt Expedia Group Technology -- InnovationUsing large language models to reveal bottlenecks in Spark SQL execution plansPhoto by Luis del Río If you've ever stared at a 300-plus-node physical plan at 2 a.m. trying to spot a missing broadcast or one cursed skewed partition, this is for you. Spark makes it deceptively easy to write complex SQL that looks correct but quietly turns into a performance and cost problem at scale. A query that runs fine on day one can slow to a crawl as data grows, joins get wider, and aggregations become more nested. Suddenly, jobs take hours instead of minutes, clusters need to be over-provisioned, and costs climb with no clear explanation. When things go wrong, the situation gets worse. Debugging Spark SQL often means wading through deeply nested physical plans, fragmented UI metrics, and stage-level statistics that don't clearly point to the root cause. Engineers are left guessing whether the issue is a bad join strategy, skewed data, excessive shuffling, or memory pressure -- turning optimization into a time-consuming, trial-and-error exercise. So we built an automated, LLM-powered workflow that reads Spark SQL plans, flags performance anti-patterns, and suggests concrete fixes. Here's why we built it, how it works, and what we learned after running it on real workloads. Why we even needed this Across teams we kept bumping into the same pain points: Slow or failing jobs that needed deep Spark expertise to debug SQL that didn't behave the way people assumed Skew, spills, or partition issues hiding beneath the surface Tuning efforts that were reactive and inconsistent At some point, the obvious question came up: Can an LLM look at a Spark SQL plan and tell you what's likely to go wrong -- where cost will spike, where execution will drag, and where seemingly harmless SQL hides real operational risk? Turns out: yes How we approached it1. Bring in real context with the Spark MCP server We used an open-source Spark MCP server that exposes: SQL exec ## The Most Expensive Milliseconds Are Unmeasured DevFeed: [The Most Expensive Milliseconds Are Unmeasured]() Original publisher: [Read original article]() Author: Divya Gupta Arora Published: 2026-06-03T17:11:58Z Content type: article Language: en Sources: [Expedia]() Topics: [Mobile](), [render](), [ui]() Tags: [case-study](), [devops](), [engineering](), [login](), [mobile](), [mobile-apps](), [mobile-performance](), [observability](), [performance](), [release](), [software-engineering](), [technology-investments](), [time-to-interactive](), [ui](), [visibility]() ### AI overview This Expedia Group engineering case study describes extending Native Time to Interactive across mobile login screens. The metric was used to evaluate technology investments, compare platform behavior, and detect performance regressions that existing system-health signals did not reveal. ### Source excerpt Expedia Group Technology -- EngineeringHow a screen-level performance metric reshaped platform decisions, engineering ownership, and release disciplinePhoto by Pietro De Grandi on Unsplash For the last few years, my responsibility has been straightforward to state but hard to execute -- owning the traveler login experience across mobile platforms. Not just whether a feature works, but whether it feels responsive, predictable, and trustworthy in the moments that matter most. During login, those moments are unforgiving: if a login screen hesitates travelers don't interpret it as 'a slow render', they interpret it as risk. And when the majority of travelers interact through our mobile apps, performance stops being a technical concern and becomes a product promise. This post is a case study of how, within Expedia Group™'s login domain, we extended Native Time to Interactive (NTTI) across login screens -- moving performance from a late-stage check to a first-class signal we can use to validate technology investments, compare platform behavior, and prevent silent regressions as we ship. The Problem: Mobile reliability rarely fails loudly Mobile performance rarely breaks with a crash. It usually degrades quietly, a button takes a beat longer to respond a screen looks ready, but taps don't register the UI stutters just enough to feel "off" Those are the expensive milliseconds -- because they erode trust without triggering obvious alarms. In our login flows, we were shipping consistently, evolving a major part of our stack, and supporting increasing product complexity. Yet we didn't have a consistent way to answer the user's real question -- "When can I actually use this screen?" Why our existing signals failed We were not blind. We tracked many useful things, crashes and ANRs backend latency and service SLIs some component-level timing signals limited Time to Interactive tracking on onboarding and initial login But we had a gap -- we had visibility into system health, not screen ## AI and the Build-versus-Buy Decision in Platform Engineering DevFeed: [AI and the Build-versus-Buy Decision in Platform Engineering]() Original publisher: [Read original article]() Author: Rick Fast Published: 2026-05-05T11:01:02Z Content type: opinion Language: en Sources: [Expedia]() Topics: [Platform Engineering](), [agentic-coding](), [Artificial Intelligence](), [Software as a service]() Tags: [agentic-coding](), [ai](), [artificial-intelligence](), [developer-tools](), [engineering-leadership](), [platform](), [platform-engineering](), [saas](), [scale](), [software-engineering]() ### AI overview This commentary examines how agentic coding tools and AI-native workflows have changed the economics of building software for platform engineering teams. It argues that lower initial build costs do not eliminate the ongoing costs of ownership, including maintenance, compliance, operational tooling, UX work, and long-tail requirements. The article supports selectively replacing low-value, undifferentiated SaaS products while maintaining discipline about build-versus-buy decisions. ### Source excerpt Expedia Group Technology -- PlatformHow AI changed the build vs. buy equation, and why discipline matters more than everPhoto by Ali Kazal on Unsplash Agentic coding tools and AI-native workflows have changed what's possible for platform engineering teams. I lead Platform Engineering at Expedia Group™, one of the world's largest travel technology companies. We power brands like Expedia®, Hotels.com®, Vrbo®, Orbitz®, and Travelocity®. My organization builds the technology that all of these brands and their partners run on: APIs, data and AI services, developer tools, CI/CD infrastructure, and the shared capabilities that let thousands of engineers ship reliably at scale. For many greenfield problems, it now feels like we can build almost anything from scratch with a fraction of the effort it used to take. But that creates a harder question: just because we can build it, should we? The temptation is real When you lead a platform organization and your engineers suddenly have access to powerful agentic coding assistants, the possibilities open up fast. It's tempting to look at SaaS products your company is paying for and think, "We could build that in a weekend." And honestly? In many cases, you probably could stand something up quickly. The initial build cost has dropped through the floor. But building something and owning something are very different decisions. That's where the new calculus gets interesting. The hidden cost of owning software Vendors aren't just shipping features. They're maintaining the software, fixing bugs and edge cases you haven't thought about yet, and improving the UX across thousands of customers with different requirements. Mature platforms have decades of accumulated work behind them: production hardening, compliance, operational tooling, and long-tail requirements you'd only discover slowly through real-world use. You can't clone that maturity quickly, even if the initial build feels cheap thanks to AI. The build side of the equation has cha ## Expedia's Service Telemetry Analyzer DevFeed: [Expedia's Service Telemetry Analyzer]() Original publisher: [Read original article]() Author: Nikos Katirtzis Published: 2026-04-28T11:01:01Z Content type: article Language: en Sources: [Expedia]() Topics: [telemetry](), [distributed-systems](), [Prompt Engineering](), [Artificial Intelligence](), [API](), [Cloud](), [Containers](), [Orchestration]() Tags: [ai](), [api](), [distributed-systems](), [generative-ai-tools](), [metric](), [observability](), [prompt-engineering](), [root-cause-analysis](), [site-reliability-engineer](), [software-engineering](), [telemetry]() ### AI overview Expedia's Service Telemetry Analyzer (STAR) is an early web-based system for investigating service degradations and outages with service telemetry data and AI models. It uses predefined multi-step diagnostic workflows, domain-specific prompt engineering, and engineering knowledge spanning applications, infrastructure, cloud, containers, orchestration, and distributed systems. ### Source excerpt Expedia Group Technology -- EngineeringA system that facilitates investigation of service degradations and outages using service telemetry data and AIPhoto by Evangelos Mpikakis on Unsplash. The recent advancements in the artificial intelligence space make us re-evaluate how work is done. From programming, to designing systems, or even operating them in production. While there is considerable focus on automating programming, one area which could undergo transformation is how we monitor and operate our systems and services. A few of us came together and designed Expedia's® Service Telemetry Analyzer (STAR), an early iteration of a system that facilitates investigation of service degradations and outages using service telemetry data and AI models and techniques. Expedia's Service Telemetry Analyzer (STAR) The early product offering includes: Execution of multi-step workflows. Integration of software and systems engineering knowledge, including application and infrastructure, cloud, containerization, and orchestration patterns, into diagnostic workflows for complex distributed systems. Application of domain-specific prompt engineering for metric and root cause analysis. Utilization of advanced off-the-shelf AI models. Implementation of prompt engineering techniques, including role prompting, prompt chaining, and generated knowledge prompting. Design The product offering is a web-based service that provides an application programming interface (API). While AI agents and chatbots are gaining traction, we aimed to start with something a) simple, b) precise (to a certain extent, considering the potential hallucinations of the models), and c) that avoids the additional and currently less understood failure modes of an agent. As this field evolves, we will continue to iterate on the design. Therefore, there is limited context engineering beyond domain-specific prompts; for instance, there is no support for function calling / tool use, short-term and long-term memory, or retri ## Reimagining Platform Engineering for an Agentic Future DevFeed: [Reimagining Platform Engineering for an Agentic Future]() Original publisher: [Read original article]() Author: Rick Fast Published: 2026-04-07T12:50:31Z Content type: opinion Language: en Sources: [Expedia]() Topics: [Platform Engineering](), [agentic-coding](), [Developer experience](), [Artificial Intelligence](), [coding](), [Hackathon]() Tags: [agentic-coding](), [agents](), [ai](), [ai-agent](), [architecture](), [developer-experience](), [expedia-group-tech](), [hackathon](), [interfaces](), [mental-models](), [platform](), [platform-engineering](), [software-engineering]() ### AI overview An Expedia Group Platform Engineering leader discusses how agentic coding is changing engineering work and what large-scale platforms need to support human and agent users. The article describes shifting human focus toward product thinking, architecture, system design, and context, along with a hackathon experiment intended to encourage exploration of agentic tools. ### Source excerpt Expedia Group Technology -- EngineeringWhen your platform's next user isn't humanPhoto by Alex Vasey on Unsplash Earlier this month I hosted a town hall for Expedia Group™ Platform Engineering organization, focused on the rapid progress happening in the agentic coding space, and what it means for us as engineers and as a platform team. Our teams are responsible for the horizontal foundations that power Expedia Group: AI and analytics, data, user experience platforms, edge and API platforms, cloud and infrastructure, as well as EG's developer experience. In other words, we own the "platform of platforms" that thousands of engineers build on every day. Since late last year, with the arrival of models like Opus and modern deep agent harnesses, we've been riding a pretty intense wave of change. Larger context windows and more capable agents have made several things clear. A huge amount of what we call "engineering work" can now be done by agents. The real leverage for humans is shifting toward product thinking, architecture, system design, and context. Our platforms, which were designed for humans, are not yet ready to support agents as a distinct user group. This post is about what it means to run a large-scale platform organization in that world, and how we're retooling our stack, our interfaces, and even our mental models to support both humans and agents at the same time. The change curve for senior engineers For many engineers, especially those who've been in the industry for decades, this isn't just a new toolchain; it's a new inner loop. We're asking people to delegate more of the "typing" to agents, spend more time on what we're building and how it fits into the larger system, and learn how to collaborate with agents as teammates, not just as autocomplete. That would be hard enough in a greenfield startup. In a company that runs a large chunk of the online travel ecosystem, it's even harder. We still must keep the planes in the air: keep sites up, pipelines flowi ## Operating Trino at Scale With Trino Gateway DevFeed: [Operating Trino at Scale With Trino Gateway]() Original publisher: [Read original article]() Author: Prakhar Sapre Published: 2026-03-24T12:01:00Z Content type: article Language: en Sources: [Expedia]() Topics: [gateway](), [Load Balancing](), [Routing (disambiguation)](), [data analytics](), [Authentication](), [SQL]() Tags: [analytics](), [authentication](), [clusters](), [concurrency](), [data-science](), [downtime](), [gateway](), [load-balancer](), [load-balancing](), [open-source](), [sql](), [trino](), [trino-gateway](), [trinos]() ### AI overview This article explains how Trino Gateway routes queries across multiple Trino clusters and centralizes routing, authentication, load balancing, monitoring, and cluster management. It describes the project's origins as Presto Gateway at Lyft and its role in supporting larger analytics platforms with more complex workloads and higher concurrency. ### Source excerpt Expedia Group Technology -- DataWorkload-aware routing for TrinoPhoto by Joseph Barrientos on Unsplash Trino -- a fork of PrestoSQL -- is a powerful tool in modern data analytics, enabling organizations to query large datasets quickly and efficiently. As a distributed SQL query engine, Trino provides fast, scalable insights without requiring data relocation. While Trino is robust on its own, its capabilities are further enhanced when paired with a Gateway, which introduces features such as query routing, strong security, and streamlined cluster management. A brief overview The Gateway project originated at Lyft as Presto Gateway, serving as a proxy and load balancer for PrestoDB. It was later forked and integrated into the Trino ecosystem, with contributions from various organizations and the open-source community. The Gateway serves as a central point for managing and routing queries, providing a unified interface for users and administrators. As organizations scale their analytics platforms, they often encounter challenges such as increased query complexity, higher concurrency, and the need for specialized cluster configurations. Directing users to specific cluster endpoints becomes impractical as the user base grows. A Gateway addresses these challenges by routing queries to the most appropriate clusters based on workload, improving efficiency and responsiveness. The Gateway acts as a vital intermediary between users and the Trino query engine. By abstracting the complexities of distributed query execution, it manages critical functions such as routing, authentication, and load balancing across diverse backend clusters. This ensures that queries are efficiently directed to the optimal processing cluster. With an intuitive user interface, the Gateway transforms what was once a convoluted process into a manageable and transparent experience empowering administrators with real-time insights and precise control over their backend cluster infrastructure. Whether it's mon