‘To master AI, prompts are important’
This is a phrase I have heard many times since ChatGPT began to spread.
In fact,
‘You are a professional editor’
‘Please answer according to the following conditions’
‘Please output in table format’
Even just adding instructions like these changes AI’s answers significantly.
However, as you start using AI in earnest, you realize something at a certain point.
There are problems that cannot be solved just by refining prompts.
It forgets the premise in long conversations.
I haven’t had it read the necessary materials.
AI cannot edit files.
I cannot confirm if the work was finished correctly.
It won’t proceed unless a human gives instructions for the next step every time.
These problems cannot be solved just by saying, ‘Let’s give instructions with better writing.’
Therefore, currently, the technology for handling AI is not just about prompts, but is being discussed from a broader perspective of
Prompt Engineering
â Context Engineering
â Harness Engineering
â Loop Engineering
.
This time, we will look at what these four layers are.
And for those who use ChatGPT normally, we will see what changes when you know this.
First is ‘Prompt Engineering’.
This is likely the one you are most familiar with.
Simply put, prompt engineering is
designing the instructions you give to the AI
.
OpenAI also explains Prompt Engineering as writing effective instructions so that the model can consistently generate outputs that meet your requirements.
For example,
you can ask it to ‘summarize this text’.
However,
if you ask it to ‘explain the important points in three items so that even a first-year university student can understand, keeping each to about 100 characters. If you use technical terms, explain their meanings immediately after,’
the likelihood of getting an answer that fits your purpose increases.
It is the same AI.
The only thing that changed was the instruction.
This is the most basic concept of prompt engineering.
What is important here is that it does not mean ‘the longer the prompt, the stronger it is’.
What do you want it to do?
Who is it for?
What is the desired output format?
What should you prioritize?
What format do you want?
Clarify the necessary information.
Even just doing this makes a big difference.
With recent high-performance AI, it has become more important to state your goals and conditions straightforwardly rather than creating unnecessarily complex instructions. Anthropic also recommends avoiding overly complex prompts and instead providing the necessary information clearly.
However, even if you write a good prompt, you might still fail.
This is the most important part of this article.
For example, suppose you tell an AI,
“Write a new article in the same style as my previous articles.”
and you give the instruction perfectly.
But what if the AI doesn’t know any of your past articles?
Naturally, it cannot reproduce them.
The instruction text is correct.
But, the information needed for judgment is missing.
Dealing with this problem is what
Context Engineering
is about.
Context Engineering is easy to understand if you think of it as
designing not just ‘what to instruct,’ but ‘what to show the AI while it thinks.’
as well.
Anthropic describes context engineering as the technique of selecting and maintaining information that leads to desired results from the finite information provided to a model. Context includes not only prompts, but also system instructions, tools, conversation history, and external data.
For example, if you have an AI write an article,
Past articles.
Article writing rules.
Target audience.
Points previously corrected by the user.
Materials to be used this time.
Making these available for appropriate reference.
This is also a technique for utilizing AI.
You can experience this even just by using ChatGPT normally.
In a new chat, suddenly,
“Create it like the last one”
rather than saying,
in an environment where past text and rules are shared,
“Create it like the last one”
is overwhelmingly easier to understand.
In other words, when using AI,
it is important not just to look at the question, but to look at what information the AI currently has
becomes important.
Even so, it is still not enough
So, for the AI,
I have clearly communicated the purpose.
I have also provided the necessary materials.
Even so, there are tasks it cannot do.
For example,
“Fix the bugs in this program”
suppose you ask that.
If the AI only looks at the code,
“It would be good to fix it like this”
it can say that.
But if you really want to complete the work,
read the files.
rewrite the code.
run the tests.
look at the errors.
re-fix if necessary.
save the changes to Git.
a work environment that can do things like this is necessary.
This is where,
Harness Engineering comes in.
is.
The word ‘harness’ carries the image of controlling something powerful and directing it toward a specific goal.
In the world of AI, while the definition varies somewhat, it broadly refers to
setting up tools, permissions, rules, and verification environments around an AI model to actually make it work
it.
On Martin Fowler’s site as well, ‘harness’ is introduced as a broad term representing the parts that make up an agent other than the model itself.
At this point, it moves quite far away from the feeling of ‘asking questions to AI’.
You are not asking the AI,
‘Please fix this code.’
It is not that.
The AI can read code.
It can also edit it.
It can also test it.
It can also see the failure results.
But it cannot access places it is not allowed to touch on its own.
You are designing the workspace itselfthat is.
The reason AI coding agents are powerful is not just because of the model.
By having a file system, terminal, search, tests, Git, and so on around the model, it transforms from a mere ‘AI that answers code’ into an ‘AI that can work on code’.
And this way of thinking is not just about programming.
An AI that can search through documents.
AI that can read emails.
AI that can check calendars.
AI that can reference internal databases.
AI that can operate browsers.
All of these also lead in the direction of ‘what kind of environment can we give AI to work in’.
And then there is the recently emerged ‘Loop Engineering’.
Even after setting up the environment to this extent, human work still remains.
For example,
AI: ‘I have corrected it.’
Human: ‘Test it.’
AI: ‘An error occurred.’
Human: ‘Investigate the cause and fix it.’
AI: ‘I have fixed it.’
Human: ‘Test it again.’
This kind of exchange.
It happens often.
In that case,
couldn’t we avoid having a human say the next step every single time?
That is the idea that emerges.
That is where attention is beginning to focus.
Loop Engineering
is.
In July 2026, IBM described Loop Engineering as a design philosophy for workflows that allow AI agents to progress toward goals with minimal human intervention through iterations of ‘act -> observe results -> judge -> act again’.
It is a relatively new term, and it is not yet a field with a completely fixed definition.
However, the concept itself is very easy to understand.
Instead of a human giving instructions every time like,
‘Do this next’
‘Okay, do it again’
‘It failed, so fix it’
we design a cycle where,
the AI itself can judge what to do next.
For example,
give it the goal of,
‘Make this program pass all tests.’
The AI examines the code.
It makes corrections.
It runs tests.
If it fails, it reads the logs.
It makes corrections again.
It finishes once all tests succeed.
With this, humans don’t have to
“Test this”
“Fix this”
“Do it again”
and input it over and over again.
The important point is
not to keep the AI running infinitely
.
What defines success?
How many times are you allowed to try?
When should you return to human control if failures continue?
What should not be executed without permission?
You need to create a loop that includes these stopping conditions and constraints.
In August 2026, research investigating open-source projects regarding Loop Engineering was published, organizing common elements such as stopping conditions, state preservation, verifiers, execution budgets, and escalation to humans. In other words, it is not just a matter of “making the AI do it many times.”
The four are not in competition
Looking at this so far,
“Is prompt engineering already outdated?”
you might think.
That is not the case.
Rather,
Prompt Engineering is about ‘how to ask’.
Context Engineering is about ‘what knowledge to provide for it to think’.
Harness Engineering is about ‘what environment to provide for it to work’.
Loop Engineering is about ‘how to iterate until the goal is reached’.
They cover different scopes.
For example, even for a single task like ‘writing a university report’,
with prompts, you specify the theme, style, and structure.
as context, you provide lecture materials and references.
as a harness, you provide an environment for searching materials and creating files.
as a loop, you repeat the process of drafting, fact-checking, revising, and re-verifying.
You can structure it this way.
Once you reach this point,
‘asking the AI good questions’
is no longer the only way to use AI; it shifts to
creating the very system that makes it easy for AI to advance the work
is the mindset that emerges.
And there is one more thing we must not forget: ‘evaluation’.
However, as the scope of what you entrust to AI expands,
‘Did it actually do it correctly?’
becomes a bigger issue.
This is where Evals, or evaluation, becomes important.
OpenAI describes Evals as a mechanism for verifying whether AI output meets specified standards of quality and content.
Rather than a fifth stage following Prompt, Context, Harness, and Loop, it is easier to think of it as
an entity that checks everything from the side
than to think of it as a fifth stage.
Did the answer improve after changing the prompt?
Did accuracy increase after adding documents?
Has the failure rate increased after letting it use new tools?
Is the automatic loop really ending at the correct point?
Instead of settling for ‘it feels like it got better,’ verify these things.
The more seriously you use AI, the more important this part becomes.
Mastering AI is not about writing long prompts.
When people talk about AI utilization,
it often tends to become a discussion about,
‘What kind of prompt should I write?’
Of course, that is important.
But current AI can do too much to think about it just in those terms.
What are you asking for?
What state of knowledge are you putting it in?
What are you enabling it to operate?
How do you get it to move on to the next action on its own?
And how do you verify that the result was correct?
Once you can design up to this point, your relationship with AI will change significantly.
From ‘someone who asks AI good questions’ to,
‘someone who creates a state where AI can work effectively.’
This is a major shift to keep in mind for mastering AI from now on.
Starting next time, we will look at the most familiar Prompt Engineering in detail, using actual prompts.
‘What specifically should I write to change the answer?’
‘Are long-form prompts really necessary?’
‘Is there any point in assigning a role?’
‘What changes when I show examples?’
We will delve into this by actually asking AI to do the same work and comparing the results.
Reference Materials
OpenAI ‘Prompt engineering’ OpenAI ‘Evaluation best practices’ Anthropic ‘Effective context engineering for AI agents’ Martin Fowler ‘Harness engineering for coding agent users’ IBM ‘What Is Loop Engineering?’ Lulla et al. ‘Loop Engineering: Building Blocks, Adoption, and Impact’
