29 ms·

The way I see it if we manage to reach a level of AI strong enough to replace software engineers it means that basically anything can be automated. It's not jus

by simias 10y ago

The way I see it if we manage to reach a level of AI strong enough to replace software engineers it means that basically anything can be automated. It's not just the end of programming, it's basically the end of jobs altogether. The consequences will be tremendous for humanity as a whole. So I'm not really selfishly worried about this. We'll go eventually, but we'll probably be amongst the last to go. By then society will have to figure out how to deal with mass unemployment, it's already a massive issue today and it's not going to improve any time soon.

donkeyd 10y ago
I don't agree, it's not like software engineering is the be-all and end-all of automation. Software engineers usually build something based om some sort of requirement. When the development part is automated, there's still a need for requirements. There will still be a job figuring out what to create in the first place. And then there's the idea that new jobs are created when others disappear. I'm sure there will be jobs in the future that we can't imagine yet. Maybe we'll actually forcibly create new jobs in order to keep people busy.
- visarga 10y ago
  Software is automation: compilers automate a large part of writing new machine code, libraries automate by reusing older code. If it can be automated, it has been automated. We have existed under the pressure of automation since the beginning of our field, we can take it.
- oblio 10y ago
  I don't know about you, but in a lot of situations when I'm asked to build something I have to actually figure out a lot of those requirements myself, as I go along. Theoretically that role is generally called "business analyst" or "product manager" or "product owner" but you know the difference between theory and practice. If we'd ever reach that point of automation my money's on many programmers just switching to some sort of "business analysis". After all, this job is all about making decisions, tons of micro-decisions.
BaronSamedi 10y ago
We may not need AI to automate software development. If genetic programming techniques started making serious advances it might be possible to evolve software. Call it "test only development"--write the tests and then grow a program that satisfies them. GP doesn't seem to get much attention so we are far from this method being practical. Actually, I'm puzzled why GP is so unpopular compared to say, type system research, since it could have a vastly greater impact if it were to make progress.
- zzalpha 10y ago
  The problem is that unless you perfectly specify your tests to provide a complete and formal definition of the interface, GP can produce results that might appear correct but is actually subtly (or grossly) broken. That's an extremely difficult task for any but the most trivial problems. It shares many of the same issues with formal verification, which has also failed to catch on beyond the odd niche project.
  - ethbro 10y ago
    As an example of why this is difficult: when integrating with legacy systems you often have (1) no API (the concept didn't exist / contractor didn't bother to isolate one), (2) no comprehensive documentation of the legacy system's internals (often, not even source), & (3) no human expert available with experience on the legacy system. Turning any kind of genetic / ML system loose on that? How would you even write test cases, short of backfeeding production data? And expecting the result to pass muster with auditors?
  - halflings 10y ago
    Yup, in ML you would call this the generalization problem: How are you going to build your algorithm build something useful instead of just memorizing the inputs in some way? Differentiable Neural Computers [1] are getting us closer (by incorporating an explicit I/O operations on a memory) but it's uncertain how much test data you would need to build complex code routines. https://deepmind.com/blog/differentiable-neural-computers/ https://deepmind.com/blog/differentiable-neural-computers/
- 10y ago

by simias 10y ago

donkeyd 10y ago

I don't agree, it's not like software engineering is the be-all and end-all of automation. Software engineers usually build something based om some sort of requirement. When the development part is automated, there's still a need for requirements. There will still be a job figuring out what to create in the first place. And then there's the idea that new jobs are created when others disappear. I'm sure there will be jobs in the future that we can't imagine yet. Maybe we'll actually forcibly create new jobs in order to keep people busy.

visarga 10y ago
Software is automation: compilers automate a large part of writing new machine code, libraries automate by reusing older code. If it can be automated, it has been automated. We have existed under the pressure of automation since the beginning of our field, we can take it.
oblio 10y ago
I don't know about you, but in a lot of situations when I'm asked to build something I have to actually figure out a lot of those requirements myself, as I go along. Theoretically that role is generally called "business analyst" or "product manager" or "product owner" but you know the difference between theory and practice. If we'd ever reach that point of automation my money's on many programmers just switching to some sort of "business analysis". After all, this job is all about making decisions, tons of micro-decisions.

BaronSamedi 10y ago

We may not need AI to automate software development. If genetic programming techniques started making serious advances it might be possible to evolve software. Call it "test only development"--write the tests and then grow a program that satisfies them. GP doesn't seem to get much attention so we are far from this method being practical. Actually, I'm puzzled why GP is so unpopular compared to say, type system research, since it could have a vastly greater impact if it were to make progress.

zzalpha 10y ago
The problem is that unless you perfectly specify your tests to provide a complete and formal definition of the interface, GP can produce results that might appear correct but is actually subtly (or grossly) broken. That's an extremely difficult task for any but the most trivial problems. It shares many of the same issues with formal verification, which has also failed to catch on beyond the odd niche project.
- ethbro 10y ago
  As an example of why this is difficult: when integrating with legacy systems you often have (1) no API (the concept didn't exist / contractor didn't bother to isolate one), (2) no comprehensive documentation of the legacy system's internals (often, not even source), & (3) no human expert available with experience on the legacy system. Turning any kind of genetic / ML system loose on that? How would you even write test cases, short of backfeeding production data? And expecting the result to pass muster with auditors?
- halflings 10y ago
  Yup, in ML you would call this the generalization problem: How are you going to build your algorithm build something useful instead of just memorizing the inputs in some way? Differentiable Neural Computers [1] are getting us closer (by incorporating an explicit I/O operations on a memory) but it's uncertain how much test data you would need to build complex code routines. https://deepmind.com/blog/differentiable-neural-computers/ https://deepmind.com/blog/differentiable-neural-computers/
10y ago