Tell it less. It gets smarter.

That sentence is heresy in a bank. We are trained, correctly, that ambiguity is where risk lives. A vague requirement produces a wrong system. A vague control produces an audit finding. Twenty years of enterprise discipline have taught us to specify everything up front, in writing, before anyone builds anything. It is the instinct that keeps regulated software honest.

It is also, when you point it at an AI agent, the instinct that makes the output worse.

The Instinct That Backfires

When you hand an agent an exhaustively prescriptive prompt, “use this pattern, structure it this way, name it that, iterate like so,” you are not reducing risk. You are capping the model at the ceiling of your own imagination and injecting your own assumptions into a system that might have found a better path without them. You have hired something that has read more code than any human alive and then told it to color inside the lines you drew from memory on a Tuesday.

There is a name for this dynamic that every engineer already knows. It is the manager who has not written code in a decade standing over your shoulder telling you how to write the loop. The instructions are not just useless. They are actively harmful, because now you are spending effort satisfying a wrong constraint instead of solving the problem. When you over-specify implementation to an agent, you become that manager. The model complies, because it was told to, and the result is worse than what it would have produced from a clear statement of the goal.

Anthropic’s own guidance points the same direction. Their writing on context engineering argues for the “smallest possible set of high-signal tokens” and finding the “right altitude” for instructions: not so prescriptive that they are brittle, not so vague that they give no signal. The trend in the field is toward less scaffolding, not more. Newer models want your intent, not your micromanagement.

Vague Is Not the Same as Unclear

I have to be precise about the word “vague,” because the guidance that says “tell it less” and the guidance that says “be clear and direct” are not in conflict. They are talking about different axes.

Be vague about the how. Be crystal clear about the what. “Build a service that reconciles these two ledgers and flags any discrepancy over one cent, and here is what a correct result looks like” is a clear goal with a vague implementation. That is the sweet spot. It tells the model exactly what success is and leaves it free to find the best way there. Compare that to “build a reconciliation service using a nested loop over the first ledger, storing results in a hashmap, with these seven helper functions.” The second is not clearer. It is just more prescriptive, and every prescription is a place you might be wrong.

Clarity of intent is not verbosity of instruction. The best prompt, like the best requirement, achieves the goal with the minimum necessary structure. It states the outcome, the constraints, and the definition of done, and then it gets out of the way. Everything you add beyond that is a bet that you know the implementation better than a system trained on essentially all of it. Usually you do not.

We Already Knew This

The strange part is that our own discipline told us this a quarter-century ago, and we ignored it.

The Agile Manifesto said, in 2001, “Welcome changing requirements, even late in development,” and “The best architectures, requirements, and designs emerge from self-organizing teams.” The whole insight was that nobody knows the full requirements up front, that the act of building reveals what the spec could not, and that rigid up-front specification produces worse systems than iterative discovery.

Then enterprise IT, banking especially, spent the next twenty years writing eighty-page requirements documents anyway, because the governance model demanded a fixed artifact to approve, and “we will discover it as we go” does not clear a steering committee. We adopted the ceremonies of agile and kept the mindset of waterfall.

Agentic development drags that unresolved tension back into the open. The manifesto’s core claim, that requirements emerge through building, is now literally how you get the best output from the tool. You state intent, you see what it manifests, you react to the actual thing instead of the imagined one, and you refine. The prompt is not a specification you write once and hand off. It is the start of a conversation. I made the broader version of this case in Architecture Is the Prompt: the artifact that matters is no longer the code, it is the precise expression of what you want, and precision is not the same as length.

What a Bank Must Never Leave Vague

Here is where “be vague on purpose” would become malpractice if I left it as a slogan. Deliberate vagueness applies to how the thing is built. It absolutely does not apply to the constraints a regulated institution operates under.

You must be ruthlessly precise about the boundaries. What data may this touch, and what must it never touch. Which regulatory requirements are non-negotiable. What the controls are. What the acceptance criteria are, concretely enough that “done” is a fact and not an opinion. What “correct” means for a financial calculation, down to the rounding rule. These are not implementation details you delegate to the model’s judgment. They are the frame inside which the model is free.

So the real instruction is not “be vague.” It is “be vague about the solution and exact about the constraints.” Let the agent choose the data structure. Never let it choose whether customer data crosses a boundary. Let it design the retry logic. Never let it decide the acceptable error tolerance on a settlement. The vagueness is a gift you give the model in the solution space. The precision is a wall you build around the risk space. Get those two backwards, precise about the loop and vague about the data boundary, and you have built exactly the wrong system with great confidence. This is the same decision discipline I argued for in The Bottleneck Was Never the Code: know precisely what you are asking for, then stop over-managing how it gets done.

The Part That Only Works If You Have Taste

There is a prerequisite to all of this that I cannot hand you, and it is the honest limit of the advice.

Deliberate vagueness only works if you can tell a good result from a bad one. When you give the model room and it comes back with something, you have to be able to look at it and know whether it is right, elegant, and safe, or plausible and wrong. That evaluation is the entire skill. A senior architect who is vague about implementation and precise about constraints gets leverage. A junior who is vague about everything gets slop, and cannot detect that it is slop, and ships it.

So “tell it less” is dangerous advice for exactly the people most eager to take it. If you cannot yet evaluate the output, vagueness is not empowerment. It is abdication. The move for someone still building that judgment is the opposite: be more specific, precisely so you can see where your specification and the result diverge, and learn from the gap. Vagueness is a technique you earn by first being able to grade the answer.

That is the uncomfortable resolution. The best prompters are not the ones who write the most detailed prompts. They are the ones who have the taste to say little and still know whether what came back was good. The skill did not disappear. It moved, from writing the specification to evaluating the result, from authoring the how to defining the what and judging the outcome.

Be vague on purpose. Be precise about the things that will end up in front of a regulator. And never confuse the freedom you give the model with the freedom to skip knowing what right looks like.

If this landed, read Architecture Is the Prompt, on why the expression of intent is now the real design artifact, and The Bottleneck Was Never the Code, on making the decision instead of over-managing the build.

Find me on X @orestesgarcia or LinkedIn.