I still have doubts but I am warming up to Claude Code. Sometimes it gets in these ruts where it tries something wrong, gets shown it's wrong, keeps digging, and can't even explain how its failed suggestions could even work. Other times, it seems to reproduce the kinds of insights (and even judgment) that I'd expect out of an actual practitioner. After suggesting code to fix problems, I always ask it to explain the context in more detail. I was recently using it help to develop a Qt C++ application, and ended up getting this interaction from it:

> Can you speculate on why this problem was only happening with these embedded buttons? Is this a flaw in Qt, or is this application trying to do something unusual?

  Why this problem occurred: This is a Qt design issue, not a flaw per se. Qt's item delegate editing model assumes editors are simple widgets (line edits, spin boxes, combo boxes) that don't spawn modal dialogs. When a modal dialog opens:

  1. The modal dialog steals focus from the editor button
  2. Qt's QAbstractItemView sees the FocusOut event and assumes editing is complete
  3. It calls QStyledItemDelegate::destroyEditor() to clean up the editor
  4. The button gets deleted while the color dialog is still running
  5. When the color dialog closes, it tries to interact with the deleted button

  This application is doing something unusual - using a button that spawns a modal dialog as a table cell editor. Most Qt delegates use immediate editing widgets (text fields, dropdowns) that don't require modal interactions.

  The eventFilter solution works by intercepting the FocusOut event that triggers editor destruction, essentially telling Qt "I'm still editing, don't destroy me yet."

  Yes, that's a valid concern. By blocking FocusOut events, we're preventing Qt's normal editor cleanup mechanism. However, the risk is likely minimal because:

  1. Qt still cleans up eventually - The editor will be destroyed when the table view itself is destroyed or when editing truly ends (e.g., clicking elsewhere, pressing Enter/Escape)
  2. Short-lived editors - These editor widgets are typically very short-lived (created when editing starts, destroyed when editing ends)
  3. Parent widget cleanup - Since the button has a parent widget, Qt's parent-child ownership will clean it up when the parent is destroyed

  To be completely safe, we could add a more targeted approach - only block FocusOut events while a color dialog is actively open, rather than blocking all FocusOut events. We could track when the modal dialog is shown/hidden and only filter during that window.

  But for this use case, the current solution should be fine since:
  - Color picking is infrequent
  - The editor lifetime is still bounded by the table view's normal lifecycle
  - Qt's parent-child cleanup provides a safety net

  The memory usage impact should be negligible compared to the complexity of implementing more sophisticated tracking.

I've definitely had less-satisfying discussions over bugs with actual human senior software engineers than this.

It seems to be just playing the “yes and” improv game with you. You might want to also try prompting it against the same suggestions and see if it changes to follow your lead or continues to hold the original opinion.