Super short version: You want to evolve programs. Randomly mutating programs is hard, most mutations break things. Instead, ask a giant language model to propose edits, in the form of diffs (like the ones you get with git or whatever). These mutations are usually reasonable, don't break things, and lead to more interesting evolved programs. You can even further improve the process by using the successful mutations to fine tune the language model to predict better future mutations.
Its "evolution" in the sense it's an attempt to apply concepts from evolutionary theory to engineering problems and the principles of biological evolution are similar in the abstract.
Evolution is just variation and selection. That might be the biological evolution we are familiar with, but it might also be improvements that a carpenter makes to their toolbox over time.
Here (the toolbox and this paper) the variation is directed rather than random, but it's still variation and selection.
You may be interested in this paper: https://arxiv.org/abs/2105.09352
As far as I know it was the first to train a model on commit diffs to generate code mutations, in this case for bug fixing.
I wonder whether you should generate the commit messages first, and then base your code changes on that.
(Might also be an interesting idea for human programmers. In analogy to Test-Driven-Development, this would be called Commit-Message-Driven-Development.)
Definitely. It'd be very Decision Transformer and prompt programmingesque: you declare what the high-level intended result should be, with requirements, test cases, examples, and then let the model condition on that and figure out the implementation. Why would you do it backwards? You're going to have to explain what you want anyway, after all. (And of course, you would ideally do it both directions, similar to image/text: neither direction is privileged, you want to be able to both generate images given a description, and generate a description of an image, and both tasks help the other.)
So their proposal is to leverage large language models to propose automated, reasonable changes to a codebase that is constantly checked for "fitness" in a particular task.
I've always been fascinated with evolutionary mechanisms in programming, this is a clever idea to make things more interesting.
I was watching this video recently from Weights and Biases on Linear Algebra intuition for ML.
A mention was made in it that the real reason matrices rather than code or formal logic are used in ML is because of their ability to be changed in small ways with a relevant directional change in the operability of that matrix. Changing a single character of a code block doesn't have the have smooth changes.
So your paper seems like a cool move in the right direction, and supportive of the work people are doing to try to make ML more interpetable by turning it into formal logic.
14 comments
[ 3.6 ms ] story [ 16.2 ms ] threadHere (the toolbox and this paper) the variation is directed rather than random, but it's still variation and selection.
A gallery of evolved robots: https://y2u.be/QNyNtvwA9FI
An evolutionary lineage from an initial (barely-functional) seed to a final robot: https://y2u.be/M9pAJuX6dyM
(Might also be an interesting idea for human programmers. In analogy to Test-Driven-Development, this would be called Commit-Message-Driven-Development.)
Though you are probably better off creating both at the same time.
What you say makes a lot of sense, if you want a human to create the commit message as a sort-of prompt engineering to ask for specific changes.
I've always been fascinated with evolutionary mechanisms in programming, this is a clever idea to make things more interesting.
A mention was made in it that the real reason matrices rather than code or formal logic are used in ML is because of their ability to be changed in small ways with a relevant directional change in the operability of that matrix. Changing a single character of a code block doesn't have the have smooth changes.
So your paper seems like a cool move in the right direction, and supportive of the work people are doing to try to make ML more interpetable by turning it into formal logic.