Test and Fix

In the previous section, Claude Code generated the entire Text Comparer app from our PRD and design documents. Now we need to verify that everything works correctly — and fix anything that doesn't.

This is a critical step. AI-generated code often compiles and looks right, but may have subtle issues: a diff that highlights the wrong segments, scroll sync that drifts on long files, or a Web Worker that silently drops error responses. Testing catches these before they become hard-to-trace bugs.

Important: Before each code change in this chapter, make sure you push your previous changes to GitHub. This gives you a clean checkpoint to revert to if something goes wrong — and it's a good habit for any iterative development workflow. If you haven't set up a GitHub repository yet, follow the GitHub setup guide.

git add -A && git commit -m "describe your changes" && git push

Verify the Build#

After Claude Code finishes generating all the files, start the dev server and test the app in your browser:

npm run dev

Walk through each feature systematically. Don't just glance at the page — interact with every control and check the result:

1. Line-level diff — Paste two slightly different texts into the left and right panels. Added lines should highlight green on the right, removed lines red on the left.
2. Word-level diff — Switch to Word mode. Within changed lines, individual words should highlight while unchanged words stay plain.
3. Character-level diff — Switch to Character mode. Individual character differences should be highlighted within words.
4. Scroll sync — Add a large block of text to one side (50+ lines). Scroll one panel — the other should stay aligned, keeping matching content at the same vertical position.
5. Navigation — Click the Next/Prev buttons. Both panels should scroll to center the target diff chunk, and the change counter (e.g., "3/7") should update.
6. Swap — Click Swap. The left and right texts should switch, and the diff should re-compute with colors flipped.
7. Clear — Click Clear. Both panels should empty, and an undo toast should appear. Click undo before it disappears — the content should restore.
8. File upload — Upload a .txt file into each panel. The content should load and diff immediately.
9. Export — Try each export format (Unified Diff, Plain Text, HTML). Check that the downloaded file contains correct diff output.
10. Settings — Open settings. Toggle "Ignore case", "Ignore whitespace", and "Ignore empty lines". Each should trigger a re-diff with the option applied. Settings should persist after a page refresh.
11. Error handling — Paste an extremely large text (>5 MB or >100k lines). A warning banner should appear above the editors instead of attempting the diff.
12. Stats bar — The footer should show additions, deletions, modifications, and line count.

Run the Tests#

Next, run the unit test suite:

npm test

All tests should pass. If any fail, Claude Code can read the test output and diagnose the issue:

Fixing Issues#

When you find something that doesn't work as expected — whether through manual testing or failing tests — describe the issue to Claude Code with as much context as possible. The more specific your prompt, the better the fix.

Compare these two approaches:

• Bad: "The diff doesn't work right"
• Good: "In Word mode, when I change a single word in the middle of a line, the entire line highlights as removed/added instead of showing only the changed word with inline highlighting. The issue might be in how computeDiff maps word-level segments back to line positions."

The bad prompt forces the AI to reproduce the bug, guess what "doesn't work" means, and figure out where to look. The good prompt tells it exactly what's happening, what should happen, and where the bug likely is — so it can jump straight to the fix.

You can also point Claude Code back to the design document for reference:

If you find multiple issues, you can fix them all in one prompt or one at a time — whichever you prefer.

Common Issues#

Here are some issues you might encounter with AI-generated code for a text comparison tool, and how to handle them:

• Scroll sync drift — If the panels start aligned but drift apart after scrolling past long insertions, the issue is likely in the alignment anchor computation or the mapScrollPosition function. Tell Claude Code which direction the drift goes and at what point it starts.
• Infinite re-render loop — If the browser freezes or the console shows "Maximum update depth exceeded", the issue is often a state update inside a scroll handler or ResizeObserver callback that triggers another render. Ask Claude Code to check for missing memoization or guards.
• Highlight colors wrong — If additions show on the left panel or deletions on the right, the segment filtering in EditorPanel or DiffLine is reversed. Tell Claude Code which panel shows which color incorrectly.
• Debounce not working — If the diff re-computes on every keystroke (causing lag), the debounce timer in DiffProvider may not be resetting properly. Ask Claude Code to verify the debounce logic.
• Settings not persisting — If settings reset on page refresh, the localStorage read/write in settings.ts may have a key mismatch or the initial state may not load from storage. Ask Claude Code to check the persistence logic.

Example: Fixing a Real Error#

Here are some real issues we encountered when building this project, along with how we reported them to Claude Code.

Cursor Misaligned with Text#

After Claude Code generated the app, we noticed that the cursor position in the editor didn't match where the text actually was. When clicking or typing in a wrapped line, the cursor appeared offset from the characters — making editing feel broken:

This typically happens when the invisible <textarea> overlay and the visible rendered text layer have different font properties, padding, or line-height — so the browser's native cursor tracks one layout while the user sees another. It's a common issue in editors that use a textarea-over-div pattern for syntax highlighting.

The fix is usually straightforward — restructure EditorPanel so the textarea and highlight overlay share a single scroll container, with the textarea positioned using a ResizeObserver-measured gutter width.

Word/Char Mode Treats All Changes as Modifications#

When switching to Word or Character mode, we noticed that every change was highlighted as a modification (yellow) — even when words were purely added or purely deleted. In the screenshot below, the original text contains "request" but the original panel renders "requestxxxx" with "xxxx" highlighted as a modification — content that only exists on the modified side is leaking into the original panel:

This also caused cursor misalignment in the original panel. Because added content was incorrectly rendered on both sides as a modification, the original panel's visible text no longer matched the actual textarea content — pushing the cursor out of sync with the visible characters.

The fix is to simplify the diff model: remove the "modified" segment type entirely and only use "added", "removed", and "equal". This way, the left panel only renders text that exists in the original input, and the right panel only renders text that exists in the modified input. No content leaks across panels, and the cursor stays aligned because the overlay always matches the textarea.

Navigation Buttons Don't Jump to Diff Regions#

The Next/Prev buttons in the toolbar updated the change counter (e.g., "2/7" → "3/7") but didn't actually scroll the panels to the corresponding diff region. Clicking through changes had no visible effect — both panels stayed at the same scroll position.

Swap Only Swaps Text, Not Headers#

Clicking the Swap button correctly swapped the text content between the two panels and re-computed the diff — but the panel headers still read "Original" on the left and "Modified" on the right. After swapping, the left panel contained the modified text under the "Original" header, which was confusing.

Iterating on the UI#

Not every issue is a bug — sometimes the generated UI just needs polish. AI-generated components often use minimal styling. A few prompts can make a big difference:

Once the toolbar looks solid, you can go further and polish the entire app. A single prompt can unify the look:

UI polish is an iterative process — you don't have to get it perfect in one prompt. Run the app, spot what looks off, describe it, and let Claude Code refine it. Each round gets you closer to a design you're happy with. Small, focused follow-ups ("make the diff colors softer", "add more padding between the panels") often work better than trying to fix everything at once.

Wrapping Up#

Once all features work and all tests pass, you have a fully functional Text Comparer — built entirely through AI-assisted development, guided by a PRD and technical design.

The key takeaway: the quality of AI-generated code depends heavily on the quality of the instructions you give it. The time we spent writing and refining the PRD and design wasn't overhead — it was the most leveraged work in the entire project. With precise specs, Claude Code can implement an entire app in a single prompt — and with targeted testing and clear bug reports, you can quickly close the gap between "generated" and "production-ready."