Build things you couldn't build before
What this is
Chapter 8 makes a claim that doesn’t sound revolutionary until you do it: AI lets you build things that wouldn’t exist if you didn’t have it. Not because you’ve learned to code. Because the gap between “I know what this should do” and “it exists and works” has collapsed from months to weeks — or, for small things, to an afternoon.
You saw Jorge do this in the book. Year 10 history teacher, half his class racing through the Cold War material, the other half still muddling the timeline. He doesn’t know any code. He describes the problem to AI in one honest message — including the “I don’t know anything about coding” part — and asks for a quiz where the questions change based on whether students are getting them right. AI suggests a paper-and-spreadsheet structure, fifteen to twenty questions branching into two paths. Jorge builds it that evening, tries it the next morning, refines based on what didn’t work. Within a month: a quiz bank for the unit, a revision guide, consistent feedback comments. None of these existed before.
This exercise runs in two short sessions. Today — about fifteen minutes — you’ll build Version 1. A week from now, after you’ve actually used it, you’ll come back for ten to fifteen minutes to refine. Most exercises pretend you can do everything in one sitting. This one tells the truth: the part that teaches you most happens after the system has met reality.
What you’ll need
- ~15 minutes today, plus ~15 minutes after a week of use
- A real recurring problem — not a one-off task, a pattern you keep working around
- Your usual AI tool, plus whatever you normally use to keep simple things (Google Sheets, Notes, a Word doc, a project app)
If you can’t name a recurring problem in two minutes, the exercise won’t work. Bookmark this page until something specific surfaces — and it will, usually within a day of paying attention.
Pick the right kind of problem
Three filters to make sure you’re picking something this exercise can actually handle:
- Recurring, not one-off. Something you deal with weekly, monthly, or whenever a specific kind of situation comes up. Not a single project with an end date
- Currently managed with workarounds. You’re using memory, scattered notes, a spreadsheet that never quite worked, or a system you keep meaning to set up. There’s a gap between what you do and what would actually help
- Not technical-by-nature. What you’ll build will be a tracker, checklist, template, decision tool, or simple system — something you can put into a spreadsheet, a notes app, or a document. If your problem genuinely needs custom software, that’s a different exercise
Good examples for AUAI’s audience: tracking what your kids need to practise across a school week; following up with clients without it depending on memory; managing the logistics of a recurring event (book club, sports team rota, family dinners); a decision tool for repeated calls you make at work (when to escalate vs. when to absorb, when to take a meeting vs. when to send a one-pager); a feedback template you reuse on similar pieces of writing.
Today: build Version 1
Step 1 — describe the problem, ask what you could build
This is the move Jorge made. One honest message describing the situation, ending with a question about what to build. The point of being honest about your constraints isn’t to apologise for them — it’s so AI suggests something that fits what you can actually use.
I have a recurring problem: [your one-or-two sentence description]. I’ve tried managing it with [what you currently use]. It doesn’t work well because [why it falls short]. [If relevant: I don’t have a technical background.] What’s the simplest thing I could build — a tracker, checklist, template, decision tool, or recurring system — that would actually help? Keep it small enough that I can put it together today in a spreadsheet, a notes app, or a document.
Read AI’s suggestion carefully. Pay attention to one thing in particular: did AI suggest the smallest version that would help, or the full version of what you might one day want? If the suggestion has more moving parts than you’d use in the first week, push back. “That’s more than I need to start. What’s the simplest first version that would still produce value?”
Step 2 — get Version 1 built, right now
Don’t ask AI to describe what to build. Ask it to produce it.
Good. Build Version 1 with me now. Show me the exact structure — whatever shape fits the solution, whether that’s headings, sections, bullet points, columns, or fields — and fill in one or two example entries so I can see how it works in practice. Don’t give me general advice. Give me something I can copy into [your tool of choice] and use this week.
Copy what AI produces into your tool of choice. You now have a working Version 1.
Stopping here is fine. This is the same point Jorge reached after his first evening with AI. Use it for a week, then come back for the second half.
After a week of use: refine
Step 3 — use Version 1 before changing it
This is the step almost everyone skips. The temptation is to ask AI to make it better immediately, while it’s still in front of you. Resist.
Use the version you have for as long as it takes for real friction to show up. For a weekly system, that’s about a week. For a checklist you use whenever a specific situation arises, it’s the next two or three times that situation comes up. Jorge tried his first quiz on the class the next morning — not the same evening he built it. The point of waiting is that real usage tells you things imagined usage never will: what you actually skip, what felt wrong in practice, where the system asked for effort the problem didn’t deserve.
Step 4 — refine, with honest observations
When you have real usage to work with, come back to AI:
I’ve been using the [tracker / template / system] we built for [how long / how many times]. Two things to tell you.
What’s working: [what helped, specifically] What isn’t: [what failed or felt wrong — the specific moment you didn’t use it, or used it and got nothing useful]
What’s the smallest change that would fix what’s not working? Don’t redesign — refine.
The constraint “don’t redesign — refine” matters. Most second versions over-correct. They become more complicated, not less, because you’ve spotted three things wrong and want to fix all three. Pick one. Fix that one. Use it again. Come back if the next problem is still real. Jorge’s first quiz wasn’t perfect either — the branching was too steep, the strong students breezed through, one student told him it felt like being punished for not knowing the answer. His refinement wasn’t a rebuild. It was two small adjustments: a confidence-builder question on the harder path, a partially-completed answer on the easier path. That was enough.
What you’ll notice
The first version is rarely the right version. That’s normal. The point isn’t to get it right on the first try — it’s to compress the loop between “I have a problem” and “I have a working response to that problem” from years to days.
The biggest gain is often invisible. You stop carrying the problem in your head. The system holds the pattern; you free up the attention. Jorge’s quiz bank meant he stopped writing individual worksheets late at night. The compound effect of that — what he did with the freed time — was where the real value lived.
What you build today won’t be the final version. It might not even survive past Version 2 or 3. The skill you’ve practised is the one that compounds: identifying a recurring problem, describing it honestly, building the smallest first version, using it, refining. The thing you build is proof of concept.