9 ms·

“It could allow non-coders to simply describe an idea for a program and let the system build it” This is not a new thought. The problem with it, however, is th

by kleiba 10y ago

“It could allow non-coders to simply describe an idea for a program and let the system build it” This is not a new thought. The problem with it, however, is that such a description would have to be very precise or else leave room for different interpretations which in turn could lead to very different programs being generated. In particular, as programmers know, it's often the edge cases that pose the main difficulty not the typical case. Describing what your program should do in sufficient detail will probably end up being not very far from the actual program itself.

rorykoehler 10y ago
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.
- unprepare 10y ago
  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"
  - rorykoehler 10y ago
    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.
  - kk_cz 10y ago
    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.
    - unprepare 10y ago
      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."
      - collyw 10y ago
        And every 6 months you need to learn the latest and greatest new framework if you live in JS land.
      - michaelmrose 10y ago
        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.
        unprepare 10y ago
        >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.
  - cabalamat 10y ago
    > 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.
    - unprepare 10y ago
      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.
    - falcolas 10y ago
      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.
      - adangert 10y ago
        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.
    - thinkpad20 10y ago
      > 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.
  - williamdclt 10y ago
    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.
    - unprepare 10y ago
      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.
  - kapv89 10y ago
    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-207d3cdfe145#.hmic6qrls https://medium.com/@kapv89/code-will-always-be-written-207d3...
    - unprepare 10y ago
      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?
  - syrrim 10y ago
    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.
  - senior_james 10y ago
    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.
    - michaelmrose 10y ago
      Were you complying with the licenses?
    - deleted 10y ago
      [deleted]
  - mk89 10y ago
    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.
  - naikrovek 10y ago
    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.
- kleiba 10y ago
  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.
  - rorykoehler 10y ago
    Sure. Exactly what I meant. It would just speed up your job.
  - sharemywin 10y ago
    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.
  - cortesoft 10y ago
    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.
  - pasquinelli 10y ago
    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.
- collyw 10y ago
  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.
- flukus 10y ago
  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.
staticelf 10y ago
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.
- scribu 10y ago
  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.
geophile 10y ago
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.
- felixge 10y ago
  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?
  - geophile 10y ago
    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.
    - spaced_out 10y ago
      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.
deleted 10y ago
[deleted]
mondoshawan 10y ago
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?
- qw 10y ago
  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.
  - NegativeK 10y ago
    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.
  - prance 10y ago
    This discussion reminds of this question/answer on quora: https://www.quora.com/Since-programming-can-be-self-taught-why-not-major-in-something-other-than-computer-science/answer/Jayesh-Lalwani?srid=us6J7 https://www.quora.com/Since-programming-can-be-self-taught-w...
  - mondoshawan 10y ago
    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.
mattferderer 10y ago
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-digital-security-company-culture-and-the-value-of-schooling/?curator=TechREDEF 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".
imgabe 10y ago
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.
- jononor 10y ago
  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.
nickpsecurity 10y ago
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.
- EGreg 10y ago
  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.
  - nickpsecurity 10y ago
    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.
deleted 10y ago
[deleted]
pasquinelli 10y ago
Sounds like we need ai to figure out what sort of software we need.
afpx 10y ago
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.
officelineback 10y ago
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.
Broken_Hippo 10y ago
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.
namlem 10y ago
The AI would have to be able to ask for clarifications on ambiguity as it goes.
amai 10y ago
"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 https://en.wikipedia.org/wiki/Prolog ?

by kleiba 10y ago

rorykoehler 10y ago

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.

unprepare 10y ago
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"
- rorykoehler 10y ago
  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.
- kk_cz 10y ago
  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.
  - unprepare 10y ago
    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."
    - collyw 10y ago
      And every 6 months you need to learn the latest and greatest new framework if you live in JS land.
    - michaelmrose 10y ago
      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.
      - unprepare 10y ago
        >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.
- cabalamat 10y ago
  > 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.
  - unprepare 10y ago
    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.
  - falcolas 10y ago
    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.
    - adangert 10y ago
      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.
  - thinkpad20 10y ago
    > 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.
- williamdclt 10y ago
  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.
  - unprepare 10y ago
    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.
- kapv89 10y ago
  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-207d3cdfe145#.hmic6qrls https://medium.com/@kapv89/code-will-always-be-written-207d3...
  - unprepare 10y ago
    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?
- syrrim 10y ago
  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.
- senior_james 10y ago
  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.
  - michaelmrose 10y ago
    Were you complying with the licenses?
  - deleted 10y ago
    [deleted]
- mk89 10y ago
  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.
- naikrovek 10y ago
  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.
kleiba 10y ago
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.
- rorykoehler 10y ago
  Sure. Exactly what I meant. It would just speed up your job.
- sharemywin 10y ago
  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.
- cortesoft 10y ago
  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.
- pasquinelli 10y ago
  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.
collyw 10y ago
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.
flukus 10y ago
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.

staticelf 10y ago

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.

scribu 10y ago
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.

geophile 10y ago

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.

felixge 10y ago
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?
- geophile 10y ago
  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.
  - spaced_out 10y ago
    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.

deleted 10y ago

[deleted]

mondoshawan 10y ago

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?

qw 10y ago
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.
- NegativeK 10y ago
  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.
- prance 10y ago
  This discussion reminds of this question/answer on quora: https://www.quora.com/Since-programming-can-be-self-taught-why-not-major-in-something-other-than-computer-science/answer/Jayesh-Lalwani?srid=us6J7 https://www.quora.com/Since-programming-can-be-self-taught-w...
- mondoshawan 10y ago
  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.

mattferderer 10y ago

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-digital-security-company-culture-and-the-value-of-schooling/?curator=TechREDEF 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".

imgabe 10y ago

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.

jononor 10y ago
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.

nickpsecurity 10y ago

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.

EGreg 10y ago
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.
- nickpsecurity 10y ago
  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.

deleted 10y ago

[deleted]

pasquinelli 10y ago

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

afpx 10y ago

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.

officelineback 10y ago

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.

Broken_Hippo 10y ago

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.

namlem 10y ago

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

amai 10y ago

"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 https://en.wikipedia.org/wiki/Prolog ?