Prompt Engineering Is a Symptom (And That’s Okay)

Or: what this book actually teaches if you read it like an engineer, not a magician.

After my last post, a few people replied with variations of:

“Okay smart guy, but prompt engineering is a real skill.”

Yes.
And so is writing SQL that compensates for a bad schema.

That doesn’t mean we should build a career on it.

Recently I read Prompt Engineering (Lee Boonstra, Feb 2025) — the one with Chain of Thought, Tree of Thoughts, ReAct, temperature knobs, and enough diagrams to make you feel productive without shipping anything.

This post is not a dunk on the book.

It’s a reading guide for people who’ve been burned by production.

What the Book Gets Right (Surprisingly Well)

The book is honest about something most AI hype ignores:

LLMs are prediction engines, not minds.
They guess the next token. Repeatedly. Politely.

Everything else — “reasoning,” “thinking,” “deciding” — is scaffolding we bolt on top.

And the techniques it describes?

• Chain of Thought
• Step-back prompting
• Self-consistency
• ReAct
• JSON schemas
• Output constraints

These are not “AI magic tricks”.

They’re control systems.

If you’ve ever:

• Wrapped a flaky API with retries
• Added idempotency keys
• Forced a response into a schema so it wouldn’t explode later

Congratulations.
You already understand prompt engineering.

You just didn’t call it that.

Prompt Engineering Is Middleware With Vibes

Here’s the reframe that made the book click for me:

Prompt engineering is middleware for probabilistic systems.

That’s it. That’s the tweet.

Every technique in the book exists to solve one of these problems:

• nondeterminism
• missing structure
• lack of contracts
• unpredictable retries
• side effects you didn’t ask for

In other words:

Distributed systems problems.

But instead of logs, you get paragraphs.
Instead of stack traces, you get confidence.

Why Prompt Engineering Feels So Powerful

Because it’s the first time many teams are forced to confront their own ambiguity.

When you write:

“If values conflict, choose the most reasonable one”

The model isn’t being smart.

It’s asking you why that conflict exists in the first place.

The book spends hundreds of pages showing how to cope with ambiguity.

It never claims to eliminate it.

That’s not a flaw.
That’s an accidental truth.

The Hidden Lesson in the Book (Nobody Tweets This Part)

The best prompts in the book all have something in common:

• Clear input formats
• Explicit schemas
• Narrow responsibilities
• Deterministic expectations
• Boring outputs

Which means the real lesson isn’t:

“Become a prompt wizard”

It’s:

“Your system finally needs boundaries, and AI won’t let you fake them anymore.”

Prompt engineering doesn’t replace architecture.

It forces you to design one, whether you like it or not.

When Prompt Engineering Actually Is the Right Tool

Prompt engineering shines when:

• The task is fuzzy by nature (language, summaries, classification)
• The cost of being wrong is low
• The output is advisory, not authoritative
• You can retry safely
• You don’t pretend it’s deterministic

If you’re using it to:

• enforce business rules
• make financial decisions
• mutate production state
• replace domain logic

You didn’t discover intelligence.

You discovered technical debt that can speak.

The Takeaway

Read the book.

Not as a spellbook.
Not as a shortcut.
Not as a career identity.

Read it like a systems engineer watching a new failure mode being born.

Prompt engineering won’t save your architecture.

But it will do something better:

It will stop letting you ignore it.

And honestly?

That’s probably why it feels so powerful.

😎