The banner on a production app event page collapsed to empty space on iOS Safari, and the background slideshow was sitting in the DOM the whole time. Safari has well-documented viewport-height quirks, so that became the assumed culprit and the session started there.

The session ran to 197 prompts before anything worked, and the count alone should have told me the diagnosis was wrong. I did not read it that way until the patch list was already long.

what responsive reordering actually did

The page had a banner section: a full-width frame with a slideshow background, and an inner content module sitting inside it. On desktop this rendered correctly. On mobile, a responsive-reorder CSS rule lifted the content module out of the banner frame and placed it lower on the page.

That left the banner frame empty. The slideshow background was still present, but the frame no longer had the child that had supplied its usable height, so it collapsed. On iOS Safari the result appeared as blank space. The image was not missing; the layout structure that gave the frame dimension was.

The responsive-reorder rule was not new. A recent change to the inner module’s markup made the collapse visible at mobile breakpoints where it had previously been masked. The symptom looked like a rendering regression. It was a layout regression that had been waiting to surface.

the patch list that should have been a signal

Claude Code is good at generating plausible interventions inside the abstraction you point it at. I pointed it at “Safari rendering problem” and it produced a coherent sequence of fixes:

  • A min-height on the banner frame to force the background to render even with an empty child element.
  • An explicit pixel height on the same frame as a fallback.
  • A MutationObserver watching for the content module to be reattached, intended to re-trigger background paint when the DOM settled. The observer also had a bad variable reference pointing to a stale node name, which made it a silent failure layered on top of the wrong fix.
  • A source swap on the slideshow’s image asset to rule out a 404.

None of these changed the observed symptom on iOS Safari. Each could be reasonable in a different diagnosis, but none addressed what had actually happened. The content module had been structurally removed from the banner frame, leaving the frame without a sizing child.

The agent had not been told the layout had changed. I had not explained it clearly, and across those 197 prompts neither of us stepped back far enough to ask whether the frame structure itself was the problem. Each individual fix was a reasonable response to the symptom as described. The accumulation of reasonable responses is what should have stopped me earlier.

the whole frame needed to move

Once I reframed the question, the useful next step was simple. Instead of asking why the banner background did not render on mobile Safari, I opened DevTools at the mobile breakpoint and asked what was actually inside the banner frame:

const frame = document.querySelector('.banner-frame');
console.log(frame.getBoundingClientRect());            // height 0
console.log([...frame.children].map(n => n.className)); // []

The answer was nothing. The responsive-reorder rule had moved the content module out, and nothing had replaced it.

The fix was to move the whole banner frame, background and content together, when the breakpoint fired, rather than moving only the content module out of it. One edit to the reordering logic, smaller in absolute terms than any single one of the failed patches. The banner frame got repositioned with its inner structure intact, the slideshow had an anchor to render against, and the blank space was gone.

The orphaned MutationObserver got removed at the same time, along with the stale variable reference that had been watching a node no longer in scope. Both were artifacts of a session that had spent most of its length searching the wrong space.

what the prompt count was measuring

A growing list of failed interventions without symptom movement is a signal worth stopping for. In this session, the prompt count made the pattern visible: later patches became more elaborate while still compensating for the limits of the original diagnosis. That was the moment to reset the investigation and inspect the frame directly.

The AI coding assistant was not the villain in this session. It produced reasonable responses to the diagnosis I had supplied. Unless the workflow explicitly asks for competing hypotheses and direct inspection, the human still has to challenge whether the problem has been framed correctly.

A follow-up testing session brought the total to 245 prompts across two branches. Both sessions spent much of their length inside the wrong abstraction. The useful question-what is inside the banner frame at the failing breakpoint-was quick to answer once I asked it.

When several patches have not moved the symptom, treat that as a trigger to restate the hypothesis, inspect the structure and data directly, and consider whether the defect sits in a different layer.