AI Engineering

We often hear that we are the generation living through a transitional period of the massive technological advance called AI. My first experience encountering AI was not much different from that of many people. I threw all sorts of questions at ChatGPT, and I was simply amazed at how it answered them so naturally.

On the other hand, watching it confidently talk about untrue content as if it were fact—hallucination—it also felt like a fun toy. But as time passed, this phenomenon gradually decreased, and now I have come to rely on it so naturally that I even wonder whether both my work and daily life wouldn't be inconvenient without AI.

As time goes on, the pace of AI's advancement is becoming astonishingly fast. It reminds me of the few years when I first started frontend development—learning JavaScript, and then React, TypeScript, Next.js, and countless state-management libraries appearing rapidly as the ecosystem changed. Today's AI feels like that pace of change compressed several times over.

But perhaps because of how fast the advancement is, it suddenly occurred to me that I might be focused only on using AI without properly understanding how it has developed and in what direction it is now heading.

Recently, when people talk about how to make good use of AI or how to build AI systems, I often come across the term "AI engineering." Starting from prompt engineering, moving to context engineering, harness engineering, and most recently loop engineering, the concept of AI engineering is also changing rapidly.

In this article, I want to briefly look back at the process through which AI engineering has developed so far, and organize insights for making somewhat better use of AI within that flow.

Prompt Engineering

When I first encountered AI, I was amazed, as if I had met an all-knowing genius, throwing all sorts of questions at it. But whenever I received an answer that fell even a little short of my expectations, I would think, "It still has a long way to go."

Then the concept of prompt engineering appeared. I came across the idea that the quality of AI's answers can vary greatly depending on how you ask, and I too began using AI by rephrasing the same question in various ways.

Prompt engineering is a method of designing and structuring the input (prompt) delivered to AI in order to obtain the desired result more reliably. Even with the same AI model, the depth, accuracy, and manner of expression of the answer varied greatly depending on how the question was written.

This resembled the way we converse with people. Just as another person's answer changes depending on how you ask, even when asking about the same thing, AI too produced completely different results depending on the input. So at the time, not only the performance of the AI model but also the ability to craft good questions felt like an important competitive edge, and it came across as interesting, as if it were testing the user's "ability to ask questions."

Prompt engineering has a few core principles. The interesting point is that these principles are also commonly applied to the AI engineering concepts that appeared later. In the end, I think prompt engineering became the most fundamental foundation running through all of AI engineering.

• Instruct specifically and positively — rather than "don't do this," say "do it this way," and give measurable conditions instead of vague words.
• Break it into steps — have reasoning unfold step by step before the conclusion, and split large tasks across prompts like draft → review → revise.
• Frame it with examples and roles — align format, tone, and perspective all at once with example answers and a persona.
• Specify structure and format — separate input with delimiters, enforce a format on the output, and fill in the first characters of the response to prevent filler.
• Let it say "I don't know" when it doesn't — open an escape hatch to reduce plausible falsehoods (hallucinations).
• Improve by measuring — iterate and improve based on eval-set scores, not gut feeling.

Context Engineering

If prompt engineering focused on "how to ask," context engineering began to focus on "based on what information will the AI generate its answer." Beyond simply writing good questions, how to provide and manage the information the model should reference emerged as an important issue.

Of course, the fact that the performance of the AI model itself improved greatly is one of the reasons the quality of answers rose. But just as importantly, as strategies for appropriately providing and managing the information the model references advanced, it became possible to produce far more reliable answers than before.

Notably, various methods for utilizing external data appeared. Approaches began to be used such as providing search results to the model through RAG (Retrieval-Augmented Generation), or accessing external systems such as databases, file systems, and APIs through MCP (Model Context Protocol) to fetch the needed information. AI no longer answers with only its learned knowledge; it now generates responses while referencing needed information in real time.

However, expanding the context indefinitely did not always yield good results. As the amount of input information increased, problems also appeared, such as missing important information or a decline in the ability to accurately recall and reason over the needed content in a long context. To solve these limitations, various context-management strategies developed together, such as selecting and providing only the needed information, summarizing and compressing long documents, and dividing a task into multiple contexts to process.

• Put in only what's truly needed, when it's needed — include only the minimum of high-signal information, and rather than pre-filling, search and inject at that moment (just-in-time).
• Reuse repeated information by fixing its position — move rarely used items to external storage and search/inject only when needed, and pin the same fixed portions used every time (system prompt, tool definitions) at the front to save recomputation with prompt caching.
• Compress when it gets long — swap out old history and tool results for summaries to reclaim tokens (compaction).
• Arrange by structure and position — separate instructions, data, and history with delimiters, and place important instructions at the beginning and end, where the model sees them best.
• Be sparing with tools — expose only the needed tools, and for results too, keep only the needed part instead of the original.
• Isolate context — split large tasks into sub-agents so each processes in its own clean window.
• Reduce by measuring — verify iteratively with eval-set scores, not gut feeling, on what to include and exclude.

Harness Engineering

AI gradually began to expand across all of our work. Beyond being merely a tool that answers questions, it naturally seeped into development workflows, performing various tasks from code review to QA, test automation, release-note writing, and documentation. It began to play roles throughout the system, as if it were a member of the team.

As AI came to perform various tasks throughout the system in this way, simply writing good prompts or providing the needed information was no longer enough. It became an era in which we must also design what permissions the AI has, what tools it can use, in what order it performs tasks, and by what criteria it verifies the results. The concept that emerged amid this flow is exactly harness engineering.

When I first encountered the concept of a harness, I did not easily understand it. It felt not much different from defining an AI's Skill. Because the way both skills and harnesses are defined takes the form of writing a kind of manual, they looked even more similar.

But the two clearly had different roles. A skill is closer to a functional unit that defines "what the AI can do." A harness, on the other hand, designs "when, how, and in what environment the AI will use that ability." That is, rather than defining individual functions, it is closer to the design of composing the execution environment, constraints, and workflow so that the AI can operate reliably.

There is no single correct answer in harness engineering. Just as with handling prompts or context, there are certain principles, but the actual form of a harness can be designed very diversely depending on the organization's way of working and system structure. That is why many companies recently build harnesses so that AI can operate consistently and reliably, and, based on these, are building stable AI infrastructure and agent systems.

• Design the loop to be simple and predictable — keep the control flow of observe → decide → act → observe clear.
• Confine tools safely with least privilege — allow only as much as needed through sandboxes, permissions, and policies, and block risky actions.
• Recover through feedback — immediately reflect tool results and errors into the context, and don't stall, using retries and fallbacks.
• Let humans supervise and intervene — trace with logging and tracing, and require confirmation for hard-to-reverse actions.
• Manage state explicitly — have the harness consistently store and restore memory, progress state, and sessions.

Loop Engineering

Entering 2026, the expression loop engineering began to be used. Loop engineering means "designing the iterative execution system itself," in which the agent generates prompts, gathers the needed context, verifies the results, and runs again until the goal is achieved.

Whereas previously the general way of using AI was to obtain one response from one prompt, in loop engineering, once you define only the goal, the AI plans on its own, evaluates the execution results, then supplements the shortcomings and performs the task iteratively. That is, it can be said to be a perspective that views AI not as a simple question-and-answer model but as an agent that achieves a goal.

I do not yet have experience designing a system that directly applies loop engineering, but I am considering directions in which I can apply it to my work by looking at various cases. For example, a scheduler could periodically analyze system logs and operational metrics to detect failures or anomalies, generate the needed tasks, then have the AI write a fix and create a Pull Request, and reflect the review results to improve again—this whole series of processes could be composed as a single loop.

In this way, loop engineering does not have one fixed form; just like harness engineering, it can be designed in very diverse forms to match the organization's way of working and system structure. I think that as AI agents advance further going forward, this iterative execution structure will become one of the core elements in designing AI systems.

• Control termination clearly — decide in advance when to stop, using success criteria, a maximum number of iterations, and token/time budgets.
• One step at a time, iterate while verifying — act → verify → repeat in small, verifiable units.
• Detect stalls and break out — detect iterations with no progress and infinite loops, then change strategy or stop.
• Reflect each iteration's result into the next plan — self-correct through errors and feedback to converge.
• Carry over the progress state — pass the learning and plan up to the previous point into the next iteration so as not to repeat the same work.

AI Engineering

It seems hard to predict in what direction AI engineering will develop after this. But so far, AI engineering has developed by gradually expanding upon the previous engineering, and I think the elements that were important in previous AI engineering are things we must continue to attend to as fundamentals thereafter.

I think it is similar to how, even in frontend development, which has advanced rapidly over the past several years, the core elements we considered important remained important parts even as new technologies appeared.

As the saying goes, "there is no future for a people who forget their history," I think that taking time to look back at previous AI engineering is one of the things we can do to prepare for the unpredictably advancing future of AI. In organizing this article, I want to once again look back at whether I have been attending well to the important elements of the past, and to prepare for the new forms of AI that will soon appear.

"The farther backward you can look, the farther forward you are likely to see." - Winston Churchill -