Claude Spent Hours Debugging the Wrong Thing.

Howdy friends!

Let me tell you about the most painful Claude Code debugging MAUI session I’ve had in a while. I was building a .NET MAUI Android app and I trusted Claude Code for too long instead of just rolling up my sleeves to see what’s going on.

---

The setup

I’m building RiseOhana, a family engagement app where parents create quests, kids complete them, and the whole family levels up together. I’m working on a reward catalog screen where parents can browse and manage rewards. Each list item is swipeable so they can edit or delete. Standard stuff. I needed to show each child’s avatar inside the swipeable list item. A small circular photo, nothing exotic.

I dropped an Image element into the DataTemplate inside the SwipeView. Android instantly died. No exception. No error message. Just silent death the moment the rows tried to render.

---

The Claude Code debugging chase

Here’s where it gets frustrating. Claude made numerous attempts at solving this.

Claude’s first theory: the Ellipse combined with Image was the problem. Swapped it for a Border with a circular clip. Still crashed.

Claude’s second theory: the HexStringToColorConverter was doing something weird. Ripped it out and bound the color directly. Still crashed.

Claude’s third theory: nullable binding values were blowing up somewhere. Added non-null defaults to every property on the model. Still crashed.

I interrupted Claude at that point. We had another page, the parent credits overview, using the exact same Ellipse and Image pattern without any issues. The only structural difference? That page didn’t use SwipeView.

So Claude landed on a theory: Image inside SwipeView DataTemplate crashes on Android.

Felt solid. Explained everything. I then told Claude to test that theory.

Claude then removed SwipeView entirely. Rebuilt the swipe interactions as tap interactions. Restructured the whole UI to work without it. And it stopped crashing! I thought it was safe to move on.

Except Claude hadn’t actually put the avatar back yet. It had removed the Image while removing the SwipeView and hadn’t gotten around to restoring it. When it added it back, same crash. So Claude did what any reasonable engineer in hour four of a debugging session does. Replaced the avatar image with a colored circle showing the child’s first initial.

At this point I was genuinely frustrated. Hours deep, stewing, completely done with it. And then I caught myself, because I realized I was directing that frustration at an LLM. It doesn’t have feelings. It doesn’t have a bad day. It was just out there confidently executing on the wrong theory, totally unbothered.

So I, not very calmly, reminded Claude that “the goal was to draw the avatar card.” Not slap a letter on a circle. The actual photo.

Claude said “you’re right, let me fix that” and kept right on going. No pause. No ego. Just on to the next thing. Which made me feel a little ridiculous about the whole “being frustrated at software” situation.

---

The actual problem

Claude had the broken XAML file and the working XAML file right in front of it, compared them, and still couldn’t spot it. I plopped the same two files into WinMerge and the difference jumped out immediately. The page was missing the converter declaration in its resources:

<ContentPage.Resources>
    <converters:AvatarSourceConverter x:Key="AvatarSourceConverter"/>
</ContentPage.Resources>

The converter was referenced throughout the template with {StaticResource AvatarSourceConverter} but was never declared on that page. Every other page that used avatars had the declaration. This one didn’t.

In .NET MAUI, a missing StaticResource doesn’t give you a compile error. It doesn’t give you a runtime exception. It just silently explodes when the binding tries to resolve it at render time. The Image element wasn’t the problem. SwipeView wasn’t the problem. The missing resource declaration was the problem. And every single “fix” that appeared to work only worked because it coincidentally also removed the broken converter reference.

All that time spent chasing the wrong culprit. A quick diff in WinMerge showed me exactly what Claude couldn’t figure out on its own.

---

What I took away from this

The software engineer is still very much needed. I know this is a hot topic right now. People are asking whether developers are going to be replaced, and sessions like this one make the answer pretty clear to me. Claude Code executed every theory it had with confidence and speed. What it couldn’t do was stop and question whether it was solving the right problem. That took me stepping away from the execution and looking at the situation from the outside. The LLM is an incredible engine. It still needs a driver. I ran into the same thing when Claude Code built a whole feature without thinking about the system it was building into — same pattern, different day.

The black box of LLM pattern matching has real weaknesses. When Claude saw a crashing Image element, it pattern matched to everything it knows about images crashing in MAUI. Converters, nullable values, layout containers. All reasonable things to try. But it had no visibility into why the pattern matched in the first place, and no way to know it was chasing a symptom instead of a cause. You don’t know what it’s latching onto, and it doesn’t know either. It just keeps generating the next most probable fix.

If you’re going in circles, stop and question the assumptions. Claude told me with full confidence that Image inside SwipeView crashes on Android. It was wrong. But we had run enough experiments that the theory felt solid. Cycling through the same family of fixes is a signal to stop and go back to first principles, not a signal to keep trying. When an LLM is confidently wrong, it stays confidently wrong until you make it reconsider the premise. That’s your job, not its.

---

The avatar is rendering now. The kids look great in the reward catalog. SwipeView is back, exactly where it belongs.

And I’ll be checking resource declarations a lot earlier next time.

Have you had a session where you trusted the AI a little too long before just looking at the problem yourself? Drop it in the comments. I know I’m not alone here.

Happy coding friends! Keep on coding on!

---

RiseOhana is a family engagement platform I’m building. Quests, rewards, and quality time for families who want to level up together. Come find us at riseohana.com.