Is it a bubble?

If a compiler counts as AI then so does literally every other program out there (at least the ones with well-defined inputs and outputs).

>Sure. As is natural language (e.g. criminal code).

Natural language is too ambiguous and self-referential to count as a programming language, per se. While a subset of natural language can obviously be used to describe programs, we distinguish programming languages from natural languages in that they are formally defined and bound to be interpreted in one way by a machine with a relatively small amount of context (notwithstanding minor differences between implementations). Natural language has the unfortunate property of semantic drift (or whatever it's called). The sounds, spellings, meanings of words, etc. are extremely context-sensitive and unsuitable for reliably encoding computer programs or anything else over long periods of time. It is very common for a single word in a natural language to have several meanings, even contradictory meanings.

>They took the higher level instructions written by the software engineers and translated that into machine code. Hence the name. Developer in the above referred to what you call software engineer.

I am well aware of what you're trying to say, and the historical context, but I think you're applying modern terminology to old practices to draw a bad conclusion.

>It seems your misinterpretation is down to thinking that software engineer and coder were intended to be the same person. That was not the intent.

I didn't misinterpret anything. These jobs were not "intended" into existence. It just so happens that writing any kind of code is challenging enough to require its own dedicated professionals. That has always been true.

>Once the job of coding went away it has become common to use those terms synonymously, but the above was clearly written about the past.

The job of "coding" never went away. The type of code being written changed. The product is still CODE as in a procedure or specification encoded in a purpose-built, machine-oriented, unambiguous, socially neutral, and essentially eternal language.

>Again, if you're looking for a silly semantic discussion, there is already another thread for that.

It's not a silly semantic discussion, it's a serious one. You think that one can be a "software developer" merely by using natural language, and that there is historical precedent for that. But this is very wrong, especially in the historical context. By your own argument, any dumbass manager could be a "software developer" if only he found an entity to write the software for him based on natural language instructions. It matters not whether the entity generating the actual code is a human being or a machine. Since there are actual people trying to hire software developers and engineers with real skills, it is a waste of everyone's time for vibecoders to call themselves "software engineers" or "software developers" because they're not. They are JUST vibecoders. That skill set may be sufficient for... something. But stop trying to make it into something it isn't with these misleading arguments and analogies.

It is slightly hilarious that this entire "silly semantic discussion" is a product of the properties of natural language. One of the massive benefits of computer languages is that you DON'T get into stupid discussions about the meanings of things very often. When you DO, it is usually because some goofball wrote a bad spec. The ambiguities and other nonsense are hammered out in the spec, and from there on the language has a concrete meaning that is not up for debate.

I'm sorry man but I've been doing this for 25 years and I've worked and studied with some extremely bright and productive engineers. I vouch for the code that I write or that I delegate to an LLM, and believe it or not it doesn't take a magician to write a k8s spec file, just patience to write 10 levels of nested YAMLs to describe the most boring, normal and predictable code to tell your cluster what volume mounts and env variables to load.

* SQL works almost as good. It's especially useful when you need to generate queries with long lists of fields and complex query criteria. Give it a schema and let it rip.

* Python code works reasonably well. If your description is terse and clear it will generally do the right thing. It has a knack for being excessive in comments and will sometimes do things in ways that feel unnatural, but business code will be as good as the context that surrounds it. For boring, repetitive tasks like setting up program args, annotating types, and writing generic request/response cycles with common frameworks it will do boring old vanilla code. You'll likely want to touch it up and adapt it to your personal preference.

* Debugging is very much or miss. It has been absolutely fantastic at troubleshooting failed and stuck k8s jobs and service configuration issues, having no qualms about creating its own shell or python scripts to investigate ports or logs, and writing JSON parsing scripts that are snoozefest for a human to write. The regexes that I'd barely be arsed to write to parse enormous logs it writes trivially. For business logic, the more convoluted your logic the harder the time it will have, and for most debugging issues I prefer to let it run and list some hypotheses and potential issues and my intent is to learn and understand the problem myself deeply before committing to a fix.