As a technical manager, this actually isn't that far from what happens with teams of engineers. The less precise I am in describing the requirements of a system, the less correct solution is produced. This isn't to say that my team is incompetent or mindless -- far from it, I find them to be some of the most talented engineers I've had the pleasure of working with.

Perhaps the solution to this particular problem is a clear specification of the requirements of the problem -- very similar to how corps define requirements documents for what their product does/behaves like?

I'm not saying it applies to your case, but one danger of specifying a problem in too much detail, is that it teaches the engineers to think less about the problem. From my experience developers often think of failure cases that the managers are not aware of, or have a simpler solution to a problem.

And yet if the problem isn't specified enough, we engineers will run off and deal with failure cases that aren't relevant to the client's needs.

This discussion reminds of this question/answer on quora: https://www.quora.com/Since-programming-can-be-self-taught-w...

I, too, find this to be the case. There seems to be a happy medium of "you figure it out" and "it must do exactly this".

As a relatively new manager, I find figuring out where the balance is tricky.

Not only is it not a new thought, but it's been the holy grail of large software companies for at least 30 years. You'd be surprised at how much money has been spent researching this problem. And, for those just coming into software engineering, this isn't a good sign. I see a lot of software engineers that don't fear the risk of automation. But, because software development is such a huge cost center and so much is controlled by software developers, complete automation is one of the most sought after technologies.

I don't mean to spew hyperbole, because complete automation is likely very far off. But, I just wanted to point out the market forces behind this type of technology are gigantic.

In my experience, people have trouble describing something in sufficient detail that another human can build what they want. I think we're a ways off yet from AI being able to do so.

Asking the right questions about the system usually helps a lot though. If an AI can help with that aspect, that may increase productivity at least.

Doesn't TDD basically provide a spec? Write a test, then let the AI generate a program that passes the test. If the program is still buggy, you didn't write sufficient tests.

To completely specify a program via tests, you've effectively written the program. You've also probably written somewhere around 2x the code the actual program would require as well.

I'd be more curious to see an AI write tests...

> ou've also probably written somewhere around 2x the code the actual program would require as well.

If you go trough the easiest path, you just need to write the program and compare the results with the AI's ;)

But if you go on a case by case basis, your work will grow exponentially with the program size, not a mere 2x.

Tests are much more verbose than specs. Test validate existential properties, ie. there exist inputs where property P is true, but specs can also specify universal properties, ie. for all inputs property P is true.

Static types also specify universal properties, which is why tests can't replace types, even in theory. But tests+types could be a type of spec.

Tests can constrain a problem enough so a human programmer can understand what was intended. In theory, many programs will pass the tests, but in practice most matching programs will be convoluted and in poor taste - they only pass the tests and not the general rules implied by the test cases. In other words, there are additional constraints implied by common-sense principles of software engineering.

Developing an AI that can infer a simple, tasteful set of general rules (and suitable types) from a small set of test cases is certainly hard but not theoretically impossible.

I don't think it's that simple. Imagine a simple add(int32, int32) int32 function. Unless you write a test for all 2^32 * 2^32 possible inputs and their expected outputs, how could you guarantee that the AI will come up with the "correct" implementation?

Automated tests are generally not practical for proofing program correctness. Why would you expect them to be sufficient as a specification format?

With property-based testing one can describing the behavior over the entire domain(s) of valid inputs. Sampling is used to draw a set of cases to actually test, up to a certain number of test. Knowledge about boundary conditions in the domain can help catching failures earlier, though plain random seems to be pretty darn effective (at least for code written by humans). Candidates with dead code should maybe be punished. Candidates with higher complexity should maybe be punished.

Software produced by a typical business app developer is not provably correct either. TDD of AI generated code could not hope to produce something more correct. As your tests get better, so would the software produced both by the human and the AI.

For your add(int32, int32) function: While an AI-generated implementation is not provably correct unless the test contains 2^64 inputs, I think it's pretty likely that a correct implementation would in fact be generated pretty quickly.

I don't think it's as likely as you assume. Let's say you ask the computer to implement your adder, and you feed it the results of a few dozen, or a few hundred uint32 a + uint32 b = uint32 c operations. By coincidence, however, in all of those operations, every time bit a[14] is zero, bit c[26] also happens to be zero. The computer may produce an implementation which assumes this is always the case. The computer may also reason it does not need to look at some of the input bits, if say, for all of the tests, bit b[2] == bit b[16].

It may seem that a solution with assumptions like those are more complex than a simple addition operation, and thus the computer will find the addition solution first, but "simple" is a matter of perspective. Addition requires a logic cascade through the entire number, since the carries of the lower bits must be passed to the upper bits, which requires a critical path equal to the entire length of the inputs/outputs. In searching for an implementation which satisfies the few dozen/hundred test cases you feed it, making assumptions like those in the first paragraph can drastically shorten the critical path, and require far less logic since it's ignoring much of the input. Thus algorithmically, the addition operation may be seen as more complex.

(BTW, I don't think it's that simple either. Just pointing out that TDD is a possible approach to avoiding the infinite recursion of specs-are-just-programs-in-a-higher-level-language.)

A few years ago I read a post by Bob Martin about how you can solve code kata problems by applying a sequence of 'transformations' to pass one test at a time. His method is very mechanical... so mechanical, in fact, that I think it may be possible to automate it.

So I started tinkering with the concept, and I've got a bit of a start on it here:

https://github.com/michaelmelanson/autocoder

What's there is very rudimentary. The main class is a good place to start.

Basically I'm building up a library of transformations that can describe solutions to kata problems (the 'word wrap' one currently). The next step is to create a search algorithm to derive an ordered sequence of transformations from that library to pass an ordered sequence of tests.

You might find Perelman et al's "Test-Driven Synthesis" paper interesting, it also cites that post as inspiration.

http://homes.cs.washington.edu/~djg/papers/tds-pldi2014.pdf

DHH did a great job explaining this exact same thing on Tim Ferris's podcast a while back. http://tim.blog/2016/11/25/david-heinemeier-hansson-on-digit... at around 13:49.

Basically as time progresses we keep creating languages that are a "higher level".

If you can describe something then you can just code it. I can see AI being used in an advanced IDE as an assistant. Just write your specs and let the AI build the app.

But wouldn't you agree that by the same line of reasoning, if you can spec it, you can code it?

I mean, the difficulty lies in specifying what you want in such an unambiguous way that a program that fulfill the specification actually does what you had in mind originally.

I think you're lacking imagination. You're thinking of a software developing ai as a simple compiler. You also seem to think there must be a 1 to 1 relationship between a user's specification and resulting program. But a software developing ai could work very quickly , taking a vague natural language specification and giving many programs to choose from. That set would be narrowed based on a learned correspondence between natural language and completed programs, and narrowed and refined further with more vague natural language specification from the user. If the ai is smart enough the system could be only a bit more complicated to use than a thumbs up/thumbs down on pandora.

or we just ditch humans and allow an ai to assess what software we need.

Sure. Exactly what I meant. It would just speed up your job.

Yes, and that difficulty has been lowered many times over the years as we create better programming languages, libraries, and tools. It is easier and quicker to unambiguously describe your program in python than it is in assembly. It is easier to write a web server using libraries than by writing the whole thing from scratch.

These advanced AIs would just be the next level of this, giving even easier ways to specify to a computer exactly what you want it to do.

but a lot of things use defaults or common practices which could be collected and used. and if this AI had a chat interface it could prompt for some of the requirements. for a lot of users its not knowing the questions. and the pros and cons of the answers.

This osund like all the promise of JavaBeans many years ago, just drag and drop and let the components write themselves.

Writing code isn't the difficult part about building most software.

making people in an industry more efficient at their jobs == job losses for that industry.

if one programmer can now do the work of 5 with the help of an AI, companies will quickly be hiring less developers.

yet everytime i mention this, im told that "software developers are the one job that will never be at risk of automation"

All jobs are at risk of automation. Jobs by themselves are a pointless construct. It is the living that they provide us that is of value. I'm looking forward to the day this is accepted in mainstream political thought.

You're making the assumption that companies need to accomplish a constant amount of work, and that they only hire enough developer to perform this work. I would argue that many companies have a limited budget, and will continue hiring developers to expend this budget. Once hired, there is effectively indefinite work that can be done, and which will better the position of the company. If each developer can do 5x more, then the company will accomplish 5x more, not spend 5x less.

> im told that "software developers are the one job that will never be at risk of automation"

The AI is itself a program. If the AI can write programs, it can write a better version of itself. A few iterations of this, and it will have far surpassed human intelligence.

So it would be more accurate to say that writing programs is the last job that will be automated.

> The AI is itself a program. If the AI can write programs, it can write a better version of itself.

Not necessarily (or even likely). There's a huge difference between being able to write "programs" (for example the ones described here are ~5 lines) and being able to write a large and very complex piece of software, which such an AI would undoubtedly be.

There's also the question of what constitutes "better." Improvements in e.g. speed or memory efficiency (hard enough as it is, but conceivable for an AI) are a quite different thing than improvements in capabilities or understanding.

> There's a huge difference between being able to write "programs" (for example the ones described here are ~5 lines) and being able to write a large and very complex piece of software, which such an AI would undoubtedly be.

That's true. real-life programs that programmers get paid to write are typically more complex than 5 lines. Any AI good enough to replace real programmers is going to be very close to good enough to rewrite itself.

This makes the assumption that every program it writes is somehow guaranteed to be better than the original. Why would it not run into the Multiplicity problem, where each subsequent copy is a bit dumber than the original?

I would think it would be much more likely follow a normal evolutionary model - improve itself to a local maxima, then just stall while the random mutations fail to make the huge leap required to hit the next maxima.

We can't even properly model the human mind in computers yet - not enough processing power - so it follows that an AI which is "better" than humans would require even more processing power than that required to ape humans.

The difference here is the "intelligence" of an AI can be described as a loss function, so if an AI can build and then train another AI which can achieve a better overall score from many examples in its loss function, then that AI, with perhaps a deep neural network will start to "understand" or the components that make a successful neural network. Thus it could use intelligence rather than random mutations to evolve.

I think things like psychology/psychiatry, social work, child protective services, and other jobs that rely on a lot of interpersonal communication will be around longer than development; at least at any scale worth talking about.

I would argue that every year programmers ARE more efficient at their jobs with adoption of new tools, frameworks and methodologies. Yet there is still not enough good developers.

yes and each new tool or helpful framework reduces the total number of developers needed. Just because we have yet to meet the demand for developers, doesn't mean that that demand is not decreasing over time.

software development is quite a young industry, so its growth can easily outpace the efficiency gains resulting in more developers, until it doesnt. Development as an industry will need to maintain stronger growth than efficiency gains through innovation, and i just dont see that happening long term.

edit: in my first paragraph i should have said " Just because we have yet to meet the demand for developers, doesn't mean that growth of that demand is not decreasing over time."

You start out with n amount of programmer time demanded from projects a b and c, given that you can do x with y number of programmer hours. So imagine that increased efficiency means you can now do 2x as much fantastic now you only need n/2 right!

Not so fast now that you can do more with less d, e, and f are worth doing and n+ are now demanded.

Basically simple economics says that decreasing price, the price for a given unit of work going down increases the demand for such. This is not realistically infinite however most of the world has a long way to go to catch up with the developed world and the developed world itself seems to have no end in sight as far as demand for automation and tech.

It would strongly look like until it doesn't is so far out on the time horizon that it is hard to predict anything at all on that scale.

>economics says that decreasing price, the price for a given unit of work going down increases the demand for such

an AI costs nothing in the long term, so you are agreeing here that demand for AI produced software will rise more sharply than demand for human developers, because they are more expensive.

So if you accept that basic law of economics, then you must arrive at the conclusion that human labor will inevitably be outpaced by cheaper labor. the fact that that labor is coding seems to be where people get really stuck here. I dont really understand why this is where people get stuck.

the population of the world, and thus its demand for food has very much grown over time, and is still growing. Yet we have fewer people producing food than ever before. The reason for this is that the augmentation of technology outpaced the increase in demand. So we had fewer farmers making more food than ever.

similarly with software development, the demand for software will continue to increase over time, but the demand for human developers will inevitably fall, due to augmentations of technology enabling fewer workers to produce vastly more output. So we will have fewer developers working than we have, say, today[1], but those fewer developers will be producing orders of magnitude more[2] software

[1]im not actually trying to predict the inflection point of this growth curve as today, i meant this only as an example to make my point easy to understand

[2] where more could mean more complex, more efficient, etc.

There is zero reason to believe that software less capable than artificial general intelligence will provide any non trivial software.

Neural nets already provide superhuman performance for many computer vision tasks. Both in terms of output of the algorithm compared to a human judgement. And it does better than most human hand-written algorithm. An automated image captioning algorithm is a non-trivial piece of software.

There is zero reason to believe it will not.

look i too can make baseless assertions.

I don't need to prove a negative.

It seems inevitable that on some time scale AGI will be achieved if we don't commit species suicide or bomb ourselves back to the stone age. It doesn't follow that AI less capable than AGI can produce non trivial software guided by non programmers. This requires proof because it has never been done in human history and thus without any examples it requires if not proof a coherent argument in its favor.

The most obvious flaw is that software that is capable of composing/improving software ought to be able to improve itself and with improvements in a finite amount of time ought to BE AGI.

This looks like the start of a great tool for people to find example code relevant to the current code. In other words new tools for programmers not a replacement thereof.

can you quote me saying non-programmers would be making software?

have you read my comments here?

Im talking about tools that enable a single developer to do the work of a great many developers, thus lowering the demand for developers in the marketplace over time.

you are talking about non programmers writing software(no clue where you got that from at all?) and you even admit that this looks like a great tool to enable developers to get more work done?

Go back and read my comments before you respond please, otherwise im not interesting in having a discussion with someone who isnt even reading my responses.

Sorry I conflated 2 related but distinct discussions. On your front I disagree that programmer productivity will have a substantial negative impact on employment for the earlier stated reasons.

Demand for software will continue to increase quickly as the rest of the planet catches up to the developed world and increased productivity just increases demand.

I also disagree with the notion that this will substantially increase productivity in and of itself.

Basically this seems like it could help you find similar example code on github or in your company's codebase I'm dubious about it being used to generate nontrivial code of any variety.

And every 6 months you need to learn the latest and greatest new framework if you live in JS land.

Open source has already started doing this to some degree. At my last few companies, we used open source projects as a base for many of our software.

Instead of having to hire multiple senior level developers, all they needed to do was hire one project manager (me) and a bunch of junior developers (which are much cheaper). This is because all of the engineering-level software was given out for free and the company only needs to make changes, which takes much less experienced employees.

Were you complying with the licenses?

Here's my 2 cents on why software developers will never be at the risk of automation: https://medium.com/@kapv89/code-will-always-be-written-207d3...

Immediately i see you have this line:

>And until we develop an AI powerful enough to write clear, step by step instructions for any random task, code will be written.

so its "will never be at risk of automation UNTIL" which is vastly different from "will never be at risk of automation"

The article we are commenting on is about an AI writing code, so im not sure im seeing a convincing argument here.

secondly, automation isnt about some industry disappearing overnight, its about an ever decreasing amount of jobs in that industry. You cant imagine a system/tool/framework that allows such greater efficiency that a single developer can now reach the output of 5 or 10 developers?

Automation is always a good thing. Should we stop progress to allow humans to do some inefficient work? Society will have to change so that work is something done by machines, not humans.

I'm not making an argument that it is bad by any means, im only countering a common thread in development circles that 'development will never be at risk of automation'

for an example, see kapv89's response to my comment. Its a seemingly very prevalent view that somehow development will not suffer job losses from the efficiency gains innovation is able to create.

I actually think that together with psychologists we are the only two categories of people killing their own job :) we really strive to automate and to use the component there etc. to make our life easier and write less code. However, as someone else said above, software engineering is not coding, this is just a subset. Our job eventually will also evolve, it's inevitable :) it has already, it will not stop certainly now.

You're right. This could happen tomorrow, if even a small percentage of Excel users suddenly knew how to use it properly. We'd be at 50% unemployment if everyone who uses Excel knew how to take advantage of it.

This has been tried before with outsourced developers which are much more intelligent than the best AI will come close to.

The end result is still that it takes more time to fix the errors than it would have to write it in the first place.

One of the things about human software engineers is that they can make assumptions based on what the system is for. For example you may say that "this system has to accept payments from counterparties" and they will intuitively know that they are dealing with people's money, and to be careful of situations like double billing and the like.

In automatic programming discussions, one commenter said long ago that we already have people that deal with English this precise: lawyers. Such a model would basically turn programmers into people writing legal documents that the AI then turned into programs.

We already have language lawyers for implementing compilers. I think the right solution is to take away most of the "convenience" features. Most people don't touch all of them anyway because they don't know how they would interact. But everyone joining a team would have to learn them.

Why do so many computer languages experience scope creep? Including C++ and JS.

Sort of. I mean that you have to write specifications gor programs in English so precise and literal that it's like writing legal contracts. Compiler writers don't do that except in language specs. They use codd. Closest thing, which would be used in addition to English, is using a mathematical notation like Z or TLA+ for anything ambiguous. That's standard in high-assurance development.

"Describing what your program should do in sufficient detail will probably end up being not very far from the actual program itself."

Isn't that the idea behind https://en.wikipedia.org/wiki/Prolog ?

Something from a non-coder's perspective:

If I can create using English, there is a lot of possibilities for me. I can work on expanding language and build on skills I already have. I figure something like this will spill over into other areas. For example, I could theoretically make animation by describing the scene with words. Detail varies depending on how detailed I get.

It would still be a vast amount of work, but suddenly it is doable just by honing skills I already have. This is where the hope lies with folks like me.

Well, I think the are refering to that the computer would solve it's specific problems by itself just as we do as programmers.

I guess that you have worked for someone else as a programmer? Didn't they tell you what they wanted? How did you achieve it? They probably didn't have to write it for you in very specific terms unless a problem occurrs.

They achieved it by making a lot of guesses, based on a huge amount of explicit and implicit knowledge about humans, computers and the world in general.

The brute-force approach described in the article, where you just randomly try lines of code without any other knowledge, won't make for a very competent programmer.

The AI would have to be able to ask for clarifications on ambiguity as it goes.

Sounds like we need ai to figure out what sort of software we need.