Demo of an OpenAI language model applied to code generation [video]
twitter.com
twitter.com
You can view the demo at https://twitter.com/i/broadcasts/1OyKAYWPRrWKb starting around 29:00.
It's Sam Altman demoing a massive Open AI model that was trained on GitHub OSS repos using a Microsoft supercomputer. It's not Intellicode, but the host says that they're working on compressing the models to a size that could be feasible in Intellicode. The code model uses English-language comments, or simply function signatures, to generate entire functions. Pretty cool.
I can see this being a useful tool [1]. However, I don't expect any ability for innovation. At best this is like having an exceptionally smart autocomplete function that can look up code snippets on SO for you (provided those code snippets are no longer than one line).
That's not to say that it can't write new code, that nobody has quite written before in the same way. But in order for a tool like this to be useful it must stick as close as possible to what is expected- or it will slow development down rather than helping it. Which means it can only do what has already been done before.
For instance- don't expect this to come up with a new sorting algorithm, out of the blue, or to be able to write good code to solve a certain problem when the majority of code solving that problem on github happens to be pretty bad.
In other words: everyone can relax. This will not take your job. Or mine.
____________
[1] I apologise to the people who know me and who will now be falling off their chairs. OK down there?
But I'm not sure about the "deeply understand programming" part. Language modelling and "AI", in its current form, uncovers only statistical correlations and barely scratches the surface of what "understanding" is. This has restricted deployment of majority of academic research into the real-world and this, I believe, is no different and will work only in constrained settings.
Edit: typo
What you're describing (outside of the square braces) is algorithmic debugging:
https://en.wikipedia.org/wiki/Algorithmic_program_debugging
It was introduced in the PhD thesis of Ehud Shapiro. There's been a steady trickle of research work since then but it's never formed into a strong current, if I may. One reason for that is of course that Shapiro's thesis was published in 1983. So it's one of the research directions that was cut short by the last AI winter. Lessons to be learned.
Shapiro's thesis is one of two doctoral theses that became the precursors to Inductive Logic Programming, a field at the intersection of logic programming and machine learning. ILP algorithms learn programs from examples and "background knowledge" (i.e. a library of existing programs used as building blocks for new, learned programs).
The way that algorithmic debugging works is that it finds differences between the intended "model" (in logical terms: the consequences) of a program and its actual model. An algorithm that can do that can also walk back up the AST of a program the other way and produce a correct program from examples of its intended inputs and outputs.
That's the kind of stuff I study. Hence my comment above about lack of innovation etc. It's possible to automatically create novel programs with complex structures (recursion and invented sub-programs) and even discover new algorithms in the process and so on -and we know ways to do that right now. But the way to do it is not with a language model trained to predict the next character in a sequence.
As to writing unit tests, the way that most ILP algorithms work is that you give them a set of examples of the inputs and outputs of the program you want to write (e.g. "droplast([alice,and,bob,sitting,on,the,tree], [alice,and,bob,sitting,on,the])") and they write the program for you. I like to think of it as a kind of automatic TDD.
This would certainly be interesting. I'm not aware of active research going on in this area (any pointers would be helpful!).
This would require an agent to have thorough understanding of the logic you're trying to implement, and locate the piece of code where it silently fails. For this you'd again need a training dataset where the input is a piece of code and the supervision signal (the output) is location of the bug. I could imagine some sort of self-supervision to tackle this initially where you'd intentionally introduce bugs in your code to generate training data. But not sure how far this can go!
2. Generate test cases from fuzz results.
3. Run tests and walk outward from symbols around relevant stacktrace frames (line numbers,).
4. Mutate and run the test again.
...
Model-based Testing (MBT) https://en.wikipedia.org/wiki/Model-based_testing
> Models can also be constructed from completed systems
Look at the static analysis tool in clang. Xcode uses it well.
This is recurrent and somewhat unfair. Current architectures have long known to be universal, capable of reproducing any computational structure (of finite depth for NNs, and Turing complete for RNNs); they have significant structural flexibility and in principle their learning can converge to "ideal processing structures" (which supposedly our brains also approach) given good enough training conditions (data, regimen, etc.). The network scales, timescales and dataset scale to achieve what comparable human function are debatable and unknown, but I believe it's very safe to judge them on function (this particular example is indeed quite impressive), because given their performance it's likely a powerful structure has emerged under the hood -- you can think of it emerging similarly to intelligence emerges from evolution (and of course human learning). Internal recurrent evaluations of logic and representations of language can all emerge.
I wouldn't describe this process as simply statistical inference, since it has complex computational priors and structure involved. It's really algorithmic learning.
Of course, you can bake in structure to accelerate this process, and we've been discovering very useful structures (such as CNNs, LSTMs, Transformer arch) which bias the models in the desired direction but still have internal flexibility.
I'm not sure how you would combine AutoML-Zero with Bert. How do you mean?
A. Add external definitions or reward formalism to make the code-space easier to search?
OR
B. Keep adding code trees, execution traces, comments, memory dumps and learn from those?
My own instinct is that AlphaZero was a lot more convincing than AlphaStar, so lots of (A) is definitely needed
Of course not. This technology converts writing code into bug hunting in pre-written code. Finding bugs in code that you did not write is way harder than writing the code yourself.
So if anything, this makes programming harder, not easier, and we will need more programmers, not less.
And then the model trains itself on the buggy code written and poorly debugged by these extra coders and then so on and so forth.
Codepocalypse.
Kill it with fire!
Yeah, all it could do for you is autocomplete around what it thinks the specification might be at that point in time.
> But what if Andy gets another dinosaur, a mean one? -- Toy Story (1995)
However, I think very little programming labor is employed in the construction of new algorithms or even most business logic, even a casual stroll through github reveals a staggering amount of reimplementation.
I think the promise here is the ability to code in a more conceptual way with less fiddling with the finicky details.
This is basically how product managers code. Or former engineers turned engineering managers. Or even team leads. Hell, maybe like an architect?
You come up with a rough sketch, design the system, think through a couple edge cases, tell the computer what you need, and the computer figures out the details for you. Similar to being a high level engineer that designs/defines/codes the broad strokes of something and then lets the lower level minions handle details.
We made a similar leap when compilers were invented.
and then the impl. turns out to have a bunch of details wrong that you didn't catch initially. And you wonder why there's so many bugs in software these days!
I think the AI model is helpful, but the specification being ambiguous or under-specified is the problem, and the effort to sort that out is hard. I'm not sure an AI can help in that aspect, and that's where most of the value of programming comes from.
In the same way, that's why I think it would be a useful tool: it promises to automate away the kind of coding that most programmers can do with eyes closed and that's the most boring and repetitive part of the job.
Like, without trying to demean it, it sounds like a great boilerplate generator.
It's part of the job to continually incorporate new capabilities and lever yourself up.
If AI gets to the point where it has a reasonable understanding of the shape of the data & the basic spatial manipulations being applied (not far off IMO), I'd expect it to be waaaaaay better at discovering certain types of new algorithms than humans. It can handle thinking about algorithms that have millions of independently moving parts in a way a human can't.
Humans have the edge deriving algorithms that require a sequence of high-level steps on an abstraction. "Do this, then we get a thing, then we do some stuff to the thing, stretch it, squash it, massage it." AI sucks at that, it doesn't think in the same kind of flexible abstractions.
But imagine if you build an understanding of how the code will be compiled & how that will interact with the cache into the AI. That's very difficult for humans because you can't think about all those mechanics at once, we have to focus on one at a time. An AI that really gets it? I could see it writing a better sorting algorithm for a specific, complex datatype than a human could, or at the very least having the competetive edge because it can do it basically instantly.
But there is the thing, the natural description of a function is not always this unambiguous.
When you are telling a function to 'compute XYZ', what you are actually doing is 'check whether X.a exists, if so execute branch 1), else branch 2)'.
If the logic gets really complicated, then describing it accurately in human language isn't necessarily faster than doing it in code directly. Otherwise, we don't need invent programming languages like at all, we can just write compilers to interpret and execute human languages.
And I am interested, as whether the model itself is conditioned on the type constraint of class. It is neat that they pick Python in this case. But if it is Java or other static typed language, would this system condition its generation not only the natural text, but also the resulted type system? My bet, per my understanding of the language modeling approach they use is, they are not doing this, due to very high complexity and cost of the training, and domain adaptation.
Overall, this again is an interesting demo. But I think for code generation based on human language to be useful, we are really in a scenario, that you need to go 99% accurate for it to be remotely practical.
Or implementing a sophisticated protocol that has a formal specification. If you can express the correct behavior in some kind of pithy pseudocode, a tool like this could "compile" that to code in various programming languages. Like a super-powered version of SWIG.
But I think the example given of unit testing - ie. natural language description of specific behavior of function -> code is extremely useful.
But that would require the condition on the type system, meaning the code-gen needs to understand the object's interface, which while not impossible in current techniques, but hard enough due computation complexity.
Again I don't dispute this tool being interesting. But claims it to be ground breaking or game changing is simply not right.
Majority of programmers time, is not typing down the code. It is to look at the comment/description, think about it, edit some code, then rethink then edit again.
This tool has potential to solve some typing time, but it still not going to things fundamentally.
The thing is, I'd really need to see a live demo to see how good this is. Making mistakes is actually kind of a big issue; as most people know, debugging code is harder than writing it. And a lot of the language models which can write impressive-seeming text also generate masses of garbage. There's no way to know whether this was cherrypicked or not.
The mere fact that it can extract meaning from text like this is already really impressive though.
However, this is fairly impressive for a couple reasons. First, the system constructs programs from natural language descriptions, rather than examples of input-output pairs or a formal specification, which are the most common settings for program synthesis. Second, they're generating full blown python, not a smaller, domain specific language.
Finally, and this is pretty mind-blowing, is the seamless, idiomatic use of loops, branches, and function calls. I haven't seen previous program synthesis tools able to generate such complex code. They're typically limited to simple linear programs with less than about 100 lines. Complex control flow and function calls are still beyond their reach for the most part.
I'm not an active researcher in neural program synthesis, so my statements may not reflect the current state of the art.
I honestly thought that the most promising route forward for program synthesis would be a model that incorporated knowledge of the syntax and semantics of code. Most likely, a model that manipulated, or at least had some view of, the program's AST. This seems to be just throwing a giant Transformer model at github.
Fine tuning a vanilla language model on a giant corpus of code feels like a dead end for the field, long-term. It seems obvious to me that humans are doing something more than just statistical pattern recognition and generation when we write and reason about code.
Then again, it's hard to argue with results. I'm sure lots of pre-neural network voice recognition researchers were in love with the elegance of their hidden markov models.
Edit: Also, everyone should go try the FlashFill feature in Microsoft excel. As far as I know, it's the only example of program synthesis shipped in a consumer facing production system, and it works shockingly well.
Yeah, this is the main reason why I would be interested in more examples. But, if this thing was trained on all of GitHub, I could imagine that it come up with decent-looking code for a lot of examples; a beefy, smarter Google with some rudimentary contextual understanding, if you will. Still, the presence of any mistakes is a no-go and I'd be really interested how it reacts to more realistic, specific requirements.
But yeah, I'd figure a model for code generation would have to have some kind of knowledge of syntax and semantics, rather than doing pure statistical pattern matching, to be of any real use. It would not only have to generate, but also to debug its code (I wonder whether you could do that purely with statistical pattern recognition). I might be wrong, of course, but I would be surprised if that is enough to write complex code.
Calling the field "statistical pattern matching" might be underselling it a bit, even if technically accurate on some level. I mean, syntax/semantics are clearly not the problem, those are the easiest to learn (see the paper above). If anything, I'm scared of it writing syntactically correct nonsense (or even worse, subtly-flawed-but-correct-looking code).
And it's not a giant language model trained on a gigantic dataset. Rather, if memory serves, it's a buch of task-specific DSLs and rules, all hand-written from scratch.
[1] O. Polozov, S. Gulwani, FlashMeta: A Framework for Inductive Program Synthesis. https://www.microsoft.com/en-us/research/wp-content/uploads/...
(Sorry I really should have refreshed my memory on Gulwani et al. I think I've even linked the paper on an HN comment before.)
Oh, btw, I doubt they're doing this with a language model nowadays. Unless FlashFill has suddendly started filling cells for email addresses with haikus etc...
But maybe this is just a question of how much compute (and network size/"depth") you invest. On a certain level we're also just some recurrent LSTM :)
This way developers just write unit tests or functional tests, and the AI generates code and retrains itself until the code passes for all tests. This could happen silently in the background as the developer defines the tests.
A number of natural language test frameworks exist, Behat for example lets you define tests such as:
Feature: Multiple site support
Background:
Given a global administrator named "Greg"
And a blog named "Greg's anti-tax rants"
And a customer named "Wilson"
And a blog named "Expensive Therapy" owned by "Wilson"
Scenario: Wilson posts to his own blog
Given I am logged in as Wilson
When I try to post to "Expensive Therapy"
Then I should see "Your article was published."
Scenario: Greg posts to a client's blog
Given I am logged in as Greg
When I try to post to "Expensive Therapy"
Then I should see "Your article was published."
Anyway interesting work. Very interesting. I remember a few colleagues laughed at me no more than 5 years ago when I suggested that AI would eventually write code. And here it is, in an early version, flawed surely but only set to improve.
Edit to add: This subject while insanely interesting to me is well out of my wheelhouse. I'm guessing there's possibly semantic structure to the above that the type of model being used in the demo can't deal with? Like this one use-case has to co-exist in an entire ecosystem of dependencies and related entities... Could the model cope with that or is it just calculating the likelihood of the next character like other models I've seen, but with insane accuracy when it comes to code?
Ultimately as well we don't care what the code looks like, if it passes all tests then it "works". You probably don't even need to generate the code in a high level language, if people aren't ever going to really read it.
You'd probably need tests designed to ensure the code is executes quickly enough and automatically generate edge case test data so you don't end up with a blog where you can only post articles with the titles in the exact test data heh.
The future seems interesting for us developer types anyway. If a product designer could express their requirements in plain language developers would only really need to be around for cases where the models failed and more training data was needed to improve them.
Are those two entirely separate and yet exactly similar initiatives?
GPT-2 is built by OpenAI
It's much more difficult problem than automated driving though - for software, the space of intents of the user is orders of magnitude greater in size. It's the job of the model to determine the intent of the "programmer". Perhaps we could meet the model half way and come up with heavily-structured natural language to communicate intent.
Also, since it would be used to build tests as well, I'd expect such misunderstandings to be pretty obvious. I would be willing to bet you'd see a net reduction in bugs, and a substantial reduction in typo related bugs.
But if you mean by lowered barrier of entry you mean the population of programmers would be less competent, yes bugs in the design might increase, however being able to more quickly get to the point of evaluating a design is a great way to learn better design.
If anyone knows a way to link to the start of the demo at 28m30s, or thereabouts, we can modify it again. (Edit: maybe https://blog.twitter.com/en_us/topics/product/2018/video-tim... can be used to make that work?)
It's not obvious that it works until you hit the play button and it starts at the right time. Seems like the only way to get it to play automatically is to embed it in a tweet like this: https://twitter.com/modeless/status/1263222139840167936
You'd be surprised how easy it is to get a model that performs as well as what you see in the video. And it's even easier now that people have built great libraries for fine-tuning generative language models.
I encourage you to try it yourself! There are many interesting extensions for people to explore:
- Use bi-directional context (vanilla GPT-2 only sees backward context)
- Integrate with semantic analysis tools.
- Experiment with different context representations. You condition the model on an arbitrary sequence of N tokens. It's not necessarily the case that you should spend that whole budget on the N tokens that came immediately before. What about including the imports at the top of the file? What about the docstrings for functions that were just used? What about the filepath of the current file?
Don't look at something like this as though watching your job be automated away. Look at it as a tool that you can master and use to move up the stack.
So the developer's role will shift to:
1) writing good enough descriptions of the code to be generated by the AI model
2) fixing any little issues in the generated code
To get this you can just grab any random 18 year old who knows js and have them hack something out. No one hires 18 year old js hackers though and there’s a reason for that.
Or, for TDD, generate the unit tests first based on the function name and description. Then, if the dev updates any of those tests, or adds more tests, use that information in auto generating the appropriate code.
This is a gamechanger for ensuring the reliability of software. Many more people can be involved in the software development process, and inject their domain knowledge into it.
Are there any plans to open source the model? I would love to play around with it.
In all seriousness, the demo really looks amazing. I'm curious to see more elaborate, real world examples though.
However; I fear this moves software engineering closer to the role of something like plumbing.
I've despaired at the state of most software I've used since as far back as I can remember, except when it comes to tools that have the maturity of something like linux, git, emacs, vim and the unix tools.
For software to get good - it needs to be deeply understood by at least one person working on it. If you train an army of warrior drones who get full line autocompletion first they'll start forgetting what types this method takes as its parameters, they'll be less likely to explore codebases instead plugging in the first autocompletion that comes to their editor.
There bosses will of course want this in the name of "Getting Shit Done". We already have this sort of divide between developers, those who heavily lean on their tools and those who use minimal editor help. Once you are forced to learn a tool because your tool isn't spoon feeding you, you have a chance to better reason from first principles using the code you have available. I don't think it's a shock that a very high percentage of the very best developers use emacs or vim with minimal tooling.
I am aware that this whole comment has subtle tones of superiority and elitism and I am genuinely sorry for that but in my experience it's just true that people who lean really hard on their IDEs to do everything for them are less able to develop creative solutions and you can tell from having conversations with them that they don't really understand what they are doing.
That seems like it would be considerably more effective, because you're removing the noise/overhead of parsing the text and giving a much clearer model of what's being manipulated to the AI.
This will end up being a better tabnine. Models like GPT2 are still just approximating intelligence, they are not rationally cognizing.
While I don't doubt people have shown that various transformer models have certain limitations, I'm pretty bullish on transformer models in general.
Here's a post exploring the application of transformers to symbolic mathematics for instance: https://medium.com/analytics-vidhya/solving-differential-equ...
def build_agi(CEV):
"""Build an AGI with the specified CEV"""Want to bet on that?
Is this one in particular open source?
This tool is the programming equivalent of an AI writing scientific papers based on an abstract. It can follow all the formalities really well. It can write beautiful English sentences. It might write formulas or produce graphs. It will dot the i's and cross the t's.
But it's unclear whether what it says is actually correct and logically coherent when used in the main part of the paper (and not just for the introduction of the paper) or just pleasing-sounding nonsense.
It can certainly help make engineers look more productive, just like it could help someone write papers at record speed. Whether the results can/will have any deeper value is yet to be determined. Maybe it will just be used for the "boring" tasks - like the paper introduction.
My personal fear is that it will be very good at writing code that looks ok, even though there is a serious flaw. Essentially, programmers tend to become good at spotting irregularities in the code corresponding to common human errors. The mistakes of this AI might be much harder to spot because they don't stand out in the same way.
From bitter experience, though, I also know how unreliable these models can be. It's possible (indeed, likely) they generated 20 samples, threw away 19 that were garbage and just showed you the one that looked nice.
If - and that's a big if - it reliably generates good-quality code, then it would probably be a nice productivity boost (~25%, particularly when it comes to tests).
Based on what I've seen over the past few years, though, I'm skeptical.
Creating flashy AI demos relatively easy. Creating important AI products that actually operate in the real world is the difficulty.
If people are truly novice, with zero programming experience, how would they know the code is correct? If not, how to debug it?
I would say this is more promising for scenarios to generate more formularitive things like business report generation. But even that, it requires in depth understanding of what those data/tables really means, and how to handle exceptions, etc.
Programming languages are automation tools. Libraries. Frameworks. It should be pretty clear this is a lasting trend, and doesn't necessarily mean programmers will have more or less jobs (due to well known effects of automation such as enabling new applications and increasing demand from increased productivity). It does mean you probably need to keep learning to stay relevant, and use those tools to your advantage!
Also, please don't rewrite titles to make them baity. That's against the site guidelines: https://news.ycombinator.com/newsguidelines.html
Edit: other users have helpfully posted a link to the video that anyone can view, so we've switched to that from https://mybuild.microsoft.com/sessions/6c6ecd46-c39c-49d8-ba... and restored the submission.
Build me a class which computes the larger of two integers.
The AI is smart enough to write it.