[Generative AI] 4 Paradigms of AI Engineering — Prompt, Context, Agentic, Harness

Overview

If you’ve been working with Claude Code for a while, you’ve probably noticed that “writing good prompts” alone doesn’t cut it. The same instruction can produce vastly different results depending on what information you provide alongside it, and how you structure your agents can make or break the quality of the output.

After reflecting on these experiences, I realized there are quite a few areas beyond prompting that need attention to use AI effectively. In this post, I’ve organized AI engineering into 4 paradigms based on what I’ve learned in practice.

1. Prompt Engineering — “How do I say it?”

This is probably the most familiar concept. How you write your instructions (prompts) to the AI dramatically affects the results.

We’ve all experienced this — the same question asked differently yields different answers. “Review this code” produces a very different response compared to “Review this code from a senior developer’s perspective, focusing on security issues.” The latter gives you much more specific and actionable feedback.

Common Techniques

• Few-shot: Show a few examples of what you want. When the AI sees the pattern directly, it grasps your intent more accurately.
• Chain-of-Thought: Ask the AI to “think step by step.” This makes it reason through the problem, often arriving at more accurate answers.
• Role Prompting: Assign a role like “You are a backend developer with 10 years of experience.” The AI then responds from that perspective.
• Output Format Specification: Saying “Respond in JSON” or “Organize in a markdown table” makes post-processing much easier.

How This Looks in Practice

Limiting the scope prevents the AI from dumping unnecessary content.

Analyze only the What and Why of the requirements.
Do not discuss the How (technical implementation).

Specifying the output format upfront means you can use the results right away.

Respond in the following table format:
| Feature | Description | Priority |

But Prompts Alone Have Limits

No matter how well you craft your prompts, you can’t make the AI fetch external data or use tools on its own. “Asking the right question” and “getting the job done” are two different things. To go beyond this limit, we need the next paradigm.

2. Context Engineering — “What do I show it?”

Even with the exact same question, what information you provide alongside it completely changes the result. Designing this systematically is Context Engineering.

Think of it this way: if the prompt is the question on an exam, the context is the reference material you place next to the exam paper. Solving a problem with a textbook open is very different from solving it with nothing at hand.

The Key Is “Selecting Only What’s Needed”

An LLM’s context window isn’t infinite. Stuffing too much information in buries the important bits and drives up costs. Too little, and the AI can’t make informed decisions.

A Common Mistake and How to Fix It

Feeding an entire API response into the context is a frequent mistake. Just extracting the fields you need can significantly improve result quality.

# This dumps all the unnecessary data into the context
curl -s https://api.example.com/comments | jq '.[].body'

# This filters to only what's needed — much more efficient
curl -s https://api.example.com/comments \
  | jq '.[] | select(.tag == "review") | .body'

The same goes for instructions. Rather than loading one massive file with every rule, it’s better to load only the relevant parts as needed.

# This loads all 500 lines into the context every time
instructions.md (500 lines)

# This loads only the modules you need
router.md (50 lines) → loads only the relevant module.md

If you use Claude Code, splitting your CLAUDE.md into separate files per subdirectory instead of keeping one giant file at the project root is a great example. There’s no need to load backend rules when you’re editing frontend code.

The Wall It Can’t Cross

No matter how well you curate the information, you still can’t make the AI open files on its own, call APIs, or execute code. Context Engineering optimizes what the AI uses to make decisions, but it doesn’t design what happens after the decision is made.

3. Agentic Engineering — “How do I let it work on its own?”

So far we’ve covered prompts (how to say it) and context (what to show it). Both optimize the AI’s “input.” Agentic Engineering goes a step further — it’s about making the AI work autonomously using tools.

Put simply, instead of asking the AI for an answer, you’re delegating work to it. You say “refactor this code,” and the AI reads the files, makes changes, runs tests, and reports back.

What Becomes Possible

• Tool Use: The AI runs terminal commands, reads and writes files, and calls APIs.
• Multi-Agent: Separate agents for code exploration, review, and implementation, each playing a different role.
• Plan Then Execute: Instead of throwing a complex task at the AI all at once, have it create a plan first, review it, then execute.
• Self-Correction: The AI validates its own output and iterates to fix issues.

Patterns That Work Especially Well in Practice

Using different models for different task types lets you balance cost and quality.

Exploration agent: Quickly surveys the codebase and identifies patterns
  → Sonnet (a fast, cost-effective model is sufficient)

Review agent: Thoroughly validates output and finds defects
  → Opus (suited for tasks requiring critical thinking)

When output quality matters, don’t try to get it right in one shot — create an iterative validation loop.

Up to 3 rounds:
  1. Perform the task
  2. Self-review or independent agent review
  3. Pass → done, Fail → fix and repeat

In Claude Code, creating sub-agents with the Agent tool or using /plan mode to plan before executing are examples of this paradigm.

More Autonomy Means More Responsibility

When agents start modifying files and running commands on their own, the question naturally arises: “Should it be doing that?” Important files could be accidentally deleted, or unintended commands could be executed. To address this, we need the final paradigm.

4. Harness Engineering — “Where does it work?”

“Harness” originally refers to the equipment used to safely control a horse’s power. AI is similar — it’s powerful, but without proper controls, it can cause unexpected problems.

Harness Engineering is about setting the rules of the room where the AI works. What tools can it use? What files can it access? What checks must it pass before performing risky operations?

Settings You Can Use Right Away

Principle of Least Privilege: Restrict the AI to only what it needs. Allow reads but block deletions and admin commands.

{
  "permissions": {
    "allow": ["Bash(ls:*)", "Bash(cat:*)", "Read(/src/**)"],
    "deny": ["Bash(rm:*)", "Bash(sudo:*)"]
  }
}

Hooks for Automatic Validation: Automatically run a linter before the AI commits code. This ensures a baseline quality level without manual checks every time.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git commit:*)",
        "hooks": [
          {
            "type": "command",
            "command": "npm run lint"
          }
        ]
      }
    ]
  }
}

If you use Claude Code, configuring permissions in settings.json and building validation pipelines with Hooks is exactly Harness Engineering.

For detailed information on Hooks setup, see Receiving task completion notifications with Claude Code and terminal-notifier.

The Environment Alone Isn’t Enough

No matter how safe you make the room, if the AI inside receives wrong instructions or looks at incorrect information, you can’t expect good results. A good environment only fulfills its role when paired with good prompts, good context, and good agent design.

Side-by-Side Comparison

How the 4 Paradigms Relate

These 4 paradigms don’t exist in isolation — they form stacked layers.

┌─────────────────────────────────────────┐
│  Harness Engineering (Environment)       │
│  ┌───────────────────────────────────┐  │
│  │  Agentic Engineering (Behavior)    │  │
│  │  ┌─────────────────────────────┐  │  │
│  │  │  Context Engineering (Info)   │  │  │
│  │  │  ┌───────────────────────┐  │  │  │
│  │  │  │  Prompt Engineering   │  │  │  │
│  │  │  │  (Instructions)       │  │  │  │
│  │  │  └───────────────────────┘  │  │  │
│  │  └─────────────────────────────┘  │  │
│  └───────────────────────────────────┘  │
└─────────────────────────────────────────┘

Starting from the innermost layer:

• Prompt is part of Context. After all, a prompt is just text that goes into the context window.
• Context is the material that Agents consume. Agents observe the information in the context, then decide and act.
• Agent runs inside the Harness. No matter how capable an agent is, it can’t do what the environment doesn’t allow.

Outer layers amplify the effectiveness of inner layers. Conversely, if any one layer is weak, it drags down the overall result no matter how good the others are. Write the perfect prompt but feed it wrong context, and it’s useless. Design a brilliant agent but give it insufficient permissions, and it can’t finish the job.

Ultimately, I believe balancing all 4 layers is the best way to get the most out of AI.

Conclusion

In this post, I’ve broken down AI engineering into 4 paradigms: Prompt, Context, Agentic, and Harness.

I feel that the era of “just write good prompts” has already passed. You need to think about what information to show the AI (Context), how to let it work on its own (Agentic), and what environment to set up (Harness) to truly unlock AI’s potential.

I’m still learning too, but I hope this framework helps anyone thinking about how to use AI more effectively.

Github Sponsor Buy me a coffee

Was my blog helpful? Please leave a comment at the bottom. it will be a great help to me!

App promotion

You can use the applications that are created by this blog writer Deku.
Deku created the applications with Flutter.

If you have interested, please try to download them for free.

word learning app for kids

BlaBoo

Korean TOPIK vocabulary app

TOPIK words

Japanese vocabulary app

Japanese words

Chinese HSK vocabulary app

HSK words