Ask Your AI Agent for HTML: 20 Examples for 9 Everyday Tasks

Suppose you ask an AI agent for three ways to implement a feature. It returns a long Markdown answer: approach A, then approach B, then approach C. You scroll up to check which option supports retries, then down to compare complexity. By the time you make a choice, you have probably reconstructed a comparison table in your head.

Try asking for a single HTML file instead. The agent can place the options side by side, put tradeoffs next to the relevant code, and make the differences visible on one screen.

That is the basic idea behind The Unreasonable Effectiveness of HTML — Examples ↗. The page presents 20 examples across nine types of tasks, from implementation planning to ticket triage. Every example is a single-file page that requires no build step.

The useful change is a small shift in how you ask. Instead of having the agent write something you must read from beginning to end every time, ask it to make something you can inspect or interact with.

1. Exploration and Planning: Compare Before Choosing a Direction#

Markdown works well once the direction is clear. During exploration, however, you have to read the options one after another, even when your goal is to compare them.

HTML can put those options on the same screen. The page includes these examples:

• Three code implementation options: Place three solutions side by side, each with its tradeoffs.
• Visual design directions: Render candidate layouts and color schemes so you can give feedback on what you see.
• Implementation plan: Combine milestones, data flow diagrams, mockups, risky code, and a risk table into one document you can use during implementation.

The design example makes the advantage clear. A description such as “a compact interface with a restrained color palette” leaves plenty of room for interpretation. A rendered layout gives you something concrete to accept or reject.

When comparing code, ask for the same headings across every option: dependencies, failure handling, expected scope of work, and maintenance cost, for example. Otherwise, attractive cards can conceal inconsistent comparison criteria.

Choose a direction first. Then ask the agent to turn that choice into an implementation plan.

2. Code Review and Understanding: Put Context Next to the Code#

A diff is a document whose spatial arrangement already carries meaning. Line positions, nearby changes, and relationships between files matter. In a Markdown review, comments often end up far from the code they explain.

HTML can put the explanation close to the evidence.

• Annotated pull request: Add margin notes, severity tags, and links to relevant locations in the diff.
• PR description for reviewers: Explain the motivation, behavior before and after the change, why each file changed, and where reviewers should focus.
• Module map: Draw an unfamiliar package as boxes and arrows, showing entry points and common paths through the code.

These pages support different ways of reading. An annotated diff helps you scrutinize changes, a PR description helps you understand their purpose, and a map helps you navigate the codebase.

Ask for file paths and line numbers wherever possible. For a module map, ask the agent to distinguish verified calls from inferred relationships. A polished diagram can make unsupported assumptions look certain.

Make it easy for reviewers to get from the page to the source code.

3. Design: See What It Actually Looks Like#

Listing color values in Markdown records a palette, but it does not show how the colors look together. A disabled button is also easier to understand when displayed than when described in prose.

HTML uses the browser to render what you are evaluating.

• Living design system: Extract color, typography, and spacing tokens from the repository and display them as samples you can copy.
• Component variations: Arrange a component’s sizes, states, and intended uses on one page.

For a component review, ask for a matrix with sizes in columns and states in rows. Include loading, disabled, focus, and error states where applicable.

Viewing them in a browser makes inconsistent spacing and weak visual distinctions easier to spot. It also gives reviewers a shared reference. “The small loading button” identifies the subject more precisely than a paragraph describing its behavior.

Check the extracted tokens against the source files before treating the page as an authoritative reference. It is a useful snapshot, but you still need to decide whether to keep it up to date.

4. Prototyping: Let People Try the Behavior#

Markdown can describe a screen transition’s duration and easing curve. It cannot let you feel whether that transition is too slow.

HTML can create small behavioral experiments.

• Animation playground: Isolate one transition and add sliders to adjust its duration and easing.
• Clickable flow: Connect four screens so people can try a sequence of actions.

Keep these prototypes focused. An animation playground should answer a question about motion. A clickable flow should test whether users understand what to do next.

Use sample data and make resetting easy. If you only want to test movement between screens, do not add authentication, persistence, or a backend.

Even connecting just four screens can reveal a missing back action or a confusing confirmation step. You can find those problems before they become expensive to fix after implementation.

5. Illustrations and Diagrams: Draw the Relationships#

Prose works well for explaining individual steps. It becomes harder to follow when multiple paths branch, merge, or fail in different ways.

HTML can include inline SVG, so the agent can create editable illustrations and interactive diagrams.

• SVG illustration sheet: Collect an article’s illustrations on one page so each can be revised or extracted.
• Annotated flowchart: Show a deployment flow, with clickable steps that reveal what runs, how long it takes, and what happens after a failure.

For a deployment diagram, ask for both success and failure paths. A diagram that includes only successful steps may look complete while omitting information operators need.

Keep important labels visible at all times. Use clicks to reveal supplementary information rather than hiding the basic flow.

Inline SVG is especially useful when you want to revise labels or arrows. The diagram remains part of the file, so you do not need to regenerate a separate image.

6. Slides: Turn a Short Explanation into a Browser Presentation#

Markdown headings can provide an outline, but a meeting also needs pacing. Let participants see the point currently being discussed without scrolling through the entire document.

The arrow-key slide deck example turns a single HTML file into a short presentation. Each section becomes a slide, and a little JavaScript controls navigation. You can see how this works in the slide example ↗.

A useful request specifies the audience, the decision to make, and a length limit. For example: “Create six slides for a ten-minute architecture review. End with the decisions we need to make.”

Open the file in the browser you will use for the meeting and check keyboard navigation beforehand. If it needs to work offline, ask for all styles, scripts, and assets to be included in the file.

7. Research and Learning: Let Readers Adjust the Explanation#

A long Markdown explanation makes readers follow roughly the same sequence, even when they have different questions.

HTML lets readers expand details, switch examples, and interact with a model.

• How a feature works: Explain the repository’s rate limiting with a summary box, collapsible processing stages, tabbed configuration examples, and an FAQ.
• Concept explainer: Teach consistent hashing with a ring that lets readers add and remove nodes, supported by a comparison table and a linked glossary.

Interaction is valuable when it reveals cause and effect. Removing a node from a hash ring should show which keys move and explain why.

For repository explanations, ask for links or references to the relevant code. For conceptual models, ask the agent to state what it has simplified. An interactive demo can explain a principle without reproducing every production detail.

8. Reports: Make Recurring Information Easy to Scan#

Weekly updates and incident reports often repeat the same structure. Markdown can convey the facts, but readers have to search paragraphs for delays, changes, and unresolved work.

HTML can put recurring information in the same place every time.

• Weekly status report: Separate shipped work from delayed work, with small charts where data is available.
• Incident timeline: Arrange events minute by minute, alongside log excerpts and a checklist for preventing recurrence.

With the same layout each week, readers know where to look. Put the reporting period at the top, label chart units, and make missing data explicit.

For incidents, distinguish observed events from later interpretations. A timestamped log entry and a suspected cause should not be treated the same way.

Formatting helps readers find evidence. It cannot supply evidence that was never collected.

9. Purpose-Built Editors: Bring the Results Back into Your Workflow#

Some decisions are hard to express in a text box. Reordering 30 tickets is one example. A drag-and-drop board lets you change their order directly.

The page includes these editing tools:

• Ticket triage board: Move tickets into “Now,” “Next,” “Later,” and “Out of scope,” then copy the results as Markdown.
• Feature flag editor: Group toggles by area, warn when a prerequisite is off, and copy only the changed keys.
• Prompt tuning tool: Place a template with highlighted variables alongside three sample inputs, updating the displayed output to match the inputs.

The most important requirement is an export button. Without one, your decisions are trapped inside the page.

Specify the output format before asking for the interface: Markdown for a plan, JSON for structured data, or a diff for configuration changes. Also specify reset behavior and a clear indicator of unsaved edits.

An editing tool is useful when it returns a result you can paste into your conversation with the agent or commit to the repository.

Pick One of These Three to Try Tomorrow#

Start with a task whose results you can check immediately.

1. Compare a real decision. Ask for three code implementation options with consistent comparison criteria and a visible list of assumptions. 2. Improve a recurring report. Ask for a weekly status report using an existing report and verified figures. 3. Triage an existing backlog. Ask for a ticket triage board that preserves ticket IDs and exports the categorized results as Markdown.

Whichever you choose, add this instruction:

> Return a single, self-contained HTML file with inline CSS and JavaScript. Use only the facts provided, make unknowns explicit, and include an export button for the decisions made on the page.

Markdown remains a good fit for text that needs editing, searching, and version control. HTML is worth using for tasks that need comparison, spatial relationships, motion, or direct interaction.

Open the example gallery ↗, choose a page that fits tomorrow’s work, and ask your agent to make a version using your own material.