Your first paragraph <i>totally</i> resonated. I&#x27;ve been thinking about this problem for several years. However, my approach is diametrically opposed to yours. I think our problems in software all stem from focussing on the code as the tangible artifact to maintain control over. We should instead be focusing on the <i>space of possible inputs</i> that the code is intended to work for. This is something you can&#x27;t deduce from the code (and automatically using the computer to deduce it, well forget about it), it requires cooperation with the original author to present things in a way that makes the state space more explicit. This is why I love projects with lots of tests. I can&#x27;t be bothered to analyze static code structure, either manually (what people call &#x27;reading&#x27;[1]) or automatically. Just show me how the program is supposed to run in all the different situations that you&#x27;ve considered. Let me change it and rerun the tests to find out if I broke something.<p>Modern programming practice emphasizes tests, which is great. However, not all kinds of tests can be written so far. So we end up doing manual certification work everytime we release or publish a new version of software, for performance, fault tolerance, etc. I want to make it all automatic. Some links about my project in case you&#x27;d like to learn more: <a href="http:&#x2F;&#x2F;akkartik.name&#x2F;about;" rel="nofollow">http:&#x2F;&#x2F;akkartik.name&#x2F;about;</a> <a href="http:&#x2F;&#x2F;github.com&#x2F;akkartik&#x2F;mu#readme" rel="nofollow">http:&#x2F;&#x2F;github.com&#x2F;akkartik&#x2F;mu#readme</a>. I&#x27;d love to hear your thoughts, either here or over email (address in profile).<p>[1] <a href="http:&#x2F;&#x2F;akkartik.name&#x2F;post&#x2F;readable-bad" rel="nofollow">http:&#x2F;&#x2F;akkartik.name&#x2F;post&#x2F;readable-bad</a>