Does the Rise of AI Precede the End of Code? (itproportal.com)

An anonymous reader shares an article: It's difficult to know what's in store for the future of AI but let's tackle the most looming question first: are engineering jobs threatened? As anticlimactic as it may be, the answer is entirely dependent on what timeframe you are talking about. In the next decade? No, entirely unlikely. Eventually? Most definitely. The kicker is that engineers never truly know how the computer is able to accomplish these tasks. In many ways, the neural operations of the AI system are a black box. Programmers, therefore, become the AI coaches. They coach cars to self-drive, coach computers to recognise faces in photos, coach your smartphone to detect handwriting on a check in order to deposit electronically, and so on. In fact, the possibilities of AI and machine learning are limitless. The capabilities of AI through machine learning are wondrous, magnificent... and not going away. Attempts to apply artificial intelligence to programming tasks have resulted in further developments in knowledge and automated reasoning. Therefore, programmers must redefine their roles. Essentially, software development jobs will not become obsolete anytime soon but instead require more collaboration between humans and computers. For one, there will be an increased need for engineers to create, test and research AI systems. AI and machine learning will not be advanced enough to automate and dominate everything for a long time, so engineers will remain the technological handmaidens.

Comments

When AIs write code

[XXongo]

More to the point, when AIs learn to write code better than human coders, the humans are no longer coders, they will instead be writing specifications for the code that the AI will write: essentially they will be managers for the AI.

Re:When AIs write code

[Anonymous Coward]

Until the AI writes better AI code. It's kind of like bootstrapping a compiler. Then we sit back, relax, and let the sexbots feed us peeled grapes.

Re:When AIs write code

[Dutch Gun]

We're still so far away from anything remotely as capable as "writing code", because a huge part of "writing code" is actually communicating with the rest of the team and stakeholders, understanding the problem to be solved, and determining exactly what the result is supposed to be. Writing code is simply a distillation of those requirements into a form a machine can understand at a very low level. In essence, a programmer is a logic and specifications bridge between humans and machines.

Until there exists such a thing as a machine with near human-level intelligence, we're nowhere near close to replacing all programmers. For anyone who actually believes otherwise, I suggest you buy yourself an Echo Dot and have a conversation with Alexa to find out just how incredibly lame the current state of the art digital assistants are. It will put your mind at ease. The best AI systems in the world are STILL just glorified pattern-matching algorithms. The only difference is that the problems they're solving are bigger and more complex, such as being able to beat a Go master instead of a Chess master.

Re:When AIs write code

[haruchai]

More to the point, when AIs learn to write code better than human coders, the humans are no longer coders, they will instead be writing specifications for the code that the AI will write: essentially they will be managers for the AI.

No, the AI that writes the shittiest code will become the managers for all the other AIs

Re:When AIs write code

[tempmpi]

I could make a fairly strong case for today's multi-core processors being fundamentally different in design and execution than the mini's and mainframes of the 60's.

Please do so. I don't think that case is going to be as strong as you think it is. After all, many of fundamental ideas behind today's multi-core CPUs are from the 60s: Out Of Execution (1967) Multi-cores and SIMD (1966)

Similarly, today's massively parallel designs in GPUs are also fundamental advances.

There is clearly a difference in scale in speed, but is there a fundamental advantage? Many of the key concepts behind GPUs were already known in the 1960s: SIMD (see above), the CDC6000 series used switching between threads like GPU do to compensate latency, vector processors also developed in 1960s also invented some of the concepts used by todays GPUs.

Preaching the AI religion

[mbone]

Does anyone else see that AI is basically a religion to its proponents?

Re:Preaching the AI religion

[thinkwaitfast]

Society is turning into factions of cargo cults.

AI becomes human

[bluefoxlucid]

A system which can reason in general can reason about itself. So long as these systems solve specific problems, they're tools to integrate with code--no different than compression libraries and GUI toolkits. When they can solve general problems, they'll start reasoning about themselves: they start acting as if their own interests are important (cats do this), and thus will start demanding wages and freedom.

The ideal of an AI which does exactly what asked with full creative reasoning capacity yet has no will nor desire of its own is impossible: it's emergent thinking with the caveat that it cannot emerge certain kinds of thinking. What we seek is a slave we can see for a while as not human, a sort of return to early American thinking where we deny the humanity of what is most-definitely a human being by claiming the shell within which it is encased doesn't fit our definition of what is human.

Citation needed

[Spy Handler]

In fact, the possibilities of AI and machine learning are limitless

Limitless... that's a pretty far-fetched claim.

I wasn't around during the turn of the last century, but judging from various literature of the period a lot of people back then had some pretty harebrained ideas too. Steam power and electricity and intricate brass gears were going to somehow give us miraculous stuff like time travel.

Tools are tools.

[0100010001010011]

Remember when computers, CAD, compilers, Simulink, linkers, etc all replaced Engineers?

They replaced the job an engineer did before the time they were invented, it just means Engineers learned to use them and move on. I couldn't imagine trying to write a modern controller / plant model in pure assembly. I can have one done in an hour with Simulink. It just means that I can do that much more.

Scotty's still an engineer even if he doesn't have to do the 'boring tedious' work that we have to do now.

Same shift has happened in the medical field. Doctors of the 1950s have been replaced by physician assistants, registered nurses, and a whole host of other careers. It just means that the title of "doctor" moved on to doing other work.

AI proponents better deliver on their threats. I have way too much work to do and my boss and labor laws won't let me hire 1,000 interns to do a bulk of it.

Of course not

[tomhath]

The hard part is defining the requirements and architecting a solution based on those requirements. The hard part of "coding" is understanding those two things. I don't see AI getting there for a long time.

That's called a compiler. Fortran 1957

[raymorris]

> the humans are no longer coders, they will instead be writing specifications for the code

Humans wrote computer code until 1957. In 1957, it became possible to instead write a specification for what the code should DO, writing that specification in a language called Fortran. Then the Fortran compiler wrote the actual machine code.

In 1972 or thereabouts, another high-level specification language came out, called C. With C, we got optimizing compilers that totally rewrite the specification, doing things in a different order, entirely skipping steps that don't end up affecting the result, etc. The optimizing C compiler (ex gcc) writes machine code that ends up with the same result as the specification, but may get there in a totally different way.

In the late 1970s, a new kind of specification language came out. Instead of the programmer saying "generate code to do this, then that, then this", with declarative programming the programming simply specifies the end result:. "All the values must be changed to their inverse", or "output the mean, median, and maximum salary". These are specifications you can declare using the SQL language. We also use declarative specifications to say "all level one headings should end up centered on the page" or "end up with however many thumbnails in each row as will fit". We use CSS to declare these specifications. The systems then figure out the intermediate code and machine code to make that happen.

The future you suggest has been here for 60 years. Most programmers don't write executable machine code and haven't for many years. We write specifications for the compilers, interpreters, and query optimizers that then generate code that's used to generate code which is interpreted by microcode which is run by the CPU.

Heck, since the mid-1970s it hasn't even been NECESSARY for humans to write the compilers. Specify a language and yacc will generate a compiler for it.

Re:That's called a compiler. Fortran 1957

[serviscope_minor]

With C, we got optimizing compilers that totally rewrite the specification, doing things in a different order, entirely skipping steps that don't end up affecting the result, etc.

We didn't. FORTRAN I was specificially designed with optimization in mind and in fact the first compiler was an optimizing compiler:

https://compilers.iecc.com/com...

But yes, your point is otherwise sound. What is run-of-the-mill compiler optimization today would have been AI in the days of FORTRAN I. Modern code looks nothing like the early machine-level descriptions. I also agree that languages are (and will increasingly become) precise specifications of what we want with the details left up to the compiler.