What if you had an AI assistant for the F1 rulebook?

This weekend, during Formula 1 free practice, Lewis Hamilton crashed and his front wing got stuck underneath the car. From the cockpit, he had no idea what happened. His team could see it and started warning him to stop. Within seconds, the commentator was already looking up the relevant regulations to understand what this meant for the rules. That moment stuck with me.

Try it out here: FIA Rules Assistant

I've watched F1 long enough to know that moments like this happen all the time — some dramatic incident unfolds, and you're left wondering exactly what the rulebook says about it. What if I had the full FIA rulebook sitting right in front of me, with an AI assistant that could actually help me find and understand the exact wording of the regulations, not just what commentators think it says? That seemed worth building.

So I gave myself a weekend goal: get a working RAG pipeline running publicly on AWS, put an interface in front of it, and see if people actually use it. Not perfect. Not a multi-agent masterpiece. Just end-to-end and functional.

When Cloud Means You Actually Have to Care About Everything

At work, there are teams, existing infrastructure, and security policies handling all the cloud complexity. This weekend project was different. I had to figure out IAM permissions, how services should talk to each other, where embeddings should live, which Bedrock models were available in my region, and how to make it all scale later. It was humbling.

The first big choice was embeddings. I could've kept things simple with local embeddings, but if the goal was a proper AWS pipeline, using Amazon Titan Embed Text through Bedrock made more sense. So I rebuilt the whole vector index around that. It meant more AWS dependency, but the production architecture became cleaner and more consistent — a trade-off worth making.

Then came compute. I didn't want to spin up an always-running EC2 instance just to power a chatbot. Lambda seemed obvious: pay only for what you use, and for a small app with sporadic traffic, that felt right. The FAISS index lives in S3 and loads when the Lambda fires up. Not perfect for scale, but perfect for a first version where simplicity wins.

Here's what the basic architecture ended up looking like:

Lambda cold starts are real, there are things I can't completely control about the runtime, and the FAISS approach obviously won't scale forever. But for a first version? It works.

ChatGPT, Some AWS Experience, and 12 Hours

I wanted to see how far I could get with ChatGPT instead of another coding subscription. It went further than I expected. ChatGPT generated a solid foundation for the RAG pipeline — ingestion, embeddings, retrieval, reranking, generation, Lambda wrapper, frontend, the whole thing. The real problems weren't about writing application logic. They were about connecting everything: finding the right AWS model identifiers, figuring out which Bedrock endpoints existed in my region, getting IAM right, making Lambda and API Gateway talk to each other, handling CORS, packaging it all in Docker. Once the basic code existed, I had ChatGPT walk me through AWS deployment step by step.

My previous cloud experience definitely helped. I wasn't learning from zero. But even so, it still took roughly 12 hours from that morning to having the first public version live. And honestly? Pretty fun weekend.

Then came launch day. I wanted to ship by 11 PM but got caught up in AI coding and deployment details. I skipped thorough retriever testing — assumed it would work since it did locally. When I pushed to cloud, it started timing out. What should have been 26 seconds per document retrieval was failing. Spent 3 hours debugging. Turned out my retriever code was tangled up trying to merge reranking and metadata filtering. Dropped both for this first release, got the latency down to 2 seconds, and shipped. They're coming back soon.

What's Actually Happening

Right now, this is a vanilla RAG system. A question comes in, the system finds relevant chunks from the FIA documents, reranks them, and the language model generates an answer grounded in those actual regulations — not guessing what it vaguely remembers. That matters when regulations are involved. You don't want confident-sounding nonsense. You want the rulebook.

The corpus is still small — regulations and International Sporting Code for now — but I'm building in metadata filtering for year, event, document type, session. That'll matter when I add race-specific material. You don't want a 2024 Abu Dhabi question competing with documents from 2020.

This Is Very Much a V1

There's no conversation history yet. No ReAct-style reasoning. No complex agents. But I actually wanted that. Better to have something that works, understand where it fails, and fix those pieces than build complexity too early.

I know ChatGPT, Claude, and other general-purpose assistants can already answer many F1 questions. That's not the differentiation I'm chasing. The real goal is making this genuinely F1-aware — connecting regulations with actual races, steward decisions, penalties, eventually race stats and telemetry. Long way to go, but the first step is live.

What's Next

I want to add a proper reasoning loop. Then improve retrieval before adding anything complicated. After that, imagine asking "Why was a driver penalized at race X?" The system could retrieve the steward's decision, identify which regulation it cited, go back and retrieve that exact provision, then return: what happened, what the stewards decided, which rule applied, what that rule says, and why it led to that decision. That's agentic RAG, not just chatbot stuff.

Try it out here: FIA Rules Assistant

It's independent and not affiliated with the FIA. But if you follow F1 and use it, I'd genuinely love to know what you'd want next.

10-Minute Agent !

 

What if AI agents could be delivered like groceries?

India has become fascinated with the idea of 10-minute delivery. Groceries, food, stationery, medicines, house help and a growing list of other services are being pushed toward the same promise: I need something now, and I don’t want to wait.

Some of these use cases are convenience plays; others, such as rapid ambulance or emergency-response services, can have a much more meaningful impact.

That got me thinking about a slightly crazy startup idea:

Why not a 10-Minute Agent?

I don’t mean that we magically build a sophisticated enterprise-grade agent from scratch in ten minutes. That would be a rather optimistic sales pitch! 😄

What I mean is: what if we could make the journey from “I need an AI capability” to “I have an AI capability deployed” dramatically faster and more configurable than it is today?

Think of it as an AI delivery network

Today, when a company wants to implement an AI solution, the journey can still be surprisingly long — requirements, architecture, model selection, POCs, data integration, security reviews, development, testing, deployment and plenty of back-and-forth.

The technology has become incredibly fast. The deployment process often hasn’t.

So imagine a different model. A customer comes to the platform and describes what they want to achieve. Instead of being handed one fixed “AI agent”, they get to configure the solution — choosing the model, data sources, capabilities and the trade-offs that matter to them.

OpenAI, Anthropic, an open-source model or their own? Documents, databases, APIs or a combination? Simple RAG, RAG + analytics, tools and workflows, or a more sophisticated agentic system? And then the inevitable trade-offs: cost vs performance, latency vs intelligence, managed vs self-hosted, simplicity vs flexibility.

In essence, the customer gets to configure their AI stack rather than buy a one-size-fits-all solution.

And this is where I find the idea particularly interesting. Instead of expecting the customer to figure out how to assemble and deploy all of this themselves, Forward Deployed Engineers become the delivery partners.

The platform takes the requirements and configuration, assembles the required components, and the FDE takes it the final mile — integrating systems, connecting data, handling customisation and edge cases, and getting the AI solution deployed.

In other words:

Maybe Dell had part of the answer

This is where an old idea came to mind. Years ago, Dell made PC buying interesting by letting customers configure their machine rather than forcing everyone into one fixed specification. You could choose the processor, memory, storage and other components based on what you actually needed.

What if enterprise AI worked the same way?

Instead of “Here is our AI agent. This is how we built it. Take it or leave it,” the experience could be: “Configure your AI.”

Choose the model, data, capabilities, infrastructure and the trade-offs you are willing to make — and let the platform recommend the right configuration.

For one business, that might simply be Vanilla RAG for answering questions over documents. For another, RAG + Analytics to combine unstructured documents with structured business data. Another might need RAG + Tools + Workflow to retrieve information, call APIs and execute defined processes. And for more complex problems, it could evolve into a fully agentic system capable of handling multi-step tasks.

The important part is that the customer doesn’t need to understand how every piece fits together. They describe the problem and the outcome; the platform translates that into the technical configuration, and the FDE turns it into a working solution.

That, to me, is where the Dell analogy gets interesting: don’t just sell the AI — let the customer configure it for what they actually need.

And this is where “10-Minute Agent” comes back

This is where I think the analogy with 10-minute delivery becomes even more interesting. A 10-minute delivery company doesn’t manufacture the grocery you ordered in ten minutes. The product already exists. What the company has really built is an infrastructure around selection, fulfilment and delivery that makes the entire experience incredibly fast.

Could AI deployment eventually work in a similar way?

The models already exist. OpenAI, Anthropic and a growing ecosystem of open-source models are already available. The databases and vector stores exist. The agent frameworks exist. Cloud infrastructure, APIs, observability and all the other building blocks required to put an AI system together are increasingly becoming commodities or readily available services.

So perhaps the challenge isn’t that we don’t have the ingredients.

Perhaps the challenge is getting the right ingredients together, in the right configuration, for the right business problem — quickly.

That is where the idea of a highly standardised configuration + orchestration + deployment layer becomes interesting. Instead of building every AI solution from scratch, the platform could bring together these existing components based on what the customer actually needs, apply the appropriate trade-offs, and create a deployable solution.

In that sense, perhaps the real product isn’t simply “an agent.”

The real product could be the AI delivery infrastructure that makes getting the right agent into a business as easy and eventually as fast as ordering something online.

And maybe that’s what “10-Minute Agent” really means.

Not necessarily an enterprise agent magically built from scratch in ten minutes — but an AI delivery system designed from the ground up to make that journey dramatically faster, more configurable and more repeatable.

Press enter or click to view image in full size

The FDE becomes the “delivery partner”

I also like the Forward Deployed Engineer part of this idea because it could fundamentally change both the economics and the operating model. If every customer requires a completely bespoke engineering team to build an AI solution from scratch, the business can very quickly start looking like a traditional consulting company — highly customised, highly people-dependent and difficult to scale.

But what if a large part of the architecture is already standardised, modular and configurable?

In that model, the FDE’s job becomes much more focused. They aren’t reinventing the entire solution for every customer. Instead, they take a pre-configured AI solution and make it work within the customer’s actual environment: connecting the systems, mapping the data, handling the inevitable edge cases, configuring authentication and permissions, adapting workflows, deploying the solution and helping the customer get it into production.

In some ways, they become the delivery partner for AI.

And there is another interesting possibility here. Every deployment can teach the platform something. The more customers you deploy for, the more integrations, patterns, reusable components, architectures and edge cases you accumulate. Over time, that knowledge can feed back into the platform, making the next deployment faster and requiring less bespoke engineering.

That is where the “10-minute” part starts becoming less of a marketing gimmick and more of a direction for the architecture.

If an AI deployment that takes months today can be standardised down to weeks, and then days, and then hours, perhaps some well-understood and highly repeatable use cases could eventually get down to minutes.

Maybe not every agent.

Maybe not every customer.

But perhaps enough of them to make “10-Minute Agent” a meaningful product philosophy.

Of course, there are some big problems

There is, of course, a rather large reality check here.

Enterprise AI isn’t quite the same as ordering a packet of biscuits in ten minutes. 😄 Data security, privacy, permissions, compliance, model quality, hallucinations, observability, cost management and integration complexity don’t disappear simply because we put a nice configurator in front of them.

Some deployments will always require substantial engineering. Some customers will need completely custom models, infrastructure or workflows. And some use cases will simply be too sensitive or too complex to automate in this way.

So I don’t think the objective should literally be “Every AI deployment takes 10 minutes.”

The more interesting objective might be:

“Make the default AI deployment experience feel as close to ordering something as possible.”

That is a very different proposition.

The ambition is not to pretend that enterprise AI is simple. It is to take everything that can be standardised, productised and automated — and make the remaining complexity as easy as possible for the customer and the FDE to handle.

So… a 10-Minute Agent company?

Maybe.

Maybe it is a terrible startup idea.

Maybe it is simply a fun thought experiment triggered by India’s obsession with 10-minute delivery. 😄

But the more I think about it, the more I wonder whether the next wave of AI businesses will be built not only around creating better models and smarter agents, but around making those models and agents dramatically easier to configure, deploy and customise for real businesses.

Because we already have most of the ingredients.

We have LLMs, RAG, databases, APIs, agent frameworks, cloud infrastructure and analytics. We also increasingly have Forward Deployed Engineers who can bridge the gap between the technology and the customer’s real-world environment.

What if we put a product layer on top of all of that?

A customer could come in with a business problem, choose the model and data sources they want, decide how sophisticated the solution needs to be, make the relevant cost-versus-performance trade-offs, and let the platform recommend and assemble the architecture.

Then the FDE takes over the last mile — integrating, customising and deploying it.

Choose what you need. Configure the trade-offs. Let the platform assemble the solution. Send the FDE to deliver it.

And eventually…

10-Minute Agent. 🚀

Just like 10-minute delivery didn’t really change what we buy — it changed how quickly we can get it — perhaps the opportunity in AI isn’t only to build more powerful agents.

Perhaps it is to build the delivery infrastructure for AI: the layer that lets businesses get the right agent, configured for their needs, integrated with their systems and running in production much faster than they can today.

From:

“We should build an AI agent.”

to:

“Your AI agent has been delivered.”

That, at least, sounds like a startup I would be curious to explore.

I keep coming back for one more knockout

Have failed so many times and frankly given up so many times that I don't even remember but will try to list few if possible. Thing is after all that and after literally feeling lost and exhausted I still come back - as in come back to try again. I just somehow do..

I won't say I am like Captain America - that I can do this all day or all along - truth is I assumed that one becomes stronger after every failure or they learn lessons but for me - each rejection had made it harder to stand again and to bring my hands up to defend - let along strike a blow.

After each rejection, each loss it has become harder to continue or try again. Especially when I don't see the reason of why should I do it or that what happens if I win at the end - I don't get the purpose of doing all this.

Running a marathon or finding a job or starting a start up or anything for that matter - I feel so lost and exhausted that I just don't want to get up and try again and most probably fail and get knocked out again.

At times it is like marathon - btw before that - I feel most of people they fail - fail and then make a come back for me things go good and then I fail and then hardly make a come back. First two times I lined up for full marathon I completed it and next two times I failed to complete - despite having experience and what not I just failed and keep failing.

So yeah - in those completed marathons I would have quit in my head like 100 times but somehow I would still continue and cross the line but in life now I feel just damn too difficult and worthless to do anything.

Things then go in cycle - since I don't feel life or energy and all in anything it makes me more dull and exhausted and then that further makes it difficult to pursue any goal and this circle just continues - like deep depression spiral and all.. Though this is bit different than depression -- I am just exhausted and don't see my North Star or don't have any goal to move towards..

It is just damn too difficult. Still I try in a hope that this too shall pass and my time may change or now also things may not be that bad but point is situation may change for more better stuff and I need to be ready and try my best - at snails pace to learn something new or try something different at work and what not..

Just for record wrote it and let us wait and watch what happens and how things shape up..

More on Shah Rukh Khan - Movie Similarities

Almost 6 years back I wrote --  Shah Rukh Khan - Then and Now where I highlighted the common themes Shah Rukh had across different movies or role that he played. Recently I found three more and decided to write another blog post on it - I tried to pull in images from the music videos and so they are not as sharp as earlier post..

1. The total white outfit

a. Kabhi Haan Kabhi Naa (1994) - song - Ae Kash k Hum . . .

b. Anjaam (1994) - song - Badi Mushkil Hai . . . 

In both the songs we see Shah Rukh in very similar full white attire.. Just released in the same year. In Kabhi haan kabhi naa song he wears the White suit only for a short clip where he is dreaming and all.. In Anjaam movie - entire song he is in the same outfit..

2. Dancing on Car (Roof)

a. Anjaam (1994) - song - Badi Mushkil Hai . . . 

b. Rab ne Bana DI Jodi (2008) - song - Haule Haule Ho Jayega Pyaar . . . 

c. Badshah(1999) - song - Main toh hun Pagal . . . 

In the first two songs he dances on car roof for substantial amount of time. Then third one is Badshah and for a brief moment and couldn't get a better picture. It is just I remembered that song and car and so included here for completeness.

3. Dancing with Cartoon Stars

a. Yes Boss (1997) - song -Chaand Tare Tod Lau . . . 

b. Pardesh (1997) - song - Yeh Dil Deewana . . . 

It Was Never About the Models

Seriously, if only model quality was preventing companies from transforming with AI, then the last couple of years should have been enough to change almost every organization. Every few months we got a better model. GPT-4, Gemini, Claude, Llama, reasoning models... the pace has been unbelievable. Yet when I look around, most organizations are still figuring out how to move beyond pilots and isolated use cases. They have a chatbot, maybe an internal copilot, some proof of concepts, but very few can confidently say AI has fundamentally changed the way they work. That makes me wonder... maybe it was never only about the models.

Now before someone jumps in, I am not saying models don't matter. They absolutely do. The leap we have seen in the last couple of years is remarkable and has unlocked possibilities that simply didn't exist before. But if the models have improved so much, why are so many organizations still struggling to create measurable business value? According to McKinsey's latest State of AI survey, AI adoption is widespread today, yet nearly two-thirds of organizations are still experimenting or running pilots, and only around 39% report measurable enterprise-level EBIT impact from AI. That statistic stayed with me because it tells me that getting access to a better model was only one part of the puzzle. The harder part was, and perhaps still is, everything around it.

For years we have spoken about data quality, governance, infrastructure, integration between systems, master data, data lakes, pipelines... frankly none of those topics were glamorous. If someone spoke about data governance five years back, not many people got excited. Today everyone wants Agentic AI, reasoning models and autonomous workflows, but if the underlying data is fragmented, scattered across SharePoint folders, PDFs, PowerPoint presentations and Excel sheets, then even the smartest model eventually runs into the same wall. In a way, GenAI didn't create these problems. It simply exposed them.

Another thing I have been noticing, and maybe it's just me, is that nowadays when we say AI, most of the conversations automatically become GenAI conversations. If someone says, "We are using AI," chances are they mean they have built a chatbot or some assistant. Go back five or six years and AI meant something very different. We were talking about anomaly detection, forecasting, recommendation systems, optimization, predictive maintenance, computer vision, classification, regression and dozens of other machine learning applications that quietly solved business problems. There wasn't this level of excitement around them, there weren't billions of dollars flowing into foundation models, and there definitely wasn't this fear of "If we don't do AI today we'll be left behind tomorrow."

Sometimes I wonder whether that narrative itself has changed enterprise priorities. Billions, perhaps even trillions if yu include the entire ecosystem, have been invested in developing and serving these large language models. Naturally, a very strong narrative has followed. Boards are asking about GenAI strategy, companies are hiring for Agentic AI, budgets are being allocated much faster than they ever were for traditional ML initiatives or even digital twins. None of this is necessarily bad. In fact, it has accelerated AI adoption more than anything we have seen before. But it also makes me think that organizations which quietly invested in data platforms, analytics and ML over the last ten or fifteen years are probably in a much better position today because GenAI is building on foundations they already created.

Think about coding for a minute. We see tremendous productivity gains there, and honestly I am not surprised. Code was always written for machines. It has syntax, structure, version control, tests, documentation and well-defined rules. LLMs naturally excel in that environment. Now think about enterprise knowledge. PPTs were created for people. Word documents were written for people. Excel sheets evolved over years with custom formatting and assumptions known only to the author. Meeting notes, PDFs, scanned reports, emails... these were never designed so that machines could understand them. We are now asking AI to reason over decades of human communication. Maybe expecting a better language model alone to solve that was optimistic from the beginning.

Okay... a lot of huff and puff. So where do I think organizations should actually start?

Personally, I feel the first layer should be a knowledge assistant. Not an autonomous agent that promises to do everything, but something much simpler and probably much more valuable. Help people find the right reports, engineering documents, standards, previous project learnings or design decisions from the company's own knowledge base. Especially all the unstructured information that nobody remembers exists. Let AI help people reach the right information in minutes instead of hours, but let humans still apply their judgement. I still believe judgement should stay with people.

The second layer, once yu are reasonably confident about your data maturity, is an analytics assistant. Imagine a finance organization where all mutual fund data, market data and risk metrics are already cleaned, governed and available. Instead of writing SQL queries or navigating ten different dashboards, analysts could simply ask questions, run scenarios, validate hypotheses or compare portfolios in natural language. AI isn't replacing analytics there. It is making analytics accessible to more people.

Coding... well there is already so much written about it that I don't think I have anything unique to add. 😄

On a personal level too, I still use these tools as assistants rather than replacements. If I have an important presentation coming up, I might ask an LLM to behave like my toughest stakeholder. "What questions would yu ask? Which assumptions am I have missed? Are there gaps in my argument?" That is a fantastic use case. Similarly, if I am building an assistant for battery charging systems, I will happily use an LLM to understand the overall process and clear some of my doubts. But if my goal is to become a battery expert, then I would still spend time with domain experts, read standards, understand the physics and learn from people who have spent years in that field. AI can definitely accelerate the journey, but I wouldn't outsource the journey itself.

Another interesting observation came from some of the recent industry reports. McKinsey's AI survey shows widespread adoption, but limited enterprise-scale impact in many organizations. BCG also talks about how the organizations creating the most value are not just deploying models but redesigning business processes around them. That actually resonated with me. Maybe we have spent the last two years asking questions like GPT or Gemini? Claude or Llama? Closed source or open source? Those are interesting discussions and they matter, but perhaps the more important enterprise questions today are much simpler.

Do we trust our data?

Can our systems actually talk to each other?

Can employees find the information they need without spending half a day searching?

Are we redesigning workflows, or simply adding another chatbot on top of an existing process?

Those questions don't sound as exciting as discussing the latest reasoning model, but I have a feeling they will decide who creates real business value over the next five years.

Maybe the title of this article isn't completely true after all.

It was about the models.

The progress has been phenomenal and there is no denying that.

But enterprise transformation was never only about the models. It has always been about the data, the engineering, the workflows and ultimately the people using them. Perhaps what GenAI really did was force all of us to finally look at those foundations again.

References

McKinsey – The State of AI

McKinsey – The State of AI: How Organizations Are Rewiring to Capture Value

BCG – Closing the AI Impact Gap

Doing the Right Thing

Doing the Right Thing - that is the final chapter of the book -- Designing Data-Intensive Applications - 2nd ed by Martin Kleppmann and Chris Riccomini and boy am I hooked !
I actually jumped straight to the last chapter, and I genuinely feel like writing my reflections after every chapter I read. This is the second one. (Yu can check out the first reflection here - Encodings)

This chapter isn't really about databases or distributed systems. It's about something much bigger, it is about doing the right thing. More specifically, collecting data responsibly, using it ethically, and understanding the trade-offs that come with it. One example the author gives is of someone suffering from a rare/critical disease. The more researchers who have access to that person's data, the better the chances of finding a treatment that could help not only that individual but many future patients as well. But now imagine the other side of that equation. What if sharing the same data affects that person's ability to get insurance, a loan, or even a job? Suddenly, the same data that could save lives can also become a liability. That's the thing with these problems they rarely have a perfect answer.

Another interesting point the author makes is that, especially in research, we often don't know upfront how data will eventually be used. New questions emerge, new discoveries happen, and entirely different research directions appear. So it's not always about organizations being unwilling to explain everything. Sometimes they genuinely don't have all the answers when the data is first collected.

Then I came across this paragraph, and honestly, I had to stop reading for a few minutes -- 

Surveillance:

As a thought experiment, try replacing the word data with surveillance, and observe whether common phrases still sound so good [23]. How about this: “In our surveillance-driven organization we collect real-time surveillance streams and store them in our surveillance warehouse. Our surveillance scientists use advanced analytics and surveillance processing in order to derive new insights.”

That one paragraph completely changed how I looked at many of the things we casually accept today.

It also made me reflect on my own work, but even more on the amount of data that is already floating around us. I still receive countless calls for loans and credit cards, and honestly, I have no idea where my phone number came from or how it reached those companies. Once that information is out there, there is practically no mechanism to pull it back or even know who has access to it.

The chapter then walks through several fascinating examples. One that genuinely surprised me was about smartwatches. Researchers have shown that motion sensor data from wearables can, under certain conditions, be used to infer the keys someone types and thus crack the password. Whether that is easy or difficult isn't really the point. The point is that something we mostly think of as a harmless fitness tracker can reveal much more than we imagine. It was one of those moments where I paused and thought, "I never looked at it that way."

The book also discusses something we all know at some level—that many of the "free" services we use are funded through data collection, primarily for advertising and marketing. That itself wasn't a new revelation for me. What I appreciated was how the author connected all these seemingly unrelated examples into one larger conversation about ethics, responsibility, and power.

Another section that really changed my perspective was around consent.

Until now, my thinking had always been fairly simple. If I don't like the terms and conditions, I simply don't use the service.

This chapter challenged that belief.

The author argues that many of these services are no longer just products—they have become part of our social infrastructure. If participation in society increasingly depends on using a platform, then saying "just don't use it" isn't always a practical choice anymore.

Take WhatsApp as an example. Friends', Family and even unOffical Office groups are there. If someone decides not to use WhatsApp, they aren't simply opting out of an app—they are slowly disconnecting themselves from an important part of modern communication. WhatsApp is just one example, and I'm sure yu can think of many others.

The same thought came to me while thinking about ride-hailing apps. Could I live without quick-commerce apps? Probably yes. But in cities like Mumbai or Bangalore, could I realistically avoid Uber or Ola altogether? That's becoming much harder. Many taxi and auto drivers now prefer accepting rides through those apps, especially for airport trips. These platforms have quietly become part of everyday infrastructure.

Again, there isn't a perfect answer here.

This chapter didn't try to provide one either.

What it did do was change the way I think about data. It made me realize that privacy isn't simply about hiding information. Consent isn't simply clicking "I Agree." And doing the right thing isn't always obvious when technology, research, business, and society all intersect.

Sometimes the most valuable thing a book can do isn't answer your questions.

It changes the questions yu ask.

These are just a few of my reflections after reading the chapter, and as always, I'd love to hear yours. 🙂

Are We Losing the Ability to Listen to Our Body?

This one is going to be a highly opinionated and biased post. :P

A few months back, one of my friends went to a dietitian, and one of the recommendations was to have exactly 25 grams of chutney with a meal. I remember thinking.. WTF. Not because nutrition doesn't matter, but suppose yu end up eating 30 grams instead of 25. The stress of constantly thinking "Oops, I overdid it" might end up doing more harm than those extra five grams ever would.

That got me thinking. Are we overdoing tracking and measurements? Wearables, fitness trackers, sleep scores, food labels, calorie counters... it almost feels like we are heading towards paralysis by over-analysis. These days our watch tells us how well we slept, how stressed we are, whether we should train, whether we should rest, and sometimes it almost feels like it knows us better than we know ourselves. I even came across a LinkedIn post mentioning "Protein Chai." Not sure how true that example was, but it perfectly captures where we seem to be heading—we take something useful and somehow find a way to overdo it.

Don't get me wrong. I absolutely believe trackers have their place. Take someone suffering from insomnia, for example. If they are trying different treatments, medicines, meditation, music, or changes in routine, then tracking their sleep for a few weeks makes complete sense. It helps identify what actually works. But once things stabilize, maybe stop measuring every single night and let your body take over again. The goal of technology should be to teach us something, not become something we can't function without.

Listening to our body—that's really what I wanted to talk about.

I'll use running as an example because I've lived through that grind. For many years, including the two full marathons I completed, I used nothing more than a simple digital watch with a stopwatch. I knew my running routes, tracked the overall time, and that was about it. I never chased a particular cadence with a metronome, never worried about staying in Zone 2 all the time, and never kept staring at my wrist every few minutes. Instead, I tried listening to my body. How were my muscles feeling? Was my breathing deep or shallow? Was I landing too hard? Could I push a little more today, or was it one of those days where I should simply back off? Those became my metrics.

Interestingly, I later heard David Goggins talk about something very similar. Early in his SEAL training and running journey, he relied much more on effort and feel than on technology. The heart-rate monitors and advanced gadgets came much later. Forget wearables—I am guilty of this too—but I have also seen people run entire marathons with headphones on from start to finish. Personally, I'm completely against that for my longer runs. For long runs - 10 miles and above, I prefer no music at all. I want to hear my breathing, feel my stride, notice if I'm getting tired, or if my form is slowly falling apart. Music, for me at least, drowns out that inner conversation. Of course, that's just my preference, and everyone is different.

The same thought applies beyond running. Want to eat healthier? Maybe the answer isn't another tracking app. Maybe it's simply eating less packaged food, cooking more meals at home, and including the ingredients yu actually want. Sure, get a health check-up every six months or once a year to make sure your vitals are within range. That's sensible. But we also need to trust that our bodies are remarkably good at adapting. Mindful eating is wonderful. Obsessing over every gram... maybe not so much.

I'll end with a completely different example.

Formula 1 cars have hundreds of sensors. Teams analyze thousands of data points every lap. They know tyre temperatures, brake temperatures, engine settings, wind conditions, fuel loads—almost everything. Yet if data alone decided races, every driver would perform exactly the same.

They don't.

The very best drivers constantly talk about feeling the car. Yu often hear commentators mention their internal gyroscope—their ability to sense grip, balance, weight transfer, and tiny changes that no dashboard can fully communicate. The data helps optimize the machine, but intuition still wins races.

Maybe it's the same with us.

In a world where social media has already taken over so much of our attention, let's not allow trackers and wearables to completely replace our ability to listen to our own body. Technology should improve our awareness, not replace it.

Sometimes, the most advanced sensor we have... is still ourselves.

Books, Bots, and Blind Spots

Steve Jobs once said,

"Yu can't connect the dots looking forward; yu can only connect them looking backward. So yu have to trust that the dots will somehow connect in your future."

Let me stretch that thought a little further.

If Jobs hadn't attended that calligraphy class and learnt about typography, perhaps the Macintosh would never have had the beautiful fonts it became famous for. One seemingly unrelated decision ended up influencing an entire generation of computers.

Now imagine if "vibe coding" or chatGPT or Claude or some similar AI stack existed back then.

Imagine if Jobs had simply learnt what was needed for the next task and nothing more. Maybe the Macintosh would still have been built. But would it have been the same Macintosh? Would it have carried the same attention to detail, creativity, and elegance?

This whole thought came to me on my recent flight from Mumbai to Bangalore.

The person sitting next to me was genuinely surprised to see me reading a thick technical reference book and asked me why I didn't ask ChatGPT to summarize it ?

That conversation stayed with me.

I told him that this is simply how I learn better. More importantly, I'm trying to understand the fundamentals behind the things I use and build almost every day—LLMs, databases, distributed systems, and much more.

Later, he mentioned he was a 2000-batch IIT B.Tech graduate. We started talking about IIT libraries, and I realized we both shared the same appreciation for spending hours with big reference books. (I loved the IIT library too. 😊)

Now, does this mean we shouldn't learn using AI?

Hell no.

I use AI every single day. I'm definitely not a 100% bookworm. 😄

Take my personal website as an example.

Instead of using WordPress, I'm building most of it myself. I use Codex and GitHub Copilot extensively. We discuss what I want to build, plan together, I let it generate code, and then I come back wearing my tester's hat to make sure everything behaves the way I expect.

For hobby projects like this, it works wonderfully.

But then I hit issues like canonical tags, CSS layouts, or some random frontend bug, and suddenly I spend half a day trying to fix something that someone with solid HTML and CSS fundamentals might solve in ten minutes.

That's when I end up learning on the go.

Now compare that with my day job.

Here, I can't skip understanding different machine learning models, ignore hyperparameter tuning, or wait for something to fail before learning how it actually works.

I need those tools in my arsenal.

I may not use every algorithm every day, but knowing they exist gives me multiple ways to approach a problem and, more importantly, choose the right one for the situation at hand.

Another thing I appreciate about textbooks, good courses, and even research papers is that they are structured.

They've been refined over years, sometimes decades. They build concepts layer by layer.

When I start learning something with ChatGPT, I usually begin with one question. An hour later, I've learnt a lot... but I'm often in a completely different place than where I started. Sometimes I skip important intermediate concepts without even realizing it.

With a book, I can go back and forth, revisit chapters, connect ideas, and slowly build deeper understanding.

For people who learn by doing—absolutely, yu learn a lot on the job.

But I still believe yu need a strong foundation to build on.

So maybe this is where I've landed—for now.

Pick a few areas in life that truly matter to yu.

Go deep.

Read the textbooks.

Read research papers.

Build projects.

Understand why things work.

For everything else, let AI help yu move faster.

Maybe that's the balance.

Or maybe, ten years from now, I'll read this post again and realize I was completely wrong.

Just another dot waiting to connect.

 

Vibe Surgeon

Doctor and GenAI -- I like to take an extreme example of a doctor and try to imagine different scenarios of docs using GenAI (LLMs) in order to replicate what engineers do or what we expect them to do and all that.

Maybe the stakes are very different, and I do believe that based on sensitivity and cost impact, different AI and analytics models can be valuable. But for a second, let us go back to the doctor in an operating theatre.

So, "vibe coding" -- imagine a Vibe Surgeon. A doc comes into the OT and uploads all reports -- maybe X-rays and a live video feed -- and asks AI to guide the surgery. Starting from which surgery to perform.

Now, say our doc knows just a little bit about tool use and how the human body works, and starts getting into the surgery. Then suddenly, he sees that this particular patient has some complications. This is realized after the initial cut. Then our AI goes into thinking mode, and after 5 minutes, again lists down 5 root causes and maybe 5 more things to look for, etc, etc. And our Surgeon follows it religiously and sees things worsening.

So here is my hypothesis, or one explanation: LLM models are trained on internet data, and they just predict the next word and then the next, and so on and so on. Common structures are bound to get higher probability, and so they will pop up more. One can tune some parameters and make the model more creative, and it will do that by matching words for very, very different domains that may or may not make sense. Meanwhile, here our patient's situation is worsening, and it turns out this is one of those edge cases. And even our GenAI is not able to fully understand the situation.

I don't want to comment on how it ends.

Marvel fan or not -- if you have watched Dr. Strange, then this paragraph may make more sense. Remember how our egotistical Dr. Strange looks at a few cases and says -- A, B, C -- simple or not worth my time or anyone else can do -- and then picks some unique case and he is like, "Yes, this is worth my thing," and all that. We need such experts. And with the way things are going on, these experts are going to be fewer and fewer. Already they are rare species, and 10 years from now? Phew. Just can't imagine.

Lesson or something -- well -- thanks for reading, but I don't have a specific takeaway for you. Just my thoughts, building a persona of a Vibe Surgeon, and I would love to hear from you.

SomeDays

 𝙎𝙤𝙢𝙚𝙙𝙖𝙮𝙨

𝙇𝙞𝙛𝙚 𝙞𝙨 𝙬𝙝𝙖𝙩 𝙝𝙖𝙥𝙥𝙚𝙣𝙨 𝙗𝙚𝙩𝙬𝙚𝙚𝙣 𝙩𝙝𝙚𝙨𝙚 𝙎𝙤𝙢𝙚𝘿𝙖𝙮𝙨 !

Somedays I feel like the King of the world

Somedays I am the Loser of the Year

Somedays I would cry over all the challenges

Somedays I would blush around all day for no reasons

Somedays I feel blessed that we met

Somedays I feel depressed that yu left

Somedays I want to dance in the pouring rain

Somedays I want to stay in blankets on a winter morning

Somedays I want to floor a sports car

Somedays I want to cuddle up with a Teddy

Somedays I would gulp down multiple scoops of ice cream

Somedays I would fast only on bitter black coffee

Somedays I don't sweat after a 10 miler

Somedays I am not able to complete 2 mile runs

Somedays I would walk 5kms to save 10 bucks

Somedays I would spend thousands for a fancy mobile cover

Somedays I would buckle up and tie up

Somedays I would roam around in shorts

𝙇𝙞𝙛𝙚 𝙞𝙨 𝙬𝙝𝙖𝙩 𝙝𝙖𝙥𝙥𝙚𝙣𝙨 𝙗𝙚𝙩𝙬𝙚𝙚𝙣 𝙩𝙝𝙚𝙨𝙚 𝙎𝙤𝙢𝙚𝘿𝙖𝙮𝙨 !

With 60% Matches Complete, Has IPL 2026's Top 4 Already Locked Horns?

Using Monte Carlo Simulations to Predict IPL 2026 Playoff Scenarios

Analysis - based till completion on match 42 on 30 April..

TL;DR: The Numbers Don't Lie

With 28 matches still to play in IPL 2026, I ran 1 million Monte Carlo simulations to calculate each team's playoff probability. Here's what the data says:

The Key Insight

Yes, RCB has less than 50% chance to qualify — but so do SRH and RR, who are tied on points!

PBKS has essentially locked one playoff spot (and potentially top 2) with 70% probability. But for the remaining three spots, we have a three-way battle between RCB, SRH, and RR — each sitting at 12 points with roughly equal ~50% odds and their odds come to 85% roughly and then it comes down to NRR..

GT lurks in the shadows with 10 points and an 56% chance — to tie or better 4th place and they will have to win with big margins.

Now, let me show you how I got these numbers — and why accounting for team form changes everything.

The Story: When Simple Math Isn't Enough

Last year, with just 14 matches remaining in the IPL season, cricket Twitter was ablaze with RCB playoff predictions. A widely-circulated analysis claimed RCB had a whopping 98% chance of making the top 4. My manager, a die-hard cricket fan, was ecstatic and shared the paper with the entire team.

Curious about the methodology, I decided to verify these claims myself. The approach was straightforward: simulate all possible outcomes of the remaining 14 matches. Each match has 2 possible outcomes (either team can win), so with 14 matches, we have 2^14 = 16,384 total scenarios. Running through all combinations on my laptop took just a few seconds, and the results were clear.

Fast forward to IPL 2026.

With 28 matches still to be played, the same brute-force approach would require evaluating 2^28 = 268,435,456 scenarios — over 268 million combinations! Even on a modern machine, this would take considerable time and memory. More importantly, it's computationally wasteful.

Enter Monte Carlo simulation — a smarter way to estimate probabilities without checking every single possibility.

What is Monte Carlo Simulation?

Monte Carlo simulation is a statistical technique that uses random sampling to estimate outcomes when the solution space is too large to explore exhaustively.

In our IPL context:

• Instead of simulating all 268 million scenarios, we randomly sample (say) 1 million scenarios
• For each scenario, we randomly decide the winner of each of the 28 remaining matches
• After all simulations, we calculate: "In how many scenarios did RCB finish in the top 4?"
• If RCB made top 4 in 475,000 out of 1,000,000 simulations, their probability is 47.5%

The beauty: With enough simulations (typically 1 million), the results converge to the "true" probability — but we only need to run a tiny fraction of all possible scenarios.

Convergence Analysis: How Many Simulations Do We Need?

One key question with Monte Carlo methods: How many simulations are enough?

To answer this, I ran the playoff predictions with different simulation counts: 100, 1,000, 100K, 500K, 1M, and 2M simulations. Here's what the convergence looks like: [can be debated though]

2M simulations - is close to 1/100th of 268M possibilities we have out there.

Plot showing % of making it to top 4 or tie for top 4 position

From above plot we see that as number of simulations increase (X-axis) - probabilities seem to have stabilized. Below table shows the difference between 1M and 2M simulations

Verdict: By 100,000 simulations, probabilities have largely stabilized. Running 1M or 2M simulations provides marginal improvements in precision. For our analysis, 1 million simulations offers an excellent balance between accuracy and computation time (~5-10 seconds).

---

Understanding Uncertainty: Standard Error

Every Monte Carlo simulation has inherent uncertainty. How confident can we be in our 47.7% estimate for RCB?

The answer lies in standard error — a measure of precision for our probability estimates:

Standard Error (SE) = √[p(1-p)/n]

Where:

• p = estimated probability (e.g., 0.8723 for RCB)
• n = number of simulations

What This Means:

Key Insight: With 1 million simulations, RCB's 87.23% estimate has a 95% confidence interval of roughly [87.15%, 87.25%] — very precise!

To halve the standard error, you need 4x more simulations (due to the √n relationship). The law of diminishing returns kicks in quickly.

---

The Problem with 50-50 Assumptions

So far, we've assumed every match is a coin flip — each team has exactly 50% chance to win. While this is a conservative baseline, it ignores a crucial factor: current team form.

Consider this:

• SRH has won their last 5 matches (100% recent form)
• LSG has lost their last 5 matches (0% recent form)

Should we really treat an SRH vs LSG match as 50-50? Obviously not.

Form-Based Simulation: A More Realistic Approach

Instead of coin flips, we can use recent match results to estimate win probabilities:

Step 1: Calculate each team's win percentage over their last N matches (tunable parameter, we use N=4)

SRH: W-W-W-W-W → 100% form
LSG: L-L-L-L-L → 0% form
RCB: W-W-L-W-L → 50% form

Step 2: When two teams face off, normalize their forms to get win probabilities

SRH vs LSG:
  - SRH gets: 100/(100+0) = 100% win chance
  - LSG gets: 0/(100+0) = 0% win chance

RCB vs PBKS (75% form):
  - RCB gets: 50/(50+75) = 40% win chance
  - PBKS gets: 75/(50+75) = 60% win chance

Step 3: Run Monte Carlo simulation using these weighted probabilities instead of 50-50

Results: 50-50 vs Form-Based Predictions

Here's how playoff probabilities change when we account for current team form:

Major Takeaways:

1. RR is the big winner (+10%) — Although their form is 50% only but the average of their opponents form is 25% and so RR stand to gain a lot if current form is to be followed.
2. SRH small improvement (5%) — they have a 100% form % but they will be playing stronger opponents as compared to RR and so they will have to fight hard to keep their spot
3. PBKS remains strong — Already leading the table with good form maintains ~98% playoff odds

---

Final Verdict: The Playoff Race as of May 1, 2026

Form-Based Playoff Probabilities (1M Simulations):

---

The Storylines:

✅ PBKS: The Frontrunners — With 13 points and strong form (98%), they're virtual locks for playoffs. Only a catastrophic collapse keeps them out.

🔥 SRH: Form is Everything — On paper, tied with RCB and RR at 12 points. But their 5-match winning streak makes them the favorites among this trio - but they do face against some tough opponents.

⚠️ RCB: The Title Says It All — Despite being tied for 2nd place in points, RCB's inconsistent form (alternating W-L pattern) drops them 4th on our list.

📉 RR: Form Slump Hurts — Like RCB, they have 12 points but only 50% form in last 4 matches. Their playoff hopes are fading fast but they might be playing some out of form opponents - who may still fight back for some glory points.

🎲 GT: The Dark Horse — 2 points behind at 10, but 60% form keeps them in the race with a 1-in-5 shot.

❌ The Rest: Mathematically Alive, Practically Done — CSK might show some probability but looks a tall mountain to climb for them. DC, KKR have 3% odds. MI and LSG are essentially eliminated (<0.01%).

Conclusion: Data-Driven Cricket Analysis

What started as a simple question — "Will RCB make the playoffs?" — turned into a fascinating exploration of:

• Monte Carlo simulation as a practical tool for complex probability problems
• Convergence analysis to understand how many simulations are "enough"
• Standard error to quantify uncertainty in our estimates
• Form-based predictions that go beyond coin-flip assumptions

---

Try It Yourself

All code and data used in this analysis are available in this Jupyter notebook:

• GitHub Repository: IPL Playoff Analysis
• Interactive Notebook: Open in Google Colab / Binder

Feel free to:

• Adjust the form window (last 3 vs last 4 vs last 5 matches)
• Run your own simulations with different team points
• Explore scenario analysis: "What if RCB wins their next 2 matches?"

Cricket + Data Science = ❤️

---

Last Updated: May 1, 2026 | Simulations: 1,000,000 | Method: Monte Carlo with Form-Based Win Probabilities