There is an uncomfortable conversation happening in engineering leadership circles right now, and most organizations are not having it openly enough. It goes roughly like this: we have deployed AI coding assistants across the team, commit velocity has increased, lines of code per engineer are up, pull request volume has climbed, and yet something feels off. The engineers who seem most thoughtful about what they are building are not necessarily the ones driving those metrics. Meanwhile, some of the most active committers are shipping code that requires repeated revision, creates architectural debt, or solves problems that did not need solving in the first place.

This is not a new tension. Engineering leadership has always struggled with the difference between activity and output, and between output and value. But AI coding tools have compressed that struggle into a much sharper and more immediate form. When a tool can generate a working implementation in minutes, the act of writing code stops being the bottleneck. And when writing code stops being the bottleneck, the metrics we built around code production start telling us less and less about who our best engineers actually are.

The question this creates for engineering organizations is genuinely difficult: if AI can generate code, review code, write tests, explain APIs, and implement features, how do you know who your best engineers are? How do you evaluate performance fairly? How do you avoid accidentally rewarding the wrong behaviors at exactly the moment when getting this right matters most?

This article is an attempt to think through that question seriously.

How We Ended Up Measuring What Is Easy to Count

Before examining what metrics should look like in an AI-assisted world, it is worth understanding why the current ones exist and why they became so entrenched.

Most engineers, when they think about travel technology, imagine a flight search engine. You pick a source, a destination, a date, and the system returns a list of flights sorted by price. That is a solved problem. The hard part is what comes after.

A vacation planning platform is an entirely different beast. When a user opens MakeMyTrip and says “plan me a 7-day trip to Rajasthan,” the system has to figure out which cities to include, which attractions to prioritize, how to sequence the days so a traveler is not criss-crossing the map inefficiently, when flights are cheapest, which hotels have availability near the right areas, what local tours are available on which days, how to get from the airport to the hotel, how to price all of this as a coherent bundle, and then orchestrate bookings across a dozen different vendors without any single failure unraveling the whole thing.

That is not a search problem. That is a large-scale optimization problem sitting on top of a distributed marketplace, layered with personalization, real-time inventory, and multi-vendor payment reconciliation.

The evolution from “book a flight” to “plan my vacation” happened because travelers stopped wanting to assemble trips themselves. Researching destinations takes hours. Cross-referencing hotel availability with flight times is tedious. Figuring out which Jaisalmer fort tours run on which days requires visiting five different websites. A modern travel planner absorbs all of that complexity and surfaces a coherent, personalized plan.

BookMyShow looks simple from the outside. You open the app, pick a movie, choose your seats, pay, and get a ticket. The whole thing takes about two minutes. But underneath that simple experience is one of the most technically demanding systems on the internet — a platform that needs to handle millions of concurrent users, prevent duplicate seat bookings, coordinate with thousands of theatres, process payments reliably, and generate tickets instantly, all without ever letting two people land on the same seat.

This is not a generic booking tutorial. This is an engineering walkthrough of how a production-scale ticketing platform actually works.

Why Ticket Booking Is Harder Than It Looks

Most engineers underestimate ticket booking systems. At first glance it seems like a basic CRUD application — read seats, mark one as taken, take payment. But that mental model breaks down immediately under real-world conditions.

Think about what happens when a blockbuster like a new Avengers film drops its tickets at midnight, or when IPL finals seats go live, or when a Taylor Swift concert in Mumbai opens for booking. In those moments, hundreds of thousands of users simultaneously hit the same endpoint, trying to grab the same finite set of seats. You are not dealing with a typical web workload anymore. You are dealing with a flash sale, and flash sales expose every weakness in your architecture.

IndiGo is India’s largest airline by market share, operating hundreds of flights daily across domestic and international routes. If you’ve ever booked a flight on goindigo.in or the IndiGo app, you interacted with one of the most sophisticated transactional systems in the country — a system that has to handle millions of searches, coordinate real-time inventory across thousands of flights, process payments securely, and issue legally valid tickets, all within a few seconds.

Airline reservation systems are not just booking systems. They are distributed systems problems at scale, with real money, real people, and legally binding contracts involved. A failed payment that results in a confirmed seat is a liability. A double-booked seat is a disaster. A slow search experience sends users to a competitor. The stakes are incredibly high.

What makes airline booking particularly hard compared to, say, an e-commerce system? In e-commerce, you can slightly oversell and manage the backorder. In airline booking, there is no backorder. If seat 14A on flight 6E-205 departing Mumbai at 8:30 AM is sold, it is sold. You cannot manufacture another 14A. Inventory is finite, time-bounded, and irreplaceable.

There is a common belief in software engineering circles that relational databases cannot scale. The moment you say “MySQL” in a room full of distributed systems engineers, someone will inevitably raise an eyebrow and say “that won’t hold up at scale.” YouTube’s story is one of the most powerful counterarguments to that assumption. At the time of its acquisition by Google in 2006, YouTube was already one of the fastest-growing websites on the internet. And it was running on MySQL.

Understanding how YouTube built and scaled its database infrastructure is not just a historical curiosity. It is a practical masterclass in how thoughtful engineers take ordinary tools and stretch them far beyond what anyone thought possible. The lessons here apply directly to the systems you are building today.

The Scale of the Problem

Let’s ground this with numbers. YouTube launched in 2005. Within six months it was serving more than two million video views per day. By 2006, that number had climbed to over 100 million views per day. Google acquired it for $1.65 billion in October of that year. By 2012, more than 72 hours of video were being uploaded every minute. Today that number exceeds 500 hours per minute.