You no longer have to deal with solution domain issues (memory leaks, crashes, deadlocks, type errors ...). However, you might still need a huge bunch of engli

You no longer have to deal with solution domain issues (memory leaks, crashes, deadlocks, type errors ...). However, you might still need a huge bunch of english text to describe the problem domain. If such a text isn't already available, you need to write it yourself (coding). However, you might not write it in one shot, so you need to store it in text files that you can read and modify later. Maybe you would team with other people to write it, and you would share and track your modifications (versioning). Maybe, to make it easier to manage, you would split your description in multiple text files (modularizing). And then, you'd need a way to ensure that your text actually unambiguously means what you want. So you'd need ways to identify (testing) and correct (fixing) theses ambiguities. And maybe, at some point you would change your mind on some behaviours ; and then you'd come back to your description and modify it so future behaviours changes might be easier to deal with (refactoring). And also, maybe your intelligent system has inferred a correct way of doing things that is actually too slow. Maybe you could order "do it faster!", or maybe you would need to identify the source of slowness (profiling), and edit your description so a faster behaviour is inferred (optimizing). At this point, you in an attempt to improve your efficiency, you might consider using a simplified notation, which would be less-ambiguous and less verbose (like did scientists, musicians, engineers, mathematicians ...). See, nothing to do with programming!