What you're describing is effectively running gameplay mechanics in a virtual machine, which can simplify the process of authoring them and insulate against bad behaviour.
As it happens, a lot of games already do their gameplay like this under the hood! If you've ever heard developers talk about incorporating scripting languages like Lua, or node graph systems like Unreal's Blueprints, this is how they work.
These scripting methods let game/level/quest designers, who might have less hardcore coding experience than the programmers/developers on the team, quickly prototype and iterate on ideas, without recompiling after every change (sometimes editing live while the game is running), and (usually) without crashing the system when a gameplay script isn't quite right for the situation.
To go from this to what you describe, you'd just be adding a friendly user interface inside the game so the player can script this behaviour themselves. This could take the form of typing commands into a text editor, or snapping together blocks/modules, or wiring up a web of nodes, for example.
Once a gameplay script has been created, it's just raw data to feed through the game's scripting system, which doesn't need to care whether it came from a designer or from the player (apart from maybe giving designer scripts a higher level of trust/permissions to muck with aspects of the game state which you might decide to treat as off-limits to the player to maintain challenge and/or stability...)
There's a thriving genre of games exploring programming-by-the-player as a core mechanic in different ways, including...
For some insights into how you might implement such a virtual machine yourself, check out the Game Programming Patterns article on what they call the "Bytecode" pattern (although the same concepts apply even if you don't boil down to literal bytecode as your internal representation)
One thing to watch out for:
"...and have the programme check to see if its right"
This can be a bit more complicated than it may sound at first. You could literally check whether
player's script == solution but this is pretty narrow & brittle. As any programmer or problem-solver knows, there's usually many ways to approach a task, and it's less fun if the player has to guess & regurgitate the one (or one of several) solutions the game considers "right," versus inventing their own.
Mechanically analyzing a program's code to determine whether it would have the desired behaviour is also often not feasible.
So usually the best way to check the player's script is to actually run it and see what happens - evaluating the player on the result of the program rather than the code itself (although you can still use code-based challenge stats to get players to try aiming for "fewest instructions used" or "solve without using [forbidden command]" etc)