Programming with AI feels like asking the ship’s android to plot a course for Antares

The more I use it, the more AI takes me back to science fiction passages where androids handle complex, repetitive calculations and processing: plotting space trajectories, monitoring ship systems or even entire fleets, forecasting situations, and so on and so forth. Last week I managed, though not without effort, to install good old Visual Basic 6 and all the dependencies of my MyShop 2005 project (yes, a few years ago) on Windows 11. A miracle, made possible only by the help of Claude, the AI I’m currently using, which found a workaround for every setup error. After the umpteenth attempt, I was worn out just from typing instructions to Claude, but I have my VB6 project running on Windows 11! I suspect that for the AI it was more laborious than plotting a course from Earth to Arcturus that avoids every radiation belt and asteroid cluster along the way. This morning I put Claude to the test. I had an old bug, very easy to fix, but I wanted to be sure it had been trained (“skilled,” for the cool purists) on VB6 code: when selling a variable-weight product, if the product’s list price had been set to zero, a lovely error message appeared: division by zero! I already knew where to look, but I asked Claude, model Fable 5.1: Good morning Claude, in MyShop 2005, POS project, if you sell a variable-weight product whose list price is zero, the message “division by zero” obviously appears. Could you fix it for me? Its reply was immediate:

I’m searching the POS project (MyShopFE) for the spot where variable-weight sales and the division by the list price are handled.

And after a few moments:

I found that in FrmCassaVirtuale12 the division by the list price (to calculate the weight) happens in four places, only one of which is protected. Now I’ll check that this is the right form and look at the context of the unprotected spots.

And then:

All clear. I’ll now apply the fixes with a Python script that works on the raw bytes, so I preserve the file’s ISO-8859-1 encoding and CRLF line endings.

And finally:

Done. I fixed the “Division by zero” in the POS and noted that the projects live in C:\MyShop2005 (the .vbp files there point to the sources in C:\DataShopSource\MyShop2005, so the modified file is the right one). Cause. In FrmCassaVirtuale12.frm, the weight of a variable-weight item is derived by dividing the amount in the EAN code by the list price. This happens in four places, but only the sale-saving routine checked that the price was greater than zero. The other three didn’t, and their error handler shows MsgBox err.Description, hence the message in the screenshot. Changes, all in the same form:

Yes, I believe that as soon as space technology becomes available on this prison planet, we’ll have fun with Androids, of which Claude and its kind are the forerunners 🎉🚀🚀😏 PS: the editor I use to write my blog articles was built with Claude’s help: a marvel 🤖