Rapid Prototyping for AI Projects

8 Interactive Sessions

Short, interactive sessions: watch it work, try it, then build it yourself. You can go deeper at any time in the written chapters.

1. 1

   A prototype is a question you can answer fast

   When a client hands you a vague ask, frame it before you build. The worst thing you can do is build the wrong thing well.

2. 2

   Find the real problem, then agree what would kill it

   Turn “frame it first” into three repeatable moves: map how the work happens today, map who feels the problem, and agree the number that would make you say no. Do all three before any code exists.

3. 3

   Look at the data before you choose a tool

   Look at the data before choosing a technology. The shape of the data decides the tool, and one simple question to the database can show the plan was wrong while it is still free to change.

4. 4

   Search the help centre by meaning, not by spelling

   Watch a simple word-matching search fail twice on real tickets, fix it with embeddings, and then build the one thing that makes any of the numbers trustworthy: an answer key.

5. 5

   Send each question to the tool that can answer it

   Build the step that turns two working parts into one useful system: a router that decides which part answers each question. It is worth more than any model upgrade.

6. 6

   Join the pieces into one system you can draw

   Turn five working functions into one system with a visible shape, so the routing shows, the human step can be counted, and someone can follow it without reading code.

7. 7

   Give it a plain page someone else can use

   Put the system in front of a non-technical decision-maker, and choose where it lives by what it has to prove, not by what would be right for the finished product.

8. 8

   Turn the result into a decision, and hand it over

   Turn a working prototype into a decision, and be as ready to recommend no as yes. A fast, well-supported no is one of the most valuable things a forward-deployed engineer produces.

How this certificate is scored

Your certificate shows how many of your written answers met the rubric below, checked by an AI grader. Anyone who checks your certificate sees it.

• You answer 8 short questions, one for each module, in your own words (at least 40 words each).
• An AI grader checks each answer against what its module asks for: it must answer the question, use the course's practice case specifically, and be correct.
• To pass, at least 7 of the 8 answers must meet that bar. The certificate says the answers were graded by AI.

The rubric

1. Module 1, A prototype is a question: The mindset, the build-run-read-cut loop, and an ambiguous brief inventoried into known/unknown/assumed.
2. Module 2, Frame it, then write what would kill it: A falsifiable problem statement + kill criteria agreed before any code.
3. Module 3, The backend is a database, not a vector store: Tickets in Postgres, the queries that answer exactly — and the one that tells you your slice was wrong.
4. Module 4, The help centre is prose — now you need retrieval: Working vector retrieval, plus the labelled answer key that makes its numbers mean something.
5. Module 5, SQL, retrieval, or both: A router that sends each question shape to the right tool, and says why.
6. Module 6, LangGraph — the pieces become a system: One graph: classify → route → gate → compose, with the human gate as a visible node.
7. Module 7, A surface someone else can use: An API and a plain page — plus a defended choice against Slack and the support tool.
8. Module 8, Demo, decide, hand over: A stakeholder demo, a go/no-go against the agreed criteria, and the handoff into production.

What you walk away with