What is this course really teaching?

At 4:30 PM on a Monday, a room full of students dialled into a video call expecting to interrogate their professor. Anand had other plans. Before he answered a single question, he dropped a link in the chat — forms.s-anand.net — and asked them to fill in a form.

"This is a session where you can ask me anything, and I have lots to ask you as well."

Anand, 11 seconds in

The form looked innocuous. Seven questions, most of them optional. But it had been designed the night before as an experiment, complete with five written-down predictions to be scored afterwards. Two of the questions were near-identical twins, deliberately placed one after the other:

• Which ONE contributed most to what you actually learned in TDS?
• Which ONE contributed most to getting marks in TDS?

Same eight choices both times. GAs/ROE. Projects. AI tools. Classmates. TAs and live sessions. Course videos and reading. Struggling on your own. Other. Neither question was editable after submission — you got one shot at each, and you answered the second one knowing what you'd said for the first.

Thirty-seven students answered both. What came back is the most interesting number in this entire story.

Read that split slowly, because it is not the scandal it first looks like.

The lazy conclusion is assessment misalignment — students are being graded on something other than what they're learning. But TDS explicitly permits, and loudly encourages, exactly this. You are allowed to use AI. You are allowed to use your classmates. You are allowed to use the entire internet. So the marks aren't measuring the wrong thing; they're measuring a different thing — the ability to marshal the world to get a result. The wrestling with the GA is where the learning lives.

Two constructs, quietly separated: "can you get the result using the world?" and "what capability has actually become yours?" Both are valuable. Only one of them is what a score usually claims to mean.

The other detail worth staring at: only 2 of 37 students named videos and readings as their main source of learning. Four named Projects as their biggest teacher and zero named Projects as their biggest source of marks — projects appear to be almost pure learning, mark-free. For a course that deliberately deleted its own content and kept only the evaluations, that is a design working exactly as intended.

"We removed the course content. We only have evaluations, and we're saying, 'Solve it by hook or by crook. I don't care how you solve it, just get there.' And the entire internet is there. Why are you relying on me for creating stuff?"

Anand, on why TDS has no syllabus to memorise

"What do you think TDS is actually teaching you?"

Ten minutes in, Anand turned the microphone around. One sentence each. Raise your hand or type it in chat. What follows is one of the more remarkable pieces of collective self-assessment you'll read — a room of students describing, unprompted, a curriculum nobody wrote down.

Notice what nobody said. Nobody named a tool. No Python, no FastAPI, no Docker, no uv. Twelve people described a stance — permission, partnership, question-asking, resourcefulness, time discipline. One person, Himanshu, said the quiet part out loud: maybe I learned nothing, because AI did it all. That objection will keep resurfacing, and Anand will spend a good part of the hour answering it.

Aditya's answer is the sleeper. "Permission" is a strange thing to list as a learning outcome — and yet, for students trained by a decade of schooling to keep reading until they understand everything, being told you may stop and ship is genuinely new information.

The exam that had to exist

The first question on the form was blunt: "As we are relying on AI for all assignments, what's the expectation from End term exam in person?"

Anand's answer was disarmingly honest. "The end term exam will be very simple." And then: "The end term in-person, no internet exam is a statutory requirement from the Senate, so it is there because it has to be there. I actually don't know what it will cover. Please ask Prasanna."

Prasanna, who sets the end-term, unmuted and took the question:

"It's more to give logical reasoning based on the knowledge that you have gained through these different courses… It will be a multiple-choice question, and there could be some subjective questions as well."

Prasanna, on the end-term

And here is the moment where an AMA turns into a design meeting. Anand, live, on the call, decided to change the exam:

"And now that gives me an idea. We will probably increase, Prasanna, if you're okay with it, the subjective-type questions a little bit… One of the major things is: how do we prompt and how do we verify? AI does the middle stuff well. The stuff that we ask for and checking the stuff that we get out is where the quality of prompts becomes important."

Anand, inventing a syllabus change in real time

The reasoning is neat. In an online graded assignment, "what prompt would you give for this?" is a trivial question — you paste the question into a model and ask it to write the prompt. That's meta-prompting, and Anand's verdict on it is generous: "Good technique." But in a closed-book hall with no internet, the same question suddenly measures something real. So: "practice learning how to prompt, specifying problems well, and verifying solutions well. These two will be part of the end term for sure, now that I think about it."

Now that I think about it. Somewhere, a hundred students updated their revision plans.

"Not only is it not a bubble, it is underestimated"

One student — Ishaan — was so keen on this question that he pasted it into the chat three separate times over half an hour: "do you think AI will bring a big crisis in the job market, or will it become a bubble like the 2001 dotnet bubble?" Uday had asked the same thing on the form. Anand took it head-on.

"Not only is it not a bubble, it is underestimated. Usually, people underestimate long-term impact and overestimate short-term impact. Short term, maybe we have overestimated — I don't know — even that I don't think so."

Anand, on the AI bubble question

That first sentence is Amara's Law being deliberately half-rejected. The argument that follows is the interesting bit: even if every model froze today, the unexploited potential of what already exists would keep the economy busy for years. Capability isn't the bottleneck; deployment is.

He then took the strongest counter-argument seriously — the claim that AI is growing along a single axis, and that intelligence is overrated:

"That may be true, but the sheer number of problems that we can solve given perfect intelligence is enormous."

Anand

Elsewhere in the hour, a subtler version of the same question arrived on the form and never got aired — Spandanjit asked whether TDS is chasing trends too hard, given that companies are already capping AI spend. It's one of the sharpest questions of the day, and it's sitting in the FAQ queue.

Willpower is a bad plan. Build assets instead

Jeevana had asked how to tackle complex tasks — what behaviours, how to work under pressure. The expected answer is grit. Anand's answer was almost the opposite of grit.

"People can push themselves behaviorally 5%, 10%, 20% better — maybe even 100% — by sheer individual ability, willpower, etc. But how much ability and how much willpower do you have, and how many courses will you apply that to? It helps to have something else that supports you."

Anand, on tackling hard things

Then a list of what "something else" means, which starts sensible and ends somewhere delightful. Agents are an asset — you give them a task, they get it done. Money is an asset — "I don't have to worry about cooking; I can eat at a restaurant, and that is one problem solved." Friends are an asset. Your notes. Your relationships. How you organise your laptop, your file system, your prompts, your scripts.

"Any kind of asset that you can build is an advantage… What are things that put you in a good position to tackle complex tasks without needing much by way of willpower or behavior change? That it happens automatically — that is the best situation."

Anand

And then the escalation ladder for getting out of bed at 6 AM, delivered completely deadpan: set an alarm. If that fails — "well, in my case, I tell my mother to wake me up." If that fails, commit to friends who will physically come and shake you. If that fails: "schedule a timer that will automatically, I don't know, turn on the AC, give you an electric shock at 6:00 AM — whatever."

The point underneath the comedy is a real one, and it's the same point as the course design: you are engineering systems and people to solve your problem so that you don't have to rely on your limited abilities. Which is, when you think about it, exactly what delegating to an agent is.

Field notes from GA5 Q11

Anand asked the room the single best diagnostic question you can ask a student: "Tell me about the last or most recent TDS problem where you were properly stuck. What did you do?"

Almost every answer converged on the same assignment. Graded Assignment 5, Question 11. It has entered TDS folklore. One student said it took two days. Another said four to five. It is the closest thing this course has to a shared trauma — and it turns out to be a near-perfect natural experiment in what "difficulty" even means.

Anand read the chat aloud as it scrolled: Varun's $700 friend, "which amortizes the cost, which is great." Devanarayanan's answer — "Build tools and use agents to get the human out of the loop" — got a single word: "interesting."

The image nobody could place

The other recurring nightmare was a Street View geolocation question in the ROE: here is a photograph, find its coordinates. Three completely different escape routes emerged, and each one is a different theory of problem-solving.

Three students, one question, three radically different definitions of "solved." That is the whole course in miniature.

The TA who was awake at 3 AM (and the students who noticed)

And then, mid-discussion, the chat produced the funniest and most revealing exchange of the hour. It began when Anand read out one of Angad's messages, deadpan: "Angad says, 'I know that Jaydeep TA sleeps at 3:00 AM.' Okay, that is helpful — leveraging the TAs is a good strategy."

Except Angad had not meant it as a metaphor.

Unpack that. A student noticed that one endpoint had scored full marks on the hardest question long before anyone else, reverse-engineered whose it was from the submission timestamps, and then wrote a loop that polled the TA's server and harvested answers whenever it happened to be up. The TA, cheerfully, explains that his 3 AM activity was Codex running unattended overnight in what he calls "Yolo mode."

Nobody was punished. Nobody was even scolded. In a course that grades resourcefulness, this is not misconduct — it is an unusually complete demonstration of the learning objective, performed by a student, on a teaching assistant, live in the chat, with an apology attached. Angad also mentioned, almost in passing, that TDS got him into bug bounties and that he'd found his way into a bank's admin page. Anand's reply: "That's something that we might be introducing in some of our projects going forward."

The confession: TDS was hackable for years

Angad had also submitted, on the form, a question that reads like a love letter with a challenge stapled to it: "I really appreciate the way you have designed TDS… is it wrong to feel that TDS can be made even more challenging?"

Anand's answer began somewhere unexpected.

"The difficulty is a relative thing these days. Somebody who finds that an agent has solved the problem — because maybe they've given the right prompt or have set it up the right way — finds that it's so easy. And somebody else who's figured out that they know the right people to reach out to finds that they have to take zero effort. And the people who have not yet figured it out are struggling."

Anand, on why "is it hard?" is the wrong question

And then, unprompted, the confession:

"For many years, TDS was entirely hackable, meaning all you have to do is figure out what is the API to send a request… the entire set of answer scripts is there, you just put in the score that you want, it will directly save that score. In that sense, every question was hackable. The percentage that hacked it was less than 2%, 3% for almost a year. So I left it open. Now we're finding that that percentage has gone up to about 15–20%, so now it makes sense to make it a little harder."

Anand, on the open endpoint he deliberately never closed

Read that again. The grading endpoint was wide open, and he knew, and he left it that way — because so few people had the resourcefulness to find it. The hack rate wasn't a security metric. It was a learning metric. When it crossed 15–20%, the lesson had been learned by enough of the cohort, and the difficulty had to move.

"If there is an open exposed endpoint, why are people not able to figure it out? There are many good reasons. They don't have enough friends; the community has not yet formed; they haven't thought about it. But these are also parts of things that we're teaching."

Anand

So: "Can TDS be made even more challenging? Yes, TDS is continuously becoming more and more challenging." Partly by design, partly because agents keep getting better and yesterday's hard question is today's one-shot. But with a governor on it — "there was a time when TDS was the easiest course… Right now, TDS is not considered among the easy courses, so we probably won't make it more challenging than the natural pace of students' learning."

The same question was transformative, enjoyable, and useless — depending on who you asked

Here is where the form did something the discussion couldn't. Half the respondents were shown "describe one painful TDS experience that taught you something you still use"; the other half got "…that taught you almost nothing." The split sample lets you see the same assignment from both sides.

The conclusion writes itself: desirable difficulty is not a property of a question. It's a property of the meeting between a question and a particular learner at a particular moment. The useful design question isn't "is GA5 Q11 too hard?" It's: at what point does productive search turn into unproductive looping — and can a course detect that transition?

One student put the mechanism precisely, in answer to "what does the TDS team believe that you think is wrong?":

"There is sometimes an assumption that struggling with a problem for a long time automatically leads to learning. In reality, without timely guidance or feedback, students can spend a lot of time debugging the wrong approach and mainly learn how to get past that particular question rather than understand the underlying concept."

Angad Jangir, on the form

The counterpoint, from another respondent, is just as short and just as good: "Surprisingly, there was no pain that was not educational." — Aaditya Bugga.

Why learn anything, if the machine can do it?

Dev Verma had asked the objection that every teacher in 2026 is fielding: if students let AI do the basics, they forego the manual effort, and the only thing they learn is to operate a generic tool. Anand agreed with the premise and then declined the conclusion.

"When a tool is available to solve a problem, the industry is not going to pay someone to do the same thing slower, costlier, and at lower quality. Today, many of the things that an agent can do, there is no point for a human to learn to do."

Anand

Then the qualifier, and it's a good one. Sometimes the process is the point, not the product.

"Today we do exercise. Why? I mean, is there anything as pointless as exercise? Lifting a weight — a machine can lift a weight better than you can, but you're doing this to build your muscle. Similarly, why are we learning mental multiplication when a calculator can do it? Because it trains our mind to think about things in certain ways. The rigor is important."

Anand, on why we still learn things machines do better

So why does TDS refuse to teach the process? Because, he argues, everyone else already is. "Most of the courses are focusing on the process anyway. There aren't that many courses that are teaching you to get the job done. So I have the luxury of saying 80% anyway you're learning that. So in TDS, let me teach you that 20% which is not often taught."

And then the line that reframes the whole course:

"These agents are like people. They're smart enough. Now, management is a subject in itself where you get people to do stuff. In a sense, TDS is management for agents."

Anand

Which sets up his answer to Anusha's beautifully self-aware question — "For GAs I'm prompting LLM, getting answer and pasting. What do I learn from TDS?" The reply is a small masterpiece of pedagogical judo:

"You're learning how to prompt, and paste it, and getting the job done. Now, if it were that easy, you'd be scoring full marks in TDS. If you're not scoring full marks, then there is something that you haven't learned. And if a reasonably large number of people are scoring full marks, we'll then move on to the next stage of learning."

Anand

And the part he refuses to spell out, on purpose:

"This 'something to learn,' I'm hoping you'll figure out what it is by yourself — I'm not trying to make it explicit, partly because I don't know, partly because it is what I'm recruiting for, that is, your ability to figure it out yourself… In other words, good question — figure it out, like many other things in TDS."

Anand

It's worth noting he isn't speaking hypothetically about recruitment. Earlier in the hour, on whether the course makes you job-ready: "TDS is basically how I would recruit and what I'm giving people out as tasks within Straive or amongst our clients. So it is not even preparing you for job interviews; it is preparing you for the jobs themselves." With one caveat delivered immediately after — "in a year's time, this material will be outdated." The point is not the material. The point is learning how to be prepared when the material keeps expiring.

How do you check an answer you're not qualified to check?

Jai Tyagi asked the question that sits underneath everything else: "How can we verify that an AI-generated answer is correct when we don't have enough expertise to check it ourselves?"

Anand's move here is characteristic. He refused to treat it as a new problem.

"This actually is an age-old problem. How does a judge who knows nothing about engines decide on a patent case between two parties about engines? How does a regulator who knows nothing about the telecom industry pass laws related to regulation? That actually seems to work reasonably well. How does an auditor who does not understand or have access to all of the information that a company does, come in and still verify?"

Anand

He then shared his screen and pulled up a talk he'd given three days earlier at the Data Hack Summit — titled, appropriately, "How do you manage something that is smarter than you?" — and walked through five verification techniques, each stolen from a profession that has practised it for centuries.

The fifth one is the one that's quietly eating the world. "This is exactly what's happening with mathematics today, which is the agent says, 'I have solved a theorem,' and we pass it to Lean, which is a programming language that can verify mathematics, and we get the result."

Can this generalise? Anand's example was insurance: take a policy, compile it into a formal language; take a claim, compile it into the same language; then mechanically check whether the clauses and exceptions fire. He called it "Insurly" — the demo is Insurle, and the underlying idea (formalise the contract, formalise the claim, let a theorem prover decide) shows up in recent neuro-symbolic agent research too. A sibling of the same idea is his own policy-as-code experiment.

"These are traditions from several professions in the past, and therefore how we verify need not be a new problem. It's something that we have solved in the past and we can learn from these professions as well."

Anand

The blind spot: the word nobody said

Now for the finding that only shows up if you go looking. After the session, all 70 free-text answers on the form — every durable-skill answer, every struggle story, every disagreement — were searched for four words.

This matters because it reveals the shape of the story students have internalised. It goes:

problem → AI/tools → persistence/debugging → answer

Which is a good story! It's the story of a resourceful person. But the story the course is trying to install is one step longer:

problem → hypothesis → answer → independent check → confidence

Debugging is "make the error go away." Verification is "prove this is right." They feel similar and they are not remotely the same skill — and the gap between them widens precisely as models get better, because a model that is usually right is far more dangerous than one that is usually wrong.

Which makes the timing of Anand's live decision to put prompting-and-verifying into the end-term look less like a whim and more like an instinct that the data confirmed an hour later. The suggested fix is almost embarrassingly cheap: after a question, ask one more question — "How do you know?"

Students, notably, are acquiring the behaviours faster than they're acquiring the vocabulary. 71% of the durable-skill answers described a portable strategy — decomposition, resourcefulness, collaboration, adaptation — rather than a named tool. They are doing something real. They just don't yet have Anand's word for the most important part of it.

Divyanshu's is the one to frame. He is not saying "I learned Claude." He has independently arrived at a portable theory of delegation and management — the same theory Anand has been trying to teach for years. That is what success looks like, and it showed up exactly once.

"What does Anand believe about learning that you think is wrong?"

The last question on the form was an invitation to dissent, and it was the one Anand most wanted answered. Twenty people took it. Eight said some version of "nothing" or "I don't know" — including the single best non-answer of the day:

"That sounds like another ROE question. I don't have an answer."

Umapathy G, declining to be assessed

The twelve substantive disagreements clustered into two camps, and they contradict each other — which is exactly what makes them useful.

Now put Camp A next to something a student said in the open question. Varun — the same person who'd typed "TDS has taught me how to fool large language models" — asked:

"How do I overcome the TDS mindset creeping into other courses? I remember the first few weeks of doing java assignments after TDS started, I had to constantly resist the urge to paste the assignment into an agent and make the agent solve the assignment for me."

Varun, on the form — asked three separate times, which tells you how much it bothered him

This is the most quietly alarming data point of the day, and also the most encouraging one. Transfer happened. A habit formed in TDS reliably fired in an unrelated Java course. That is precisely what a course designer dreams of.

But look at what transferred. Not "decide what to learn versus what to delegate, then verify." Just: "delegate." The memorable rule turned out to be a little too memorable — and the tension students keep circling isn't should we use AI, it's when am I producing, and when am I practising? Production mode says: get a robust result efficiently, use everything. Practice mode says: install this capability in my head, so do one manual rep. TDS is almost entirely production mode — deliberately, distinctively — and students are left inferring the boundary for themselves.

Anand's answer to Varun refused to draw the boundary for him, and instead reframed the whole thing as a question of agency:

"This is like asking: how do I resist the urge to get onto social media? Or how do I resist the urge to just play video games… If you just went to the agents fully and said, 'You solve it for me,' there are certain skills that you will not be picking up. But maybe it doesn't matter. Maybe that is not the area that you end up learning skills in. Maybe you will spend the time that you save by doing that, learning something else. What could that be? I don't know. Professional dancing? Who knows?"

Anand, declining to moralise

The only instruction he was willing to give was about how to choose, not what to choose:

"Whatever you're doing, try to do it intentionally. If the mindset comes in, just pause for a second saying, 'I'm doing this. Do I want to do this?' And at that moment, if you say yes, do it. If you say no, don't do it. Secondly, write it down… You'll find journaling to be one of the most powerful techniques. And you can always take that journal, give it to an LLM also, and say, 'Here is how I'm deciding, how can I improve myself?'"

Anand

Or, compressed: "When you do something intentionally, at least you know where you're going and why." Prince Kurien, on the form, had independently proposed the institutional version of the same idea — "A learning log should be requested, along with a proportion of the mark for uniqueness."

"If AI becomes 10× better next term, what should I stop teaching?"

Anand's second big question to the room. The answers came fast, and collectively they sketch a curriculum that doesn't exist yet.

Anand's running commentary as he called on people was itself a taxonomy: "Interacting with humans rather than with AI. Got you." … "Security at scale is a fair point." … "Specification and verification is where I think you're going." … "Effectively evaluating outcomes rather than…" … "Working alongside rather than against AI."

Not one student proposed teaching more tools. Every single answer moved up the stack — to specification, judgment, security, documentation, human interaction, or the design of the problem itself. A room of students, asked to redesign their own course under a 10× capability shock, independently converged on the thing that AI cannot yet do: decide what is worth doing, and whether it was done right.

Careers: the rise of the vibe-code fixer

Aaditya — a self-described "non-tech person from a traditional industry" wanting to move into product management — asked for career musings. The answer was more optimistic than he probably expected.

"The execution part is becoming easy. So, telling agents what to do and figuring out if that is correct is growing. Therefore, the role of someone who is non-tech in the traditional sense, maybe even tech-adjacent, is growing. And this is exactly what a product manager does, which is telling a team what to do — and in this case, the agent becomes the team — and verifying if they've done their job right."

Anand, on non-technical careers

The economic logic: because agents execute so cheaply, the number of people needed to specify what to execute goes up, not down. The shape of those jobs? "I don't know."

Soham then asked the question every final-year student is actually asking: "TDS is hard but I loved it; still, traditional coding gets tough, so why is fresher job hunting still so heavily DSA-oriented?" (It took the chat a moment — Anand initially guessed DSA meant "Data Science and Analytics" before Devanarayanan, Aaditya and Suyash all corrected him in unison: Data Structures and Algorithms. Varun's gloss: "leetcode grinding etc".)

The answer had two halves, and the second half surprised the room.

Half one: the industry hasn't caught on yet, and there's a chain of reasons why. "There is an HR team who gets requirements from the business team, who gets requirements from the client project manager, who gets requirements from the client business stakeholder. If the client business person has not yet caught on to the need for someone with a very different skill profile, the entire chain has not yet caught on." His estimate: Data Science took three or four years to establish as a role. "I expect forward-deployed engineers to happen a little faster than that, probably a lot faster."

Half two: actually, DSA is about to matter more, not less.

"There really is a need for Data Structures and Algorithms because people are vibe-coding like crazy. A big role that is emerging is 'vibe-code fixer.' Somebody has created it, it's a mess — which is a good thing because somebody's finding it to be a useful mess. So somebody has to come and clean up the mess."

Anand

Or, in the least sanitised phrasing of the session: "maintaining code, which people and agents have vomited out and nobody knows what to deal with, will be a growing thing." Two demand curves rising at once — "the demand for agentic use will grow a lot. But the demand for more structured programming will also grow."

How to predict five years out (spoiler: you can't, so predict something else)

Shivam asked how to read the direction of AI over five to ten years. Anand's answer opened with a confession — "I am trying to figure out as well and I'm in the same boat as you are" — and then offered a genuinely useful trick: stop predicting where AI will go, and predict where it can't.

That third card is the sharpest observation in the section, and it doubles as a labour-market forecast: if AI raises output per hour, we don't get shorter days. We get more output. "These are businesses that one can invest in because you have something that is likely to be protected irrespective of technology."

Two questions about course design, answered like an engineer

Shishir had a complaint that reads like a bug report: "Why are we saving the last submission instead of the best submission? Since we create the server only once, and it is hosted on Cloudflare, it may be lost or reset, causing all progress to be lost."

Anand did two things at once. First, he took the suggestion seriously and immediately imagined how he'd exploit it: "Supposing I said we'll take the best response. Here is how I would approach the question. I would create 30 servers, tell it, 'Create random answers.' One of them is bound to be right." Not a criticism — an endorsement. "This is not a bad strategy. And I'm not trying to discourage that strategy either." He took it as a to-do: some future questions will explicitly say toss 100 answers at it, we'll take the best.

Then he explained why it can't be the default, and this is the best defence of an annoying design decision you'll read this year:

"The whole point of I'm hosting it in an environment where it might get reset — that is exactly the kind of real-life problem that an agent is not going to be able to solve for you. Today agents can create so much code that creating the code is not the difficult part. It is: how do I get the code to be reliable enough in a deployment environment? … If I can't run 10 services in one session, keep them all alive, then I haven't picked up the skill to be able to deal with the deluge of code and services that agents will be able to provide."

Anand, on why your Cloudflare deployment has to still be alive at grading time

Or, in one sentence: "the thing that is difficult is exactly what we're trying to test if you're able to learn."

Can AI judge human experts?

The last question of the hour, from Jai: can AI agents act as judges or auditors of human expert work in high-stakes domains? Anand inverted the framing entirely.

"If an AI agent comes in and says, 'I think you are doing X right and Y wrong because of blah blah blah,' it is so high-stakes that I will verify what it's saying as well. Now it's giving me an extra pair of eyes. I wouldn't mind. So if we use AI as an additional pair of eyes, it's both harmless and reasonably high impact because it might be able to literally look at things with a fresh perspective."

Anand

The counterfactual matters: high-stakes industries need experts, and experts are expensive. If AI can prepare 50% of what an expert checks, so the expert only has to glance and approve, that's real leverage — with the caveat that you'd still sample outputs to watch for drift.

And then the reframe that should probably be printed on a poster somewhere:

"I don't think the segmentation is: is this high-risk or low-risk industry? It is: how we break the task. Is it generation or is it verification? Is it preparation of verification or is it approval of verification? Is it verification of simple tasks? Is it verification of subtle tasks?"

Anand, on the only risk taxonomy that actually works

Which lands us, an hour later, back at the word nobody in the room had used about themselves.

The close: an email address that answers itself

The hour ran out with fifty-odd questions still unanswered on the form. So Anand did the most Anand thing possible. He gave the students an agent.

"For the next 21 days, till the end of the month, my email ID is available and I'll give you a specific email ID: askai@s-anand.net… Any email that any of you send to this will be answered by my agent, which has all the context of TDS and my work and everything else, and you will get a response within a day. It's a human-in-the-loop; I'm still very much looking at the inputs and outputs, but it saves me bandwidth."

Anand, closing the session

Consider what just happened. A course that spent an hour arguing about when it's legitimate to delegate work to an agent ended with the instructor delegating his own office hours to an agent — and disclosing it, precisely, including where the human stays in the loop. Checklists, receipts, audits, voting, exams; specify, then verify. He demonstrated the entire curriculum in ninety seconds, using himself as the worked example.

Angad, who had spent the hour looping a TA's server, had already typed his verdict into the chat a few minutes earlier:

"Sir, the way you think about problems and design questions inspires me a lot. I feel if a professor can think at this level, then I should also push myself to reach that level someday. That's why, Sir, you are genuinely one of my idols."

Angad Jangir, in chat