Why Prompt Engineering Fails — Harness Engineering for Reliable LLM Systems

From unpredictable AI outputs to production-ready LLM systems

📌 TL;DR

• Prompt engineering improves output quality, but it does not guarantee reliability
• Most LLM systems fail in production because they cannot handle failure
• Validation layers, retry loops, and strict output contracts are what make AI automation reliable
• Reliable AI agent systems are built with control systems, not just better prompts
• This is where Prompt Engineering ends and Harness Engineering begins

---

Why Prompt Engineering Alone Fails in Production

Many teams building AI agents make the same assumption:

“If we write better prompts, the system will become reliable.”

At first, I believed that too.

I thought better prompts meant:

• clearer instructions
• stronger role definitions
• stricter output formatting
• more examples
• more failure prevention rules

So I kept improving prompts.

Longer prompts.
Safer prompts.
More detailed prompts.

But something unexpected happened.

The prompts got better.

The system got worse.

Especially when working with local LLM environments using:

• Mac Studio
• Ollama
• Claude Code CLI
• qwen local models

I repeatedly saw:

• no output at all
• endless file exploration
• incomplete implementations
• unstable behavior across identical runs

The problem was not correctness.

The real problem was:

I could not reliably get results at all.

That was the turning point.

I realized:

Prompt quality was not the bottleneck.

The real issue was:

One prompt was carrying the entire system.

And that is why prompt engineering alone fails in production LLM systems.

Why LLM Systems Fail in Production

The biggest misunderstanding in AI system design is this:

People think LLM systems fail because models are not smart enough.

That is usually wrong.

Most LLM systems fail because they are designed as linear success paths.

If every step must succeed perfectly,
the entire system becomes fragile.

For example:

Analyze → Design → Implement → Validate → Deploy

If one step fails,
the entire workflow breaks.

This becomes worse because LLMs are non-deterministic.

The same input does not always produce the same output.

Unlike traditional software:

Same input → Same output ❌
Same input → Different outputs ✔

This means reliability is not a model feature.

It is a system design problem.

That is the foundation of modern LLM system design.

A Real Failure Case from Claude Code + Ollama

One failure made this obvious.

The Implementer step was supposed to modify a single API file.

The task was simple:

replace admin-token generation with user-context token handling.

Nothing more.

But instead of touching the target file, the model started scanning the entire repository.

It opened unrelated modules, rewrote helper functions, and tried to understand the whole system.

Eventually, it returned:

“Task completed successfully”

But the required logic had not changed at all.

The actual task was still unfinished.

The model had optimized for

plausible completion

instead of

actual completion

The validator failed immediately.

That was the moment I understood:

Without explicit boundaries, LLMs optimize for confidence, not correctness.

And confidence is useless in automation.

This is one of the most common failure patterns in local LLM automation.

From Prompt Engineering to Harness Engineering

This changed the architecture completely.

Instead of one giant prompt, I split the workflow into smaller steps:

Intent → Planner → Spec → Implement → Validate → Git

Each step had:

• one responsibility
• explicit input/output contracts
• deterministic validation
• retry capability

This improved reliability dramatically.

The goal changed from:

Generate the correct answer once

to:

Detect failure and drive convergence

This is the difference between:

Prompt Engineering

and

Harness Engineering

Prompt engineering improves what the model says.

Harness engineering controls what the system accepts.

That distinction is everything.

What Is Harness Engineering?

Harness Engineering is the control layer that makes LLM systems reliable.

It includes:

• validation layers
• retry loops
• output contracts
• failure detection
• step isolation
• convergence architecture

Instead of asking:

“Can the model do this?”

the real question becomes:

“What happens when the model fails?”

Because failure is not an exception.

Failure is the default state.

Reliable AI systems are not built by avoiding failure.

They are built by surviving it.

That is Harness Engineering.

Contract-Driven LLM Execution

The biggest improvement came from removing ambiguity.

I stopped asking the model to:

“Do the task well”

and started requiring:

“Satisfy the contract”

For example:

### REQUIRED OUTPUT

- Must create:
  .handoff/task-1/spec.md

- Must include:
  SPEC_DONE

- Must NOT:
  modify request.md

- Final line must be:
  <<<DONE>>>

Outputs also had strict file-based contracts:

[FILE]
path: .handoff/task-1/spec.md
---
implementation details here
---

No free-form output.

No interpretation.

Either the contract was satisfied or it failed.

This made failure measurable.

And measurable failure is what makes retries possible.

This is one of the most important patterns in production-grade AI agent architecture.

Why Validation Layers Matter in LLM Systems

Validation is what transforms LLM output from “probably correct” into “safe enough to continue.”

Validation was deterministic.

For example:

if ! grep -q "VALIDATOR_DONE" output.txt; then
  echo "Validation failed"
  exit 1
fi

Other validation checks included:

• required file existence
• schema validation
• forbidden output detection
• completion marker verification
• PASS / FAIL summaries

The question changed from:

“Does this look correct?”

to:

“Did this satisfy the required conditions?”

That is how validation layers improve LLM reliability.

Because intuition does not scale.

Validation does.

Retry Loops Create Reliable AI Automation

Retries were not random.

They were guided by failure signals.

When validation failed, the next prompt included correction feedback:

Previous output failed because:

- missing [FILE] block
- invalid completion marker
- required file was not created

Fix only these issues.
Do not rewrite unrelated sections.

This made retries behave like:

gradient-free optimization

The model did not need gradients.

It only needed clear failure signals.

That was enough to create convergence.

This is why retry loops are the core of reliable LLM systems.

Not just better prompts.

Why Agents Alone Are Not Enough

Many people ask:

Why not just use Claude Code directly?

The answer is simple.

Claude Code is a brilliant interactive engineer.

But production automation does not need brilliance.

It needs boring reliability.

Interactive agents work well when humans are present.

Because humans can:

• notice failure
• redirect execution
• stop bad decisions

But in a fully automated workflow:

there is no human in the loop.

The system must decide:

• did this step succeed?
• should we retry?
• what exactly failed?
• is it safe to continue?

That requires a harness.

Not just an agent.

The agent generates.

The harness controls.

That distinction separates demos from production systems.

Final Takeaway

The real question is not:

How do we build smarter AI?

The real question is:

How do we build systems that do not collapse when failure happens?

Reliable LLM systems are not built by asking better questions.

They are built by designing better control systems.

This is the core of production AI engineering.

And this is where Prompt Engineering ends.

FAQ

What is Harness Engineering?

Harness Engineering is the system design layer that controls LLM behavior.

It includes validation, retries, structured output contracts, and failure detection.

It is what makes LLM systems reliable in production.

Why does prompt engineering fail in production?

Because prompt engineering improves output quality, but it does not guarantee reliability.

Production systems fail when there is no validation or recovery mechanism for bad outputs.

How do validation layers improve LLM reliability?

Validation layers make failure measurable.

They check completion markers, files, schemas, and output contracts so the system can safely decide whether to continue or retry.

Why do local LLM systems fail more often?

Local LLMs usually have smaller context windows, weaker reasoning consistency, and higher instability in multi-step tasks.

That makes validation and retry systems even more important.

What is the difference between prompt engineering and harness engineering?

Prompt engineering improves model outputs.

Harness engineering controls whether those outputs are accepted, rejected, or retried.

Prompt improves quality.

Harness creates reliability.

Related Articles

• Why Prompt Engineering Alone Fails in LLM Systems (And How to Fix It with Convergence)
• Why LLM Systems Fail in Production (And Why Prompt Engineering Is Not Enough)