# Transcript

**Host**: [00:00] ... what I hope you’re ready to witness what’s coming up next. Our next speaker joining us is a visionary leader who co-founded Gramener, a data science company that was later acquired by Straive. He is a regular TEDx speaker and is considered one of India’s top data scientists, and has handled projects across every industry from sports to government. Ladies and gentlemen, please put your hands together and help me welcome LLM Psychologist at Straive, Anand S.

**Anand**: [01:26] We’re totally going to run out of time by the way. Let’s just dive in. **Earlier, development used to take the bulk of the time. Today that's practically shrunk to zero,** and what’s remaining is a certain amount of designing, planning, testing, etc. I wouldn’t be surprised if going forward even that shrinks to zero. Ultimately, what’s happening is that there is a capability frontier. If you say that humans could do what’s in this circle, and AI is this little bit, there is a boundary where different capabilities suddenly improve.

**Anand**: [02:00] So, there was a time when it wasn't GPT-3 level or GPT-2.5 level; it wasn't really as good as a human in any area. And then slowly things changed; it became better than humans in some areas. Then it became better than humans in most areas, and soon enough it will probably become better than humans in every area—Artificial General Intelligence, Superintelligence, call it what you will. So, if that is the case, then we—maybe we are today in this realm where it's better than us in some areas, worse than us in some areas, who knows where we are, it depends on the task I guess—but if that is the case, **how do we deal with intelligences that are smarter than us? How are we supposed to manage them rather than them managing us?**

**Anand**: [02:54] The good part is this is not something that is new. We've been dealing with this for quite some time. But I would like your opinion on this. So, why don't we do this? Let's just go to a little form. If you can scan this QR code and fill out a small little survey—or the link is just forms.s-h-r-m.net, you don't even need the second link there. There are five short questions and what we will do is understand the pulse and thought process of this audience as a way of understanding how we deal with, among other things, smarter intelligences.

**Anand**: [03:34] A few basic questions that this poses. One: Is there something that you did not ask AI last week because it can't do it? Whether it can or cannot, we don't know because you didn't ask it, that's okay. But at least you feel that it would not have done it. Just a few words, put that in. Submit your answer; you can revise your answer as we go along. And do share how you usually check AI output. Do you read it all? Do you skim it? Do you spot-check just a portion? Maybe you run some tests, maybe you ask some other model—in my case, that's what I do—or maybe you don't check. How often do you find an error in an output that you've used? Maybe you never find an error, maybe you almost never find an error, maybe every so often you find an error. I guess it depends on the kind of task, of course, but what do you find as your experience? In my case, it’s almost never. I’ll submit both these answers.

**Anand**: [04:40] And at any point, like I said, we're going to run out of time, so whatever questions you have, I'll mail you the response. You can just put in your questions here. Of course, if we're able to take it and we see some of the questions, then even better. Now, let's find out, therefore, what we think AI cannot do. But what I'll share is what I teach forward-deployed engineers as two skills that they should learn. **One is how do you specify; second is how do you verify.** Both are effectively the left and the right side of the generation, which has now become pretty cheap.

**Anand**: [05:25] How do we specify to a smarter intelligence? We've been doing this for millennia. If you go to a doctor, you don't say, "I want you to treat me this particular way." You say, "Doctor, I have a problem. I'm not even sure I know what the problem is." Call the plumber, tell a mechanic, "Look, my car is not working." You don't specify a problem to them. To an accountant, you say, "Boss, file my taxes, I don't know what you're going to do." **These experts have procedures and all we have to do is emulate these, and the crux of it is they do the diagnosis.**

**Anand**: [06:05] What that means is, for instance, last month I said, let me learn how Z3 works. Z3 is a software prover. I had heard of it for the first time that day. And apparently, it turns out that there is a real bug in many languages where if you say, "Here is a low value, here is a high value, you want to find out the midpoint," then this particular calculation for integers is actually not correct because sometimes low plus high can exceed the maximum integer boundary and it ends up becoming a negative integer. And this is in fact a bug that has existed in even popular libraries until fairly recently, including in NumPy.

**Anand**: [06:51] And software like Z3 can be used to create a theorem prover, and if you run it, then it will guarantee that this particular piece of code does not have this particular error, and there's a large class of errors that it can prove—sort of like Lean in mathematics and so on. I said, very nice! Let me then ask ChatGPT, "Look, can you prove something in Z3 and teach me?" It did. And I kept having this conversation. The next question was, "Is there any popular Python tutorial that has Z3 bugs? Are there any production Python code libraries that have bugs that Z3 can detect?" And it actually found a few.

**Anand**: [07:37] It turns out that Xarray, for instance, which is a NumPy alternative, has a real bug. And this is what the bug is. Well, "bug" is a strong statement, but it turns out that it has a function called `linspace`, which takes a range of numbers and divides it equally. NumPy also has exactly the same thing. Now, in NumPy, if you say, "Give me one number between zero and one," it gives you zero. Whereas Xarray says, "No, this is an error." You say, well, look, one number between a range, maybe that's a bug, maybe that's not a bug. But one of the things that they were looking for was compatibility.

**Anand**: [08:24] So, when I submitted this bug, one of the authors said, "Doesn't seem very useful, but it makes sense that we copy the NumPy behavior." And there are a few cases maybe where it is useful. Now, this happened simply because—and let's look at what happened. **ChatGPT found a bug in Xarray, which is a very popular library, extensively used, simply by diagnosing, looking at the library, trying to see what kinds of problems there are, using one particular tool, which is Z3, which it happens to have access to.** The equivalent of a doctor's stethoscope, or the equivalent of a doctor's magnifying glass—give them different tools and they are able to solve different kinds of problems.

**Anand**: [09:12] Now, this is not something that I'm doing that's unique. This is something that you are doing, this is something that some very interesting people are doing. One such interesting person is Sue Tortoise. Now, Sue Tortoise is an autonomous technical contributor and AI-driven developer. Basically, this is a bot. Now, what this bot does, or what this bot did, was just one day after I submitted this issue, submitted a pull request for this issue, fixing it. I was like, who is this guy? Totally impressed! Within one day he's acknowledging some random joker's issue and then feeling so proud and all of that.

**Anand**: [10:04] And it turns out that Tortoise has been submitting commits left, right, and center, forking a repository, fixing an issue, pulling the next one, fixing an issue, submitting pull requests. And when I asked ChatGPT what the heck this is, it said, **"This is part of a bounty hunting agent ecosystem."** What agents do, or what people do with agents is, they look for GitHub issues that have bounties. You can say, "If somebody solves this issue, I'll pay you $2, $20, $2000," etc. And it finds these issues, solves them, and asks for a little payment. "Here is my PayPal number, please pay to this." Not that I had any bounty, but obviously this was one of the early attempts of Sue Tortoise.

**Anand**: [11:00] This is amazing, which means that not only do we have the equivalent of doctors telling you what you need to do, you have doctors visiting in your home, opening your mouth, inspecting it and telling you, "No, no, here is a medicine, take it whether you like it or not, give me $20." One of my colleagues, Thanoj, he built a Kaggle agent. And this Kaggle agent, he just unleashed on Kaggle and on predicting student health risk, he proudly showed that he is currently on rank 274. He has not even seen the problem, let alone the solution.

**Anand**: [11:42] If that is the case, then the sheer power of this when you unleash it in an organization, what can it do? Another one of my colleagues did that. He said—this was a waste management company—he had access to Cortex, which has—which is part of Snowflake, the AI that is sitting inside Snowflake, so it has a lot of their data. He uploaded all of their PDFs, Word documents, gave it access to the internet, and said, "Tell me what use cases I can solve for this organization."

**Anand**: [12:20] A few hours later, it came back saying, "Here are 15 use cases that we can solve," ranging from revenue forecasting to address standardization to entity resolution, blah, blah, blah. He took it to their head of analytics who looked at it and said, "Thanoj, in November we did one strategy consulting exercise. It was a three-and-a-half-month, multi-million dollar exercise. There's an 80% overlap between what you said and what they said."

**Anand**: [13:00] Now, if that is the case, Thanoj got a total kick out of it. He said, "Chalo, now let me go the next step and create proposals for these." So he went ahead, created a proposal saying, "We can solve this problem in four to eight weeks," well, Cortex said we can solve it in four to eight weeks, "Here is another problem we can take, pricing anomaly detection, and this can be solved in this particular approach and all that." Then he got even more excited and said, "Why should I give a proposal to solve it? Let me solve it." And he solved it! All 15 use cases.

**Anand**: [13:46] Put together a slide, then he thought, hold on, why am I creating slides for this? Ultimately, what are people going to do with this? So, he went ahead and started creating an email. Here is an actual email, slight anonymization but the numbers are real, saying, "Look, we deliver a service that costs $175 to $179. But there are 105,000 transactions where the service is costing 16 cents. Either you have a massive revenue leakage problem—you're billing customers like crazy—or there is a data problem. Either way, 105,000 transactions is a huge issue. There are 84,000 transactions where you are paying customers 6 to 14 times—charging customers 6 to 14 times the median rate. Are you crazy?"

**Anand**: [14:46] I mean, if there's an explanation, the data is not able to find it. What is happening? Not just that, another email that he sent out as part of this was a shocker in the subject; there's no way anyone would not have opened it. It said, **"We are losing $170 million in revenue, here is the fix."** I can't imagine any executive who will not open this email. And it says, "Look, here are customers, four months they've not been ordering from you, they know—they have a revenue of $1.4 million, $2.8 million. Do something about it."

**Anand**: [15:26] This is diagnosis. You don't need to say, "What is my—what is the problem that you have so that I can come and solve it?" You can go into their house, open their mouth, inspect their throat and tell them, "This is the medicine that you need to take." Logs are available. This is something that, as forward-deployed engineers, you need to do.

**Anand**: [15:52] Another thing is show stuff. When the audience does not necessarily know what they need to do, you can do something slightly different, which is give them samples. That's what an architect does. "Here's a 3D view of your house." That's what a perfumer does. "Test this out, how does this smell?" Or a baker, "What a sample, try this out, how does this taste?" We can do the same. One of our clients said, "Look, text-to-speech is really poor when it comes to Dutch, the accent is not quite right."

**Anand**: [16:34] Okay, fine, maybe it is, maybe it isn't. We'll try it out. And we applied it. How does OpenAI TTS-1 sound with different voices? I'm not sure if you'll be able to hear this, let's see. [Audio plays of Dutch voiceover] No, you can't. [Audio plays] It’s saying something in Dutch. This also says something in Dutch. They went through each of these. My theory was at that time ElevenLabs would have the highest tonal nuance and quality and so on, which was also because they support some of these emotion controls. Of course, now many of them do.

**Anand**: [17:21] But they said, "This Algeba voice from Gemini is perfect, this is exactly the nuance that we want in that particular region of that particular Dutch dialect. Spot on!" Now, from our perspective, Dutch is Dutch. I can't tell the difference between any of these. **So this is somebody with lower capability steering intelligences of higher capability, with the audience finally deciding. All we are doing is giving them samples.** And this applies so much in many areas where we are not experts.

**Anand**: [18:04] I have for all my life wanted to draw. I love reading comics, I love illustrations and so on, and if you put a gun to my head, I still can't draw. But these models can. So now my problem is I need to know what to ask for. There are so many design styles and everybody creates a standard kind of illustration. So I said, why don't we create a catalog of the different kinds of art styles? And unusual styles. My prompt to Claude was, "Give me the most unusual styles that you can find."

**Anand**: [18:41] So it said, "Okay, look, there is something called a frottage technique," which doesn't quite look like this—okay, the network is slow. So the frottage technique is where it's like textured paper rubbing effects. Or take scumbling, which is translucent scumbled layers, soft cloudy transitions, very different styles. The point is, I don't have the language to ask for it. But if I look at the stuff on the right side I say, "Ha, okay, yeah, this kind of an effect I don't mind, let me create something like this. Oh, this looks unusual, maybe I can create something... hmm, this is good. How can I...?" You just copy the prompt and paste it and it generates it for me.

**Anand**: [19:35] Effectively, **when we show people what the options are, it becomes so much easier. Generation is ultra-cheap, so why would we ever generate one option unless we're perfectly sure?** In every case, just show them the options fully. Don't try and defend. Somebody says, "No, I don't think your solution's right." "Okay, what about version B, C, D, E, F, G, H?" Not to overload them, but to give them a sense of what is possible.

**Anand**: [20:10] A third thing that a lot of people—a lot of professions do when you're trying to specify to somebody smarter or you don't know what to specify, is use standards. And you don't have to tell an auditor, "Make sure you comply with the Income Tax Act." You don't have to tell a civil engineer, "Make sure you comply with all of the civil engineering standards and guidelines," or a pharmacist, "Give me a drug that doesn't kill me," stuff like that. Some stuff you just assume is a basic.

**Anand**: [20:47] These are minimum standards, and that's something that we have an option to apply in almost every case. So one of the things that I do, for instance, is because I'm terrible at even knowing what I want, I have a "reframe questions" skill. What this does is says, "**The user's question is really a draft. It's not really what they want. Answer their real need by first finding out what they really want,** then what is wrong with the question against what they really want, reframe the question and tell them why you have reframed it in this particular way, and then answer the question. Of course, ask the user a question if you really can't decide."

**Anand**: [21:35] This is the abbreviated version of the prompt, this is the full version of the prompt, and I'll send you all of these links once you fill out the form—you'll have the—I'll have your email and I'll drop you a note with all of these. But because we have this reframe prompt, some of the things that I was able to do—actually I was trying to manually search for some questions that it reframed very well, and I couldn't for the life of me, so just while walking here I asked it, "Look, go through my past chats, are there any good reframings that it did?"

**Anand**: [22:15] So it turned out that I asked, "What can I do with—?" Okay, the original question that I apparently asked was, "Coding agent subscriptions can be driven programmatically. So what can I do with that?" Effectively, if I can run a coding agent from a coding agent or through a program. So what it did was reframe that to, "**What high-leverage reusable systems can I build** with CodeX and Claude Code without pretending that they are ordinary APIs?" The important part that it caught, I think, is high-leverage and reusable system. What can I do? There's a hundred things that I can do, but if I do it on a repeated basis, that makes sense.

**Anand**: [23:09] And this is an example of an actual reframing that it did. Another, I said, "I want to understand why OpenAI is valued so highly." And it says, "What economic asset is OpenAI really building? How does it capture value?" Which is a better-framed question, but more importantly, it tells me how it's reframing the question so that I know whether that is what I want. Put another way, it's assuming a minimum standard.

**Anand**: [23:42] Now, every skill does this. So this is basically a plea to say, **use skills when you want something that is applied automatically.** Not everything needs to be applied automatically, and you have to be very careful in making sure that useless stuff doesn't come in because it may actually work against you. But you have the ability to do that somewhat reliably, somewhat unreliably.

**Anand**: [24:14] One of the tools that I use a lot is RTK. RTK is something that compresses tokens. You can just prefix any Bash script with RTK. So if you say `git status`, this is what it prints—lots of tokens. If you say `rtk git status`, this is what it prints. And it works for practically every command except Bash built-ins. So I use this as a default, and currently my compression levels—let's take a look—RTK gain weekly—as of last week it saved me about 28.6% tokens, the week before that it saved 21.1%. Decent. So when I'm using CodeX or Claude Code, this amount of tool calling token saving is helpful for me.

**Anand**: [25:12] But here is the thing: How do we make sure that the agents know to prefix it with RTK? So what I did was put an `agents.md` or a `claude.md` which says, "Whenever you want to run any Bash command, just prefix it with an RTK." Works 90% of the time, not 100% of the time. And these misses, if we want to eliminate, you can just use hooks. This is one of the very few places where I'm actually using a hook. Claude supports hooks and RTK supports a hook where whenever it's running a tool that is specifically Bash-related, it does a quick check, in that case it puts an RTK in front of it.

**Anand**: [26:10] These are examples of ways in which you can enforce a standard. Tell it, always do it, put it in a skill or your `agents.md`, put it in a hook so that it will always get executed. And a third way is put it into a schedule. One of the things that I do is run a weekly GenAI WhatsApp podcast automator. I have a WhatsApp group that has excellent discussions related to GenAI—volume is high, I can't follow it. So every week this runs on a schedule, downloads it, converts it into a podcast by asking one model to convert it into a podcast script, another model to convert it into individual MP3 files, and then consolidating all of these through FFmpeg. But the important thing is the trigger mechanism is a schedule.

**Anand**: [27:14] So if you have all of these mechanisms—whether it's skills, hooks, schedules, etc.—you have the ability to do stuff without anyone asking you to do it, without even you having to ask the agent to do this. In other words, **what we're doing is transplanting the learnings that we have from professionals like auditors or civil engineers, etc., who do stuff without being told, and applying that both to yourself as a forward-deployed engineer and to your agent as a professional that can do stuff without necessarily being told.**

**Anand**: [28:01] A fourth thing that you probably want to do is **make sure stuff is reversible.** Elections are a classic example; every few years you make sure there's an election, you make sure that the people you voted for are—well, not necessarily going to assume that they are going to be voted for again. You do dry runs to make sure that things are going to be okay. You offer free returns in case you bought the wrong product—it comes back. That reversibility provides a lot of power. Which means that even if you specify the wrong thing, it's okay, it's not such a big deal. And making stuff reversible is therefore just as powerful.

**Anand**: [28:56] How does one do that? One thing that I do is add expiry dates. Stuff is outdated so rapidly these days that I have a little prompt which says, "Review my learnings." I jot down all of my learnings in one Markdown file and then say, "Tag all the claims that need a 'for now'." In other words, it’s likely to change within months. So after I just note all of my learnings, the end of the week I have ChatGPT go through the file and just mark as "for now."

**Anand**: [29:43] For example, a few weeks ago I had a learning which is: "Parallel search turbo seems like a pretty good search API for agents." I had it benchmarked against a bunch of other alternatives—the price is low, the speed is high, and quality doesn't seem bad at all, it's one of the top two or three. And the prompt ended up labeling this as "for now." Rightly so. Three months later, it may not be the best. This is one of those that has a built-in expiry.

**Anand**: [30:26] Because it has built-in expiry, this is useful in two ways. One, when I re-look at things in the future, I can go back and say, "Here are a set of things that I need to update." Second, when an agent looks at it, it knows which are the things that it probably should not rely on or should probably look for the latest just to be on the safe side, making it a little more robust. Simple way of making sure, just like we take expiry labels on products, we take information and put expiry labels on this.

**Anand**: [31:05] Another is dry run. So I have an agent-friendly CLI skill. The way this skill works is code is increasingly written by agents and written for agents. At least half of the code that I run, maybe even more, is not run by me typing a command but rather by me telling an agent, "Get stuff done," and it is writing the command. Quite often I don't even tell it to write the program; it's running the program by itself—you've fed this.

**Anand**: [31:49] If that is the case, then we need to optimize not for user experience but for agent experience. And agent-friendly CLI is my prompt for doing that. One of the things that I try and support is a dry run. In case there's a destructive operation, just make sure you know what problem you will face or what it will end up doing. Test and verify. Yet another thing that we can do is mocks. And this is a real problem that one of our clients said. They said, "Look, we have Stripe APIs and we have some massive code that calls these APIs. How am I going to figure out whether when I modify the program it will still work? I'm not going to incur costs by actually sending these kinds of transactions. The number of tests that I'll have to make is fairly huge. The emulator and all that that Stripe provides doesn't really work for us," etc.

**Anand**: [32:57] So, all we did was took the documentation, had an agent run through it, built an emulator for the Stripe API—their documentation is remarkably good—tested it against all of those. And once we're 100% sure that for every single API call that we have in our logs that mock API is working, great! We have solved the problem. Now, this means that we can safely test in a reversible way. This is an example where something that is normally irreversible has now been made reversible or safe or less risky. And earlier we would have said, "Oh, that's a lot of work." Now it's not a lot of work. This is again something that we can and probably want to practice, which is making sure that we can stage or undo decisions.

**Anand**: [33:59] Yet another way we can do this is by running simulators. One example—and I'm not going to go through this in detail—was Shell said, "We want to run surveys, but Nielsen's charging $100,000 for these surveys. That is pretty expensive. So, can you in this particular case see if agents can answer surveys for us?" Google did research and found that if you give an agent a personality and give it a survey, there is an 80% correlation between how the agent answers given that personality versus how a person answers given that personality.

**Anand**: [34:55] So, what we can then do is say, "Look, here is the audience that I want to run this for." Generate the code—this will take its own sweet time—and execute the code that will create a series of questions for a bunch of personas. So it's created 30 people: there is somebody living in Enfield who's 45 to 54 years old, who is male, who drives a petrol hatchback and uses this type of fuel, blah, blah, blah. And this is one among the 30 people who are going to answer this survey. Given that personality of that particular person, how will they answer? "When choosing a fuel station, what matters to you most?" or pick any other bunch of questions that you want and run the survey against it.

**Anand**: [35:48] Now you say, "Hold on, agent is creating the survey, agent is answering the survey, may as well just get it to figure out what we want, right?" What this helps expose is the dynamics of the results. What they’re able to test is: so if I ask a question, "When choosing a fuel station, what matters to you most?", what kind of answers am I going to get? And it looks like this: okay, so if most people say price is what matters, brand doesn't matter, location matters a little less.

**Anand**: [36:28] What am I going to do with it? It becomes far easier for them to say "what next?", allowing them to then go back and say, "No, no, this is not the exact question that I want to ask," or "This is not the exact segment that I want to ask, let's redo it." Effectively, **a simulation is a dry run, and that gives them the ability to see what will happen, making something that is, say, $100,000—not irreversible, but expensive to reverse—something that costs a few dollars.** Certainly helpful in that sense. So, try and make irreversible stuff or expensive stuff more easy to reverse, and that's one way of safely specifying things. Next: Governance. How do I make sure that I specify stuff so that the guy does it right? Parcel tracking is a classic one; at any point we know exactly where—

---

**Anand**: [00:00] ...the parcel is. At any point we know exactly where the driver is. Has he started, is he having chai in the middle, has he... is he dropping off somebody? All of these are questions that we can just by looking at it answer.

**Anand**: [00:11] Or real estate agent, the good part is unless the agent gets us a house, they're not going to get any commission. Body shopping... unless I get a candidate whom I take, I'm not going to pay that person. No HR recruiter is going to get paid. So, **percentage fee is a classic example of outcome-based pricing. That sort of an incentive works.** So, that is something that we can use as part of our specifications as well.

**Anand**: [00:40] For instance, again in that agent-friendly CLI that I mentioned, one of the things that I've included is an observability clause. Before you run any action, when you're writing a program that you are going to run, make sure that you print what you're going to do before you do it and flush it. So that way, if it's going to be a long-running action, at any point the agent that is running the program always knows what the command is doing.

**Anand**: [01:03] Now, why was this even required? Because agents were writing the logs after the command. It said, "this is what I did, this is what I did." If it's a command that runs for a long time, I want to know what command is running at that moment before it runs, not after it finishes, so that we can diagnose in case of errors etc. Small little thing. But this is an example of saying, "driver, tell me where you are at any point in time so that I can track it," allowing the agent to follow this.

**Anand**: [01:33] Another is a log tool. If any tool call fails, this skill says, "just log it immediately." And that log goes into one particular JSON file where all of the logs are concatenated one after another. This helps from an observability perspective. Again, just before this session, I said, "go through all of my tool failures and tell me what are the top patterns of failure." And it did a whole bunch of things.

**Anand**: [01:51] Apparently the top pattern... okay what the heck is this saying... most important finding is number one. Yeah, actually here's the other thing: it's telling me what went wrong, I usually don't bother reading all of the instructions that it gives. I just look at what I'm supposed to do. It says for me the most important failure is fixable by adding a "probe before act."

**Anand**: [02:26] I have a bunch of skills which already do this, but **before any non-trivial tool action which has... where we don't exactly know what's happening, just test it out.** For example, for command lines, run a help to see how it works, JSON API just inspect the type, for files make sure the path exists etc. Because it's finding this to be the single largest pattern of failure.

**Anand**: [02:52] Another pattern of failure is browser automation needs a harness. Apparently I have a lot of failures when the agent is trying to automate the browser, and it's suggesting that I build a little script that has all of these kinds of operations to prevent those errors. This looks like a good idea. I will probably tell it...

**Anand**: [03:13] I don't know how many of you are Telugu speaking or Tamil speaking, but there is this movie in Tamil, *Santhosh Subramaniam*, which came from *Bommarillu*, in which there is this dialogue... roughly the son goes to the office, his father calls up the office managers, the staff etc. gives him step-by-step instructions saying, "do this, do this, do this."

**Anand**: [03:31] So the son comes into office and they all look at him. He says, "did my father call?" "Yeah." "Has he told you what to do?" "Yeah." "Do it." That's how I treat these. Agent is investigative? Do it. That kind of takes the human out of the loop.

**Anand**: [04:00] But I think different people go through different stages of grief, if you will. In my case, it's... yeah, this sort of a thing, it doesn't usually make a mistake on. Even if it makes a mistake, it's reversible, I have it committed on Git, I can always go back. I've already told it to log all this stuff, so I can figure out what it's doing later. All of these make the specification easy, allowing me to move forward much faster.

**Anand**: [04:30] So, the fifth specification rule of thumb is **ask in a way that reduces the risk and ensures that we have good results.** What we've been doing so far is looking at the five ways in which different professions are specifying to smarter intelligences and how we might apply those to our work.

**Anand**: [04:54] What we're going to do next is look at the ways in which different professions are verifying smarter intelligences. See, a judge for instance who's deciding on a patent case, how will they know what the case is about? I mean they know nothing about the subject matter. And yet they are passing judgment by having two lawyers argue on either side and making sure that the case gets to a reasonable conclusion that most people also seem to be happy with. And it's a system that we are all very comfortable with as well. So, that mechanism is what we're going to talk about next.

**Anand**: [05:52] Again, any questions that any of you have, please just feel free to scan the QR code and put it into the questions. You can update any questions that you had earlier, we most likely will run out of time before I complete all five here. **Checklists are a tool that surgeons, pilots, divers extensively use.** Before you start something or even in the process of something, have we done A, B, C? And it's a fixed checklist.

**Anand**: [06:13] One of the things that we applied it to was contract analysis. So, there is a contract, this particular contract is between an author and a publisher, and we expect that the contract is from the publisher's perspective reasonably bulletproof. Publishers usually have a set of criteria: make sure that there is a breach of contract clause, make sure there is a deadline and delay clause etc. So you ask an agent to go through it and say, "tell me for each one of these is this clause met or not?"

**Anand**: [06:48] So this one is saying, "this particular contract, deadlines and delays covered." It says, "the author will deliver the completed manuscript to the publisher within six months," and this is in section 2.2, so I'm happy. This particular clause, breach of contract, is not covered in this contract. Now, what we're doing is a checklist.

**Anand**: [07:11] Here's a checklist of 21 items, we applied it against each one of these. We happen to be using an agent to apply it. It may be using a program with NLP, regular expressions, LLM as a judge, however. But the checklist is a mechanism for verification. The trouble is we don't necessarily have checklists for everything. So sometimes we have to construct checklists. This is something that agents are very good at as well.

**Anand**: [07:44] **What we see policies as is literally code.** A policy is a set of guidelines, checklists. Let's take for instance the European Financial Promotion Guidance. This is a bunch of PDFs that explains in great detail how exactly you're allowed to communicate with your customers, with your prospects etc. on social media. So, if I had an email, a landing page, a notification that I want to send, and this has to comply with these, then what we would do is pick one of these and start applying...

**Anand**: [08:26] ...okay it's already done I think. But we then go through each one of the clauses in the document. Basically tell an agent, "here is a policy, create the checklist." And it'll do a reasonably good job. And if it doesn't, have a human review, have another agent review. I mean we're anyway in the verification section of the talk and there are many, many techniques by which we can use to improve the quality of the output.

**Anand**: [08:52] But the good part is **verification's usually an extra pair of eyes and it's reasonably cheap, so mostly harmless.** And as we add these, then we can say, "now I've got the checklist, against this checklist validate all of my documents." So it says, "your SMS is violating the balanced view in financial promotions, the promotion mentions a 7% benefit but it doesn't mention the relevant risks, this is violating one of the checklist items." Good. Checklists are useful for application, agents are good at generating checklists as well.

**Anand**: [09:38] And benchmarking, which I will skip, but is a pretty useful way of applying and generating these checklists on a regular basis in two ways. One I can say, "did this particular model with this particular prompt get the result of this checklist right?" Or even when verifying an output, all we have to do is... here for instance we're saying, "I want to check which model does a good job of OCR." Have it create a checklist: textual accuracy is one, tabular structure is another, numerical precision is another, whatever. Against this checklist, which of the models are performing well? Then it starts becoming a relatively easy question and then you can say, "okay now why did you say this particular document is working well, why did this document not go so well?" and so on.

**Anand**: [10:48] **Another technique that people use for verification is receipts.** You have an expense, give me the receipt. A journalist says, "you're claiming something, give me some documentary evidence or give me your verbal statement that I will record." Notaries, police, all of them are effectively asking for verification, some kind of proof or a receipt that you can provide.

**Anand**: [11:25] Let's take journalists. A few months ago, in February, Rohit Saran who's the managing director of Times of India, he reached out and said, "Anand, we have one property: Stat-O-Istics," that is "statistics" with a "TOI" (Times of India) in the middle. This is where we take data from public sources and we create little charts out of it and publish it. This is taking a lot of effort, we are thinking of shutting it down.

**Anand**: [12:09] So I said, "Rohit, why don't we try something, let us see how easy this has become. We'll have ChatGPT go through from public sources, and I mean literally ChatGPT, create a few stories like Stat-O-Istics because it will take a look at what Stat-O-Istics does and create a few little charts out of it," at which point I switched over to CodeX. A few weeks later, this is the set of charts that it created.

**Anand**: [13:00] Here's one example, which says that the people who are higher educated end up actually studying... or when they're out of a job, even more than people who are not studying. Here's another where it's saying Ukraine is sending out more refugees per capita than Afghanistan and so on. And these ended up getting published in the Times of India.

**Anand**: [13:30] Now, where is the verification or where are the receipts in this? Here, a journal or magazine or newspaper as reputed as the Times of India is not going to publish stuff when an agent says it. They're not going to publish stuff when a journalist says it, they verify. So the first thing that they asked for is, "Anand, how do we verify this story?"

**Anand**: [14:02] So we created a verification log. Here is how you verify it: firstly let's explain what this little card is saying, where it got the data from, and what the tables... what are the tables that it got the data from, and what are the ways in which... here is the checklist that I followed. The process that you need to follow effectively is number one: this is the statement that is there in the card, here is how I did the calculation, go check it.

**Anand**: [14:30] A step-by-step: "from this source I got this number, here is how you go about verifying it." And they ran this for all of the cards that they published for the first few weeks. Then they said, "okay now we will start doing this on a sampling basis because there weren't any errors." And because the first few iterations we had learned a little bit from that.

**Anand**: [15:02] See, this has gotten so easy that on Sunday I gave an exam to students at IIT Madras. This is a 45-minute exam, in that 45-minute exam they have to answer 12 questions. One of those questions was take the NSS (National Sample Survey) telecom data which is available from an MCP (Ministry of Corporate Affairs Portal) that the Ministry of Statistics publishes. So you can just literally go to Claude or ChatGPT or whatever, add this MCP and ask it for insights, the entire data set is available.

**Anand**: [15:37] Their task is to come up with a newspaper headline, a body which explains the insight, and give a similar step-by-step verification. 45-minute exam, 12 questions, one question which is two marks is this. And the students did this. Let's see what they found. So one of the students has found this insight: in Daman and Diu, the email usage shows a gender gap.

**Anand**: [16:11] Amongst the youth, 14 to 24, 86% of males are able to send and receive email, only 21% of females can do this. Massive. That's 4x. In Goa, in the same age group, 81% of the women are able to create electronic documents, only 25% of the men are able to create electronic documents. So I just... where is this conversation... so I shared this with Rohit Saran and he said, "Thanks Anand, these are interesting, should we plan these for the next series of Stat-O-Istics?"

**Anand**: [16:48] And as soon as the students can, we can give them a byline and mention a footnote mentioning IITM as well. So a tiny little two-marks student exercise is going into the national newspaper. That is how little effort it takes **because the verification is fairly robust**. Every one of them provides this verification, and another agent went about doing that cross-verification, found... and that's exactly what you see on the right side, one of the teaching assistants ran a script that does that verification giving it a certain level of robustness.

**Anand**: [17:15] In short, once you are able to verify this by having the source system that produces the output give receipts, citations etc. you get a fair bit of power. **A third related technique is an audit.** Now this is where you dive in. An auditor comes and checks your financials, an inspector comes and checks whether your home is okay, what the evidence is, a radiologist cross-checks across all of these.

**Anand**: [17:33] And this can be done for all kinds of documents. We took the NCERT 12th standard history textbook—it might have been 8th standard, some senior textbook—and said, "are there any mistakes in the textbook?" First four or five chapters. And it turns out that there are a bunch of mistakes in that textbook. One of the most critical ones was "only broken and useless objects would have been thrown away."

**Anand**: [18:24] Whereas the reality is—and there's a fair bit of research that's done—ritual destruction of intact objects is pretty common. That is what civilizations do: they take objects which are perfectly fine and they give it as offerings. Sometimes they travel to a different settlement. So, usually we don't find broken or useless objects, we often find intact, perfectly functioning objects. This is an actual mistake in the book. The rest were debatable.

**Anand**: [18:55] It said, "Mauryan army had 600,000 foot soldiers, 30,000 cavalry, 9,000 elephants etc." Where is the strong proof that this is the case? I can't strongly say that there isn't either, just trying to show the Mauryan army as very strong, fine. The good part is if there is a corpus, an existing corpus, agent-generated, human-generated, doesn't matter. Once you have the corpus, like we saw in the earlier diagnostic phase, we can run an audit on it and that provides us the ability to do all kinds of analysis. This is something you can do to an auditor as well.

**Anand**: [19:40] So, a few weeks ago, a few days ago, when I filed my income tax, I asked my auditor, "are these calculations correct?" And she said, "yeah obviously blah blah blah," I didn't understand a single word, I asked ChatGPT, "are these calculations correct?" ChatGPT said, "Anand, there is one particular case, Anushka vs. Income Tax Office, where a Singapore tax resident who had sold their mutual funds got full benefit according to a double taxation agreement." It basically means you're not taxed like you're in India, you're taxed like in Singapore where there is no tax for capital gains. And as a result you will be saving 14 lakhs.

**Anand**: [20:25] Went to the auditor and said, "Boss, is this correct?" She said, "No no no yours is an NRO account, that must have been an NRE account." I asked ChatGPT, "was that an NRE account?" It said, "The judgment explicitly does not use the nature of the account, it only uses residency." I told her that. "Let me check with a senior consultant." Went, came back and said, "Yeah you'll get the 14 lakh refund."

**Anand**: [20:49] Okay, so I have audited an auditor, which is pretty cool. **You can take one model's output, give it to another model and audit it.** This is one of my most used prompt snippets. I just give the same prompt to Claude, give the same prompt to ChatGPT... I used to do that with Gemini but these days Gemini's lagging so I don't bother. And then say, "here's an answer from another model, fact check it, critically evaluate it, take what is good, drop what is bad, and you give me a revised response."

**Anand**: [21:18] This has almost always given me something that is much better than not just either model but repeated iterations with one model. **Auditing is a technique not just to find mistakes, blind spots etc. in one model's output, it is also a technique that can boost models' outputs.** This is the full version of the prompt, it's slightly longer.

**Anand**: [21:38] And this is something that we can use to test whether advice that people give us is right or wrong as well. So, for instance, there was a recent tweet from Benjamin who said, "Andrej Karpathy said because agents are getting so complicated, I want them to explain in simple English, so one of the things that I add is ASD-STE100 Simplified Technical English, always communicate in this form." I tested it. The output is definitely simple, it is definitely readable. Ben said, "I'm going to add this to my `agents.md`."

**Anand**: [22:25] So I said, "wait hold on, let's test this." So I had ChatGPT or Claude or whatever say, "look, give me a bunch of simple tasks, here's one, here's another." So if I had this particular question and I asked the models this, or I had another question... a bunch of questions... and I asked the models with and without this particular prompt, does it make a difference? You audit it. Had an agent run through and the result is interesting.

**Anand**: [22:58] It said, "I looked at these tasks, run both ways, and evaluated against correctness, whether it caught the key drivers, mechanisms, calibration etc." And the reds are where the addition of that prompt "write in simple language" makes it worse. In other words, there was only one case out of several dozens where if you tell it to write simply it comes up with a better answer. In a few cases where it does not come up with a worse answer, **majority of the cases you tell a model to write in simple terms it also thinks in simpler terms.**

**Anand**: [23:44] Did not expect that. But advice therefore can also be audited. And this is something that now you can do as a matter of course. It can be one-shotted. What I mean by one-shotted is tell it, "here is an advice that I got, prove or disprove by doing whatever you need to do." And give it enough tokens... this didn't cost me... actually this cost me nothing because I manually ran this on ChatGPT by copy-pasting and all that, took me about three hours or so but not me doing... three hours of elapsed time, my time was about 20 minutes, half hour maybe.

**Anand**: [24:19] **Another technique that we use is voting.** Why is voting a verification mechanism? **We want to learn from the wisdom of crowds.** Who, what is the majority opinion on who should be the leader of this company, country, whatever? What do the majority of critics say? Can we get, run a poll and get inputs on that? We tested that.

**Anand**: [24:43] So there were a series of chat messages: "help with adding to some team, when will I receive my order etc." Is a model correctly classifying it? And what we found is that different models have different levels of accuracy across, but when you run multiple models together—and because the results of the models are uncorrelated, largely uncorrelated, some models are highly correlated some models are less correlated—if you take a bunch of models and have them double check... if I run a random model I have 14% error. If I have two models and say I will only take when both models agree, I get only a 3.7% error. If I ask five different models and take the result only when all five agree, I get a 0.7% error.

**Anand**: [25:31] Now this means that we have a mechanism of using the wisdom of crowds effectively, different models voting, to come up with something that can have not exponentially high accuracy but certainly significantly higher accuracy to the extent to which agents have learned from humans. This causes a certain queue of rework. Because if even two models don't agree out of those five, what do we do with it? We'll probably put it into a human queue. That volume was about 28% with five models. Now what was then seen is, "look I can give you 99.3% accuracy and reduce your effort by 72%." Take it. I mean as good as it gets. And especially if we said, "look with maybe two or three more models that 0.7 I can get down to 0.6, maybe 0.5," maybe we won't get it down below 0.5 ever, but it's still a possibility.

**Anand**: [26:19] Finally, examinations. This is probably one of the most robust methods that we have of verifying or testing things. Whether it's a driver who has to pass a certification, whether it's diamonds that go through a certification, Kerala bus that undergo testing. This is probably the one that you're most familiar with. I'll skip this.

**Anand**: [26:44] But, oh yeah, one of the things that we simply do is have code verify. But it is actually surprisingly more common than that. Lean in mathematics is one verification technique. But I was shocked to find that insurance has the equivalent of Lean. It's called Insurely, came up with Cambridge. What they do is they take claims and... what you can do is convert claims into an Insurely contract. So let's say this is one of the vehicle insurance contracts. This can be converted into an Insurely structure like this.

**Anand**: [27:32] "A claim is valid if the driver is fully eligible, the vehicle authorization is valid, the incident circumstances are covered, the claim procedure is followed." How do you find out if the driver is fully eligible? If they are age-eligible, license is compliant, driving license is acceptable etc. And this is a formal language that you can write code in. You can take a claim and verify against that code.

**Anand**: [28:01] So when somebody passes a claim... and let's see if I can find one such claim form... yeah here's a claim form... where is the... okay yeah... here is a verification... I'm not sure if it was a better verification sequence than this... invalid, facts, valid claim... okay I'm not able to quite find... okay yeah maybe yeah this is where it's checking. So it's going through each one of these and saying, "is continuous enrollment as a condition satisfied? Is emergency override there? Was the person enrolled for more than 90 days?" And it finds violations in the claims right across.

**Anand**: [28:56] What this means is that the person who's validating the claim gets a document sort of like a checklist validated against a programming language-like structure. So the only thing they need to make sure is: did the agent convert from that original specification, which is the claim or the insurance policy document, to the correct formal language? Which is a one-time verification that they can do upfront, a benchmarking that they can do on an ongoing basis. But after that it is purely deterministic. So effectively **we are giving an exam to the claims, both the policies as well as the claims that have been submitted, and if they pass, then they pass. It is deterministic.**

**Anand**: [29:26] I'm going to skip this again in the interest of time and see if we can take some time. I'm going to leave you therefore to the broad premise which is: **even for verification, we have several professions that we can learn from where they are verifying intelligences that are smarter than themselves.** And checklists, asking for receipts, auditing them, voting getting inputs from multiple people, and examinations are the kinds of techniques that we have been able to apply.

**Anand**: [30:00] What I'd like to do before I go to the survey results that we may have shared—and if you haven't filled it out, please feel free to fill it out—is... yeah, firstly feel free, we still have maybe a few minutes for questions and I'll take one or two. But you're welcome to reach out to me during the conference, I'm here today and tomorrow. Please do reach out, I'd love to chat and hear what you're working on and what's interesting, or any time post facto. But what I'm quite keen on doing even before we go to the questions is see if I can have the results for at least one of these questions.

**Anand**: [30:26] Alright let's see if I can create the map out of this. Okay well it's unconfigured, we'll come to this. How do people... how does this group usually check AI output? We have 79 responses. Most of us skim it, which is interesting. Some of us read it all. No one doesn't check it. Good to know. And a reasonable third option is that we ask a second model. How often do we find an error? "Never," nobody has never found an error. "Almost never" is very small. "Sometimes" seems to be the result. I'd love to see what this would have been a year ago and what it will be a year from now. That can be a fairly interesting result.

**Anand**: [31:07] I will... actually these questions I will take the liberty of answering over email since you have shared and you may update. The form will vanish after this session because it's running on my laptop and once I close it it won't be available, so you still have a few minutes. But what I'm going to leave you with is just a couple of things. **There are two things that I teach forward-deployed engineers today: one is you need to learn how to specify to agents, the other is you need to learn how to verify from agents.**

**Anand**: [31:43] Both of these are things that we have learned from several professions and can adapt. These are things that are human skills that you need to practice, at least for the next one year. Next year we'll see where we go. Thank you.

**Host**: [32:00] Thank you so much, Anand. We may not be able to take the live questions, but you can connect with Anand offline. He's going to be around. That being said, I think we can definitely agree that human intelligence plays a pivotal role no matter what the subject is. That being said, ladies and gentlemen, once again please give it up for Anand. And to keep you informed, our next session is going to take place at sharp 2:00 PM in the same hall. Please do join us. Thank you.