If I were a chef some of my stuff is definitely art, basically spaghetti.

I can absolutely imagine this done in a bunch of different ways, and some of them would look like the scribblings of a child, and another approach could be really elegant. One approach may be built to extend, while the other just gets the job done. One approach may trade speed for readability, or vice versa.

Sure. Businesses often - more often than not! - initially write code that's less readable, less maintainable, less elegant etc. on the first, second, third, nth iteration. And then later, if it becomes an issue, they address any limitations that are actually affecting the business.

I'm actually a fan of code as art, but the average business system is not that. Elegance doesn't usually matter. Extensibility only matters if the product is such that extensibility is essential - in which case the business will probably figure that out after a few iterations, or fail in some way.

There are some kinds of software where all these properties might help it succeed, but again it's not typical business software. A banking or trading or healthcare management system is not going to be art.

This is just a description of your experience. I've worked at places where the performance requirements were very clear up front and "it works" was not good enough for a first version. If you haven't that's fine, but it doesn't mean that every gig allows you to iterate on some piece of junk. Sometimes you really do need to get it right in various ways on the first try.

First, I wrote "Businesses often - more often than not!", but you seem to have ignored that.

Second, the presence of performance requirements up front doesn't negate what I'm saying in any way. What do you think that has to do with the code as art discussion? Do you think that the systems you're talking about were works of art because they had performance requirements?

I was credited as a contributor to a couple of C++ networking and component frameworks that were used in many projects with stringent high performance requirements, including avionics and telecommunications. You can see a long list of those projects here: https://web.archive.org/web/20251010124300/http://www.dre.va... (original site seems to be down; this software dates to the late 1990s.)

The frameworks, and many of the systems using it, certainly had "performance requirements [that] were very clear up front". But was that code art? One of my contributions was pointing out that the code included a misguided attempt to integrate Microsoft's DCOM distributed component system at a very low level, to achieve some sort of imagined compatibility. Once I pointed out why that wouldn't be useful, they removed the code in question.

This isn't the sort of thing that really happens with art. The kind of improvement I proposed for that C++ framework simply doesn't apply to an artwork. Someone might complain that an artist used some approach that they didn't like, but that's purely an opinion, not something that can be tested against functional requirements.

If systems like the ones we're discussing are "art", then all human creations can be said to be art. But then the word "art" becomes too broad to be useful.

The OP is just trying to justify their biases. Early on they make the unsupported assertion that "we shouldn’t be using AI to produce Art." But why not? If everything a human makes is art, and AI's shouldn't produce art, then by OP's logic, we shouldn't use AI at all. Which may be what he's going for, but then programming is just a red herring. It also makes it difficult to avoid the conclusion that everything an AI makes is art.

It's a kind of variation of the Principle of Explosion: if you make the meaning of words sufficiently broad, you reach a point where any statement is valid.