To explicate this, it would make sense that when you pass a source file to the compiler, it would:
1. Parse the code into an AST (to strip away any pre-parse differences, like formatting or syntactic sugar usage), then hash that AST (recursively--replace any non-primitive function references with hashes of their own current ASTs)
2. Run unit tests, fuzz, etc--taking the AST hashes of each function of the testing code as well (though using symbolic, rather than "hard", references to the implementation-code, so it can change without making the test's hash change)
3. If a piece of code fails a test, add the pair (test AST hash, code AST hash) to some database (preferably an online, global database).
4. From then on, before anything is allowed to be compiled, perform a lookup in said database, and refuse to compile anything if the database finds any known (test, failed code) pairs in your code.
---
The interesting thing is that this system is very conservative--if a piece of code depended on by the code you wrote changes, then your code is given another chance (because maybe your code was just failing because it was expecting something of that other code, and that other code was wrong, and then it was fixed.)
Likewise, if you change the requirements, your code must be re-evaluated for conformance--code shouldn't be barred because it fails a "wrong test" like assert_equal(add_two_plus_two(), 5);.
But on the other hand, if you add tests, the old barrings based on previous tests stay in effect as well--this actually incentivizes breaking unit tests into small, orthogonal functions that pass or fail separately.
I don't think there would actually be any problem doing real development under this "restriction". In practice, given the way we currently do software engineering, it would only catch problems within your own project that had been seen+caught before--because those would be the only tests you had included.
In theory, though, you could also import, say, a global "test set"--basically, AST hashes for every test of the current stable branch of all major open source projects, or something similar--and check your code against that as well, just in case you happened to write, say, an incorrect date-handling function that someone else had ever written in an AST-identical way.