I like to draw a distinction between abstraction and automation as architecture ideas. Abstract stuff is "just" more abstract and adds a new concept on top of

I like to draw a distinction between abstraction and automation as architecture ideas. Abstract stuff is "just" more abstract and adds a new concept on top of the old. Abstraction makes the coder feel all grown up and maintain the daydream: "once it's done building the features will be so much easier." Automation is the part where we say, "this is repetitive and hard to keep track of - so make the computer do it." Automation creates leverage. And sometimes you need a truly novel abstraction to automate successfully, but in most instances you only need the same old 70's era programming constructs wired up a bit differently. Which does lead to dropping one abstraction in favor of another, as you allude to. Even if you get into, "well we need to Optimize it, we can't just do the simple and straightforward thing" you can start automating the trivial, repetitive optimizations and get into the business of generating code. And that can be abstract, but it doesn't have to be - you don't have to incorporate a whole suite of compiler checks or a runtime model, the "compiler" can be a FSM that emits source code - but it'll be automated, and you can add the interface and checks to it that are most relevant to the problem, and make the output look human-readable to some degree. Edit: another benefit of this approach is that your initial coding environment truly is "implementation detail" since it's the starting point and you just add the leverage you need from that point rather than feeling obligated to use the officially branded abstractions.