This sounds suspiciously like the "inner platform" (anti)pattern.
The basic idea is to write a piece of software that incorporates into itself a free-form means of configuration and/or command specification. This method is usually, as others have correctly pointed out, a "Domain-Specific Language" or DSL, interpreted by your software into more static pieces of code you have written. There are many such languages already out there; VBA, SQL, the scripting behind the Quake and Source engines, etc.
However, the flaw in such a pattern becomes evident when you look at the example DSLs. I doubt there's a DBA on the planet who would trust anyone in Accounting enough to give them a copy of SQL Management Studio and let them run their own reporting queries. On the flip side, I doubt there's any accountant on the planet who thinks that's a valid solution to their need for custom reports. 99% of users have no clue how to write a script to automate something in a Quake or Source-engine game; the ones that do keep finding holes in what those engines don't allow you to do, to do something that gives an unfair advantage.
While we could implement our own DSL (graphical or text-based) that simplifies the creation of custom queries and that does not allow the user to screw up anything beyond their own query, there is a very fine line to tread when designing a DSL that allows the user to do what they need, in a way they understand, without preventing then doing something they'd legitimately need, or allowing them to do something harmful. Often, there is no such solution, and even if it exists, providing a DSL that allows them to do anything they should be able to will not shield you from ever having to change the DSL to allow something new that nobody ever thought about before, that is perfectly acceptable and not harmful. As such, inner platform doesn't really solve the problem it was intended to; letting users do their own "programming", so the real developers can do more interesting things than customizing UI or report layouts/content. The devs will always be called on to "explain" (that is, hold the user's hand) the DSL they gave the user, and to answer the "well why can't I just do it like this" questions that are inevitable.
Even programmers deal with this all the time, in dealing with DSLs designed for interaction with third-party software. "Hey, why can't I do X, it sounds simple enough and I really need it to do this thing my user wants"... "Well if we let you do that then an attacker could do something similar and really screw you up, and us too". We as programmers expect a certain amount of that; end users expect a little more ease of use. That's why we're here.