Ask a random person on the street to name an AI company, and nine out of ten will say ChatGPT. Maybe a couple will mention Google or Midjourney if they are feeling adventurous. That’s it. That’s the whole list in most people’s heads.

Source: AI

And honestly, it makes sense. ChatGPT is the thing people touch. It’s the front door. It’s the interface that shows up on your phone, answers your questions, writes your emails, and occasionally makes up facts with total confidence. So of course it becomes the face of an entire industry.

But here’s the thing nobody tells you: ChatGPT, and every other consumer AI product like it, is standing on top of a much bigger structure. It’s the tip of an iceberg, and most people never look below the waterline. If you actually want to understand who controls AI, who profits from it, and who will still be standing when the current hype cycle cools down, you need to look at three very different layers of this industry, not just one.

Over 90% of developers at some companies are using AI coding assistants. GitHub says AI now writes nearly half of all new code on its platform. Gartner thinks that number hits 60% by end of 2026. By every measure, we’ve crossed the point where AI in software development is optional.

And yet, if you talk honestly with engineering leaders, there’s a quiet unease underneath the adoption numbers. Something feels off.

Source: AI

Let me tell you what the data actually says, and more importantly, what it means for how you should be running your teams. The data in this article are taken from the websites and research paper published and I have obviously used AI tools to fetch those.

The productivity story is real, but it’s smaller than the headlines suggest

The task-level numbers are genuinely impressive. GitHub’s own studies showed developers completing coding tasks up to 55% faster with Copilot. PR cycle times dropping from 9.6 days to 2.4 days. Developers saving 3–4 hours a week on boilerplate, documentation, and the kind of low-brainpower code that used to eat your mornings.

That part is real. I’m not here to dismiss it.

If you have ever used a cashback platform and wondered how the money actually flows from a merchant back to your wallet, you are not alone. Most users think of it as a simple discount. You click a link, buy something, and money appears in your account a few weeks later. But beneath that simple experience is a surprisingly intricate distributed system that touches affiliate networks, fraud detection, financial ledgers, event pipelines, and real-time attribution engines.

CashKaro is one of India’s largest cashback and rewards platforms. It operates as a bridge between users who want to save money and merchants who want to acquire customers. Every time a user makes a purchase through CashKaro, a chain of events fires across multiple systems, involving third-party affiliate networks, internal computation engines, wallet services, and eventually a payment processor. Building and scaling that chain reliably is a serious engineering challenge.

This blog walks through the complete system design of a platform like CashKaro. We will go from first principles all the way to distributed systems concerns, and we will stop at every layer to explain not just what the system does but why it is built that way.

Why Cashback Platforms Are More Complex Than They Look

Cashback is fundamentally different from a discount. A discount reduces the price at the point of sale. Cashback is a post-purchase reward paid from the merchant’s commission budget, routed through an affiliate network, validated against a return window, and then credited to a user’s wallet after a delay of days or even weeks.

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.