By the end of this module, participants should have the 'holy shit, I can build something' moment: they can describe a useful work artifact in natural language, have AI produce a simple editable version, iterate on it, and save or share it without pretending they are now software engineers.
Part 1
AI is not just a chatbot
Most people first experience generative AI as a question-answer box or writing assistant. That is useful, but it undersells the shift. AI can also translate intent into working artifacts: formatted documents, HTML pages, intake forms, invoice layouts, checklists, trackers, and simple spreadsheet-style tools.
- The goal is not to become a software developer in one module.
- The goal is to understand that code, HTML, and structured documents are output formats AI can help shape.
- Natural language becomes the editing interface: make it cleaner, add a totals section, fit it on one page, use our colors, create a print version.
- Small artifacts build confidence faster than abstract AI theory.
Quick check · <30 sec
What is the actual goal of this module?
- A. Become a software developer
- B. See structured formats as something AI can shape via plain language, and build one safely
- C. Replace your tools with AI
- D. Learn to code HTML by hand
Show answer
The confidence shift is the point: intent → artifact → iterate → export, with the boundaries intact.
Part 2
The full loop in five minutes (walkthrough script)
Before you build, watch the whole loop once at a narrated pace. This is the script — read it as the steps you will repeat. (It is written as a video script because the loop is best seen end-to-end; recording is out of scope, the script is not.)
- 0:00 Idea: 'I rebuild the same service invoice by hand every week.' Name the artifact and the annoyance.
- 0:40 Prompt: the five-part pattern from Module 2 — goal (printable invoice), context (sanitized, fake client), constraints (one page, no real data), output (self-contained HTML), validation (ask what to check).
- 1:40 Output: open the generated file in a browser. It is rough; that is expected.
- 2:20 Revise in plain language: 'make totals prominent', 'fit one page', 'add a notes box'. Watch it change.
- 3:40 Validate: check the fake math by hand, confirm no real data, confirm scope (no payments/integrations).
- 4:20 Export: browser print / save-as-PDF, store as a reusable template after human review.
Quick check · <30 sec
Put the loop in order.
- A. Revise in plain language
- B. Idea
- C. Validate
- D. Prompt
- E. Export
Show answer
Idea → Prompt → (output) → Revise → Validate → Export. Revision comes before validation; export only after validation and human review.
Part 3
Start with a safe, useful artifact
The best first build is small, practical, and low-risk. It should solve a real annoyance without touching production systems, private data, payments, customer records, or regulated information. Think prototype, template, or internal aid — not enterprise application.
- Admin: invoice template, intake form, meeting agenda, office checklist, status tracker.
- HR or training: onboarding handout, policy acknowledgment form, role checklist, learning tracker.
- Sales or service: proposal one-pager, quote mockup, customer follow-up checklist using fake data.
- Operations: shift checklist, equipment inspection form, simple dashboard mockup, recurring task tracker.
- Managers: scorecard, team agreement one-pager, weekly update generator, coaching form.
Quick check · <30 sec
Which is a safe first artifact?
- A. A form that collects real customer payment details
- B. A printable shift checklist with placeholder data
- C. An app that writes to the production database
- D. A tool that auto-emails customers
Show answer
Prototype/template with fake data and no live integration. The others cross the boundary into payments, production, or automated sending.
Part 4
Why HTML is a friendly first build format
HTML sounds technical, but for this lab it is just a printable layout language. A single HTML file can be opened in a browser, edited by AI, styled with colors and spacing, and printed or saved as PDF. That makes it a great bridge between plain documents and software.
- Ask for one self-contained HTML file with simple CSS in the same file.
- Use placeholder data unless the company explicitly approves real data for the tool and use case.
- Open the file locally in a browser to inspect it.
- Use browser print or save-as-PDF for the first export path.
- Treat logos and brand assets as approved sample assets unless the organization provides real approved files.
Quick check · <30 sec
Why is a self-contained HTML file a good first build format?
Show answer
It opens in any browser, is editable by plain-language requests, styles easily, and prints/saves to PDF — a low-risk bridge between a document and software, with no install or deployment.
Part 5
Format gallery and in-product canvas surfaces
HTML is the friendly default, but the same workflow output has several useful shapes. Choosing the right one is part of the skill. And most approved assistants now have a side-by-side 'canvas/artifact' surface where the document renders next to the chat — useful, but it does not change the data rules.
- Same content, five shapes: a printable HTML page (hand to a person), a markdown table (drop into a doc/wiki), CSV (open in a spreadsheet), a mermaid diagram (a flow or org chart from text), draw.io XML (an editable diagram).
- Pick by destination: spreadsheet → CSV; wiki → markdown table; printout → HTML; process explainer → mermaid.
- Canvas/artifact surfaces (e.g., Claude artifacts, ChatGPT canvas, Gemini canvas, a Copilot draft pane) render and let you revise in place — confirm behavior in your approved tool rather than assuming; it varies and changes.
- Multimodal input: approved tools can often take a screenshot or photo as input — 'rebuild this paper form as an HTML template' from an image is sometimes faster than describing it. Same sanitization rules apply to the image.
Activity · ~7 minbuild artifact
You have one workflow output: a 4-step onboarding checklist with an owner and a due window per step (fake data). Produce it in two formats and pick which fits which destination.
- Content: Steps: accounts, equipment, intro meetings, first task — each with owner-role and a due window
- Destinations: (1) the team wiki (2) a spreadsheet tracker
Your task
Write the two prompts: one asking for a markdown table for the wiki, one asking for CSV for the spreadsheet. State which destination gets which and why.
Show a hint
Markdown table → wiki (renders inline). CSV → spreadsheet (imports as columns). Same content, different shape.
Compare with a strong answer
Wiki prompt: 'Output a markdown table, columns Step | Owner role | Due window, using this fake data: …'. Spreadsheet prompt: 'Output CSV with header Step,Owner,DueWindow and these fake rows: …'. Wiki gets the markdown table because it renders inline; the tracker gets CSV because it imports cleanly as columns. No real names used.
Why this matters: Format choice is where 'I made a thing' becomes 'I made the right thing for where it has to live.'
Quick check · <30 sec
Your output needs to land in a spreadsheet tracker. Best format to ask for?
- A. A mermaid diagram
- B. CSV
- C. A printable HTML page
- D. A screenshot
Show answer
CSV imports cleanly as columns. HTML/mermaid are for reading or diagramming, not spreadsheet ingestion.
Part 6
Natural-language iteration is the real skill
The breakthrough is not the first generated artifact. The breakthrough is watching the artifact improve through ordinary language. Participants should practice giving concrete revision requests instead of accepting the first draft.
- Make this look more professional and less crowded.
- Add a signature line and approval date.
- Use a blue and charcoal color palette.
- Make the totals section easier to read.
- Fit this on one printed page.
- Replace this paragraph with a checklist.
- Add a placeholder logo area at the top right.
Activity · ~10 minbuild artifact
Build one small artifact end-to-end in ~10 minutes using an approved tool. Pick from the starter list; use only fake data.
- Starter build prompts: (admin) one-page intake form · (ops) shift checklist · (sales) proposal one-pager with fake client · (HR/training) onboarding handout · (manager) team agreement one-pager
- Rule: Fake data only · at least two plain-language revisions · no payments/integrations/deployment
Your task
Write the initial five-part prompt, then make at least two revision requests, then state how you validated it and how you would export it safely.
Show a hint
Strong revisions change layout or usability ('fit one page', 'make the totals prominent'), not just wording.
Compare with a strong answer
Initial: 'Self-contained HTML one-page intake form, fake fields, clean blue/charcoal, print-friendly, list what I should check.' Rev 1: 'group fields into Contact / Request / Internal sections.' Rev 2: 'add a sign-off line and fit one page.' Validate: opened in browser, confirmed only fake data, no submit/integration. Export: save-as-PDF, store as template after a colleague reviews it.
Why this matters: The confidence shift only happens by doing the loop once with your own hands — reading about it does not transfer.
Quick check · <30 sec
Which is a strong iteration request?
- A. "Make it better"
- B. "Group the fields into Contact / Request / Internal and fit one page"
- C. "Fix it"
- D. "Improve the design"
Show answer
Concrete, structural, checkable. Vague requests ('better', 'fix it') just restart the guessing.
Part 7
Safe boundaries for artifact building
Building something feels powerful, so the boundaries need to stay visible. This lab is for prototypes and templates. Participants should not build tools that collect real private data, process payments, make decisions, bypass approved systems, or get deployed publicly without review.
- Use fake, sample, or sanitized data.
- Do not include patient, student, customer, employee, financial, legal, credential, or proprietary details.
- Do not add logins, payment collection, database storage, integrations, or automated sending in this module.
- Do not use unapproved logos, brand assets, or copyrighted material as if they are company-approved.
- Have a human review the artifact before anyone uses it for real work.
Quick check · <30 sec
Which crosses this module's boundary?
- A. A checklist with fake data, reviewed by a colleague
- B. A form wired to collect and store real customer payments
- C. A markdown table for the wiki
- D. An HTML page printed to PDF
Show answer
Payments, real data, storage, and live integration are out of scope here — this lab is prototypes and templates only.
Part 8
From one artifact to better workflows
A simple generated artifact is not the endpoint. It is the doorway into better workflow thinking. Once someone can make a form, invoice, checklist, or tracker, they start seeing repeatable processes, required inputs, validation steps, and handoffs more clearly.
- What information does this workflow need?
- What should be standardized instead of recreated every time?
- Where does human review belong?
- Which parts are safe for AI assistance and which parts need approved systems?
- What would make this artifact easier for a teammate to reuse?
Quick check · <30 sec
Why is the artifact a 'doorway', not the endpoint?
Show answer
Building a form/checklist/tracker exposes the workflow's real inputs, the parts worth standardizing, and where human review belongs — which is the input to Modules 5 and 6.