When researching “how to give good instructions to AI,” terms like prompt, context, and harness keep appearing one after another. For those who are just starting to learn development using AI, it might be difficult to grasp the differences between them.
I think it is easier to organize these concepts if we view this movement as “the scope of what we can optimize in development is expanding.”
In development, both how we write code and how we proceed have changed.
The languages used to write programs have expanded from machine code to assembly language, and then to high-level languages. This is an effort to express detailed instructions to machines in a form that is easier for humans to handle.
Development methodologies also include waterfall, where processes are carried out in stages; prototyping, where things are verified with trial models; and agile, where development and reviews are repeated in short cycles.
It is not the case that old things have all disappeared and been replaced by new ones. They are used selectively or combined depending on the purpose and conditions.
Rather than viewing the changes in AI-driven development as a linear generational shift, it seems easier to connect them to actual development if we see them as an increase in the objects of optimization.
Vibe coding and the three perspectives of design
Conveying requests in natural language and having AI write the code. I have started hearing the term “vibe coding” as a way to describe this approach.
However, if treated as having the same meaning as AI-assisted development in general, the differences become obscured. Simon Willison’s explanation distinguishes it as an approach where you do not review the generated code, but instead rely on the results of running it.
On the other hand, prompt, context, and harness engineering are perspectives on what to design when delegating work to AI.
Prompt engineering: How to ask
This involves optimizing the content and structure of the instructions given to the AI.
For example, instead of just saying “create an input check,” you convey the input fields, permitted values, and expected behavior in case of an error. It is a design that makes the request concrete so that the desired output is communicated.
Context engineering: What to use as a basis for judgment
In addition to instructions, you organize information that the AI refers to, such as related code, specifications, and past interactions.
For example, in the case of a date input check, not only the date format but also existing validation logic and the project’s common error display methods become materials for judgment.
Anthropic’s explanation describes context engineering as an effort to select and maintain information placed within a limited context. The focus is on gathering the information necessary for the work at that moment, rather than just providing a large amount of documentation.
Harness engineering: How to work, verify, and continue
This is a perspective that includes designing the tools used by the AI agent, the execution environment, verification, and the handover of work. The AI agent referred to here points to a mechanism that proceeds through multiple steps while using tools.
For an input check example, you don’t just write the code; you also set up the workflow to run tests, read the failure details, make corrections, and record how much has been verified.
The long-context task experiments published by Anthropic also combine breaking down functions into smaller parts, documenting progress, and verifying behavior. They are not trying to support long development tasks solely through clever prompt engineering.
Development work beyond the new terminology
How to make a request. What to use as a basis for judgment. What procedures to follow for the work, and what constitutes completion.
These things overlap. Even while setting up a harness, there is design involved in prompts and context. You don’t need to discard previous learning every time you encounter a new term.
For example, when a test fails, you can think about it in parts: was the specification ambiguous, was there missing related code, or was there no environment available to run the test, rather than just asking it to ‘fix it again’.
I want to value this kind of separation when learning AI-driven development as well. Instead of just chasing the novelty of words, I want to find what is missing in the current task. If you view these terms as perspectives for that purpose, each one connects back to the actual work of development.
