Human language lets us express almost any intent. That does not mean a machine is going to interpret it the way we expect.
You ask for a teddy bear with a big heart of love (corazón in Spanish). One typo turns corazón into coraza (armor), and you get a plush bear in medieval armor, spikes, and a warhammer.
The comic is absurd. The problem it illustrates, less so.
Between what we mean, what we write, and what a system executes sits a gap. Natural language lets us cross it with striking ease, yet it can also hide how much was left up to interpretation.
Talking gives us freedom. Programming forces precision.
When we talk to another person, we leave a lot unsaid. We share context, speak in approximations, and expect the other person to fill in the blanks.
“Have it ready for tomorrow” can be plenty of instruction between two people who know the work. Outside that context, it leaves basic questions open: what does ready mean, by what time, by what criteria?
With AI we do something similar. We state an intent and expect the model to turn it into a result.
Programming languages and declarative languages demand a different discipline. We have to represent what we want inside an explicit vocabulary, structure, and set of rules. That constraint feels uncomfortable, and it is also useful.
A compiler can reject a malformed instruction. A type system can block an incompatible operation. A schema can catch an unknown field or a value outside the allowed options. They do not know what I meant to do, yet they can detect that what I wrote breaks certain rules.
Sometimes an error is a good answer
One of the things we value most in language models is their ability to work with imperfect input. They understand incomplete sentences, tolerate typos, and produce answers even when details are missing. For exploring ideas, that is an advantage; for executing actions with consequences, it can become a risk.
In the comic, the odd request does not stop the robot. It interprets it, fills in the details, and produces something consistent with that reading. It even adds weapons nobody asked for. The user discovers the misunderstanding once the result is already sitting in front of them. A reply like “did you mean corazón (heart) or coraza (armor)?” would have been less dramatic, and far more useful.
The problem is not always that the system fails. Sometimes it is that it keeps going when it should stop.
Compiling does not mean it is right
We should not romanticize code either. A program can compile cleanly and run the wrong logic. A SQL query can be valid and modify the wrong rows. A configuration can pass its schema and point at the wrong environment. Formal languages do not guarantee that intent, logic, and outcome match.
What they give us are mechanisms to check parts of that relationship: syntax, types, constraints, preconditions, and tests. If we express a condition and build a proper check, we can reject whatever fails it. The error shows up when a rule the system can verify is violated. If we never state the rule, we cannot assume anyone is checking it. The same happens with prompts, just with a much wider surface for interpretation.
Stating intent should not be the last step
Consider this instruction:
Clean up the old customer records.
Does “clean up” mean fixing data, archiving it, or deleting it? Old according to which date? Does it include active customers? Can it be undone?
A model could propose a reasonable interpretation. That does not make it the right one.
For a task like that, I prefer separating the process:
- State the intent in human language.
- Resolve the ambiguities that change the scope.
- Turn the interpretation into explicit rules: which records, which operation, and which exclusions.
- Inspect a preview before modifying any data.
- Verify the result against those rules.
Natural language works well for talking through what we want. Verifiable constraints work well for limiting what the system is allowed to do.
You do not have to give up one to benefit from the other.
A prompt does not replace a contract
I am interested in building software by stating intents instead of writing every instruction by hand. Still, making it easier to express an intent does not remove the work of checking it.
A longer prompt does not automatically solve the problem either. You can write several pages and still leave the verb that authorizes an irreversible action ambiguous.
When the result matters, we need more than a convincing reply: boundaries, validations, and conditions that force the system to stop.
Check the words in your next prompt. Then check what would happen if the system read them a different way.
When ordering a plush toy, an unexpected suit of armor can make a good joke. When operating a system, I would rather get an error back than get a “done” on something I never meant to do.
