시니어 엔지니어가 AI 에이전트 만들기에서 헤매는 이유 — 교통 통제관에서 디스패처로

생각 덩어리

교통 통제관에서 디스패처로 — spec·code·deploy가 아니라 정의·실행·관찰의 루프

When we wrote software, we created a spec, a PRD, wrote code, sometimes created tests to make sure our code works. We deployed it and then our user used it. And when building agents, things are a little bit different. We define instructions on what we want our agent to do. We run it, we observe what it does, we maybe adjust our prompts, maybe we adjust our tools. We run it again and we have like this iterative loop of how can we improve and make our agent way more reliable, which is very different to how we build software.

traditional software is more like we acted as a traffic controller, right? We had control over the street lights or how fast you can go, which roads you can use, basically how the car drives. And now with agents, we are more of a dispatcher.

We tell the agent, "Hey, I want to go to London and I'm from like Germany. I could use the train, I could fly, I could use my car and go like under the water."

we define the goal on what we want the agent to do, but we don't define the exact step the agent needs to take to achieve that goal. And I mean every one of you has probably seen in their coding agent that sometimes it does something very weird, but at the end it achieves the outcome.

Text is our new state — Boolean과 flag로는 의미를 못 잡는다

starting with the first example, text is our new state. I mean traditionally we had data structures and everything was kind of mapped to Boolean or to like flags we could check.

In traditional software, we might have had an exact plan or deny plan, but we couldn't catch semantic meaning. And now what we have with LLMs is they can understand the semantic meaning.

if I have a deep research request on like doing some market research, I can approve the initial plan, but I can also on the same time provide additional information. So maybe I want to focus on like the US market and ignore California. ... Traditionally it would probably said decline and then it has a follow up. I might needed to provide more input, create a new plan and continue.

Celsius로 살고 요리는 Fahrenheit — 데이터 구조에 안 담기는 개인화

everything related to memory and personalization we do cannot really be mapped to data structures

I'm from Europe, so I mostly use Celsius, but what if I would like to use Fahrenheit for cooking, right? Previously we might had some flags on like the user profile is Celsius or is Europe or use Fahrenheit, but I couldn't like dynamically adjust based on the user preference, based on what I provide.

really it's all about text and context. I mean could be images, video, audio as well, but we no longer are really operating in those clear structured data concepts.

통제권 양도 — intent 분류와 사전 정의 workflow의 함정

when a user reached out, "Hey, I want to cancel my subscription." I might have had classification model which kind of classified the intent, "Okay, the user wants to churn." And then I had a predefined workflow of, "Okay, do you try to sell it? Do you cancel the subscription?" But there was no like dynamic kind of option to react to it dynamically.

what if your agent like kind of tries to understand the meaning and like offers something ... and the user changes their mind and now you have like a whole different intent. And it's very hard to model all of those differences and uniqueness

we need to like trust into the LLM or like hand over control that we are no longer working in those purely deterministic environments.

에러는 그냥 입력이다 — 15분짜리 run을 처음부터 다시 돌릴 수는 없다

The third one is errors are just inputs. So if something in your agent flow fails, we need to treat it as a normal input as very similar to a user input. In Go, we already do this, right? A function call can be an error or can be a value and we treat them kind of equally.

In the past, HTTP requests were very cheap. When some search, some product search failed, you just rerun your request, you redid all of the work, which was okay. But now if you have like an agent which takes 5 minutes, 15 minutes and something in the flow breaks and you would start all over, you would need to spend a lot of compute again to like do all of the previous steps. And you also might lose the existing context.

We need to kind of understand and treat errors differently, provide them back to the model, maybe have some other workarounds, some additional checks that we basically keep going forward in the flow and not like starting over from the beginning.

Unit test에서 eval로 — 입력 A가 늘 출력 C를 보장하던 시대의 종료

we assume that when we provide input A for our code B, we will always get C as an output. And that's no longer the case with agent. Agents are non-deterministic. We cannot always guarantee that the same input will lead to the same steps and the same result.

We need to test how often something works because agents are only successful if they are really reliable, right? If you have a customer agent and the same prompt only works one out of 10 times, it's nothing really you want to put in production and it becomes very flaky.

compared to traditional software, results are very subjective, right? An outcome can be very different if you ask it to create research report, if you ask it to create a customer feedback kind of scenario. And we need more like qualifying feedback. LLM as a judge or human expert for example is a good way.

Maybe the agent decides for like one user it needs to do like four more steps to do more research than for the other user. It consumes maybe a few more tokens, but at the end the outcome is really what we need to measure and want to measure in terms of success.

Agents evolve, APIs don't — 에이전트는 네가 API를 만들며 쌓은 세월의 맥락을 못 본다

you might have seen a lot of methods, API endpoints which feel very self-explaining to you like delete item feels very self-explaining if you are working on like the product API. But an agent doesn't see the code, an agent doesn't have the context and the background from all those years from you working on the API.

our agents only see like the function schemas and the doc strings and the tool definition. So on the first look, they don't really see what the delete item method does.

we need to build APIs or tools which are really agent ready, which are self-documenting with semantic interfaces.

we need methods, tools which are written for agents to be used and not assume long year developer expertise and people who have built the API.

Trust but verify — 모델과 싸우기를 멈춰라

we need to give trust, but we also verify. We should stop fighting the model. You should not like try to force the model into this one specific workflow with step one do this, step two do the other thing.

We need to preserve meaning. Everything is a context now. We no longer have those very well-defined data structures for all of our applications.

We need to design for recovery. Models are not perfect. Agents are not perfect, especially if we have longer running agents. There will be some very weird things happening.

We need to evaluate and then don't only assert. Agents are not 100% reliable. We need to find the right balance between how many times our run need to be successful to provide it to the user.

Build to delete — software는 disposable이다

And last but not least, build to delete. The bitter lesson is what everyone of us is learning is like software is disposable. We are going to rebuild many, many times the same things with better models, better agents. Things will change.