Claire Legous

SE Radio 379: Claire Le Goues on Automated Program Repair

Claire Le Goues, Associate Professor at Carnegie Mellon University discusses her area of research: automated program repair – the ability of programs to fix bugs in other programs.   Host Felienne spoke with Le Goues about how these techniques work. The techniques include: applying ‘sensible’ edits (moving blocks of code, adding null checks automatically) and then running tests to see if the change happens to solve the program. The show also covers: how program repair is being applied in industry, and what developers can do to make their code bases as suitable as possible for program repair tools.

Show Notes

Related Links

SE Radio theme music: “Broken Reality” by Kevin MacLeod (
Licensed under Creative Commons: By Attribution 3.0

Join the discussion
1 comment
  • A very interesting show!
    This topic corresponds very nicely to my own thoughts about the (far) future of programming: Computers will be able to write the code for us, given that we’ll write tests first. Clearly, we won’t need to write all the tests in advance, but to do it iteratively, just like in TDD, but the computer will write the code for us. Even though Claire mentioned research about automatically writing tests, IMHO tests can only be generated automatically by deriving them from the actual application’s behavior. I cannot see how a machine will be able to know what we *expect* from the program. As programming is all about innovation, I’m very skeptic that AI will be able to write code without people defining the tests or other kind of formal specification. (AI may help us find trivial bugs that don’t require domain knowledge and formal specification). So learn TDD today if you want to stay relevant in the future 🙂

    Another related topic that I find interesting is automated refactoring. I also believe that this should be an easier thing to do. Many refactorings can be automated today (e.g. extract method, extract super class, etc.), but the programmer still chooses when and where to apply them. I can foresee a future where a tool will suggest (and maybe even do without our approval) a complete sequence of refactorings that simplify our code. This will help reduce technical debt and make code easier to maintain. Automated refactoring doesn’t even need tests, as each step can be proven to leave the behavior intact. Though naming will probably still be one of the two toughest problems in computer science (cache invalidation, naming, and off-by-1 errors :-))

More from this show