These days it is hard to find a developer who doesn’t use an AI coding agent. AI has become that much a part of developers’ daily work. But where the story used to be that it helps, now you regularly hear people say they feel anxious, as if their expertise has been replaced. And this is only a year after Andrej Karpathy introduced the term vibe coding.

Recently this anxiety even got a name. Claude Blue, a term first used in the Korean essay Claude Blue: All of Silicon Valley Is Depressed, refers to the depression that comes from seeing your expertise and career get replaced by rapidly advancing AI. People feeling anxious whenever technology advances quickly is nothing new, but this time the shape of it is a bit different. AI is invading “intelligence,” supposedly a uniquely human domain, and doing it so fast that the fear is on a different level from before.

On top of that, the flood of terminology is serious. Vibe coding, prompt engineering, context engineering, harness engineering. A new “engineering” shows up almost every day, and each time the pressure of falling behind comes with it. According to one survey, 24% of workers said their mental health had gotten worse because of information overload from AI.

How to Overcome Fear

People feel fear in front of what they can’t understand. When an unidentifiable sound came from inside a cave, the best strategy our ancestors had was to run. It was a rational instinct for survival, but in modern society this instinct often backfires.

The fear AI creates has the same structure. Something you can’t identify is advancing at tremendous speed, new terms pour out every day, and everyone around you seems to be adapting just fine. It is not easy to keep your judgment under that kind of pressure. Therapy and counseling cases among developers are in fact increasing, and so are complaints of sleep problems and social withdrawal.

It is a hard situation, but there is one way to overcome fear. Face it directly and understand what it is. An unidentified sound in the dark is scary because you don’t know what it is. Once you learn the sound was a branch swaying in the wind, the fear disappears. Fear comes not from the thing itself but from ignorance of the thing.

Of course, the sound isn’t always a branch. It could really be a dangerous animal. But if you know what the animal is, the story changes. If you know whether it’s a bear or a snake, you can decide whether to run or hold still, and you can prepare in advance. When you don’t know what it is, every possibility is a threat. When you do, the range of the threat becomes clear, and only then can you respond.

Fear of AI is no different. What we are afraid of is not so much AI itself as the fact that we don’t know how it works. Because we don’t know what it is, we can’t see the boundary between what it can and can’t do, so every possibility feels like a threat. But once you understand what it is, what looked like magic starts to look like technology. And technology is something you can learn, and something that has limits.

What an LLM Really Is

Put simply, an LLM is a model that predicts the next word. It is trained on an enormous amount of text and computes “which word is most likely to come next in this context.” Whether it’s ChatGPT, Claude, or Gemini, the core principle is the same. It takes the input text and generates the next token, one at a time.

You might wonder how something that just predicts the next word can be so smart. A model trained with enough data and parameters goes beyond simple word prediction and manages reasoning, translation, even writing code. But underneath all of those abilities there is still a single principle: generate the most appropriate output for the given input.

So how do the LLM services we use make use of this model? It looks complicated from the outside, but it’s remarkably simple. It is an HTTP API call. Every LLM service works the same way. The client sends messages containing the conversation to the API server, the model behind the server generates the next tokens, and the result is streamed back. When you watch letters appear one by one in ChatGPT, this is what is actually happening.

Even an AI agent’s powerful coding ability comes from nothing more than a wrapper around this API call. Build the messages, call the API, receive and process the response. That is the basic skeleton of every LLM application.

How AI Agents Got Smart

LLMs are powerful, but they have clear limits. The model holds no state, so to “remember” a conversation you have to send the entire previous conversation again every time. There is a limit on how much text you can send. It doesn’t know anything from after its training, and it sometimes generates plausible but wrong content. On its own it can’t read a file or run code either.

AI agents exist to overcome these limits. Writing the prompt well, using the response to build the next prompt, filling in the knowledge the LLM doesn’t have. All of it is about how an AI agent makes use of an LLM. And that is exactly what all those “engineerings” tormenting us are.

Let’s look at how the methods for handling LLMs well have developed, in chronological order, and understand the structure they share.

Thinking About Good Prompts

Even with the same model, the result changes a lot depending on how you ask. As people started to realize this, research into how to write the prompts sent to an LLM began. This is called prompt engineering.

Basically, an LLM is a model that predicts the next word. That also means the context of the input text decides the direction of the output. If you send “Tell me about Korea,” the model can go in any of countless directions: history, culture, food, economy. The probability of the next token is spread evenly across many candidates. If instead you send “The capital of Korea is,” the probability that the next token is “Seoul” becomes overwhelmingly high. The more specific the context, the narrower the range the model’s output converges to.

Several techniques that use this principle have been studied. Give the model a role, like “You are a senior developer with 10 years of experience,” and it responds with the vocabulary and depth that fit the role, because it generates the kind of text that would follow something a senior developer wrote in the training data. The Few-Shot technique, which shows a few examples of the output you want, creates the context of “answer in this pattern.” The Chain-of-Thought technique, “think step by step,” has the model output its intermediate reasoning to improve the accuracy of the final answer. Ask it to solve a complex problem in one go and it makes frequent mistakes, but have it solve the problem in steps and the output of each step becomes context for the next, leading to a more accurate result.

The names sound difficult, but in the end it’s about how to compose the text you send to the model so the output goes in the direction you want. Writing a good prompt alone can get you impressive results, but using that in a real product ran into another problem. The LLM’s output is nondeterministic.

Putting the Response in a Format

An LLM’s output is nondeterministic by default. Even if the prompt says “answer in JSON,” the model would add explanations before and after, or output a broken format. That’s fine for a human to read, but fatal for a program to parse, so putting the output into a format became a key task.

The methods developed in several directions. First came specifying the desired format in the prompt or forcing JSON output through API settings, and later came features that guarantee output matching a given JSON Schema. The point was to turn the model’s output into a structure a program could handle reliably.

Extend this idea a little further and something interesting becomes possible. What if the output format is set to “the name of a function to call and its parameters”? For example, when a user asks “What’s the weather in Seoul?”, the model doesn’t know the weather itself. Instead it outputs a function call: get_weather(location="Seoul"). The developer then runs the function and hands the result back to the model, and the model generates the final response from it. This is called Function Calling.

Put a list of available tools in the prompt and the model picks the one that fits the situation and calls it. The tool definitions are also just text injected into the prompt, and the model just reads that context and predicts the next token. When the prediction matches the tool-call format, the runtime executes it.

This is when AI agents started getting smart in earnest. There was now a way to handle information the model wasn’t trained on, and things the model couldn’t do by itself could be solved by connecting tools. MCP, RAG, and other ways of connecting to external knowledge can also be seen as forms of tool calling.

Now we knew how to write prompts and could connect tools. But the instability, where changing a prompt’s wording slightly changed the result a lot, was still there, and tools alone weren’t enough for handling information the model hadn’t learned. People gradually began to realize that what context you provide alongside the prompt affects the result more than the prompt itself.

Realizing the Importance of Context

Context engineering emerged naturally from this flow. If prompt engineering is about “how to ask,” context engineering is about “what to show the model before it starts reasoning.”

Why is this a separate problem from the prompt? An LLM generates output based on the context of the input text. The longer the input gets, the less attention the model pays to each piece of information. Just as a person reading a thick book in one sitting easily misses what was in the middle, an LLM has a similar problem. Research has confirmed that models miss information placed in the middle of a long input. Stuffing in more isn’t automatically better. The right information has to go in the right place for the model to make proper use of it.

Context can be designed in many ways. You can put in the conversation history as is, but you can also put in a summary of only the important parts, or rules and guidelines the model should follow in a structured form. For a task that needs tools, putting the tool definitions and usage into the context is important too.

Designing what to show the model, from the system prompt and conversation history to structured rules and tool definitions, is context engineering. Depending on how it’s done, the same model produces results on a completely different level.

But context engineering has limits too. No matter how well the context is composed, the hallucination problem, where the model generates plausible but wrong content, didn’t go away, and putting in too much information sometimes lowered accuracy instead. Above all, as the conversation got longer or the task got more complex, the context window ran out. Trying to fit everything into one giant prompt had a physical limit.

Splitting the Prompt

If one prompt can’t solve everything, split the prompt. Instead of handling a complex task with one giant prompt, break the work into small units and combine prompts for each. For example, prepare one prompt for code review and another for writing tests, and use each when needed.

Develop this idea further and, like Function Calling, you can let the model pick the prompt that fits the situation. Today this is commonly called a Skill.

Techniques for managing the context window efficiently can be understood the same way. Compaction keeps only the essentials from the earlier conversation and summarizes the rest. Sub-agents split the work into small units, handle each in its own independent context, and return only the results. The shared principle is to process “many small, focused prompts” instead of “one giant prompt.”

So now we can write prompts well, connect tools, design context, and split up work. But one problem was still unsolved. Detecting when the model is heading in the wrong direction and correcting it is not something a prompt alone can do.

Putting On the Harness

Writing prompts well, connecting tools, designing context, splitting up work. We got this far. But once AI agents began editing files, running code, and working through multi-step tasks, a new problem surfaced. When the model writes wrong code, who detects it? When a tool call fails, how do you recover? When the agent is heading somewhere it shouldn’t, how do you correct it?

The word harness originally means the gear you put on a horse. It’s a device for controlling the horse’s power in the direction a person wants. A harness for an AI agent is similar. It refers to the entire execution environment that controls the power called a model in a safe and useful direction. It’s sometimes expressed with the formula “Agent = Model + Harness,” and the harness is everything except the model itself.

So what goes into the harness? From the API-call point of view, it’s a loop that controls when, under what conditions, and how many times the API is called, and the things that fill this loop fall into two broad groups.

The first is guides. They set the direction before the agent acts. Providing the project’s coding convention document or architecture description, or making type definitions and API docs available for reference, falls here. Writing project rules in the system prompt or a file like CLAUDE.md is a typical example. In horse-gear terms, it’s closer to the reins that set the direction the horse should go.

The second is sensors. They check the result after the agent acts. After code is written, run a linter or the tests automatically, and if there’s a problem, tell the agent again. The agent fixes the code based on this feedback and runs the tests again. It’s like pulling the reins when the horse tries to go the wrong way. With guides but no sensors, the agent knows the rules but can’t check whether it followed them properly. With sensors but no guides, it repeats the same mistakes.

There’s an amusing technique related to this called the Ralph Loop. Named after Ralph Wiggum¹ from The Simpsons, it works like this: even when the agent declares the task done, if the completion criteria aren’t met, the same prompt is injected again and the agent keeps repeating. Progress is stored in the file system and git history rather than the context window, so each iteration can start with a fresh context and still continue the previous work. The philosophy is that if you repeat stubbornly enough, stupidly enough, you eventually succeed, and it drew attention for showing surprising results in practice.

As the Ralph Loop got attention, some people started equating harness with Ralph Loop, but the two are not the same. A harness is the broad concept of designing the entire execution environment around the model, and the Ralph Loop is closer to one iteration pattern you can use inside it. Having guides and sensors, connecting tools, and managing state is the harness. The Ralph Loop is one of the strategies that run on top of such a harness.

Designing a harness well is called harness engineering. Of course, it has limits. An agent has none of the intuition a person has or the tacit knowledge of an organization, so the harness has to compensate for that, and there’s a dilemma in that the harness itself becomes hard to manage as it grows complex.

So What It All Comes Down To

Some of you may have noticed by now that everything discussed so far has one thing in common. Writing prompts well, putting the output in a format, designing context, splitting up work, putting on the harness. All of them are ways to do one thing well: send a prompt to an LLM API and receive the response.

Come to think of it, this is something we have always been good at. Any developer has called an external API, parsed the response, handled errors, processed the result, and shown it to the user, countless times. Everything that happens on top of an LLM sits on this familiar pattern. It is not difficult at all.

This applies equally to people who use AI agents and to developers who build them. Whatever tool you use, what you’re doing in the end is composing the right input for the model, sending it, and receiving and processing the response.

Getting Out of FOMO

If you’ve read this far, you probably have some sense of how LLMs and AI agents work. And yet you may still feel anxious. Why?

Because there are people around us who induce FOMO. Content that scares you with “fall behind if you don’t learn this” and talks every day as if the world has turned upside down. Content that shouts “game changer” every time a new tool comes out and says what you learned yesterday is useless today. Keep consuming that and you start to feel like you know nothing, or that even if you’re using these tools, you’re not using them properly.

One good way to avoid FOMO is to look at what the FOMO inducers have actually solved with AI. Most of it is “I built this with AI in 10 minutes” stories. But making something fast only compresses the process. That isn’t the same as solving a problem. Doing work means “what you did,” not “how fast you did it.” Be careful not to get dazzled by speed and miss the important question.

That is why it is more important to build the ability to take in the right information. This article talked about how LLMs work and how AI agents are structured for the same reason. If you understand the essence, you can calmly check new information against what you know when you encounter it. You can judge for yourself whether it’s really a new paradigm or a variation on an existing concept, whether you need the information or not, whether it’s fact or exaggeration.

What Should We Do

Among those who have read this far, some will have fully understood the content and some will still feel vague. Either is fine. But even if you understood it, you may still be afraid. If the anxiety remains after you know what it is, it most likely comes from not knowing how you should act now, rather than from AI itself.

Honestly, you don’t necessarily have to do anything. The really important thing is the problem-solving perspective. If AI doesn’t help with your problems, just keep living the way you have been. If you’re curious about AI, follow the news and understand what it fundamentally is, and when your work needs AI, use it then. In the end it’s just a tool. Use it if you need it, and if you don’t, don’t. Just because the hammer was invented doesn’t mean everyone has to pick one up.

Besides, expectations of AI differ from person to person. Some find it amazing just to build a small personal tool. Some are satisfied with it writing code for them. Some feel it is still lacking in an enterprise environment. Whichever you are, judge by your own expectations.

If you still want to try something, starting by asking ChatGPT or Claude anything at all is fine. Change the prompt this way and that and watch the result change, and what this article explained starts to be understood with your body rather than your head. If you want to go a step further, I also recommend building a simple agent yourself. Getting an API key, composing a prompt, calling the API, and receiving the response lets you feel every concept in this article at once. I wrote about how to build an agent (in Korean) before, so feel free to refer to it if you’re interested.

New terms will keep coming. But if you understand the structure covered in this article, when a new term shows up you can tell whether it’s about writing prompts well, designing context, or putting on the harness. Instead of being pushed around by terms, you get an eye for the essence.

Closing

Of course, this alone won’t make all the anxiety go away. How AI will change our jobs and how a developer’s role will look in five years, honestly, nobody knows. But there is a big difference between knowing what something is and not knowing. Wandering in the fog of fear and looking at the road ahead after the fog has lifted are not the same situation.

You may still be afraid. I too have had times when I felt left out of the festival called AI, and depression came as the expertise I’d built up over years seemed to crumble. At that time my girlfriend said something to me. “It looks like the world is leaving without us, but we’re part of the world too, so it will surely take us along.” However fast the world changes, we are not standing outside it. We are already standing together in the middle of the change.

1. Ralph Wiggum is a character in The Simpsons, portrayed as a dim-witted kid. ↩