Since I’ve retired I’ve taken up reviving a project that I co-wrote over 20 years ago, bringing it into the modern age. The project is Dabo: a framework for writing cross-platform, database-centric apps. Nowadays things like this are done over the web, but in 2004 the state of web applications was pretty limited as far as UI flexibility and database integration. And there were many companies who ran their business on a networked application rather than over the internet, so the market for desktop apps was there.
The project was written using the tools of the day: Python 2.4, wxPython 2.x for the UI classes, along with the database drivers of that era. So bringing Dabo to modern times would take a lot of work. Updating to Python 3.10+ was straightforward enough; I had already worked on several 2->3 projects over the years. Updating the database drivers was also straightforward; most had current versions with the same interface, and the others had been replaced with new products that also shared a similar interface (thanks, Python DB-API!).
The biggest hurdle by far is updating to the current state of wxPython. This is a Python wrapper around the wxWidgets project, which is a C++ cross-platform framework for creating native GUI widgets. wxPython inherits a lot of the C++ feeling and style, and as a result is very un-Pythonic. So when we wrote Dabo, we made our UI layer a wrapper around wxPython. In other words, it’s a wrapper of a wrapper of a C++ library.
You’ve probably never heard of wxPython or wxWidgets – they are relatively obscure these days. And that’s where I think there’s a problem.
I was trying to debug a crash that happened in a part of an app: clicking a button on one tab of a pageframe ran some code, and then switched to a different page. Without fail, switching the page caused a crash with no Python traceback. I asked Claude to debug this for me. It spent a lot of time reading through my codebase, then the entire Dabo framework, and then the entire wxPython project before it could understand where the fault lay. It then confidently pronounced that it understood the issue, and coded the fix. I ran that fix, and it also crashed. Fed that crash report back into Claude, and it went through the same “thinking” steps before pronouncing the new fix. Well, you can guess where this is going. I went through this loop six more times until it finally got a fix that worked. The trouble is, it was one of the ugliest hacks I had ever seen: removing several event bindings, switching the page, and then restoring those bindings.
I’ve seen a lot of reviews of vibe coding where they say to consider Claude and others as “junior developers”, but I would never expect such an ugly hack from anyone, no matter how inexperienced; they would have come to me and said they can’t figure it out, so could I help them with it?
I had an idea as to what caused the crash, as I’ve seen similar crashes before and they almost always involved the event loop. Briefly, events fire all the time, and the framework handles them in the order they are received. So in a case like this, where the code changed the active page, under the hood it fired several events that control updating the UI. These events can sometimes conflict with others that happen around the same time, and cause a weird appearance at best, and a system crash at worst. The trick is to use the “call after” invocation, which instead of firing the events immediately, tells the app to wait until all pending events are processed before handling this one.
I told Claude that its “fix” was unnecessarily hackish and ugly, and had it revert those changes. (Tip: always have tools like Claude work on a development branch just in case it blows up like this). I then changed the one line that set the active page to use the call after design, and the crash went away.
Now I’m not trying to disparage tools like Claude; I’ve used them successfully in the past. What I think is different this time is unfamiliarity: there just isn’t that much code out there that uses wxPython for them to get sufficiently trained on in order to determine the correct approach. You can get great results with apps written in Python, JavaScript, Rust, Go, etc., because there are tons of repos in GitHub in those languages for LLMs to train on. There just isn’t enough training material for wxPython.
Which brings me to the main thought that resulted from this: creativity. How can we ever expect LLMs to come up with something new? They are designed to draw on what’s already been created, and if it hasn’t seen something yet, it is very unlikely to ever come up with that. I’m guessing that there was nothing in the crash report that had a link to a fix using call after, or else Claude would have come up with it as a solution. So in the next few years – the era of “vibe coding”, where LLMs generate the majority of new code – how do we expect new solutions to come about? New versions of the models will be trained on increasingly greater proportions of LLM-generated code; an inbreeding process that can only make newer models more repetitive.
Given this, can we ever expect an LLM to be creative? To propose an approach that has never been done before?