Andrej Karpathy made a simple point on X : as AI does more of the work, our job moves to oversight and understanding, and plain text is often the slowest way to understand anything. He suggests a ladder of output formats: controlled-language text, diagrams, interactive HTML pages and explainer videos. He also says code is now cheap enough to build large, throwaway software that you use once.
That idea is easy to agree with and easy to forget. This guide makes it practical. Below are five real cases you can set up today in Claude Code, Cursor or Claude, each with a prompt you can copy. Then there are five more ideas for later.
Every case follows the same loop:
Keep the file self-contained. No build step, no server, no external data. That one rule makes it work the same in every tool.
Course Blog into Interactive lesson using AI
Problem: Course content is usually long text. Students skim it and forget it.
Fix: Turn each lesson into a scroll-based story with a diagram, a small interaction and a quick check.
Prompt:
Read lesson-03.md. Create lesson-03.html as one file. Make a scroll story: one idea per screen, an SVG diagram for the main concept, one interactive element (a slider, toggle or click-through), and three quiz questions at the end. Write the text in simple technical English: short sentences, active voice. Dark theme.
Where to run it: Claude Code or Cursor, with a loop over the lessons folder. Ask for the same layout every time so the course looks consistent. Check the facts in each lesson yourself before you ship, because a polished page makes a wrong claim look right.
Git difference into Visual PR preview
Problem: A diff shows what changed, not what it means. Reviewers read hundreds of lines to find the one risky change.
Fix: Generate a visual preview for each pull request.
Prompt (in Cursor or Claude Code, inside the repo): Run git diff main...HEAD. Create pr-preview.html as one file. Include: a plain-English summary in five lines, a diagram of the files and functions that changed and how they connect, before and after snippets for the three most important changes, and a list of risks and things to test.
Open the file next to the real diff. Use it as a map, not as a replacement for reading the code. For a team setup, add the file as a CI artifact so every PR has a link. The model can miss a bug, so treat the "risks" list as a starting point.
Daily agent report for the teams
Problem: You run several agents. Each one writes a long log. The person who needs the result, such as a manager, a client or the parents of a student using a learning agent, will not read raw logs.
Fix: One interactive daily report.
Here are today's logs from five agents (logs/*.json). Create daily-report.html as one file with the data embedded. Show: a top card with what got done, what failed and what needs a human decision; a timeline per agent; a filter by agent; and a "why" panel that opens on click. Use plain, calm language for a non-technical reader.
Where to run it: A scheduled script collects the logs, calls Claude, writes the file and emails or hosts it. Because the data is embedded, the page works offline when opened from an email attachment. For anything about children, show only what the parents need and do not include private details by default.
YouTube videos into interactive examples
Problem: The best teaching is locked in long videos.
Fix: Archive the transcript, then turn it into a page. TubeLog saves each video's transcript as a Markdown file, which is the ideal input.
Read videos/<channel>/<video-id>.md. Create an HTML explainer with: five key ideas as cards, a diagram of the main process, a glossary of terms, and a link back to the original video. Stay inside the transcript. Do not add facts that the speaker did not say.
That last line matters. If you want a video instead, ask for a scene plan and Manim or Remotion code, one scene at a time. Always read the script before you render.
Codebase onboarding tour with architechture map
Problem: A new developer opens a repo with 300 files and no idea where to start.
Fix: An interactive map of the project.
Explore this repo. Create onboarding.html as one file. Show an architecture diagram where each box is clickable and opens a panel with what the module does, its key files and how to run its tests. Add a "follow one request" walkthrough from the entry point to the database. Add a first-week reading order.
Where to run it: Claude Code is best here because it can read the whole repo. Regenerate the file when the architecture changes. Click a few boxes and compare them to the code, since models sometimes describe files they only skimmed.
Text is the default, not the best option.
For each task that ends with "someone has to understand this," ask for a diagram, an interactive page or an explainer. Start with one case today. Pick the one you hit most often, paste the prompt, and see how much faster you understand the result.
More to come in the next one
Shrey