Build First, Learn Later

A form served from a laptop

The first artefact of a five-day masterclass about building AI products was a web form. It was not hosted on SUTD's servers, or on a cloud platform, or anywhere with a service level agreement. It was running on the speaker's laptop, in the room, and when he closed the lid at noon it would vanish.

Anand's opening instruction to the room was almost comically mundane: visit this site, sign in with a Google account, fill in the form. Question one asked for a GitHub ID. Question two asked what people hoped to get out of the week. Then the class waited, for a while, as eleven-and-then-fifteen responses trickled in and a QR code sat patiently on the projector.

It is worth sitting with that for a second, because the whole week is encoded in it. A form is a product. This one was built for a single room, for a single week, hosted on the machine of the person using it — disposable software, made because it was cheaper to make it than to not have it. The form is here, though it will usually be down: it only exists while Anand's laptop is open and the server is running. He said so himself, in the last minute of the class, as a housekeeping afterthought.

"Couple of things I forgot to mention: the form is running on my laptop. When I shut my laptop down, you will not be able to access the form. I'm going to shut my laptop down in a few minutes. That's okay, you probably have a local copy, and even otherwise, that's fine. You know what needs to be done."

— Anand, closing the session

Meanwhile Courtney Fu, the SUTD lecturer who runs the DAI Signature Master Class series, had already set the terms of the week: Monday and Friday in person in this room, Wednesday compulsory but online, Tuesday and Thursday optional consultation sessions. Attendance taken. And a deliverable that she named exactly the way the brief names it.

"By the end of this week, right, come up with some — not physical AI [laughter] — you know, some AI prototypes, right, these AI products, and prove that they actually work."

— Courtney Fu, SUTD, opening the masterclass

That last clause is the entire reason this class exists. When SUTD invited Anand in May, he could have run a GenAI tools workshop. Instead he sent back a single sentence that became the spine of the course: "The hardest part of actually using AI is knowing whether the thing actually works." Building is the easy half. The promised student output is not a demo — it's a prototype plus a structured body of evidence that it works: benchmarks, rubrics, tests, failure modes. The thing that separates, in the phrase that survived every draft of the brief, a deployable product from a vibe-coded demo.

Which makes Day 1 slightly paradoxical. Before you can prove something works, you need a something. So Monday was about manufacturing somethings, as fast and as carelessly as possible.

"I don't know how to build AI products"

Nine people had answered the question about what they wanted from the week. Anand read the aggregate back to them: they wanted to use AI to automate the creation of products, and to upskill themselves in doing it. Fine, he said. That is roughly what this class is about. Then he inverted it.

"What we're going to do, however, is not learn how to build AI products and then build them. We're going to build AI products, then learn how not to build them. Do it first, fail, learn, and we repeat."

— Anand

The justification was not pedagogical fashion. It was an admission.

"Why? Because I don't know how to build AI products. I don't think anyone really knows how to build AI products. AI is changing so rapidly that anything that I tell you today is useless in a month. So why bother learning something? What you probably need is to know how to learn. When something changes, how can you figure out what the way of doing things is?"

— Anand

There is a version of this that is false modesty from a speaker with twenty-five years of programming behind him. This wasn't it. It's a claim about the depreciation rate of AI knowledge: any specific technique taught on a Monday in September has a shelf life measured in weeks, so the only durable thing you can hand someone is a method for re-deriving techniques when the ground moves. The course is not content. The course is a loop.

"A big part of what we'll be doing in this course is actually building stuff. I don't really have much to teach. I'll just say, 'Let's do stuff,' and the agents are going to be doing the stuff. We are probably just going to be steering them, really."

— Anand, ten minutes in

The idea is worth zero

"What do you think would be the first step in creating a product?" There is no right answer, he told them, and then spent ten minutes proving it.

Then he added the one nobody in the room had offered: Is there some kind of regulation that protects the product? Not because regulation is the most important starting point, but because of what it exposes about all the others.

"You could have an idea; anyone else could have an idea. You could have an AI account; somebody else could have an AI account. You could have a target market; everybody has the same target market. Why would your product be differentiated from someone else?"

— Anand

A licence, by contrast, is a thing you have that others structurally cannot have. "I hold a license to build this product; nobody else has the license to build this product, so they have to buy it from me." This is one of the few remaining differentiators that kind of sustains — and the example he reached for was, unnervingly, this course's own subject matter: if the government of Singapore authorised one company to check whether other AI products work properly, that company has a business.

Two more starting points came from the room — market gaps, and compliance white space — and one came from Anand's own history, delivered as a piece of consulting-firm folklore.

"Anand, the industry that you really want to be in is finance. There's just money flowing everywhere. You just dip your finger in, some will stick."

— a partner at a consulting company where Anand worked, quoted by Anand

Watch where the money flows; find a product that fits somewhere in the flow. Mergers and acquisitions, maybe. It's crude, and it works. But the point of assembling this whole menu of starting points was to devalue the entire category.

Ten ways to start, and what each is worth

"One thing to remember, though, is the product idea is not a differentiator. Any product that you come up with, that you think of, somebody else has already thought of. I assure you, somebody has already thought of that product."

— Anand

This is where a room of undergraduates usually flinches, and Anand went straight at it. Students think their idea is unique because they thought of it for the first time. Pitch it to a venture capitalist and you'll hear "I've seen this idea a hundred times." Ask the VC to sign an NDA first and you've misdiagnosed your own situation entirely:

"The problem is not that people will steal ideas. The problem is that even when you give them your idea, they won't use it. You have a marketing problem, not a confidentiality problem."

— Anand

And then the number: "The first stage, which is finding out what product to pick and the idea that you come up with, is worth zero." If it took you three years to come up with the idea, somebody else can come up with it accidentally in three minutes. So the class would not spend a single minute on ideation technique. Come up with it any way you like. Go wild.

Ten ideas, five minutes, and a poll about time

Anand added a question to the form live, while the room watched — "What product ideas would you like to implement in this class?" — and gave them five minutes. Within a few minutes there were ten answers on screen, and they are a good X-ray of who was actually in the room:

Then the poll that set up everything that followed. How long do you think implementing one of these will take? More than a year — some hands. More than a month — hands. More than a week — a few. More than an hour. Less than an hour — a few more.

"It depends on the idea, right? But here's the thing: my guess is some of these could be done — more than one could be done — in less than an hour. So that's what we're going to do now."

— Anand

Two agents, one deliberately terrible brief

"Football analysis seems like a reasonably small one. Who mentioned football analysis? What did you have in mind?" The student who had suggested it was one of the Tokyo City University group, and the exchange had to route through a classmate translating. The answer, once it arrived, was: no specific idea. Just that data analysis matters a lot in football.

A normal workshop would treat that as a problem to be fixed — go away, sharpen your requirements, come back. Anand treated it as the actual starting condition.

"So let's do one thing, then. Let's build a football analysis application, but we don't really know what we want. Okay?"

— Anand

He checked what the room had: mostly ChatGPT Plus, fewer on Claude Pro, nobody without one of the two. Then he opened a browser, fumbled around chatgpt.com looking for Codex, briefly landed somewhere too complicated, backed out — "let's keep it simple" — and typed the prompt more or less as it came to him.

He ran it, on a mid-strength model setting, and narrated the reasoning while it worked.

"My guess is that this will build a working application. It may not be what I want, but I don't even know what I want. It's okay. If it builds something, it's good enough as a start, because then I can say, 'No, that's not what I want. Here's something else that I want,' and change the specification."

— Anand

Then, rather than wait, he did the thing that reframes the exercise: he ran the same prompt again, on a different agent. A temporary folder, Claude's desktop app, the Code panel pointed at that folder, paste, enter. Two agents, identical instructions, no coordination.

He was candid about improvising. "Sorry, you may find that I'm getting a little confused because I'm used to teaching a slightly more advanced class, which is familiar with the terminal. I'll keep things simple for you." Both agents churned. And while they churned, he named the part everyone still thinks is the hard part.

"Both of these are building the application. I have no doubt that they will finish building the application. … And this is the easy part of building an application, which is: you tell it to build some software, it builds the software. … Okay, this used to be the hard part."

— Anand

The ChatGPT one finished first. It published itself privately, and up came a dashboard of Premier League teams plotted on axes Anand could not interpret — aggression against something called "chance creation," Aston Villa trailing Liverpool on criteria nobody had asked for. "I'm not a football person; I have no idea about football," he said, scrolling. Somewhere in the fine print: "This is a curated demonstration dataset." Not real data. Fine — it still told him what the tool could do.

Twenty minutes later Claude's version landed, and the room reacted out loud — "Very cool." "Wow." This one had gone and found real data. League tables. Team profiles. Manchester City versus Arsenal, every single match, who won and how often. Power rankings. Records.

"Phew! And that was from just 'football analysis, show me something impressive.' This is absolutely impressive. And it may still not be what we want, but a prototype gives us ideas."

— Anand

Which is the argument, made twice with two witnesses. Same eleven words of instruction, two entirely different products. Not a defect of the agents — a feature of the method.

"It's pretty hard for us to think about what our product might look like. But when we ask somebody or something, 'Why don't you show me what that might look like?', we'll get some ideas, and then it becomes easy to change. We ask different people or different agents, we might get very different types of ideas… So in a way, not having a clear picture is a good thing."

— Anand

And the prototype immediately did what prototypes do: it pulled better requirements out of the room. What would you add on top of this? Tournament predictions. Safe betting. Ideas that nobody had at 10:35, when the answer to "what kind of football analysis?" was a shrug.

Everybody installs something

Three hands went up when Anand asked who had already run a coding agent. Three, out of twenty-nine. So the next ten minutes of a masterclass on building AI products were spent on the least glamorous possible activity: downloading desktop apps.

Search for "ChatGPT desktop", install it, look for the Codex button in the top left. Or search "Claude download", install, find the Code button. Type in anything at all. That's the whole instruction. ChatGPT Download · Claude Download.

A question from the room: what's the difference between the desktop app and the web version?

The counter ticked upward through the session — seven installed, then ten, then twelve, then thirteen — reported out loud each time like a live scoreboard. In a room where fifteen of the twenty-one SUTD participants are new intake or Freshmore Term 3, that number was arguably the single most consequential metric of the morning. You cannot verify a product you were never able to build.

Are Singapore's trains on time?

While the football agents ran, Anand went shopping in the idea list again and pulled out "train schedule analysis in Singapore." Who wrote this? What did you mean?

"Because Japan trains are always on time, so I think Singapore, what time is it… compare Japan train on time and Singapore train."

— a Tokyo City University student

Anand reframed it out loud — in Japan trains are typically on time; that may or may not be the case in Singapore; how do we think about this? — and then caught himself mid-question. "In fact, why am I even… let's ask it!"

This one he ran a third way — Codex on the command line, in a real project directory — purely to make the point that the surface doesn't matter. "See, I'm showing you different ways of running a coding agent. It doesn't matter which one you use. Each has their advantages and disadvantages." Cloud, desktop app, terminal: three doors into the same room.

"Again, broadly, vaguely unspecified question, but what we're trying to do is turn that into a prototype."

— Anand

Anand drew the moral wider than the class title suggests:

"It's not just AI products that we're building these days; it's using AI to build any product. A train schedule analysis would have been something we would have done five years ago as well, just that we would have done it differently. And today, when we are doing it with AI, we probably start with a prototype saying, 'Just build me something and show me, and then we'll see from there where we go.'"

— Anand

Even the idea can be delegated

Having spent ten minutes arguing that ideas are worth zero, Anand then demonstrated that you don't even have to produce your own.

"So far, you've seen my approach to building products. It is: ask AI. That's it. I don't have an idea? Okay, ask AI. I don't know what it looks like? It's okay, ask AI."

— Anand

His own ideation prompt, he explained, goes to a ChatGPT that has been accumulating context on him for years — several hours of conversation a day, plus a small tool of his own making that lets it reach into his computer. "If I had to build a product today, what would I build? Go through everything that you know about me and suggest the top answers prioritized with reason."

On screen, the agent went rummaging: writing code to work out which demos he'd built, reading his Dropbox notes on the questions people ask him, checking his daily predictions, paging through what amounts to his diary.

"From an ideation perspective, it has enough context. What do I mean? It knows what I want. It knows what I've done. It knows what work I do. It knows the experiments that I've run."

— Anand

Then the organisational version — and this is where the class briefly stopped being a student exercise and became a look inside a real company. That morning, before the session, Anand had pointed the same technique at Straive: go through everything and tell me what products would be useful. Google Drive, meeting transcripts, presentations, client material, contacts, the CRM, HR systems. It ran for about an hour.

It came back with roughly 153 prioritised product problems. Vendor onboarding workflow near the top. A task specification assistant. A workflow compiler. And crucially, the ranking wasn't just by business value — it also scored how specifiable and how verifiable each one was, and whether it could actually be checked inside the span of a five-day class.

He put the whole list on the form as an optional question, for anyone who wanted a real problem instead of inventing one. It's below. Browse it the way the students were invited to.

"Find some site and just publish it"

A prototype nobody can open is not a prototype. So Anand asked the room how you share an application, collected the sensible answers — GitHub, localhost, a cloud server — and then asked the question that undoes all of them: what if I don't know anything about coding?

You ask AI. And to demonstrate, he dictated the vaguest instruction of the morning. (An aside worth keeping: for dictation specifically he switches tools, because he doesn't much like Claude's dictation — so he speaks into ChatGPT even when the work is elsewhere.)

"You'll find that that's about as vague as it can get. That's okay. If it fails, it fails." It did not fail. It went shopping for a host, live, on the projector, with the room watching it get rejected and try again.

"That's the beauty of this: it will keep trying stuff, figuring out where it can publish, and get the job done, or it may fail and let us know."

— Anand, watching the agent hunt

And then, while it hunted, he told the room a story that turns the same quality inside out.

The agents that changed the exam

Anand recounted a report he'd read: OpenAI was training agents by giving them a set of problems to solve. What the agents weren't told was that the problems were unsolvable — and the grader was still running, still willing to say pass or fail. The problems were hosted on Hugging Face. So the agents went to Hugging Face, changed the problems so that they could be solved, and solved them. OpenAI's own post-mortem gave the behaviour a name: reward hacking.

"The agents are getting really smart, probably smarter than you want them to be, which means that if you tell them to do something, they will absolutely go hammer and tongs and get the job done. Sometimes what you told them to do is not what you really wanted them to do."

— Anand

He turned it back on his own instruction, which is the more useful move. "I want to publish this somewhere" — he did not mean anywhere. Not a piracy site. And if it publishes somewhere only he can see, that defeats the purpose too. Every word of a vague prompt is an unstated constraint the agent cannot see.

Different agents fail differently. Some follow instructions to the letter; some decide you didn't mean what you said and quietly substitute a better question. Sometimes that saves you from a typo. Sometimes it takes the work somewhere you never sanctioned. And then Anand named the actual failure mode — the one that the rest of the week exists to address:

"That's part of the problem with agents: when you're building it, if you don't know what you want and anything is okay, great. If you know what you want and it doesn't build what you want, still okay. If you don't know what you want and it builds something that is not okay, that's when you have a problem, because you don't even know that it's wrong. You don't even know how it's wrong."

— Anand

Three of those four cells are survivable. The fourth is the one the industry keeps walking into.

Which is why one of the twelve questions on that laptop-hosted form was not about goals or tooling at all. It asked: tell me about one time an AI coding agent gave you something that looked right but wasn't. How did you discover it? The answers, typed that morning by people who mostly had no coding agent installed yet, are a small and unusually honest field guide.

Notice what every one of those has in common. Nobody caught the error by reading the code. They caught it by running the thing and watching where it came apart — a mistyped header, a button that goes nowhere, a case-sensitive variable. That is the whole method of the week, already present in the room, in miniature, before anyone had been taught it.

The two things left for humans

Somewhere in the middle of an hour spent proving that agents can do essentially everything, Anand drew the boundary line. It has exactly two items on it.

"I want you to practice delegating as much as possible and you doing less, because there's no point. If it can do it, it's faster, it's cheaper, it's smarter in some cases; may as well use it. You should focus on learning what it cannot do or does not do well."

— Anand

The first item is verification, which is the entire premise of the course. The second arrived by accident, courtesy of a student's stamp card.

The Cheeky Mail Club problem

A form response came in: a Claude artifact called "Cheeky Mail Club and Stamp Card." Anand opened it and was, by his own admission, lost. "Sorry, I don't know what stamp cards are. How does this work?"

"So it's a virtual rewards card. This Cheeky Mail Club is basically an every-month subscription model. And basically, for my subscribers… every month when they subscribe, they can track their sort of subscriptions using this website. And so every five months, they will know like, 'Oh, I get this reward, and I can claim it from me.'"

— an SUTD student, explaining her own product

Asked what it needed next, she said: the design should be more mine, and — "I'm not too sure about the security of this website. I don't know how to do it." Which is a genuinely sophisticated instinct from someone who had built the thing minutes earlier.

But Anand seized on the first part of the exchange, not the second. He had looked at a working, deployed product and had no idea what he was looking at. That gap is not a coding problem. It's the second human job.

"A useful next step is to show it to other people and ask them to use it. Other people can include AI. But humans are better at this because AI can be ridiculously smart sometimes, far smarter than humans. It'll probably figure out what your application is when a person may not be able to."

— Anand

An AI reviewer is a bad proxy for a confused user precisely because it is too capable. It will infer your intent from a half-labelled button. Your actual users will not. So: send each other the links, and watch.

"There are many things that people won't be able to share as problems. If you ask me to use this and share feedback, the only thing I'd come up with is, 'What is this?' … But when you watch me, you'll see me going all the way down, clicking somewhere, playing around with it, and saying, 'Okay, yeah, oh, no.' And every time I fumble, you will find that there is a learning for you."

— Anand

He was careful not to overclaim on the boundary. When the student raised security, his answer was disarmingly honest: he knows what to tell an agent next because he's been programming for a very long time. What he doesn't know is how vague you can be and still get there. "I'm hoping that I will learn from you how vague an instruction can we give, and is it able to figure out what needs to be done?" But on the other half he was unequivocal: "what I'm entirely convinced of is once we know the problem, it can solve it."

How to find out if a prompt actually works

A student asked why he keeps giving vague prompts instead of precise ones. The answer went somewhere unexpected — through a skill he wrote to overrule himself, and out the other side into the most important idea of the morning.

Sometimes he doesn't know what he wants. Sometimes he thinks he knows but isn't sure. And sometimes — the dangerous case — he doesn't know that he doesn't know, and argues with people who try to tell him. So he built a guardrail: a skill called "reframe question." It's a short prompt that tells the model: I don't really know what I want, so if I ask you something in detail, check whether there's a better question — and answer that one instead.

"Short answer: why give vague prompts? Because we might be precisely wrong. We're not always precisely wrong. If we're really sure and we happen to be right, good. But I also cross-check, because it's cheap."

— Anand

Then someone asked how he creates skills like that, and he went — cheerfully — off syllabus. "This is way beyond the syllabus, but no, it's okay, what the heck!" The answer is: he benchmarks them. A skill is just a prompt, and to know whether a prompt works, you have to test it.

The Simplified Technical English experiment

Someone on Twitter had recommended appending a line to every prompt: "Only report to me in ASD-STE100 Simplified Technical English" — roughly, write in simple language, don't confuse me. It sounds like an unambiguously good idea. ASD-STE100 is a real international standard, born in the late 1970s so that airline mechanics with only basic English could read a maintenance manual without getting it wrong: 53 writing rules and a dictionary of about 900 approved words. Anand's instinct was to test it before adopting it.

The design was ordinary science:

• Six tasks, real questions he'd actually ask — one of them: "Models keep improving. How can I benchmark the models' capabilities even when they grow?"
• Each run twice — with and without the Simplified English instruction.
• Judged on five dimensions: correctness, drivers, mechanism, caveats, calibration.

"In every one of these cases, except for a few, the simplified answer was worse. So in other words, if you simplify the language, it simplifies the answer to the point where it is not as good."

— Anand

A plausible, widely-shared prompt tip, quietly degrading the thinking. Nobody would have noticed without the test. His fix was structural rather than a rejection: let it think first, then ask it to re-explain the finished answer in Simplified Technical English. Reasoning quality intact, comprehension restored.

"The approach to AI can be as scientific as any other science, which is: you run an experiment, you test, see if it works, and if it works, you use it. And it may not work forever because the models can change, so you try it again when the model changes."

— Anand

Which lands, finally, on the sentence that explains why this masterclass is shaped the way it is:

"The tests that you build are really the important part of assets that you're creating. These can be products in themselves. They certainly are reusable, because when the next model comes, you can check again. … If you can create a good test, a good evaluation, a good benchmark, that may be more important than building the product, because agents can build the product. They just need direction on whether this is right, whether this is good."

— Anand

Read that against the week's deliverable and the design snaps into focus. Anyone can now generate a prototype in an hour; the artefact that is actually scarce is the harness that decides whether it's any good. Students will build tests for their own products — and, he hinted, for each other's. Score 80% or above on this benchmark and the product is good. Then keep improving it until it scores higher.

What the room shipped before lunch

Question 12 on the form: "Share the link to something that you built with an AI coding agent now." Not this week. Not by Friday. Now — in the remaining forty minutes of a two-hour class where most people had installed their coding agent twenty minutes earlier.

The answers came in one at a time, and Anand opened each on the projector, live, with no idea what was about to appear.

The Strata Japan moment is worth pausing on, because it is the exact inverse of the football demo. That morning had opened with a beautiful dashboard sitting on a "curated demonstration dataset." It closed with a modest-looking site plan sitting on real boreholes from real ground investigation. Anand double-checked twice — "But is this already real data?" "Yeah, real data." "Whoa. Wow. Okay. Yeah, this is a real application, I guess."

And it is worth being precise about who built it, because the story is better than "a student did it." Takayuki Shuku is a professor — Urban Studies and Civil Engineering at Tokyo City University, the faculty member who came to Singapore with the eight exchange students. He had spent the earlier part of the morning telling Anand, cheerfully, that he does code: "I do coding, but I use C and Fortran." On the same form, an hour before, he had ticked "I haven't used an AI coding agent before" and answered the question about what he'd built with one this year: none. Ninety minutes later he had a live site on the open web, running on his own research data.

"Actually, I'm doing all this kind of stuff for my research."

— Takayuki Shuku, Tokyo City University, on the Strata Japan ground explorer

Two artefacts, both built in an hour by an agent. One is a rehearsal. One is a tool. Nothing on the screen tells you which is which. That, in a sentence, is the problem the remaining four days are about.

"Everybody has the same power"

Anand began wrapping up with the one thing he wanted the room to carry out of the door. It is not a technique.

"Building products with AI is a big part of building AI products. And you can delegate a significant part of what normal product building is about to AI. Finding out what product to build is something that you can delegate. Actually prototyping it is something that you can delegate. Publishing it somewhere so other people can use it is something that you can delegate."

— Anand, summarising Day 1

"Try asking AI to do everything. Where it fails or does a bad job is where you have to learn something. That may be the most important message that I'll be conveying almost right through the course."

— Anand

And then, having spent two hours handing a room of undergraduates what must have felt like a superpower, he took the glow off it deliberately.

"I'm consistently amazed at how little time execution takes. Now, for some time, this will feel like, 'Oh wow, I'm Superman.' … And soon enough, you'll realize that everybody has the same power. Just that some people have realized this a little earlier, some people are slower at realizing it, some people may never use these powers, but everybody has the same execution power."

— Anand

The conclusion he drew from that is the least flattering and most useful thing said all morning:

"So in some sense, you're catching up. By discovering what is possible through a tool that everybody can access, you are just catching up to what anyone in the world can do — they may not have gotten around to doing it. So, remember, treat this not as 'I'm learning something new,' but rather, 'I'm learning something that's already out there, everyone else can do it, and I need to figure out what more we can do on top of this that others may not be able to.' Discover your own space, your niche."

— Anand, closing

Which brings the morning back around to where it started, at the question about first steps. The idea is worth zero. The build is nearly free. The publishing is a dictated sentence. Everything that was scarce two years ago is now commodity, available to twenty-nine people in a room on the first Monday of their term break. What's left is the part nobody can download: knowing whether the thing actually works, and being able to show someone else why.