Vibe coding as a coding veteran: from 8-bit assembly to English-as-code

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."

> Is there a danger of leaked Qt resources now that we are blocking destruction?

  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.

ChatGPT is pretty useless at Prolog IME

In the early 70's Microdata trademarked "English" as the name of their SQL-like database retrieval language.

I wonder why it’s not the norm to use code generation or some other form of meta programming to handle this boring repetitive work?

One of my test queries for AI models is to ask it for an 8 bit asm function to do something that was invented recently enough that there is unlikely to be an implementation yet.

Multiplying two 24 bit posits in 8-bit Avr for instance. No models have succeeded yet, but usually because they try and put more than 8 bits into a register. Algorithmically it seems like they are on the right track but they don't seem to be able to hold the idea that registers are only 8-bits through the entirety of their response.