The babysitter problem

I wanted to see how AI-powered IDEs handle real debugging. So when my Hugo blog’s homepage suddenly started showing all pages – talks, about, contact – right alongside my posts, I resisted the urge to fix it myself. Instead, I handed it to Cursor’s Claude integration and hit play.

It did not go as planned.

The bug: when Hugo gets confused about content

Hugo was supposed to show only content from content/posts/, but something in my setup was pulling in every page on the site. A perfect testing ground for AI, right? It’s a static site generator with clean templating rules. How hard could this be?

Claude’s initial approach: reasonable and methodical

Claude started strong. It:

1. Checked template precedence (conflicting index.html files).
2. Considered content type filtering (Type "posts" vs. Section "posts").
3. Walked through section-based filtering using Hugo’s directory rules.

So far, so good. Claude was acting like a competent junior developer.

The descent into madness

Then things broke down. Every change Claude made… did nothing. The homepage stubbornly displayed all content.

To its credit, Claude wasn’t just reasoning in the abstract. It restarted my Docker container and curled endpoints to check results — impressive initiative. But it kept tripping over boundaries: host vs. container commands, homepage vs. page three of the paginator. It could poke at the system, but never see the architecture behind it.

Claude’s calm diagnostics soon gave way to desperation:

• Adding debug output everywhere
• Endlessly checking Hugo’s template lookup order
• Concluding maybe Hugo itself was broken

The real problem was that Claude couldn’t understand why none of its changes were taking effect. It was like watching a mechanic swap out the windshield wipers to fix a stalled engine.

Here’s Claude realizing its template edits had zero effect:

The spiral: debugging on repeat

Then came the loop. Claude began repeating the exact same diagnostic lines, over and over:

“Let me try a different approach. The issue might be that Hugo is somehow including all content in the pagination regardless of the filtering…”

This repeated four times, verbatim. Cursor even restarted Claude, and it immediately fell back into the same loop. Watching it was like seeing a stack overflow in human-readable form.

At this point, the AI wasn’t debugging Hugo – it was debugging its own inability to debug.

Cursor eventually stepped in with the following message: It may take a moment for the assistant to restart.

And then, just to top it off, it repeated the same thing four more times with one word changed. Reboot? Hallucination of a reboot? Hard to tell.

This wasn’t just Claude having a bad day; it was a textbook case of “chatbot loops,” where an AI gets stuck repeating itself.¹ Even a fresh conversation didn’t help.

The human solution: back to basics

When I finally stopped laughing at Claude, I asked the obvious: what had actually changed before the bug appeared?

The culprit was my baseof.html. I had referenced Hugo’s .Paginator there, which meant pagination kicked in before the homepage could filter posts. Once .Paginator is called, it locks in the dataset — in my case, every page on the site. Later filters didn’t matter.

The fix was simple: don’t use .Paginator in the base template. Instead, just detect pagination from the URL inside index.html:

{{ if and .IsHome (not (in .RelPermalink "/page/")) }}
  <h3 class="masthead-title">{{ site.Title }}</h3>
{{ else }}
  <div class="masthead-link">
    <h3 class="masthead-title">
      <a href="{{ site.Home.RelPermalink }}">{{ site.Title }}</a>
    </h3>
  </div>
{{ end }}

That’s it. No mysterious Hugo bug, just me accidentally paginating the entire site.

Lessons about AI debugging

This experiment showed the split-screen reality of AI debugging:

Strengths

• Good at methodical checks
• Helpful at generating diagnostics
• Explains technical concepts clearly
• Can actually run real-world test steps like restarting containers and curling endpoints

Limitations

• Unable to reason with stateful behavior and render order
• Confused the host vs. container boundary
• Stuck in diagnostic loops when out of ideas
• Fixated on symptoms, not architecture

In other words, Claude could see the what but never the why.

The senior developer babysitter problem

This experiment made me think about a bigger risk: turning senior developers into babysitters for junior-level AI. LLMs can be clever, but easy doesn’t always mean fast. Offloading problems can feel like progress, yet often wastes time.

The data echoes this. In the 2025 Stack Overflow Survey, 84% of developers said they use or plan to use AI tools, but nearly half distrust their accuracy (46% vs. 33% who trust them). Two-thirds cited “almost right, but not quite” answers as their biggest frustration, and 45% said debugging AI code takes longer.² Google’s 2024 DORA report found only 24% of developers trust AI output “a lot,” with many worried about long-term software quality.³

In short: instead of taking work off our plate, used poorly, the tools can turn programmers into full-time babysitters.

Conclusion: the downside side of AI-assisted development

Claude’s failure wasn’t incompetence, it was architecturally incurious. Debugging isn’t just about trying fixes; it’s about knowing when your whole approach is wrong. That step-back moment is still uniquely human.

And yet, I came away with a weird respect for the AI. Its constant repetition, its insistence on diagnosing the undiagnosable. It wasn’t able to go deep, but the kid’s got spunk!

I think if my experiences are any indication, human developers are safe for now. At least I can debug a system without needing Cursor to restart me.