[bufbupa]

I'd wager this methodology is going to become very prevalent in enterprises going forward. Encoding all of the context necessary to recreate your entire application in "plans" or "rules" allows for much more rapid refactoring to address new business needs.

It also makes for much more fungible developers. Instead of having a few key engineers that know the system inside and out, that knowledge is encoded in markdown throughout the project, allowing new devs to ramp up by asking questions against the codebase and tracing the history of reasonings that led to the shape/implementation that exists today. It's like having near exhaustive design docs & documentation with change tracking included.

While it seems likely that developers will become more fungible (replaceable) going forward, I think being able to operate at this layer of abstraction & still having the capacity to drop down to the nitty gritty implementation details will make strong devs more valuable, rather than less.

[whattheheckheck]

It's the latest iteration of the Mechanistic Myth described in the book Software and the Mind, http://www.softwareandmind.com/

[xg15]

Is there a summary for what exactly he means with the "myth" in the context of software? The whole detour into the history of western science and philosophy is interesting but also quite expansive.