Right, but I think he also has building websites in mind. So, both, I guess.
Five years earlier, Prof. Harel wrote a book, Come, Let's Play[2], in which he explored the role that temporal logic[3] could have in the building of reactive software systems (e.g. desktop GUI applications, among many others). If you visit Harel's full list of publications[4] and do an in-page search for the terms "LSC", "behavioral" and "scenario", you can follow the links to a number of papers published since the early 2000s, related to the application of temporal logic in the process of software design.
It's possible that my connection of Granger's "eve" to Harel's work is completely mistaken; and if so, I apologize for jumping the gun.
[1] http://www.wisdom.weizmann.ac.il/~harel/papers/LiberatingPro...
[2] http://www.wisdom.weizmann.ac.il/~playbook/
Short: You provide the goals and the constraints, then through a back and forth dialogue with the computer you describe and clarify the problem (and also your understanding). You keep on negotiating and providing more constraints until it simply finds a possible solution (the problem domain is now computable) or the best fitting solution now satisfies your needs (in time).
The hardest parts are probably: 1. Collecting, developing the constraint solvers. Should we imagine that collection more as platform of user contributed (programmed/trained) packages? 2. Developing the dialouge that is not just textual but visual (in both ways) (notepad vs IDE vs Theater(?!) don't forget macros/acting out!)). Showing is always faster then writing and gives one better cues on the closures/framework of the actual discussion.
[1] http://scattered-thoughts.net/blog/2014/07/21/imperative-thi... [2] https://gist.github.com/jamii/8957881c8eaa4035f4ae
https://speakerdeck.com/mtrimpe/graphel-the-meaning-of-an-im...
http://en.m.wikipedia.org/wiki/Subsumption_architecture
http://en.m.wikipedia.org/wiki/Behavior-based_robotics
Kodu was based on this model, and it worked very well.