This deck walks through two real examples, using llm-dev:cycle in
single- and multi-iteration sessions to produce real things.
Each example includes
session transcript excerpts, rendered dev-cycle documents, and the live interactive
artifacts produced.
Deck 1 taught the cycle in the abstract. This deck shows it applied to two real builds that sit at different scales: Part 1 is a presentation with simple interactive elements, built in a single cycle iteration; Part 2 is a more complex interactive artifact, built across three. Same process, two very different sizes of job — that's the lesson.
Everything here is real and runs offline: the decisions, the quotes, the bugs, the refactors — all pulled from the actual session transcripts and the cycle artifacts in this repo. The rendered docs in the right-hand panes and the live artifacts are one click away; open them as you go.
Example 1 walks through a single llm-dev:cycle loop performed at the command line with Claude Code. Example 2 shows multiple loops run in Claude Desktop.
Ex.1: Differential Privacy Explainer — an interactive HTML slide deck produced for CYB-4203/6203: Secure & Trustworthy AI at The University of Tulsa, Spring 2026.
Ex.2: Pathfinding Algorithm Race — a complex interactive artifact demonstrating computer science concepts for Summer ASWP work, based on an existing github project.
All materials shown here can be run offline locally with zero dependencies using only vanilla HTML/CSS/JS, and thus are good examples of the kinds of things we can produce this summer for our ASWP work.
The split is deliberately along a scale axis, not a "slides vs apps" axis — both builds are interactive HTML. Part 1 is what a single, well-run cycle produces; Part 2 is what happens when you keep iterating. Framing it this way makes the point that the cycle is the same whether the job is small or large.
Tell the team: watch how Part 1 goes phase-by-phase through one build, then Part 2 switches to going iteration-by-iteration — because for a multi-pass build, the iterations are the story.
The Differential Privacy Explainer — built in one cycle, walked phase by phase. Open the finished explainer ↗
This is the part to slow down on: it's a complete, honest walk through one cycle, start to finish. Each of the next six slides pairs the actual conversation that drove a phase (left) with the rendered cycle document it produced (right). Encourage the team to open the live explainer first so the phases have something concrete to point at.
"I'd like to run an llm-dev cycle to develop an interactive demo I can present in class tomorrow — privacy-enhancing and security tech: differential privacy and federated learning."
Ran Phase 1 Review — first iteration, so I loaded the course context, wrote review.md, and opened the design questions.
"This could be an app where students participate by scanning a QR code… or just a demo I do on screen, though I'd like them engaged through participation somehow."
Captured the constraints — same-day (April 6) build, instructor laptop, no assumed student devices — and flagged podium connectivity as uncertain.
"Help me understand what differential privacy protects against, and then let's think about how to demonstrate a real-world use case."
Explained DP's threat model — re-identification from query results, the epsilon guarantee, Census/Apple/Google deployments — and argued for an attack-then-defense demo.
The teaching point: naming the hard constraint early is what makes every later decision obvious. "Same-day + offline + live demo" quietly settles the tool, the scope, and the format before any code exists.
The pane on the right is the actual Review document the phase produced — point at it to show that each phase leaves a real, readable artifact behind, not just a chat log.
"For Differential Privacy — what questions could gather data used in real ML applications? Rather than unread emails, how about late or missing assignments…"
Proposed a realistic student-retention-risk scenario (sleep, screen time, late/missing assignments → at-risk) — deliberately uncomfortable, so the privacy tension lands.
"I think we need to pivot to an interactive artifact that students won't necessarily use, but that I can run from the podium…"
Reframed scope to a self-contained, instructor-driven explainer of DP fundamentals — a clean problem-to-mechanism walkthrough existing tools didn't fill.
"I'd like to follow the general progression of this podcast to teach the DP section — extract the themes and ideas."
Extracted an 8-act progression and proposed mirroring it as the artifact's story-first structure, with interactive moments at the key beats; wrote brainstorm.md.
Story-first is the lesson. The eight-act arc was designed here, in Brainstorm, before a line of HTML existed. Just as important is what got cut: the tempting participatory, multi-device demo was dropped to keep a same-day build achievable.
Deciding what you won't build is half the value of this phase — the rendered doc on the right captures both the chosen arc and the rejected alternatives.
"Let's do a full iteration for DP right now — we'll get to FL later."
Ran Phase 3 Research — studied the existing self-contained-HTML course-demo pattern, zero dependencies, as the baseline.
Verified the Laplace mechanism is ~5 lines of vanilla JS (inverse-CDF sampling) — no chart library needed; all four interactives doable with raw DOM/SVG.
Rejected React/Vite, D3, and Chart.js as needless build/dependency risk for a same-day offline build; chose vanilla single-file HTML/CSS/JS. Wrote research.md.
This is the decision that makes the artifact offline — the same reason our tutorial decks are vanilla too. React, D3, and Chart.js were all considered and rejected in favor of the simplest tool that meets the requirements.
The payoff is sophisticated interactivity — Laplace-noise sampling, live SVG histograms, sliders — in pure client-side JavaScript, with nothing that can break between now and class tomorrow.
"Let's plan."
Ran Phase 4 Plan — wrote plan.md with the file structure, an 11-step ordered build sequence, and a ~10-hour budget with fallbacks.
Sequenced the build act-by-act (scaffold → Acts 1–8 → wrapper → deploy), giving the k-anonymity and epsilon-slider exhibits the most time.
Defined per-step acceptance criteria, a manual test checklist, and explicit out-of-scope boundaries — then offered to execute.
A good plan is self-contained — someone else could execute it without being in the room. Two things this one got right: an ordered build sequence (scaffold → narrative acts → interactive exhibits → deploy), and acceptance criteria written as pass/fail checks, which are exactly what Verify confirms later.
The "plan for a structure that can split as complexity grows" foresight is the direct setup for the refactor two slides from now — good plans anticipate where the pressure will land.
"Execute!"
Built the ~1,766-line self-contained artifact; Node-tested the linkage filter (20→6→3→1, landing on Gov. Weld) and the Laplace math.
Testing caught a too-wide epsilon slider — its max mapped to ε≈1000 (meaningless) — and capped it at ε≈20.
"Let's try again — I just enabled the Chrome MCP and enabled the browser extension."
Page loaded — verified all four interactives in-browser (linkage, k-anonymity, epsilon slider, minority erasure), no console errors, and screenshotted.
"Test early and often" is the whole lesson. The epsilon-slider bug was caught only because each interactive was exercised in the browser as it landed, not at the end — and until that fix the demo was complete but pedagogically broken, since the privacy-vs-utility tradeoff wasn't legible.
The link jumps straight to the fixed slider; re-roll the noise a few times to feel both the randomness and why the narrowed range matters.
"I've been through the verify phase — the split artifact works in Chrome, all 18 slides and exhibits are good, speaker notes and key/slider focus all work."
Treated this as the manual verification of record — wrote verify.md marking all acceptance criteria PASS, with deviations documented.
"Write review.md as complete, verified against acceptance criteria, manually verified by me. You don't have to walk the slides — they're good."
Recorded the consciously deferred items — a Safari smoke-test (low risk) and public deployment — plus the educational-fair-use decision.
"We're still developing, so do not deploy."
Held the deploy per instruction, fixed a stale wrapper title in three spots, and confirmed the artifact was production-ready but intentionally not yet live.
Evidence over assertion: "verified hands-on in Chrome, all interactives exercised" beats "looks done." The honest part worth highlighting: Safari and a public deploy were consciously deferred as low-risk and recorded as known gaps, rather than silently skipped.
That explicit scope management — and the instructor's "do not deploy" — is what separates verification from wishful thinking.
After the initial llm-dev:cycle pass, Claude and I began polishing each
slide by hand. As slides multiplied and interactivity grew, editing the single monolithic
html+css+js file grew slower and slower. I got tired of waiting, and asked Claude:
"What's the best way to break this up so that you don't have to read the entire HTML file and modify it every single turn of conversation?"
Claude's solution was to split the file into 3 parts:
Doing this kind of thing from the beginning probably would have been obvious to an experienced web dev, which I am not (but I'm getting there, thanks to Claude : )
This is "refactoring emerges from the cycle" made concrete. The one-file-to-three split wasn't scheduled — it was triggered when the growing code (and the cost of re-editing one huge file every turn) signaled it was time.
It was safe specifically because the slide IDs weren't referenced in JS and the
counter auto-computes from slideElements.length. That same three-file
split (.html / .css / .js) is what our starter template ships with.
Example 1 showed a single llm-dev:cycle followed by a long,
linear polishing pass run from Claude Code at the command line.
Example 2 shows 3
llm-dev:cycle iterations with zero linear polishing, run from the Claude
Desktop app in a normal chat session.
Reset expectations here. Part 2 won't go phase-by-phase — for a multi-pass build, the interesting structure is the sequence of iterations, each a small complete cycle that adds one capability while protecting everything already working.
Plant the tool-agnostic flag now ("built in a different app") so the closing slide lands as a payoff rather than a surprise.
Pathfinding Algorithm Race — BFS, Dijkstra, Greedy Best-First, and A* racing across a shared maze in parallel.
This is the more ambitious build: four search algorithms animated side-by-side on a shared, user-editable weighted maze, with a per-panel scoreboard. The next three slides each take one iteration — left lists all six cycle phases for that pass, right runs the actual artifact as it stood at the end of that iteration, so the team can watch it grow 571 → 891 → 907 lines.
Each iteration slide has a Launch Full Artifact button to open that version full-screen in a new tab; the finished build is also on the closing slide.
Four algorithms race in lockstep on one shared weighted maze; each panel scores cells visited, path cost, and optimality.
Scoped an offline single-file pathfinding demo; narrowed to four contrasting algorithms.
Chose four algorithms racing in lockstep on shared weighted terrain.
Prototyped and ran the search engine in Node; validated optimality, min-heap, DOM rendering.
Laid out the single-file structure and a seven-step build with twelve acceptance criteria.
Built the ~520-line file; 84 tests green; race contrast confirmed headlessly.
Re-ran all suites fresh plus a user browser check; 12/12 criteria passed.
The discipline beat here is prototype-before-commit: the pathfinding engine was built and unit-tested in Node first, then ported into the HTML and re-tested to prove the port was faithful. The artifact shipped with zero known bugs because the logic was proven outside the UI before it ever rendered.
The right pane runs the 571-line first version — let the team scrub the maze and watch BFS vs A* diverge, then note that everything after this is built on a tested core.
Adds a Study Mode that focuses one algorithm and walks its pseudocode line-by-line, synced to the grid.
Reflected on iteration 1; flagged step-granularity as the central decision for pseudocode highlighting.
Chose a focused line-by-line Study Mode over one shared skeleton; default off.
Unified race and study on one generator micro-stepper, validated against the iteration-1 oracle.
Six steps gated on the iteration-1 regression; refactor the engine, then add the study layer.
Added Study Mode; the engine refactor passed regression identically; 110 assertions green.
Re-ran suites and closed three gap items with new assertions; 12/12 passed.
The discipline beat is the regression gate: before building Study Mode, the entire iteration-1 test suite was re-run against the refactored engine and had to produce identical results. Only then was the new feature added. That's how you add capability to a working artifact without quietly breaking it.
Show the team Study Mode walking one algorithm's pseudocode line-by-line — then stress that the feature was only safe to build because the core race was provably unchanged.
Same race and Study Mode, restyled into a light, Apple-style design — appearance only, all behavior preserved.
Reflected on iteration 2; targeted reversing the dark theme to light, appearance-only.
Chose a refined light redesign: off-white surfaces, a single blue accent, re-derived cell palette.
Validated palette contrast with WCAG math; fixed iso-luminant path/frontier; confirmed offline system fonts.
Six CSS-concentrated steps, each gated by re-running the iteration-2 regression suite.
Restyled in CSS plus two markup touches; path inset-ring fix; 97 behavior assertions unchanged.
Re-ran 128 assertions plus contrast fresh; user sign-off "looks amazing"; 12/12 passed.
The discipline beat is a behavior-neutral change: a full visual redesign that touched no JavaScript — only styles and two markup wrappers — and then re-ran the entire behavior suite to prove nothing changed underneath. The CSS-variable architecture from iteration 1 is what made a redesign this clean possible.
Worth calling out: an accessibility fix (path-vs-closed cells) was done with a non-color inset ring, satisfying WCAG 1.4.1 rather than just swapping colors.
Use it as a Claude Code plugin,
or load the skill files into any LLM
chat or IDE session.
This is the slide that frees the team from any single product. We deliberately built the two examples in two different tools to make the point concrete: the value is the cycle, not the vendor. Encourage people to run it wherever they already work — the artifacts and discipline transfer.
If someone asks "do I have to use Claude Code?" — no. The cycle is the portable part.
Open the single-iteration presentation from Part 1 — it runs fully offline.
▶ Open the DP ExplainerOpen the multi-iteration artifact from Part 2 — the finished Pathfinding Race.
▶ Open the Pathfinding RaceReady to build your own? Grab the starter and run a cycle on a real topic.
New here, or not in the ASWP org? Read the public Getting Started guide — no account needed.
Read the Getting Started guide →
Optional, but recommended: install the llm-dev plugin for Claude Code ·
github.com/DallasElleman/llm-dev
(or load skills/cycle/SKILL.md into any LLM chat to run the cycle anywhere)
The concrete next step: the team now has two full worked examples at two scales — a
single-iteration presentation and a three-iteration artifact — plus the re-themeable
starter. Run /llm-dev:cycle on a real topic of your own; every artifact
and both live builds are here in the repo to study offline first.
Deck 3 picks up from here, laying out two ways to style and build your decks — our scroll-snap starter versus a fixed-canvas system with three ready themes — so you can choose the look that fits.