Other than that, implementing an AI that is capable of understanding business problems and solving them via code probably is nothing short of artificial general intelligence. In that case we won't have to worry about not being needed anymore anyway because by then we'll either very rapidly have a post-scarcity economy or you know ... Skynet ...

If AI gets to that level where the programmer is completely replaced, well, regarding "the top" that "wants us gone"... many of them would also be gone. There's no reason a general AI of that power could not automate (to give typical "the top" occupations) much of finance, law, health care, or even management / executive work.

(For comparison: the average public school student in the US costs $12,000 to educate. And yet plenty of people will say that even that is not enough.)

But the good news is if we don't fuck up, that number will continue to grow nonlinearly, just as it has for many decades. We will live to see it cross the point where it really is high enough to give everybody a comfortable life.

Why does it cost $30,000 to educate a class of 30 kids for a month? The salary of the teacher should be <$5,000. Double, or triple that to include rent and other costs. It still comes out at half of $30K.

Will it? When you look at most First World countries in general nobody there has to starve anymore.

In the Middle Ages only liege lords could get by without ever having to work. Nowadays, even middle-class people don't necessarily need to work till retirement age.

Use of food banks has increased in the UK, and hunger is very much present: https://en.wikipedia.org/wiki/Hunger_in_the_United_Kingdom

This is a policy choice. For many voters, it's far more important that nobody "gets something for nothing" than nobody starves to death. This has resulted in the benefits system being increasingly punitive leaving some people without money for food for weeks at a time.

Tell that to the people who insist that Real Programmers™ always write these things from scratch, never use a library to help them with it, etc.

2. This may just be my projects, but people tend to re-make excel on the web with it.

3. Its easy to get started coding with it, but quickly turns in to spaghetti filled with glass shards when you try to do advanced things with the controls.

What experience or understanding about "AI" do you base your opinion on?

This is a cynical view of the world. Maybe the people "on top" simply want to improve their company's efficiency in order to return value to investors, etc. My point being its economics, not some evil intent.

Software engineers need to recognize this common threat and organize (labor) sooner than later

And the point of that would be what? To protect our jobs by demanding that industry ignore and no longer pursue innovation? That seems like heresy for anyone in Tech.

If the day does come that AI starts writing code, the lost of our fat salaries and stock options will likely be the least of our problems; or perhaps the world will be void of problems altogether.

Those who already have capital and can invest it smartly might fare much better than those who only rely on BHI, which is at the whims of politicians. A person need not be super rich, if she can associate with other to buy land for agriculture or robots for manufacturing. Robots are analogous to land. You gotta have one or the other :-)

HN doesn't bat an eye at Uber, AirBnB, Netflix, Amazon disrupting and taking away jobs. But it's interesting once programming jobs are threatened, some become defensive.

An interesting analysis on a world with increased automation via emulated brains of the best of humanity: http://ageofem.com/

I'd love to hear your thesis for this, in a way that doesn't whitewash away the negative effects on the individual. If you're going to claim we should all be throwing ourselves on the burning pyre of progress no matter what I'd love to hear more of a compelling argument than "never a good iea".

There's no reason why you have to think "I'm a software engineer, therefore any attack on software engineers is an attack on me." You could, just as easily, define yourself by "I'm a person. I do software engineering because the money is good right now and that is what the economy happens to need right now, but if in the future society ceases to need software engineers, I'll retrain with whatever skill is highly valued then."

I remember coming out of college, happy to learn about the world, and thinking how sad it was that people's identities were so wrapped up with their jobs that they were broken when their jobs were eliminated. I felt that shift happening soon after I turned 30, where I started to get just a little bit too comfortable and too proud of what I was rather than what I did, and then quit so that I'd have that opportunity to grow again.

Software development has been invaded by mouth-breathers who don't give a shit about what they're doing, and I don't see a way to switch careers as an adult chasing money without becoming one of those.

And I don't meant that facetiously - interpersonal skills matter. A lot more than pure technical skills, because they allow you to leverage groups of people to achieve bigger goals.

I know it sounds cruel to talk about people like a resource or as an animal, but that is precisely how I see society as treating lots of us in the name of a greater good. Under the guise of social-welfare we've increased our numbers to levels that never would have occurred naturally by us simply taking care of the really needy.

So now we're stuck in this predicament. Either we progress our society, and potentially affect a lot of people negatively. Or help everyone slightly-struggling and below out by preventing a technological-revolution so we can grow a bit at a time, and delay the problem for the next generation.

I'm a full-time software engineer, but I spend maybe 50% of my day implementing code. I spend a lot of time figuring out trade-offs, exploring edge cases, and verifying that the business/marketing people know what the side-effects of a given feature will be. There's also a lot of flag-waving to make sure that small problems don't become big problems.

I've run into the "that should be able to be automated" hand-wave of a thought before. I think it's always done by people who haven't actually spent time thinking about the edge-cases and all the little decisions that are put into a final software project. Sure, you can hand-wave and get a CMS, but you're going to be unpleasantly surprised when the defaults don't match your subconscious expectations.

Here's how software engineers could retain their position in a world where our code is automatically generated:

- Understand and communicate the trade-offs of different solutions

- Embrace product design-- a lot of us unwittingly become novice visual designers and product designers during our work, and we should embrace that domain knowledge that we learn, rather than being frustrated that we're being taken away from our primary task, coding.

- Explore edge cases, and explore new ways of doing things

- Understand and get involved in the business process!

The bigger issue is what has we've already started to witness: automation leads to accelerated accumulation of wealth and resources among those who already have the most capital. Historically, corporate profit and labor demand went up or down together. Now they're diverging: corporate profit grows while demand for labor shrinks. The spoils of corporate success goes to those who own the tools of automation, and others lose their job and income.

In any case, OpenAI's vision here is much bigger than making software developers obsolete: they want to study (or create) AI that can improve itself (i.e., a singularity scenario).

Has organized (labor) ever saved organized labor's job?

Organized labor is useful against a whole lot of problems, but not this one.

If one would reflect back on the applications that they've built in their career I suspect a number of those applications are now available generally as packaged software with customizable components.

E.g. The dawn of the web saw many publishing, & catalog systems being built. Now you don't need to, you can simply grab a commercial or OSS package and customize it for your needs. Same is true for document management, workflow.

This hasn't impacted jobs yet because we are still early in this industry, and growth is still outpacing this commoditization. But, yeh, I see the day where software developers become quite rare and software customizers are common.

The tricky challenge is organizing our labour efforts. It's already easy for IT organizations to outsource development to cheaper markets, I fear labour organization would accelerate that movement.

Step it up a level further, if computers could think of programs to build themselves (which they probably would have to if they are going to be anywhere close to practical), that's when the "singularity" truely starts to take off. At the speed that computers operate, programs would very quickly go beyond what humans are capable of.

It's not in any danger of happening soon, but if/when it happens, you might as well join the union of street gas lamp lighters.

So, I think it'll be a long time until 'the people at the top' get what they want. Until they start coding a replacement for Dropbox or SublimeText that will be the end-all of filesharing/file-editing, we'll always need another IPFS, another Atom, etc., etc.

Just in case, since I think I'm up against Poe's law here: I am, in fact, 100% serious.

Isn't, given a problem 'X', produce a solution 'Y' kind of automation, called AGI?

Well then you have little to worry about. If AGI is indeed invented you have bigger things to deal with than worrying about your job.

In any such eventuality 'people at the top' are likely to be eliminated rather more quickly than us. Because an AGI with huge resources can make far better decisions than any CEO ever can.

The upside is that I think it would be really accessible for anyone to have it's own personal army of programmers. Although that's also quite dangerous.

The only way around the halting problem is to use something other than computation as we know it. I.e. an entirely new kind of machine based on different principals. And no, quantum computers do not solve the halting problem since they are still Turing-complete machines.

There is a fairly large subset of useful programs that can be proven to halt. Anything that uses straight-line linear control flow. So can anything with that plus conditionals. So can that plus foreach loops, as long as iterators do not reflect updates to their underlying collections. Add a "forever { ... }" construct and you can prove that the program will not halt; in combination with the other constructs, you can prove liveness on each request handler while also guaranteeing that the server itself will never go down.

The two constructs you have to watch out for are loops that mutate state used in the conditional and unbounded recursion. Even for these, there are techniques to increase the set of programs that can be reasoned about, eg. using dataflow analysis to identify which state is mutable and preventing it from being used in conditionals or tracking data & codata through the typesystem.

http://blog.sigfpe.com/2007/07/data-and-codata.html

Such a language would not be Turing-complete; you won't be able to write an interpreter for a Turing-complete programming language in it. But the majority of common business problems don't require an interpreter for another programming language; most of them focus on storing data, triggering events, or computing functions of data.

http://mathoverflow.net/a/153106

Because of the list of correct answers for a finite subset of the Halting Problem is finite, the Turing machine you mention does exist, but we not only can't find it, we can't know when we've found it!

Where the Math Overflow post mentions that "experts could compute the particular value of n", there has recently been such a bound published in a thesis, such that we can be confident that we can never construct or recognize the solutions beyond that point (using a particular axiomatization of mathematics).

You referred to the idea that "you can have a Turing machine that solves this", and we can agree on that with the caveat that, above certain problem instance sizes, you can't know or verify in any way that you have such a Turing machine!

My argument stands. Unless the halting problem is overcome, there will still be jobs for humans to write Turing-complete programs.

Turing machine X can produce programs that meets certain specifications => Turing machine X solves the halting problem.

Here's a nice simple one for you:

    def collatz(n):
        while n > 1:
            n = n/2 if n%2==0 else 3*n+1

In practice, programming doesn't require solving halting problems. We write programs that are on average easy to analyze, especially if you're calibrating the scale with busy beavers. There's no fundamental reason that a computer program can't collect requirements, collect clarifications, and translate those specs into executable code. Clearly it's hard (How do you do the translation? Optimizing Prolog isn't easy! And how do you avoid asking for millions of things that humans take for granted as obvious?), but I don't see anything that makes it impossible.

The halting problem doesn't really matter that much in this context. Just spawn up a bunch of threads that churn away at the problem, using random mutations, and any that go on too long can just be considered flawed, regardless of whether they have any redeeming qualities.

Then you select the winners, based on the selection criteria, and churn away on some more mutations of those new variants.

In general, you will not be able to easily find P using a genetic algorithm (which amounts to a random walk through the space of all programs) even with many threads. The problem is that the algorithm is exponential in the length of P. It only works if you only consider a very limited set of possible programs. E.g. very short programs or programs which are only slight variations on a known program.