Don't Start with AI, Start with a Problem

New model out, first question: “What can I build with this?” That order produces demos nobody asked for. Flip it: pick the person, find the chore, then ask where a model helps.

Step 1: Write the problem down

Answer three questions:

1. Who? (e.g., parents helping kids revise for Singapore school exams).
2. What slows them down? (e.g., marking open-ended science answers against SEAB criteria and explaining the lost marks).
3. What do they do today? (e.g., flip through assessment-book answers showing one model answer, no explanations).

No mention of AI yet. That’s the point.

Step 2: Sketch the information path

Every app moves information from A to B. Draw the three stops:

• Source: where raw input comes from (a photo of homework, a typed answer).
• Processing: what has to happen (read the image, compare with the mark scheme, score, explain).
• Destination: where the result lands (the student’s phone, with follow-up chat).

One sketch exposes the dependencies before you build.

Step 3: Split code work from language work

Ordinary code

Anything with a fixed rule: database reads and writes, logins, arithmetic, request routing, PDF export. Faster, cheaper, easier to test — start here.

A language model

Messy input or written output: reading photographed handwriting, comparing a free-text answer against a mark scheme, condensing a meeting transcript, pitching an explanation at the right reading level.

Keep the model on language. Keep everything else in code.

Step 4: Define “done” before building

“Feels smart” can’t be tested. Write checks you can observe:

• Photo in, feedback back within an acceptable time?
• Feedback cites the relevant mark-scheme idea?
• Blurry photo gets a “send a clearer one” reply instead of a guess?

Problem named, path sketched, split decided, checks written — now building is straightforward.