Prompt Engineering Patterns That Actually Work: From Naive Prompts to Engineered Systems

July 17, 2026 · 9 min read · Prompt Engineering

Jose Chirinos AI & Software Engineer

Most prompts I've come across in production — including plenty of my own early ones — were naive prompts. Not because anyone was lazy, but because prompt engineering looks like typing and is actually interface design, and few of us were ever taught to treat it that way.

I build agentic AI systems for a living. My personal platform, Jarvis, orchestrates agents across Claude and Gemini through MCP tool-calling, with RAG pipelines and eval harnesses behind it. And I eat my own cooking: before building anything serious, I ask Jarvis first — "What's the best way to achieve this? How do you think we should approach it?" It proposes a few different approaches, I pick the strongest, and that becomes the master prompt I actually run. Every reliability problem I've debugged in that system traced back to one root cause: a prompt that asked the model to guess instead of telling it what the job was.

This post is a tour of the prompt patterns I actually use — persona, the interview pattern, chain of thought, tree of thought — with an honest assessment of what each one has done for me, what it hasn't, and when the extra structure paid for itself. One thing before we start: these are field notes, not laws. Models change fast, smart people disagree on all of this, and every claim here deserves to be tested against your own stack.

What naive prompting looks like (and why it fails in production)

A naive prompt is a request with no contract:

Summarize this customer feedback.

It reads fine. It even works — sometimes. That "sometimes" is the problem. Run it a hundred times in a pipeline and you'll get bullet points, paragraphs, five items, twelve items, English summaries of Spanish feedback, and the occasional helpful preamble like "Here's a summary!" that breaks your JSON parser at 2 a.m.

Naive prompts fail in three predictable ways:

1. Ambiguity — the model fills unspecified decisions (length, format, language, audience) with whatever is statistically likely, and "statistically likely" changes between runs and model versions.
2. No constraints — nothing tells the model what not to do, so it helpfully does extra things you never asked for.
3. No output contract — downstream code expects a shape; the prompt never promised one.

The fix is not magic words. It's the same discipline you'd apply to any API design: define inputs, outputs, and behavior at the boundary.

You are a senior product analyst who turns raw customer
feedback into roadmap decisions.

Summarize the customer feedback below for a product manager
deciding next quarter's roadmap.

Rules:
- Output exactly 3 bullet points, 20 words max each.
- Each bullet names the feature area and the user's pain.
- Keep the original language of the feedback.
- If the text contains no actionable feedback, output "NO_SIGNAL".

Example bullet:
- Checkout: users abandon carts because payment fails on mobile.

Feedback:
"""
{feedback}
"""

Same task. But now the role, length, format, audience, edge case, and failure mode are all specified — and one example locks the output shape. That's the whole game: a prompt is an interface, and interfaces need contracts. Everything else in this post is a pattern built on top of that idea.

The persona pattern: quite useful, but misunderstood

The persona pattern is the one everybody learns first: "Act as a senior security engineer…" And here's my honest take after using it in production: the persona pattern is quite useful — but it's often expected to do a job it was never going to do.

In my testing, adding "you are an expert" to a prompt hasn't made the model smarter — it was trained on the same data either way. What a persona has reliably changed for me is point of view: tone, vocabulary, priorities, and what the model chooses to pay attention to.

Review this Dart code.

You are a senior Flutter engineer reviewing Dart code for a
production app with 400M-user-scale expectations. You care
about: state management correctness, widget rebuild cost, and
null-safety edge cases. You do not comment on formatting or
naming.

Review the code below. For each issue: cite the line, explain the
failure scenario, and rate severity (blocker / should-fix / nit).

The second prompt works — but look closely at why. The persona ("a senior Flutter engineer on a production app") contributes the lens. The actual quality gain comes from the constraints and the output contract underneath it. Strip the persona and keep the rules, and you lose a little focus. Keep the persona and strip the rules, and you're back to a coin flip.

Where personas genuinely earn their place:

• Tone and audience-fit — writing for executives vs. writing for engineers.
• Domain vocabulary — a "clinical documentation specialist" persona reliably surfaces the right terminology.
• Multi-agent role separation — this is the big one. In Jarvis, every agent's system prompt is a persona: a planner that only plans, a researcher that only retrieves and cites, a critic that only attacks the plan. The persona isn't decoration there; it's the mechanism that keeps agents inside their lanes.

Use personas to set the point of view. Use contracts to get the quality.

The interview pattern: make the model interview you

This is one of the least-written-about patterns, and it's the one I reach for most when requirements are fuzzy: flip the direction of the conversation. Instead of stuffing everything you know into a mega-prompt and hoping, tell the model to interrogate you first.

I need a data retention policy for a mobile app that stores
health-related measurements.

Before writing anything, interview me: ask me questions one at a
time, until you have enough information to draft a policy that a
compliance reviewer would accept. Start with the highest-impact
question. Do not start drafting until I say "go".

Why this works: the model has seen thousands of data retention policies. It knows which decisions matter — jurisdictions, data categories, deletion SLAs, third-party processors — better than you can enumerate them from memory. The interview pattern converts the model's latent checklist into questions, and your answers become the spec.

When it beats the mega-prompt approach: any task where you are the bottleneck of unknown requirements — architecture decisions, migration plans, legal-adjacent documents, project scoping. When it doesn't: tasks you've fully specified before. The interview is for discovering the spec, not for executing it.

There's a meta-point here worth being transparent about: this article — its audience, its language strategy, even which opinions appear in it — was scoped using exactly this pattern. An AI interviewed me, one batch of concrete decisions at a time, before a single paragraph existed. The pattern is not a party trick; it's how I start most serious AI work.

Chain of thought prompting: mostly absorbed by frontier models

Chain-of-thought prompting — "think step by step" — was the technique of the early LLM era, and it produced real gains: forcing intermediate reasoning steps measurably improved math, logic, and multi-hop questions.

My experience in 2026, on the workloads I run: frontier reasoning models have absorbed most of it. Claude, Gemini's thinking variants, and their peers now run extended internal reasoning without being asked. On the tasks I've measured, prompting them to "think step by step" felt like telling a chess engine to "consider its moves" — the advice arrived a few years late. That's my data, though; your tasks may push back, and the experiment is cheap to re-run.

Explicit CoT still earns its keep in three places:

1. Audit trails. When a decision needs to be reviewable — a triage bot justifying severity levels, a screening pipeline that compliance will inspect — you want reasoning in the output, not hidden inside the model.

Classify this support ticket's severity (P1-P4).

Output format:
reasoning: 2-4 sentences citing specific phrases from the ticket
severity: P1 | P2 | P3 | P4
confidence: high | medium | low

2. Structured intermediate outputs. Forcing a specific decomposition ("first extract the entities, then map relationships, then answer") isn't really CoT — it's you designing the algorithm and the model executing each step. That structure is still worth specifying explicitly.

3. Small and local models. Sub-frontier and on-device models did not absorb the technique. If you're routing easy tasks to a cheap model — which you should be — your CoT scaffolding suddenly matters again.

So my suggestion — a suggestion, not a commandment: before defaulting to "think step by step" on a frontier model, ask what reasoning you need visible, contract for that, and let your evals decide whether the scaffold still earns its tokens.

Tree of thought prompting: branching, scored, and expensive

Tree-of-thought extends CoT from a line to a tree: generate several candidate reasoning paths, evaluate them, expand the promising ones, prune the rest. In its research form it's a search algorithm over reasoning states, and you can approximate it in a single prompt:

Propose 3 fundamentally different architectures for offline-first
sync in a two-user shared-state mobile app.

For each: describe the approach in 3 sentences, then score it 1-10
on: conflict-resolution complexity, battery/network cost, and
time-to-ship. Then pick a winner and defend the choice against the
strongest competing option.

That's the honest, budget version — and for most decisions it's enough. The expensive version is where tree of thought gets interesting for me: the branches don't have to live in one context window. In a multi-agent system, each branch can be its own agent exploring a hypothesis in parallel, with a judge agent scoring the results. Tree of thought, implemented as orchestration, is a real production technique — that's essentially how Jarvis fans out alternatives on hard problems.

The catch is cost. Every branch is tokens, and most branches get thrown away — that's the point of the pattern. Use it for decisions where being wrong is expensive: architecture choices, security designs, anything you'd normally convene three senior engineers to argue about. Don't use it to write a commit message.

Choosing a prompt pattern: the 30-second cheat sheet

One honest caveat: this table is how I currently decide, not a standard. Different tasks, models, and teams will move these lines — which is exactly why the next section is about measuring instead of trusting defaults, including mine.

Prompt engineering in production: the receipts

Everything above is running in Jarvis today, and the receipts are measurable. The clearest one: context engineering — being deliberate about what enters the model's context window, backed by deterministic guardrails — cut my inference costs by roughly 30%. Not a new model, not a pricing change; the same tasks, engineered prompts and context instead of naive ones.

The other lesson from running an eval harness against my own prompts: my intuition about which prompt is "better" is wrong often enough that I stopped trusting it. Prompt changes ship like code changes — measured, not vibed. If you take one thing from this post, take that: patterns get you a good first draft of a prompt; evals tell you the truth about it.

FAQ: the questions I actually get

Does the persona pattern improve accuracy?

In my testing, not on reasoning tasks — the model was trained on the same data whether or not you call it an expert. What personas change reliably is point of view: tone, vocabulary, and what the model pays attention to. In my projects, the accuracy gains often attributed to personas have usually come from the constraints and output contracts written underneath them.

Is prompt engineering dead?

From where I sit: the magic-words era is fading; the engineering era isn't. Prompt engineering is professionalizing into interface design, orchestration, and measurement — the parts that were always engineering. Models absorbing chain of thought retired a technique, not the discipline.

Should I still use chain-of-thought prompting in 2026?

My rule of thumb: with frontier models, mainly when you need the reasoning visible — audit trails, reviewable decisions, decompositions you design yourself. With small and local models, yes: in my experience they never absorbed the technique, so CoT scaffolding still does real work there. Either way, I'd treat "think step by step" as a hypothesis to eval, not an incantation.

Fix the prompts before you upgrade the model

If you're building AI features and your prompts still look like the naive examples above, that's fixable — and the fix usually costs less than the model upgrade you were considering instead.

About the author — Jose Chirinos AI & Software Engineer with 10+ years shipping products for Pinterest, Netflix, Intel, and United Airlines at 400M+ user scale. Now specializing in agentic AI — multi-agent orchestration, MCP, and RAG — and builder of Jarvis, a personal agentic platform orchestrating Claude and Gemini.