The Need: it works, but it looks like a prototype

I am a 60-year-old non-programmer. Claude Code can build what I describe, but I cannot describe what a good e-book reader looks like. I know it when I see it on a store-bought reader app. I do not know the words: line breaks, tap zones, running heads, safe areas.

My viewer worked. It also looked rough. The text broke in the middle of Korean words, the cover needed scrolling, and there was no page-turn mode.

This post is about one habit that helped: I used a second AI as a design reviewer, and Claude Code as the builder.

(A companion post covers the technical side: fonts, footnotes, and the page-turn code. This one is about the workflow.)

The Proof: what changed in one afternoon

All of this happened on one day, between the first prompt and the final phone test.

Before and after, as I see it on my phone:

  • Cover: scrolled, two repeated lines → fits one screen, with a “Continue reading · Chapter N” button.
  • Body text: broke inside words → breaks between words or justified like a paper book, my choice.
  • Table of contents: a flat list → nested chapters, a ✓ or a % for each chapter I read.
  • Menu: always visible → hides when I scroll down, comes back when I tap the middle.
  • Reading mode: scroll only → scroll or page turn, with a short slide.

I said afterwards that I was very satisfied. That is my opinion, from one phone.

The Story: why this feels like a bigger step

These viewers are for books from a public-domain library that I translate into Korean and read. I had translated six volumes earlier. A viewer I can read comfortably is what turns “a folder of translated files” into “books I actually open.”

So for me the viewer was not a side project. It is the first piece that lets me start using the library for real.

The How: the loop

The loop in four lines

  1. In the chatbot, upload the current book HTML (or a screenshot) and ask, in my own words, how to make it feel like a commercial e-book reader, and for steps I can give to Claude Code.
  2. The chatbot answers with a reviewed list of steps, and writes one prompt per step.
  3. I paste one prompt into Claude Code. It plans, builds, tests, and commits.
  4. I copy Claude Code’s report back into the chatbot. It reviews the result and writes the next prompt.

I never had to judge the design myself. I judged one thing only: “does it look right on my phone?”

Honest note: I only have the prompts as I pasted them into Claude Code. I did not save the chatbot’s side of the talk, so I can’t quote its reasoning here.

What the prompts looked like

Looking at the five steps afterwards, they share a shape.

1. Look first, don’t touch. The first prompt asked for a backup copy of the viewer and a short summary of the code. Then:

💬 Prompt that worked “Before you start: 1. Copy the current viewer HTML into the same folder as a backup file. 2. Read the code structure and tell me briefly which feature is where. Don’t change any code yet.”

The second prompt asked what the page images were made from, where the font and resolution were set, and whether text instead of images was possible. The answer to that last question became the whole reflow viewer.

2. Plan before code, with conditions. For the reflow viewer and later for page-turn mode, the prompt said “plan only” and listed rules: keep the old viewer working as an option, use a book-specific storage key, and say which source file to use and why. For page-turn mode it also asked for the hard parts up front:

“Include in the plan: how to keep pages correct when the address bar appears and disappears and the screen height changes; how to avoid cutting a footnote number or a chapter title across two pages; how to avoid touching the existing scroll code; and what will be hard to build.”

I think this is the best habit I got from the chatbot. The risky parts showed up in the plan, not in the middle of coding.

3. A numbered fix list for visual polish. The polish prompt had 11 numbered items in four groups (cover, body, contents, settings), each with a measurable check. One example:

“In the body, offer ‘justified’ (default) and ’left’ in settings. Check at 390px width, with font size 18 and 22, that no line has gaps that are too wide.”

Because of that check, Claude Code measured the gaps. They were up to 1.6 em wide on a justified line, and it fixed that with text-justify: inter-character. A vague “make it look nicer” would not have found that.

4. “Stop here and let me test.” In the page-turn plan I changed the order myself: after the page frame was built (step 2), stop, and show me the longest chapter at font size 28 so I can check it on my phone. If it fails, we decide whether to switch method.

5. One commit per step. Each step ended with a commit. When step 3 had a bug, I could see exactly which commit introduced what.

🗂 Claude.md Rule For UI work: plan first, give a measurable check for every visual change, stop for a phone test after the risky step, and commit after every step.

What still went wrong

The loop did not make the code perfect.

  • After step 2 I tested on my phone and found that tapping did nothing on the first page, the page number was too small (11px), and the top menu seemed to be only the font-size button. The tap zones covered only the text box, and on a phone most of the screen is margin. This is the kind of bug you only see on a real device.
  • Later, “continue reading” seemed to be gone. The cause was a test link I had given to my phone with saving turned off. It was my test setup, not a bug.
  • Claude Code once could not run something in my browser test setup, because the test tab was in the background and animations paused. It took a while to see that this was the test, not the code.

What I’d tell someone trying the same

  • Give the chatbot the real file, not a description.
  • Ask it for prompts that include “don’t code yet” and “what will be hard.”
  • Paste results back as they are, including the bad news. A review is only as good as what it sees.
  • Keep a phone in your hand. A review can’t see your screen.
  • Expect to still correct things yourself. I overruled the plan at least twice: I dropped a compatibility requirement that no longer applied, and I changed the step order to add a phone check.

Cost

$0 in API fees for this part. The viewer makes no API calls and the font is free. I use the chatbot and Claude Code under my existing plan and did not track how much of it this afternoon used.

What I have not checked

  • Phone rotation, the in-app browser of a chat app, and iPhone Safari.
  • Whether this loop works as well for a task where I can’t judge the result by looking at it.
  • The translated text inside the viewer is machine output and not yet reviewed.