A plane flies and is nothing like a bird.

Most likely, the APP-E or GAME-E, given a prompt generate an application or game, will not generate C++/JavaScript/Swift/Kotlin but directly target the pixel space, running in a 60+ FPS loop a single "function" such as `nextFrame(currentState)`.

It will probably be here in the next few years: write a prompt such as "2D game like Mario but with butterflies" and receive a 2GB blob which opens a window accepting inputs and changing the pixels accordingly. Or, something more serious, a prompt like "invoicing application following the laws of France, Material Design, store the database in AWS using <token>". APP-E or GAME-E doesn't need to totally replace software development, just be good enough to replace in 99% of use cases.

Bugs/tests could probably be solved by some mechanism for injecting localized prompts: given an already generated binary, fine tune it accordingly to a list of other prompts.

As for deployment, it's already pretty much solved with the CI/CD solutions galore all around, not sure why you would need generative statistics for it.

What DALL-E offers is a glimpse of the next 30 years, and probably 99% of the infrastructure required to run it to its full potential is not here yet. Just as in 1992 (3 years after the HTTP proposal, but 2 years before the launch of Netscape) there were only glimpses of what a connected world would look like.

If we had such advanced AI we wouldn’t ask it to build programs, we would just tell it to do those computations directly. So instead of asking for an invoicing application, we’d just ask to generate an invoice to whatever parameters we need, and to remember the reusable data for next time.

Sure, who knows. Although humans are allegedly bad with 7±2 parameters, hence a nice user interface is still required if humans are to be kept in the loop.

My point was that something like APP-E or GAME-E seems very plausible in the near future and it is more likely to render pixels with the underlying logic encoded in an inscrutable sparse matrix, somewhat the consequence of a beefier DALL-E with regard to the data set, the learning modalities, and the attention span, than to write programs to be compiled/interpreted by any current language stack.

I guess the difference is, with the art the human can immediately reject/accept and iterate. And a bad image can be crappy, it doesn't break anything.

With software it might take days of testing to verify the result, and then repeat that for every iteration. Would be cheaper to build the thing!

Where AI might work is in some restricted subset of software, like a web CRUD app where you say "I want an app that stores a TODO list with dates". With the constraints of it being crud, it just needs to AI the database and arrangement of fields and so on.

The AI is not programming so much as it is choosing which "rails-like scaffolds" to initiate.

Simple CRUD apps are mere toys these days. We don’t even need AI to quickly generate them, it can be done with a couple scripts. The only people that would be replaced by an AI that specializes in CRUD would be recent CS graduates, junior developers.

The serious engineers are all working on things that go far deeper, and they could never be replaced.

If you want to build a business big enough to be listed on the NASDAQ, you need real developers, and you need to pay them real money.

Writing software is like writing novels: putting words together to make sentences is easy. Making the story make sense is difficult.

One could think that much of art is just pretty form without sense and that is why DALL-E works.

I don't think that assessment of art is accurate.

Most art is not "pretty form without sense". It actually has sense and meaning more often than not, so we can debate what a particular piece "means".

The difference with engineering is that art's meaning is way more subjective, and that if I "miss the point" or simply disagree with the consensus on its meaning, this doesn't make an airplane go down or a nuclear reactor to melt down.