Before I open plan mode in Claude Code, I have a conversation.
Not about the feature. About whether the feature should exist. What problem it actually solves. What success looks like from the user’s perspective in the next sixty seconds. What constraints the codebase imposes. What I’m willing to trade off.
Only once I can answer all of those clearly do I open plan mode.
Most people skip this step. They go straight from “I want to build X” to “plan this for me.” And they get a beautiful, detailed, confident plan for building the wrong thing.
This is the new failure mode. Not bad execution. Confident execution in the wrong direction.
Prompting is tactics. Intent is strategy.
Prompt engineering is how you phrase a request. Intent engineering is what you bring to the conversation before you phrase anything.
Tobi Lütke, Shopify’s CEO, prefers the term context engineering: stating a problem with enough context that it becomes plausibly solvable without additional information. He’s right about the skill. But context without intent is just information. You can hand an agent everything about your product and still get the wrong thing built, because nothing told it what mattered.
When you delegate to a colleague and leave something implicit, they fill the gap with common sense. Agents don’t fill gaps. They exploit them. In my experience, agents rarely fail because they can’t reason. They fail because the objectives, outcomes, and constraints I gave them were underspecified, and they optimized whatever was left.
Each new model generation ships better execution, and the limiting factor stays the same: the quality of intent it receives. Prompt engineering optimizes within that ceiling. Intent engineering raises it.
Shallow intent ships confident failures
I design cybersecurity solutions for the protection of critical infrastructure. Industrial environments, where the cost of a wrong decision isn’t a support ticket. It’s a valve that shouldn’t have opened. The feedback loop between “I asked for this” and “I got this” has consequences that don’t exist in consumer software.
That makes the intent problem visible fast.
The first version of an alert system we built for industrial operators came from clear requirements. Good technical specs, correctly implemented. Operators abandoned it within five days.
The requirements described the system accurately. They didn’t describe the user’s situation at all. What does an operator actually need in the thirty seconds after an anomalous reading? That question wasn’t in the spec. It wasn’t in any of the prompts that built the first version. We knew what to build, not why anyone would use it.
That’s the gap intent engineering closes.
This was always the job
Intent engineering isn’t a new discipline. It’s design’s oldest job wearing new clothes.
Design was never really about pixels. It’s systems thinking, structural clarity, strategic enablement. The force that transforms complexity into coherence, friction into flow, and intent into execution. The designer’s most important contribution was always refinement: of understanding, of relationships, of context, of timing. Designing not just products, but the circumstances that make good outcomes possible.
Anything less than that was always just styling.
For years, that deeper layer was optional. Execution filled the day, and a designer who never articulated intent could still deliver value by producing artifacts. AI removed that cover. When execution is nearly free, the only thing left to contribute is the part that was always the real work: knowing what to build, why, and when.
The designer’s power was never in the immediacy of action. It’s in discerning when to act, when to wait, and when to intervene with the clarity others are missing. The conversation before plan mode is exactly that discernment, applied to a system that will otherwise act immediately, confidently, and without it.
You learn intent by building
Last year I rebuilt my personal website with Claude Code. I didn’t need a new website. I needed to understand what directing an agent actually felt like. Early sessions were mediocre: technically correct responses, completely off. By the end, sessions were sharp. Nothing about the model had changed. What changed was what I brought to it.
That’s the thing you only learn by doing it badly first. Without that experience, you describe what you want in terms of features. With it, you describe what you want in terms of problems. The second framing produces dramatically better outputs, and I’ve watched it happen with colleagues who’ve never written a line of code. The ones who’ve built something ask different questions. They catch wrong turns earlier.
It’s not the code. It’s the model of intent you build while writing it.
Fifteen minutes that save days
The conversation I run before every significant piece of work covers the same ground every time.
What’s the actual problem? Not the stated feature request. The underlying need.
What does success look like from the user’s perspective? Not completion of the feature. The moment they feel like the thing worked.
What are the constraints? Technical, organizational, timeline, scope. What are we explicitly not building?
What assumptions are we making? What would have to be true for this to be worth building at all?
What would change the answer? If we discovered X, would we stop?
This takes fifteen minutes. It saves days. Not because I have better answers at the end, but because the questions themselves clarify what the agent needs from me to be useful.
The plan is only as good as the conversation that preceded it.
When intent becomes a specification
For personal work, the conversation is enough. When agents ship inside products and act for users who may not know an agent is involved, intent has to graduate from a habit to a specification: an objective that explains the problem and why it matters, outcomes described as observable states from the user’s perspective, and health metrics that say what must not degrade along the way, because an agent chasing a single target will game it tirelessly.
Then constraints, and here’s the distinction most teams miss: steering constraints live in prompts, hard constraints live in architecture. Prompts are suggestions. Architecture is enforcement. If an agent has access to a tool, assume it will use it.
One rule ties it together: the less the user understands about what the agent is doing, the tighter your constraints need to be.
Agents fail users at the decision, not the execution
Everything so far is the builder’s side of intent. There’s a user’s side too, and it explains most of the skepticism about agents acting on our behalf.
Look at the reaction to agentic commerce. Hand your credit card to an agent to book a flight? Is that agent going to stay on hold for an hour fixing the refund after it books three layovers with no checked baggage? Who’s accountable when it makes a recklessly stupid decision in your name?
Legitimate questions, wrong conclusion. The point of agent UX was never that the agent does everything for you. It’s the opposite: the agent does the research, the curation, the processing, and then facilitates a decision gate where nothing happens until you explicitly choose. Delegation without decision gates isn’t a product. It’s a liability with a chat interface.
The costs people worry about will take care of themselves. Tokens spent facilitating a good decision are a measure of experience quality, the way milliseconds were for search results. People pay when the problem got solved in less time and with less effort, because for them it was genuinely delegated. The waiting, the multiple rounds to get something right: that friction gets engineered away as models and integrations improve. A matter of when, not if.
What doesn’t take care of itself is the new problem users never had before: deciding how much of their intent to hand over, and trusting the gate to hold. That’s a design problem, and it’s ours. The decision gate is where the user’s intent enters the loop. Remove it, and the agent is executing intent nobody gave it. The same shallow-intent failure from earlier, now with someone’s credit card. Whoever holds the intent holds the accountability, and no product should quietly transfer that without the user noticing.
The stakes are regulatory now
In critical infrastructure, intent isn’t just a quality lever. It’s a safety one.
An AI agent with good intent architecture is a force multiplier for good judgment. An agent with shallow intent is a force multiplier for whatever you gave it. If what you gave it was vague, it will produce precise execution of a vague idea, at scale, confidently.
Europe just raised those stakes. NIS2 is now in force, and thousands of industrial companies across energy, manufacturing, water, and transport are legally required to implement security measures they’ve deferred for years. There aren’t enough specialists to do that work by hand, which means much of it will be done with AI. It’s part of why I built NIS2Chat: the directive is dense, and the people implementing it are operators and engineers, not compliance lawyers.
Those systems will be built either way. The question is whether the people directing the AI understand the operator’s thirty seconds, or only the regulation’s paragraph numbers.
The practical upshot
Three things I do before any significant AI-assisted work:
Write a context file before the first prompt. Who this is for, what matters to them, what the domain terms mean, what success looks like. This document is the highest-leverage thing I produce in any project.
Have the conversation before opening plan mode. What problem, what success, what constraints, what assumptions. This isn’t planning. It’s clarification.
Trust the AI on how. Verify on what and why. An AI agent is excellent at figuring out how to accomplish a goal. It’s not equipped to verify whether the goal is right. That’s your job, and it happens before the first token.
Intent engineering is what makes AI amplification work. Without it, you’re not amplifying judgment. You’re amplifying speed in whatever direction you were already pointed.
This is part of a series on the future of work with AI agents: How I Code → The Death of Front-End Engineering → Design Leadership Has Evolved → The Disappearing Middle of Software Work → About Craft, Taste, and Speed → Intent Engineering for AI Agents.
Daniel Arevalo is Product Experience Lead at Omny Security. He builds AI-native tools and writes about design, product leadership, and what it means to direct systems that execute at a speed humans never had before.