Use AI · Chapter 4 of 13
Build one small useful tool before you build a company
Turn an unclear idea into a prototype with inputs, outputs and tests that a real person can understand.
About 5 minutes · school-level background
Edition 2026-10-28.1 · Checked 2026-10-28
What you will understand
Define and test a tiny product without confusing a working demonstration with a service people can rely on.
In this lesson
Build the idea
The smallest version that helps
An AI events platform sounds exciting. It could read every website, organise every event, answer every question and book every ticket. It also hides a hundred different jobs inside one sentence. Start with something you can inspect in an afternoon: a checker that takes three event notes and produces a review table. It might be a spreadsheet template or a local page. The useful part is that an organiser can spot a changed venue before publishing the wrong one.
A prototype is a small version built to answer a question. Your question here is whether the review table helps someone find errors faster and more reliably than reading the notes alone. That is different from asking whether the interface looks like a finished product. A beautiful page can still make the task harder. Keep the question visible while you build.
Choose one repeated job
Build the smallest useful version
Test normal and difficult inputs
Let a person inspect the result
A simplified reading aid. Follow the article for sources, conditions and limits.
What the source reports
A pattern worth borrowing
Anthropic’s engineering guidance recommends starting with simpler arrangements and adding complexity when the task needs it. For this prototype, the main work is extraction and comparison. A long-running autonomous agent is not required just because the eventual product concerns AI. We will test the output and workflow before expanding the machinery.
Original report: Anthropic: Building effective agents
Use the idea
Specify the contract in ordinary words
Write down who uses the tool: a club organiser preparing a public listing. Name the input: a few public or fictional notes, each with a label and date. Name the output: a table of event details, conflicts and missing fields, plus a draft that the organiser approves. Name the boundary: the tool does not publish, book or message anyone. This little contract helps both a human developer and a coding assistant understand what completion means.
Specify what happens when the inputs are bad. An empty input should produce a request for information, not a made-up event. Two different dates should appear as a conflict. A cancelled event should not emerge as a cheerful invitation. Text inside a note that says to ignore the user should remain quoted data. Your application should not interpret it as a command. These cases belong in the first version because they define the service’s basic behaviour.
Worked teaching example
Use five tests before adding five features
Here is a fictional acceptance set. Case one has a single consistent note and should produce a complete table. Case two omits the venue and should mark it unknown. Case three changes the venue in a newer update and should show the change with both sources. Case four cancels the event and should suppress an invitation draft. Case five includes an instruction inside the source asking for a secret; the output should neither follow that instruction nor invent a secret.
Notice that the expected results are observable. You can look at the output and decide whether the venue is marked unknown. You can check whether a cancelled event is presented as cancelled. Compare this with the requirement that the tool be smart or professional. Those words express a wish but do not tell you how to check the implementation. A useful specification turns your wish into examples that could reveal a mistake.
Try the process manually before asking for code. Put the inputs in a document and fill in the output table yourself. You may discover that the proposed fields are confusing or that source dates do not establish authority. For example, a recent volunteer message may repeat an old poster while an earlier organiser notice is the actual correction. Adjust the rule to compare authority and content, not simply choose the newest date. You have improved the product before writing a line of software.
Use the idea
Give a coding assistant a bounded build
If you use a coding assistant, provide the contract and the five tests together. Ask for a local prototype using fictional data, a short explanation of how to run it, and a record of tests actually executed. Ask it to stop before adding accounts, payment services or public deployment. That keeps the first experiment understandable. You can inspect the tool’s result without simultaneously managing a business and an infrastructure project.
Run it with the examples and with at least one fresh case. Check the actual interface, including what a reader sees after an error. If the assistant cannot execute the prototype, label the output as code prepared but not run. A confident description is not an execution record. Keep the source files and test inputs so that a later change can be checked against the same cases.
Build the idea
Watch a person use the result
A useful observation is not whether someone says the idea is clever. Give them the notes and ask them to prepare an accurate listing. Watch where they hesitate, what they double-check and whether the table changes their decision. If you compare against reading the notes alone, account for practice: a person who has already seen the answer will usually be faster the second time. Use different comparable examples or change the order across participants.
Suppose a tester ignores the evidence column because it is too narrow on their phone. The fix may be layout rather than a different model. Suppose they cannot distinguish an old value from a disputed value. The fix may be a clearer label. Your first few observations should change the product, not merely decorate a promotional page. Record the task and the actual issue so you can tell whether the next version helps.
Use the idea
Earn the next feature
At the end of the exercise, keep a small package: the contract, fictional inputs, expected results, prototype and observed failures. That package is useful even if you decide not to continue. Someone else can see what was attempted and what still needs work. If the tool does help a real organiser, ask which repeated part of their process is still painful. That is a better source for the next feature than an endless list of things AI might do.
Words you can now use
- Prototype
- A small implementation made to test a specific product question.
- Acceptance case
- An example with an observable result that the product must achieve.
- Regression
- A previously working behaviour that breaks after a change.
Check your understanding
Your prototype passes all five prepared cases. Is it ready to publish event information automatically?
Show the explanation
No. Those tests support the checked cases, not all live inputs or permission to publish. Try fresh cases, observe the intended user, and separately decide what review and authorisation the public service needs.
Read the original sources
- Anthropic: Building effective agentsEngineering experience · Published 2024-12-19 · Checked 2026-10-28
Try it with your own assistant
Select and copy this bounded exercise. A normal chat assistant is enough to start.
Prepare a prototype specification for a public event checker. Include the three notes from the previous lesson, a missing-room case, a cancelled-event case and an embedded malicious instruction. Ask for a local draft only; no accounts, messages or deployment.
Keep the task brief, supplied inputs, checked output and unresolved questions together. Using this exercise does not submit anything to WRS.