Test driven development would take on a new meaning, with the programmer a writing collection of tests and letting the computer find the shortest program that makes them pass.
Wouldn't writing a complete test suite take equivalent effort to writing the program in the first place? I mean, wouldn't they require the same amount of information? Then, to simplify the task of writing test suites, you might want to design a programming language that compiles into test suites, but would you use your program-writing program to write the program that describes the test suite? And also, who watches the watchers?
Let's say we wanted to implement addition for a calculator. Here's a complete description:
-1 is the lowest number
-successor(N) is the successor to number N
In the first place, that is not a complete description of natural numbers. Natural numbers have to be integers. So if you're going to tell a computer program that "1 is the lowest number", you'd first have to tell it what you mean by "number" and "lowest". Also, "successor(N) is the successor to number N"? That seems rather meaningless. What is "successor" in the first place? If your generator already knows what "successor" means, why do you have to describe it again? If the generator doesn't know what "successor" means, why are you using it in your description of a successor function?
That's a complete description of the natural number system, but it's not a useful addition function in any sense.
Even assuming your description was complete, why would a description of the set of natural numbers imply the creation of an addition function? Unless we're talking about a code generator that reads minds! :)
One important thing about TDD, in my view, is that you have two separate descriptions (the test and the code) that agree. If you get your code generated from your tests then how do you detect bugs in your tests?
This would probably produce a program that cheats a lot. Perhaps not by simply hardcoding the answers to the tests, but by finding a good compressing function for the set of (input, output) pairs in the test. I bet this would seldom provide the expected answers on inputs not covered by the tests.