Context Engineering > Prompt Engineering: Patterns That Actually Work

There's a common belief that getting good output from LLMs is about finding the right magic words. The perfect prompt template. The clever trick that unlocks better responses.

After months of using Claude and ChatGPT as my primary thinking partners for architecture, product specs, strategy, and implementation, I've come to a different conclusion: prompt engineering is maybe 20% of the value. The other 80% is context engineering.

Prompt engineering is about how you phrase the instruction. Context engineering is about what the model understands about your world before you ask it anything. The distinction changes everything.

Here are the patterns I've found that actually matter, ordered from foundational to advanced.

In this post:

1. The briefing formula: role + context + scale + constraints + outcome
2. Scale as a constraint language: numbers eliminate naive advice
3. Constraints as first-class ingredients: shape the solution space
4. Ask questions, don't give instructions: activate reasoning before generation
5. The seed-and-expand: start with a structured brain dump, let the model grow it
6. Reference architecture as thinking scaffold: analyze first, apply second
7. Conversational scaffolding, then artifact extraction: explore through dialogue, crystallize into deliverables
8. Prompts as living artifacts: encode failures as guardrails

---

Pattern 1: The briefing formula

Looking across hundreds of my conversations, the prompts that produce the best output follow a consistent shape:

Role + Business Context + Scale + Constraints + Target Outcome

For example, many of my prompts roughly follow this structure:

"I'm a [role] in a [business context] operating at [scale]. We're trying to achieve [goal]. Our constraints are [constraints]. Given this, help me design/prioritize/structure [decision area]."

This works because it tells the model five things at once:

1. Who is asking
2. What world they're in
3. What matters to them
4. What is hard about the situation
5. What success looks like

Each element eliminates entire categories of generic advice.

The role matters more than you think. When I specify "CTO evaluating a vendor" versus "PM scoping an MVP" versus "engineering lead planning a migration," the model calibrates its response depth, abstraction level, and tradeoff emphasis. A CTO wants leverage, risk, and strategic fit. A PM wants user value, scope boundaries, and KPI design. The same question produces fundamentally different (and more useful) answers when the role is explicit.

---

Pattern 2: Scale as a constraint language

One of the strongest patterns I've noticed is that including scale numbers dramatically changes output quality.

When I mention "300 million users," "50,000 purchase orders per month," "200 stores across 15 channels," or "4 engineers deploying weekly," I'm not being gratuitously specific. I'm using numbers as a constraint language that prevents generic answers.

Many recommendations only sound good until scale is introduced:

• "Use a graph database for relationships" is reasonable at 10K records. It's questionable at 500M.
• "Do manual code review on every PR" works for a team of 3. It breaks at 30.
• "Run a full test suite before every deploy" is ideal. It's impractical when the suite takes 45 minutes and you deploy 10 times a day.

The model can't calibrate its recommendations without knowing the scale.

The transferable lesson: If the answer would be different at 100 users versus 100 million users, say the number. If it would differ at 3 engineers versus 30, say it. Scale is the single fastest way to eliminate naive recommendations from LLM output.

---

Pattern 3: Constraints as first-class ingredients

A common weakness in prompting is asking for "best ideas" without mentioning constraints. My style does the opposite. I specify:

• Time horizon and deadlines
• Team size and bandwidth
• Tech stack and infrastructure
• What's explicitly out of scope
• Adoption barriers and organizational context

The difference is dramatic:

Scenario	Instruction Prompt	Context-Engineered Prompt
System design	"Design a caching layer for my API"	"We serve 50K RPM with p99 at 200ms. Our DB is the bottleneck. We run on Kubernetes with 4GB RAM per pod. Design a caching strategy that respects these constraints."
Product spec	"Write a spec for a dashboard"	"Our ops team (12 people) monitors 200 stores daily. They currently use 3 spreadsheets. The spec should cover what they need to see in the first 10 seconds of opening the dashboard."
Architecture decision	"Should I use microservices?"	"We have 4 engineers, a monolith serving 2M users, and deployment takes 45 minutes. We want faster deploys for the payments module without rewriting everything. What's the right boundary to extract?"
AI application	"Build me an AI chatbot"	"Our support team handles 3,000 tickets/month. 60% are order status and return policy questions. We need a bot that handles those categories with verified answers from our help center, and routes everything else to humans."

When I say "we have 4 engineers," "this is still being built," "we deploy weekly," or "move this to backlog," I'm shaping the solution space. Constraints aren't limitations on the output. They're the most valuable input you can provide. They tell the model what realistic looks like.

A useful reframe: I treat constraints the same way I'd brief a senior consultant. You wouldn't hire McKinsey and say "fix our strategy." You'd say "we have $2M budget, 6 months, these three market pressures, and a board that cares about margins." The constraints are the brief.

---

Pattern 4: Ask questions, don't give instructions

Most people prompt like they're filling out a form: "Write a blog post about X." "Create a marketing strategy." "Analyze this data." The model treats these as tasks to complete. It optimizes for speed, not depth.

A more effective approach is what some call "Socratic prompting": instead of telling the model what to produce, ask it questions that force it to reason through the problem.

Instruction prompt: "Write a value proposition for my analytics product."

Socratic prompt: "What makes a value proposition compelling to enterprise buyers? What logical and emotional triggers should it address? What objections do buyers typically raise? Now apply that framework to an analytics product that replaces manual spreadsheet workflows."

The model thinks first, then writes. The output is structurally richer because the reasoning happened before the generation.

I use this pattern constantly for architecture decisions:

Instead of: "Should I use a message queue here?"

Try: "What are the failure modes of synchronous processing at 50K events per hour? What are the tradeoffs between a queue and a batch job for this throughput? Given that our team is 4 engineers and we deploy weekly, which approach has the lowest operational overhead?"

The model reasons through the tradeoffs instead of pattern-matching on my keywords.

---

Pattern 5: The seed-and-expand

My typical opening message isn't "help me build X." It's a structured brain dump: 5-10 numbered points capturing my current thinking, architectural constraints, and open questions. I treat the first message as a seed crystal that contains the essential structure, then ask the model to grow it into a complete artifact.

For example, when designing a notification system for a multi-tenant platform, I didn't say "build me a notification service." I opened with eight bullet points covering:

• what we already had (event bus, user preferences table, email provider integration)
• what we wanted (multi-channel delivery, batching and digest logic, per-tenant templates)
• what I wasn't sure about (retry strategy for failed deliveries, rate limiting approach, priority escalation rules)

Then a single instruction: "Expand on this and spec it out."

The result was a full technical specification with delivery pipeline stages, schema definitions, a batching algorithm, and failure handling flows, all grown from that compressed seed.

Why it works: LLMs are excellent at structural extrapolation. When you give them a well-structured seed with clear domain vocabulary, they can infer the shape of the complete artifact. The seed needs to demonstrate how you think about the problem: the taxonomy, the boundaries, the relationships between concepts. Not just what you want built.

The anti-pattern: Opening with "build me a dashboard" or "write a spec for X" with no structural seed. You get generic output because the model has no signal about your mental model.

---

Pattern 6: Reference architecture as thinking scaffold

Before asking the model to design something for my context, I first ask it to deeply analyze an external reference system. Then I use that shared understanding as the foundation for my own design.

The workflow has two phases:

Phase 1: Build shared understanding: "How does [reference system] handle agent orchestration? What are its key design principles? What tradeoffs did they make?"

Phase 2: Apply to my context: "Now apply these principles to my platform, given these constraints."

Why it works: By establishing a shared reference first, you give the model a structural vocabulary to reason with. It's not pattern-matching on your keywords anymore. It's applying a coherent design philosophy. The reference architecture acts as a scaffold that both you and the model can point to.

The technique behind the technique: When I share reference material, I don't just say "read this." I ask for analysis first: what are the key design principles, what are the tradeoffs, what's the philosophy. This forces the model to internalize the why, not just the what, before I ask it to apply the ideas.

---

Pattern 7: Conversational scaffolding, then artifact extraction

Many of my best specs didn't start as spec requests. They started as exploratory conversations where I was building my own understanding through dialogue. Once the conversation reached a certain density of insight, I pivoted: "Now turn this conversation into a formal spec."

The pattern:

1. Explore through open-ended dialogue
2. Refine through pushback and stress-testing
3. Crystallize into a formal deliverable

For example, I once started with an open architectural question about how to enforce tenant isolation when an AI agent generates database queries. Through dialogue, we explored defense layers, debated different compilation approaches, and arrived at a hybrid architecture. Then I asked for it as a formal architecture decision record. The output was production-grade because the reasoning had already happened across 15 messages.

The meta-insight: Conversations where I change my mind mid-thread produce better artifacts than conversations where I knew exactly what I wanted from the start. The model picks up on the evolution of thinking and incorporates the corrections. The conversation is the drafting process. The artifact request is just the export step.

---

Pattern 8: Prompts as living artifacts

After running a complex prompt through a production workflow, I don't just fix the issues. I do a systematic analysis of what worked and what didn't, then encode those findings as guardrails in the prompt itself.

The prompt now contains institutional knowledge:

"Output must include baseline alongside target for every metric" exists because the first run produced isolated numbers ("65% sell-through") that were meaningless without context.

"Every recommendation must specify fallback options" exists because the first run assumed ideal conditions that never hold in practice.

This is the continuous feedback loop. Prompts are software. They have bugs, they need testing, and they improve through iteration. The "quality guardrails" section in a prompt is equivalent to a test suite: it encodes known failure modes and prevents regression.

This is also where context engineering connects back to the CLAUDE.md pattern from my previous post on agentic engineering. The CLAUDE.md file is essentially a persistent prompt that accumulates institutional knowledge. Every rule in it exists because something went wrong once and was encoded as a guardrail. The document compounds in value over time.

---

The meta-pattern

If I had to distill everything above into a single insight, it's this: the most impactful work happens before you write the prompt.

The techniques that matter most aren't clever prompt tricks. They're about:

• Briefing the model like a senior hire who needs operating context (the briefing formula)
• Using scale and constraints as a language to eliminate generic advice
• Asking questions that activate reasoning instead of generation (Socratic prompting)
• Structuring your own thinking before you engage the model (the seed-and-expand pattern)
• Building shared understanding through reference architectures and dialogue
• Treating prompts as code that improves through testing and iteration

None of these require special tools or frameworks. They require a shift in how you think about the human-AI collaboration: from "how do I ask for what I want?" to "how do I build a shared context where what I want becomes the obvious output?"

The quality of the output depends less on prompt cleverness and more on whether the model understands the operating context. Once you see it that way, the question is no longer "what prompt should I use?"

The better question is: what does the model need to know about my world to produce an answer I can actually use?

---

For the agentic engineering workflow that builds on these patterns, see Agentic Engineering with Claude Code.