Are you seeing that AI is replacing programmers?

[Bruno Valdeolmillos]

Hello,this is a question! thanks

[Claude Moore]

My two cents: at the current state of the art of AI, it's really unlikely that we'll manage to create a General Artificial Intelligence. You asked about replacing programmers: well, write a program means to understand a goal, create an algorithm to achieve that goal, and evaluate consequences ( I mean: consequences in terms of business logic) of the algorithm programmer's willing to write. It's pretty similar to have a GAI, because a GAI is supposed to be able to plan its own actions (and a lot more else).
What I think we'll be able to see sooner or later, and in my opinion sooner than later, is a  specific AI integrated in IDE to help programmer to write better and better code, hinting possibly inefficient code and so on . An enhanced intellisense, I mean. In some IDE is already available, by the way.

[Bruno Valdeolmillos]

I saw a program that you write 3 words and it already suggests about 20 lines with arrangements, functions, definitions, etc. That's what I mean, not an IDE.
The ide is already current, my question points more to a medium-term future as well, and if someone is seeing this in their work, thank you.

[Tim Holloway]

This question has been asked before, so you might want to search the forums to see what others have said.

However, my short take is this: AI is presently not used for application program generation/maintenance. It's primarily used for data evaluation, and particularly for Machine Learning. Most of that sort of thing produces statistical values, not concrete code statements, and ML doesn't require much in the way of algorithm writing, since it's powered by the data its fed (the "Learning" part).

We have had "Wizards" in IDEs for many years now and certainly there are some shops that think that they can replace skilled programmers, but the cold fact is that wizards are really only good for what the wizard's creator wants to build and rather rapidly some user will want something that the wizard cannot handle.

So no, I still see nothing automated that can replace developers, only assist them. Management has been trying to get rid of developers for many decades, and it has never worked for them. Absent a complete out-of-the-blue change in how software is created/maintained, I don't see AI taking over there.

[Les Morgan]

My 2 cents here...

I have, as long as I have been in the computer industry, over 40 years in some way or another, seen the Holy Grail of idea to be: "Replace programmers--make them a not needed quantity in the industry." In each of the generations in this quest, there has been a significant increase in the "intelligence" packed into a language.  What I mean is 1GL, 2GL, 3GL, 4GL, and 5GL type of progressions.  Each of these have a significant decrease in the amount of work needed to be done to develop a solution with.

A very simple comparison, if you will allow it, is 1GL, machine coding or, arguably, Assembler.  Can you imagine that work that would have to be done to start off making a SQL based solution using only Assembler, or even regress back to machine code?

The very best of these type of development tools, that I have seen to date, was the "Next" application development system--developed for the Next system about 25 years ago--a platform that never really made it out the door.  it was a GUI drag and drop with minimal manual intervention for typing.  Think of SQL Server Data Tools, but only more robust and actually works.

What is seen in each of the generations of languages is a progression of intelligence in cross compiling from one programming format to another--ultimately down to a language that the computer can understand and use to effect the solution developed.

I think this will become, and is becoming, a real replacement for various technologies today--higher level languages or GUI representations for "programmers" to use to get the product out the door faster, meaning more cost effective.

No matter how automated that gets, there will always be some highly paid "nerd" (technology implementor--ie programmer) having to be there to fix the bugs that will, and always do, creep into system development.

So: eliminate programmers?  No, but each generation will, and does, change the face of programming and the tools that a programmer will have to use.

-- just my 2 cents --
Les

[Campbell Ritchie]

Les Morgan wrote:. . . eliminate programmers?  No, but each generation will change the face of programming . . .

Isn't that the sort of thing that makes the work worthwhile?

[Les Morgan]

Campbell,

It is, IMO, I have programmed extensively in Assembler, and even some in Machine Code and even hardwired jumpers on trainers: I much prefer a 3GL type of language or C/C++ which can arguably be place about 2 1/2 GL.  the real key to it all is that no matter how good the tool becomes, there will have to be a human practitioner there to fish through it all and fix the bugs

Les

[Les Morgan]

Campbell,

I used to work for one of the big consulting firms locally, they sold to a national company sometime after I left, they came across a very nice development tool they billed as a 4GL.  They wanted us to use it for development to increase their profit margins by shrinking our development time.  What we found, in all cases, was that the tool did get us to a "pre-Alpha state" faster, but then we had to fish though the generated source and find the, shall we say "less than optimal code segments".  So we were left with thousands of lines of C++ code that was machine generated to fish though.

Often times to implement changes that needed to be effected, we had to mark entire sections, hundreds of lines of code, as manual maintenance and take it out of the realm of the "4GL".  This, in itself, insured that there had to be a C++ coder/maintenance person that was on staff for each project.  Not to mention that it took way more time to fish out and fix the bad sections.  That coupled with each section of code marked for manual maintenance became legacy C++ code, which became an ever increasing percent of each application developed, the idea of using the 4GL soon was realized as an artificial boost in profits, only to be sucked away and completely lost in long run.

Our "old out of date" development paradigm, as they called it in the presentation, proved to not only be more profitable, but also a lot more dependable.  Our clients much preferred the 3GL development cycle over the "new and better" 4GL approach.

The only thing the 4GL approach even "kind of" worked for was to lock our client in, as we were the only ones using the 4GL at the time, but when they found that the source was all in C++, they bought the source and jumped ship because of the flawed development and maintenance cycle--they still required to buy time with our C++ programmers.

Les

BTW: yes, all the developers hated the machine generated C++ code, it was horrible to look at (alien to decipher), not documented with any reasonable explanation of what is being done, and each time we marked a section for manual development, it just meant one of us had to be tied to that project forever... with the garbage looking autogenerated C++ code to maintain

[Tim Holloway]

Les Morgan wrote:
The very best of these type of development tools, that I have seen to date, was the "Next" application development system--developed for the Next system about 25 years ago--a platform that never really made it out the door.  it was a GUI drag and drop with minimal manual intervention for typing.  Think of SQL Server Data Tools, but only more robust and actually works.

DDD (Drag, Drop, Drool) programming wasn't confined to the NeXt machine. I have on my shelf the instruction manual for AmigaVision. I believe that the Icon programming language from Griswold - who is famous for SNOBOL was also a member of that august society. And wasn't Logo DDD-based?

DDD's tend to be limited. Also, text-based programming can be displayed and edited far more compactly.  Which is why they haven't taken over. Some efforts do exist in .Net and there are artefacts in JavaBeans that were intended to allow for that, but it really hasn't turned into anything earth-shaking. The languages are more compact and more powerful, the support libraries more plentiful (it wasn't talking to databases in assembler that was the real pain, it was having to re-create every bloody little last component from scratch that really hurt. Another bubble-sort anyone?)

On the other hand, the "Spoon" ETL editor application for the Pentaho DI application is a very useful special-purpose DDD for a declarative language. The ETL process is typically a fairly short non-looping pipeline and the editor actually saved/loaded the waypoints along that pip in XML format. But that's the beauty of declarative languages. You can rigorously define and check stuff. The downsize is that if you need something that doesn't have a declaration definition, you fall off the edge of the Earth, so to speak.

[Bruno Valdeolmillos]

Les Morgan wrote:. . . eliminate programmers?  No, but each generation will change the face of programming . . .

probably the majority of trainers and junior programmers will soon disappear... I guess.
it is logical that man advances at the pace of man and AI exponentially., right?

[Tim Holloway]

Bruno Valdeolmillos wrote:

Les Morgan wrote:. . . eliminate programmers?  No, but each generation will change the face of programming . . .

probably the majority of trainers and junior programmers will soon disappear... I guess.
it is logical that man advances at the pace of man and AI exponentially., right?

Don't count on it. Even I spent about 2 weeks as a Junior Programmer. AI is not going to replace programmers at any level at the current state of things.

As for training, there are two primary types: in-school education and on-job product-specific training. It's true that a lot of the traditional training has been replaced by stuff like YouTube videos as opposed to being sent to a class or having an instructor come in-house, but again, AI can at best assist, not replace. Someone still has to know the correct answers and keep the material up to date.