Fighting slop with slop. My name is Vibbov and I'm going to talk about something that is a little I would say maybe a little silly at first. I'm going to show you our team's engineering practices really quickly.

We do no code reviews. We require every engineer to work on things in parallel and we have no standardization how people do AI. And I know immediately what almost all of you are thinking. We're probably a Zoomer YC startup.

And I can guarantee you I'm clearly a millennial. So what do we actually do at our company without code reviews?

Well, we about three years ago we decided to build a programming language. That's something that has absolutely no room for slop. It's something that has to work every single time exactly the same way.

It's something that you can't just change a year later or a month later because you made a bad design decision.

You have to be correct. And for the last three years, we've been in an onslaught of war against slot.

And when I first met this enemy, I went to my great mentor, Slop Sue, and he taught me something. To to defeat the slop, we must become the slop.

So, we began and we prepared, and then we started winning. So, when we think about it, what is slop?

Slop is just any code you don't read. And whether any of you admit it or not, this is the least amount of slop that your codebase will ever have.

Cherish it. So we started fighting back against the slop. And we started fighting back with slop.

So how do we go ship a stable programming language with these engineering practices? Well, the first skirmish we ever had was a skirmish of standards. The hard part about hiring great engineers is you sadly can't tell them what to do. Some of them want to use cloud.

Some of them want to use codec. someone want want to use the latest thing that they just found on hackernews. So instead of trying to hold standards in our codebase, we did something that is an invariant.

We built an architecture.mmd file. Instead of using cloudm, just pick something that every model can just understand. This file has to be incredibly small and it can only have things that will not change for months or for years. In our case, it's the layers of the compiler.

you go deeper into the compiler, tell the agent to just talk to at least one other person. That slows it down a little bit. So now we have standards so anyone can use whatever they want.

But the real foe we faced was actually the battle of design. Everyone here knows that you have to write perfect design docs.

And we have a very simple rule in our team. Code can be slop, writing cannot. And of course if I tell every engineer this, they write beautiful writing and they handw write everything.

They don't use AI. Well, sadly not. So we built a design tool, design doc tool. What this design doc tool does, it's a replacement for both notion and GitHub effectively for design docs. It allows versioning, commenting, all the stuff you want. And obviously we do this, people use this.

Well, sadly not. We built another tool on top of that. And this tool was a Slack integration for that tool. Every time a design doc got updated, this channel got notifications.

And what ended up happening is this channel became the most popular channel in our company really fast. At 2 a.m., someone shipped a new design doc. Three people started reading it right away because it's just interesting. The most interesting stuff is design docs that are not going to change.

But this wasn't enough. All of this is actually backed by markdown files and simple CLI scripts that make it treat like GitHub without being GitHub itself.

So now agents can go do this. But the real problem with all this is I built this and I hit a little bit of AI psychosis and I started shipping 10 design docs a day and soon the team was fighting my slop.

So we had to go in back at the last rule.

This last rule was if you're going to ship a design doc, you require people to actually go read it. And with this last standard, we suddenly had design docs that are incredibly high quality.

But what about the battle of architecture? You how do you have your codebase converge? We built another tool. This tool basically visualizes our dependency graph internally with some external dependencies as well and allows to watch the codebase change.

It has semantic boundaries, individual packages. But what's more interesting is we can go build CLI tools that guarantee that certain invariants can't be broken.

And what this does is when Claude builds a new package or adds a dependency that's leaky, we now have CI/CD changing or or a simple git commit history that tells us exactly where things break.

And by this, we're actually able to make our architecture change. We haven't changed our architecture in the last three or four months.

But as much as we might do design docs and as much as we might have stable code, would you genuinely ship code without reading it, would you trust your team to go do that?

And think about a programming language. A programming language has so many invariants. You have generics, you have closures, you have memory allocation, you have FFI boundaries.

Could you trust that system? Python has bugs 25 years later. Well, here's where we did something slightly different.

What we did was we built a system that actually has agents constantly running and creating BML programs. We take these BAML programs.

One second. And we have agents try and spin something up from scratch. We then look at the entire claw transcript, see what tools it used, see what happened.

And obviously we as humans can inspect them. But more importantly, we can have agents go inspect them. and agents find what was good, what was bad, and not just what was bad in terms of what was incorrect in the language, but what took three tool calls when it should have only taken one.

And then we can go ahead and find issues.

And we can have humans collaborate with these issues to figure out which ones are real, which ones are hallucinations, which ones are don't have taste, as much as I hate to use that word.

And then we can have agents go ahead and create fixes to these problems and go address them. And most importantly, instead of trying to just detect these issues, we can go one step further. What if you could find language features and instead of guessing what was good, guessing what skill was good, you could go and AB test it.

You could figure out which ones took less tool calls, which one took uh which one made less errors, which one produced the correct outcome and deterministically know what's going on.

The point is you can start building datadriven systems without ever writing a single line of code.

And the thing that really I care about the most over here is not that any one of these tools is specifically what you should go build, but the fact of the matter is in order to build a programming language, it wouldn't have taken eight people.

It wouldn't have taken less than two years.

It would have taken hundreds and thousands and tens of thousands of manh hours and then you would still have a broken system. And today we can just spend billions of tokens and make it work and we can make it stable.

And you could you too can go home and build these internal tools and these sloppy tools to make sure that your code bases can ship without really having to read necessarily every single line of code because your engineers aren't going to.

And I think we can start winning this battle against slop. And as we win this battle, slop can be defeated. But sadly, I have a sad thing to say.

I think we're still going to lose the war. I think the reason that we're going to lose this war is because some of the foundational stuff that we try and go use itself is broken.

Probably most of you hopefully at this point or at least your agents have. So something around there. Um did you know that Typescript's main design goal is to strike a balance between correctness and productivity?

And there's an asterisk here because what they really mean is human productivity. And if you think about it, there are things you would never do in a programming language at the very core layer if you were designing in a world where humans never wrote a single line of code.

Let me show you what that really means. I'm going to write something and try and guess what this code does. Pretty safe.

What about this one? or even more so this one. Why do we turn things to strings when we sort them? This is just slop baked into the language whether you like it or not.

What about this? I love this part of TypeScript. And you know what? My agent loves this part of TypeScript. This is slop baked into the language.

And whether you like it or not, the systems will have slop if you build using these tools. Oh, I'm sorry, wrong talk.

But if you think about what JavaScript does, JavaScript exists and then after JavaScript existed, we started building systems to layer it on. We built coffecript, then TypeScript, and now we're trying to build effect.

But thing is the thing underneath is already broken and more so the way we write code is also different now.

So why are we trying to patch something like this? Why don't we just try and do something a little different? And I think what we might need if we try and go do that is basically going to be a madeup language.

So let me show you what BAML really can do and when you start thinking from first principles how you can try and combat slop from a very foundational layer itself.

I keep talking about not reading code. Does it even matter? Well, let me show you a new way to think about code.

And this isn't to say we all have to go do this right away. But what if every single time I looked at code Whoops.

What if every single time I looked at code, what I really saw was not the code itself, but a quick little thing that could actually visualize all the code for me.

As I clicked around, it took me to exact lines of code that was linked to if I wanted to have a slightly broader view.

I could zoom in and click around and have it expand and I could navigate my code bases more interestingly. I'm going to let this run really quickly, but while it runs, I'll show you a different pipeline.

Without any of you ever reading the code, you know, I'm setting up stuff and I have an agent loop because the semantic boundary is in there.

I can expand this. I can keep expanding this and I can say, "Nope, that's too much slop. Let's let that be slop and walk away." So instead of having to understand all the code, I can opt into what parts of the code I want to read and understand and go to the exact lines when I really care about them.

But if we go back to the previous pipeline that was running, what if while it's running, I can actually get a full execution trace.

In a world where we don't read all the code, the only way to understand the code is actually by the execution trace and actually by seeing exactly how much time was spent on what parts of my program at any given time.

If you wanted to go and actually track your program through, think about how slow your program would be if you had to go trace everything in Python or TypeScript. It's untenable.

And the best part here is if you start from first principles, you can make this effectively zero performance cost. Not only can we make it great for humans, but because it's all built for agents anyway, you can go ahead and make it so that every single file has a tracing system that Claude can navigate through.

So Claude can find what were bugs, what were errors, and what were inefficiencies and start optimizing your code without you having to do it yourself.

And I think if we go start thinking about it from this way, it's not so much about reading all the code, but it's more so about as a human understanding the system that you're working with.

And the tools that you can build can give you information about the system that you're working with.

But I think there's another layer to it. We've spent decades building ID tooling. And that think about how long it took before someone like me who does not know how to escape Vim to this day can finally start using VS Code. It was a beautiful day when that happened.

I became a real programmer. Well, according to some people, I'm still not because I can't write Vim code. But what does agent first tooling look like?

I think we're all familiar with GP, so I'm not going to go and talk about it. But I will talk about RIP GRAP because GP should not be used anywhere. If I wanted to GP through my codebase and understand what it was, I would rip GPAP say something like calculate and it would give me a bunch of code where everything was being used and maybe it would be somewhat useful.

But what if you could instead just start describing code and say, "Can you describe calculate for me?

" What if it came with all the dock strings?

What if it came with the actual source code? And what if it also told you everywhere was actually used under the hood? We can make something that used to be multiple tool calls a single tool call all of a sudden.

What if the way you wanted to learn about libraries that you were using instead of having to do a web search, you just did you just you could just ask for any external library as well and it would just give it to you because when I first learn started learning how to code, one valuable lesson I had was the code is always a source of truth.

Don't read anything but the code itself. the docs may lie. The um the actual description or architecture file or read me file will definitely lie, but the code cannot lie except if you're working on some weird architectures.

And then when you go down this road, you go from not reading the code to understand the architecture. You go from not searching the code to understanding exactly what you're getting in everyone tool call.

But what's the next thing you do? Well, the last thing I do to truly understand code is I run the code. So, what if every single thing you ran, every single function you ever wrote was immediately available?

And I'll pop this code over here was immediately available as a simple CLI command. So, if I run AD, add AD add becomes a CLI command that has A and B parameters attached to it.

And I can just run it really quickly and see what happens. What if every single CLI tool I had could be packed into a li into a CLI that's completely standalone multiply that I can just run without ever having to actually execute any of the code and is now a total CLI binary that has a function just bundled in.

Suddenly we can build really quick tooling where agents don't have to go gp through what's happening. Everything is type- safe. Everything is deterministic and everything is actually guessable.

And the best part is imagine you could build on any system and your agents don't have to worry about deployments across Windows, Mac and Linux and you can just target any layer you want and it builds for any architecture including WASM systems.

All of a sudden as an engineer you're supercharged.

You're no longer bottlenecked by what you can do in the systems underneath you are preventing. You can just move very fast. You can move at agent speed.

But a lot of the stuff that I've been talking about to this date has been about tooling. What if we tried to fix some of the real sins of JavaScript?

Some of the stuff that is deep in the language. Not the sort stuff, but I mean more important stuff like errors. Have you seen error handling be beautiful ever other than Rust?

Um what I see agents do over here is you do try catch and then they keep nesting try catch after try catch after try catch and eventually they give up and say console.log. some error happened and deal with it. What if we could do error handling from very first principles?

What happens in that world? Well, I showed you add, multiply, subtract. I didn't show you divide. Divide is dangerous. It's spooky.

So, let's go look at divide. You can see over here, divide throws a division by zero error. But what else happens? The function actually knows that it throws division by zero error without you having to write any any code. If I go up to the calculate function which at some point calls divide, this function also knows is throws division by zero error.

So error types now get inferred without you ever having to do any guess work. That means if you catch or handle errors, we can do exhaustive guarantees and the compiler can prove that you have handled the error or not handled the error.

It's no more guessing. There's no unknowns. It's guaranteed to be proven. So if you wanted to ship an API where it guarantees that it never throws, well, this system is broken because it doesn't meet the constraints.

It has two errors that you're not throwing. If you wanted to go catch that, well, I can write the code for that in a second.

But you can start catching certain errors. Let me I'm just going to return a sentinel value for now. And now this parse thing which previously threw division by zero error is now guaranteed to no longer throw the division by zero error because if I catch any exceptions in here, I return a zero value every single time.

The compiler and the tooling can do a lot of work for us.

And we're already used to this in our code bases. We many of us probably don't know how compilers work under the hood and we trust them. code is a matter of trust.

The reason that we don't tr use LM code blindly is because we don't trust it yet because the systems underneath them don't have enough rigidity.

One more thing, but before I tell you all to go write a bunch of BAML code, because I've been there and I can tell you what someone would tell me if I said, "Hey, use this new programming language.

It's going to solve all your problems." It's just going to become come with a whole slew of new problems.

So we said, I think we'll lose the war on slop if we try to ask everyone to rewrite all their code in the world into this new system. So what does a solution like that look like where you don't have to rewrite all your code?

[한영자막] 슬롭에는 슬롭으로 맞섭니다 — Vaibhav Gupta, Boundary

Tech Bridge

코드 리뷰를 배제하고 병렬적 작업을 지향하는 환경에서 불변하는 아키텍처 파일과 도구 연동을 통해 표준을 강제합니다.

AI 에이전트가 직접 코드를 실행하고 추적하며 비효율성을 탐지하는 데이터 기반의 시스템을 구축하여 인간이 일일이 코드를 읽지 않아도 안정성을 확보합니다.

기존 언어와 호환되는 BAML을 통해 타입 안전성과 명확한 에러 처리를 보장함으로써 시스템 기반의 근본적인 슬롭 문제를 해결할 수 있습니다.

표준화와 아키텍처 불변성 유지

기술적 다양성을 존중하되 코드베이스의 무결성을 지키기 위해 우리는 코드 자체를 강제하는 대신 **`architecture.mmd`라는 아키텍처 불변성 문서**를 도입했습니다. 이 파일은 컴파일러 계층 구조와 같은 변하지 않는 핵심 요소만 포함하며, 에이전트들이 작업 시 반드시 최소 한 명 이상의 인간 또는 다른 에이전트와 소통하도록 규정하여 무분별한 기술 도입을 방지합니다.

설계 문서화의 자동화와 품질 관리

설계 문서의 품질을 확보하기 위해 '코드는 엉망일 수 있어도 글은 그럴 수 없다'는 원칙을 세우고, 이를 강제할 수 있는 **전용 설계 문서 도구와 Slack 알림 연동 시스템**을 구축했습니다. 단순히 문서를 작성하는 것을 넘어, 팀원들이 실제 문서를 읽고 피드백하도록 요구함으로써 **문서의 게시와 열람이 실시간으로 이루어지는 높은 품질의 엔지니어링 표준**을 정립했습니다.

의존성 그래프와 에이전트 기반의 코드 검증

코드베이스의 의존성을 관리하기 위해 내부 의존성 그래프를 시각화하고, 특정 아키텍처 경계나 규칙이 깨질 경우 CI/CD와 Git 커밋을 통해 즉시 경고를 주는 CLI 도구를 개발했습니다. 특히, 에이전트가 생성한 결과물을 인간이 일일이 검수하는 대신 **에이전트 스스로가 도구 호출 효율성, 오류 발생 여부, 최적화 가능성을 분석**하도록 함으로써 인간의 개입을 최소화하면서도 결정론적으로 신뢰할 수 있는 시스템을 만들었습니다.

기초 계층의 근본적인 문제와 새로운 시도

현재의 개발 도구(TypeScript 등)는 인간의 생산성에 치중하여 설계되었기에 코드 곳곳에 의도치 않은 슬롭이 스며들어 있습니다. 우리는 이러한 **기존 프로그래밍 언어의 한계를 극복하기 위해 제1원칙부터 재설계한 BAML(Boundary AI Modeling Language)**을 도입했습니다. BAML은 모든 파일을 에이전트가 탐색할 수 있는 추적 시스템을 갖추고 있어, 코드를 다 읽지 않아도 시각화를 통해 시스템 전체를 파악할 수 있게 합니다.

자동 추론과 타입 안전성을 통한 에러 처리

BAML의 핵심 강점 중 하나는 **에러 타입을 컴파일러가 자동으로 추론**한다는 점입니다. 예를 들어, 0으로 나누기 에러와 같은 상황이 발생하면 호출부까지 연쇄적으로 이를 인지하게 하여, 개발자가 예외 처리를 누락하지 않았음을 언어 수준에서 보장합니다. 이는 더 이상 추측에 의존하지 않고 **증명 가능한 안정성을 확보**할 수 있음을 의미합니다.

BAML은 기존의 Python, TypeScript, Rust 등과 결합하여 사용할 수 있습니다. **BAML의 함수를 기존 언어에서 호출하고 타입 안전성을 유지**하며, 언어 경계를 넘어 클로저나 람다를 전달할 수 있는 브리지 기능을 통해 기존 생태계의 장점은 유지하면서 시스템의 근본적인 견고함을 높입니다.

엔지니어는 이제 단순히 코드를 작성하는 존재를 넘어 시스템의 아키텍처와 도구를 설계하는 존재로 진화해야 합니다. 수만 시간이 걸릴 대형 시스템도 오늘날의 AI 기술과 새로운 도구 기반으로 단기간에 구현할 수 있습니다. **코드 리뷰라는 전통적 프로세스에 얽매이지 말고, 에이전트와 공존하며 슬롭을 기술적으로 물리치는 새로운 엔지니어링 시대**를 열어가야 할 때입니다.

슬롭에는 슬롭으로 맞섭니다. 제 이름은 바이브하브이고, 처음엔 조금 어리석게 들릴지도 모르는 이야기를 해보려고 합니다. 우리 팀의 엔지니어링 관행을 아주 빠르게 보여드리겠습니다.

우리는 코드 리뷰를 하지 않습니다. 모든 엔지니어가 병렬적으로 작업할 것을 요구하며, 사람들이 AI를 사용하는 방식에 대해 표준화도 하지 않습니다. 여러분 모두가 지금 무슨 생각을 하는지 압니다. 아마 우리가 Z세대 YC 스타트업이라고 생각하시겠죠.

하지만 저는 확실히 밀레니얼 세대입니다. 그렇다면 코드 리뷰 없이 우리 회사에서는 실제로 무엇을 할까요?

우리는 약 3년 전 프로그래밍 언어를 만들기로 했습니다. 그건 슬롭(slop)이 끼어들 여지가 전혀 없는 작업입니다. 매번 정확히 똑같은 방식으로 작동해야만 하죠.

잘못된 설계 결정을 내렸다는 이유로 1년이나 한 달 뒤에 함부로 바꿀 수 없는 것이기도 합니다.

정확해야만 합니다. 지난 3년간 우리는 슬롭과의 전쟁을 치러왔습니다.

이 적을 처음 만났을 때, 저는 저의 위대한 멘토인 슬롭 수(Slop Sue)를 찾아갔고 그는 제게 가르침을 주었습니다. 슬롭을 물리치려면, 우리가 먼저 슬롭이 되어야 한다고 말이죠.

그래서 우리는 시작했고 준비했으며, 결국 이기기 시작했습니다. 그렇다면 우리가 생각하는 슬롭이란 무엇일까요?

슬롭은 그저 여러분이 읽지 않는 모든 코드입니다. 인정하든 안 하든, 지금이 여러분의 코드베이스에서 슬롭이 가장 적은 상태일 것입니다.

이 순간을 소중히 여기세요. 그래서 우리는 슬롭에 맞서 싸우기 시작했고, 슬롭을 이용해 싸우기 시작했습니다.

그렇다면 이러한 엔지니어링 관행으로 어떻게 안정적인 프로그래밍 언어를 출시할 수 있었을까요? 첫 번째 전투는 표준에 관한 것이었습니다. 훌륭한 엔지니어를 채용할 때 어려운 점은 그들에게 무엇을 하라고 지시할 수 없다는 것입니다. 어떤 이들은 클라우드를 쓰고 싶어 하고,

어떤 이들은 코덱을 쓰고 싶어 하며, 어떤 이들은 해커 뉴스에서 방금 발견한 최신 기술을 쓰고 싶어 합니다. 그래서 우리는 코드베이스 내에서 표준을 강제하는 대신 불변하는 무언가를 만들었습니다.

우리는 architecture.mmd 파일을 만들었습니다. CloudM을 사용하는 대신 모든 모델이 이해할 수 있는 것을 선택하세요. 이 파일은 매우 작아야 하며 몇 달 또는 몇 년 동안 변하지 않을 내용만 포함해야 합니다. 우리의 경우 컴파일러의 계층 구조가 그렇습니다.

컴파일러를 더 깊이 파고들 때 에이전트에게 최소한 다른 한 명과 대화하도록 지시합니다. 그러면 속도가 조금 느려지죠. 이제 표준이 마련되었으니 누구나 원하는 것을 사용할 수 있습니다.

하지만 우리가 직면한 진짜 적은 사실 설계라는 전투였습니다. 여기 있는 모두가 완벽한 설계 문서를 작성해야 한다는 것을 알고 있습니다.

우리 팀에는 아주 간단한 규칙이 있습니다. 코드는 엉망일 수 있어도 글은 그럴 수 없다. 당연히 제가 모든 엔지니어에게 이렇게 말하면, 그들은 아름다운 글을 쓰려고 손으로 모든 것을 직접 작성합니다.

그들은 AI를 사용하지 않죠. 안타깝게도 말입니다. 그래서 우리는 설계 문서 도구를 만들었습니다. 이 설계 문서 도구는 사실상 Notion과 GitHub를 대체합니다. 버전 관리, 댓글 달기 등 원하는 모든 기능을 제공합니다. 당연히 우리가 이렇게 하면 사람들은 이 도구를 사용하게 됩니다.

아쉽게도 그렇지 않았습니다. 우리는 그 위에 또 다른 도구를 만들었습니다. 바로 해당 도구를 위한 Slack 연동 기능이었습니다. 설계 문서가 업데이트될 때마다 이 채널로 알림이 전송되었습니다.

결국 이 채널은 우리 회사에서 가장 인기 있는 채널이 되었습니다. 새벽 2시에 누군가 새로운 설계 문서를 올리면, 세 명의 사람이 즉시 읽기 시작합니다. 그냥 흥미롭기 때문이죠. 가장 흥미로운 것은 변하지 않을 설계 문서들입니다.

하지만 이것만으로는 부족했습니다. 이 모든 것은 사실 마크다운 파일과 간단한 CLI 스크립트로 구성되어 있어, GitHub 없이도 GitHub처럼 다룰 수 있게 합니다.

이제 에이전트들이 이를 수행할 수 있게 되었죠. 하지만 진짜 문제는 제가 이 도구를 만들고 약간의 AI 정신 착란을 겪으며 하루에 10개씩 설계 문서를 쏟아냈고, 곧 팀이 제 엉망인 결과물과 싸우게 되었다는 점입니다.

그래서 우리는 마지막 규칙으로 돌아가야 했습니다.

그 마지막 규칙은 설계 문서를 게시하려면 사람들이 실제로 읽도록 요구하는 것이었습니다. 이 마지막 표준 덕분에 우리는 갑자기 매우 높은 품질의 설계 문서를 갖게 되었습니다.

그렇다면 아키텍처 전쟁은 어떻게 할까요? 코드베이스를 어떻게 수렴시킬까요? 저희는 다른 도구를 만들었습니다. 이 도구는 기본적으로 내부 의존성 그래프를 외부 의존성과 함께 시각화하여 코드베이스의 변경 사항을 관찰할 수 있게 해줍니다.

여기에는 의미론적 경계와 개별 패키지들이 있습니다. 하지만 더 흥미로운 점은 특정 불변성이 깨지지 않도록 보장하는 CLI 도구를 구축할 수 있다는 것입니다.

이것이 하는 역할은 클로드(Claude)가 새로운 패키지를 빌드하거나 누수가 있는 의존성을 추가할 때, CI/CD 변경 사항이나 간단한 깃 커밋 기록을 통해 어디서 문제가 발생하는지 정확히 알려주는 것입니다.

이를 통해 실제로 아키텍처를 변경할 수 있게 되었습니다. 저희는 지난 3~4개월 동안 아키텍처를 변경하지 않았습니다.

하지만 설계 문서를 작성하고 안정적인 코드를 유지하려고 노력하더라도, 코드를 읽지 않고 배포하거나 팀원들이 그렇게 하도록 신뢰할 수 있을까요?

프로그래밍 언어를 생각해 보세요. 프로그래밍 언어에는 수많은 불변성이 존재합니다. 제네릭, 클로저, 메모리 할당, FFI 경계 같은 것들이죠.

그런 시스템을 신뢰할 수 있을까요? 파이썬도 25년이 지난 지금 여전히 버그가 있습니다. 그래서 저희는 조금 다른 방식을 취했습니다.

저희는 에이전트들이 지속적으로 실행되며 BAML 프로그램을 생성하는 시스템을 구축했습니다. 이 BAML 프로그램을 활용하는 것이죠.

잠시만요. 에이전트들이 처음부터 무언가를 시도하게 하고, 전체 클로드 트랜스크립트를 살펴보고 어떤 도구가 사용되었는지, 어떤 일이 일어났는지 확인합니다.

물론 인간인 저희가 직접 검사할 수도 있지만, 더 중요한 것은 에이전트가 검사하게 할 수 있다는 점입니다. 에이전트는 무엇이 좋고 나쁜지 찾아냅니다. 단순히 언어적으로 잘못된 것뿐만 아니라, 도구 호출을 한 번이면 끝낼 수 있었는데 세 번이나 호출한 경우 같은 것도 찾아내죠.

그리고 나면 문제를 찾으러 나갈 수 있습니다.

사람들이 이 문제들과 협업하여 무엇이 실제 문제인지, 무엇이 환각인지, 혹은 제가 이 단어를 쓰고 싶진 않지만 무엇이 '취향'에 맞지 않는지 파악할 수 있습니다.

그리고 에이전트들이 이러한 문제에 대한 수정 사항을 생성하여 해결하게 할 수 있습니다. 무엇보다 중요한 것은 단순히 문제를 탐지하는 데 그치지 않고 한 단계 더 나아가는 것입니다. 언어 기능을 찾아내어 어떤 기술이 좋은지 추측하는 대신, 직접 A/B 테스트를 해볼 수 있다면 어떨까요?

어떤 것이 도구 호출을 적게 사용했는지, 어떤 것이 오류를 더 적게 냈는지, 어떤 것이 올바른 결과를 도출했는지 파악하여 무슨 일이 일어나고 있는지 결정론적으로 알 수 있습니다.

중요한 점은 단 한 줄의 코드도 작성하지 않고 데이터 기반 시스템을 구축하기 시작할 수 있다는 것입니다.

제가 여기서 가장 중요하게 생각하는 것은 이 도구들 중 하나를 꼭 만들어야 한다는 것이 아니라, 프로그래밍 언어를 만들기 위해 8명의 사람이 필요하지 않았을 것이라는 사실입니다.

2년도 채 걸리지 않았을 것입니다.

수천, 수만 시간의 인력이 필요했을 것이고, 그래도 여전히 망가진 시스템이었을 겁니다. 오늘날 우리는 수십억 개의 토큰을 사용하여 이를 작동하게 만들고 안정화할 수 있습니다.

여러분도 집으로 돌아가 이러한 내부 도구와 슬롭(slop) 도구들을 직접 구축하여, 엔지니어들이 모든 코드 라인을 일일이 읽지 않아도 코드베이스가 배포될 수 있도록 할 수 있습니다.

저는 우리가 슬롭과의 싸움에서 이기기 시작할 수 있다고 생각합니다. 이 전투에서 승리하면 슬롭을 물리칠 수 있습니다. 하지만 안타깝게도 슬픈 소식이 있습니다.

우리는 여전히 전쟁에서 패배할 것이라고 생각합니다. 우리가 이 전쟁에서 질 이유는 우리가 사용하려는 기초적인 것들 자체가 망가져 있기 때문입니다.

TypeScript를 사용해 보신 분은 얼마나 계신가요?

아마 대부분이거나 최소한 여러분의 에이전트는 사용해 보았을 것입니다. TypeScript의 주요 설계 목표가 정확성과 생산성 사이의 균형을 맞추는 것이라는 사실을 알고 계셨나요?

여기에는 별표가 붙어 있는데, 그들이 실제로 의미하는 것은 '인간의 생산성'이기 때문입니다. 인간이 단 한 줄의 코드도 작성하지 않는 세상에서 설계했다면, 프로그래밍 언어의 핵심 계층에서 결코 하지 않았을 일들이 있습니다.

그게 무엇을 의미하는지 보여드리겠습니다. 코드를 작성해 볼 테니 무엇을 하는지 맞춰보세요. 꽤 안전해 보이죠.

이건 어떤가요? 심지어 이것은 또 어떻고요. 왜 우리는 정렬할 때 항목을 문자열로 변환할까요? 이것은 좋든 싫든 언어 자체에 스며들어 있는 슬롭입니다.

이건 어떤가요? 저는 TypeScript의 이 부분을 정말 좋아합니다. 그리고 아시나요? 제 에이전트도 TypeScript의 이 부분을 좋아합니다. 이것 역시 언어에 스며든 슬롭입니다.

좋든 싫든, 이런 도구들을 사용해서 빌드하면 시스템에 슬롭(slop)이 생길 수밖에 없습니다. 아, 죄송합니다. 잘못된 발표네요.

하지만 자바스크립트의 역할을 생각해보면, 자바스크립트가 등장한 이후 우리는 그 위에 시스템을 구축하기 시작했습니다. 커피스크립트를 만들었고, 그다음엔 타입스크립트를 만들었으며, 지금은 이펙트(Effect)를 만들려고 하죠.

그런데 문제는 그 기반 자체가 이미 엉망이라는 점이고, 더 나아가 우리가 코드를 작성하는 방식도 이제는 달라졌다는 것입니다.

왜 우리는 이런 식의 패치만 하려 할까요? 왜 좀 더 다르게 시도해보지 않을까요? 그렇게 하려면 아마도 완전히 새로운 언어가 필요할 것입니다.

그럼 BAML이 실제로 무엇을 할 수 있는지, 그리고 제1원칙에서부터 생각하기 시작할 때 어떻게 기초 단계부터 슬롭을 방지할 수 있는지 보여드리겠습니다.

코드를 읽지 않는 것에 대해 계속 이야기하고 있죠. 그게 정말 중요할까요? 자, 코드에 대해 생각하는 새로운 방식을 보여드리겠습니다.

모두가 당장 이렇게 해야 한다는 말은 아닙니다. 하지만 코드를 볼 때마다 말이죠. 웁스.

만약 코드를 볼 때마다 코드가 아니라, 코드를 시각화해주는 무언가가 있다면 어떨까요?

클릭하면 정확한 코드 라인으로 이동하고, 더 넓은 시야가 필요하다면,

확대하고 클릭하면서 더 흥미롭게 코드베이스를 탐색할 수 있을 겁니다. 잠시 실행되는 동안 다른 파이프라인을 보여드리겠습니다.

코드를 전혀 읽지 않고도, 저는 설정을 하고 에이전트 루프를 실행합니다. 왜냐하면 그 안에 의미론적 경계(semantic boundary)가 있기 때문이죠.

이걸 계속 확장해 나갈 수 있습니다. 그러다 '아니, 이건 너무 슬롭이 많아. 그냥 슬롭인 채로 두고 넘어가자'라고 할 수 있죠. 그래서 모든 코드를 이해할 필요 없이, 읽고 이해하고 싶은 부분만 선택해서 정말 중요한 순간에 정확한 라인으로 이동할 수 있습니다.

하지만 이전 파이프라인으로 돌아가서, 실행 중에 전체 실행 추적(execution trace)을 얻을 수 있다면 어떨까요?

우리가 모든 코드를 읽지 않는 세상에서, 코드를 이해하는 유일한 방법은 실제로 실행 추적을 통해, 그리고 프로그램의 특정 부분에 정확히 얼마나 많은 시간이 소요되었는지 확인하는 것입니다.

만약 파이썬이나 타입스크립트에서 모든 것을 추적해야 한다면 프로그램이 얼마나 느려질지 생각해보세요. 감당할 수 없는 일입니다.

가장 좋은 점은 첫 번째 원칙부터 시작하면 성능 비용을 사실상 0으로 만들 수 있다는 것입니다. 인간에게 유용할 뿐만 아니라, 어차피 에이전트를 위해 구축되었기 때문에 모든 파일에 클로드가 탐색할 수 있는 추적 시스템을 갖출 수 있습니다.

그래서 클로드는 버그와 오류, 그리고 비효율적인 부분을 찾아내어 사용자가 직접 하지 않아도 코드를 최적화하기 시작할 수 있습니다.

이런 방식으로 생각하기 시작하면, 모든 코드를 읽는 것이 아니라 인간으로서 자신이 작업하는 시스템을 이해하는 것이 더 중요해집니다.

그리고 우리가 만드는 도구는 작업 중인 시스템에 대한 정보를 제공할 수 있습니다.

하지만 여기에는 또 다른 층위가 있다고 생각합니다. 우리는 수십 년 동안 IDE 도구를 만들어 왔습니다. Vim을 어떻게 종료하는지도 모르는 저 같은 사람이 VS Code를 사용하게 되기까지 얼마나 오랜 시간이 걸렸는지 생각해보세요. 그날은 정말 아름다운 날이었습니다.

저는 진짜 프로그래머가 되었습니다. 음, 어떤 사람들에 따르면 제가 Vim 코드를 작성할 줄 모르기 때문에 여전히 프로그래머가 아닐 수도 있겠지만요. 그렇다면 에이전트 우선 도구(agent-first tooling)는 어떤 모습일까요?

우리는 모두 Grep에 익숙하니 그에 대해서는 따로 이야기하지 않겠습니다. 하지만 Ripgrep에 대해 말해보고 싶습니다. 왜냐하면 Grep은 어디에서도 사용되어서는 안 되기 때문입니다. 만약 제가 코드베이스 전체에서 Grep을 사용해 무언가를 이해하고 싶다면, Ripgrep으로 'calculate' 같은 것을 검색할 것입니다. 그러면 코드가 사용된 모든 위치를 보여주겠지만, 그것이 얼마나 유용할지는 알 수 없습니다.

하지만 대신 코드를 설명하면서 'calculate 함수에 대해 설명해 줄래?'라고 물어볼 수 있다면 어떨까요?

모든 독스트링이 함께 제공된다면 어떨까요?

실제 소스 코드가 함께 제공된다면 어떨까요? 그리고 내부적으로 사용되는 모든 곳을 알려준다면요? 예전에는 여러 도구를 호출해야 했던 작업을 한 번의 호출로 해결할 수 있게 만들 수 있습니다.

웹 검색을 할 필요 없이 사용 중인 라이브러리에 대해 배우고 싶을 때, 외부 라이브러리라면 무엇이든 바로 물어볼 수 있고 답을 얻을 수 있다면 어떨까요? 처음 코딩을 배울 때 제가 얻은 귀중한 교훈 중 하나는 코드가 항상 진실의 원천이라는 점입니다.

코드 그 자체 외에는 아무것도 읽지 마세요. 문서는 거짓말을 할 수 있습니다. 실제 설명이나 아키텍처 파일, 리드미(README) 파일은 분명 거짓말을 할 수 있지만, 특이한 아키텍처에서 작업하는 경우가 아니라면 코드는 거짓말을 할 수 없습니다.

그런 길을 따라가다 보면, 아키텍처를 이해하기 위해 코드를 읽지 않던 것에서 나아가, 모든 도구 호출에서 정확히 무엇을 얻고 있는지 이해하기 위해 코드를 검색하지 않게 됩니다.

하지만 그 다음에 무엇을 할까요? 코드를 진정으로 이해하기 위해 제가 마지막으로 하는 일은 코드를 직접 실행해 보는 것입니다. 그렇다면 당신이 실행하는 모든 것, 당신이 작성한 모든 함수를 즉시 사용할 수 있다면 어떨까요?

그리고 이 코드를 여기로 가져와서 간단한 CLI 명령어로 즉시 사용할 수 있게 하는 것입니다. 예를 들어 'add'를 실행하면, 'add'가 A와 B라는 매개변수가 포함된 CLI 명령어가 되는 것이죠.

그럼 아주 빠르게 실행해 보고 무슨 일이 일어나는지 확인할 수 있습니다. 만약 제가 가진 모든 CLI 도구를 실제 코드를 실행할 필요 없이 바로 실행할 수 있는 독립형 CLI로 압축할 수 있고, 함수가 포함된 전체 CLI 바이너리가 된다면 어떨까요?

갑자기 우리는 매우 빠른 도구를 구축할 수 있게 됩니다. 에이전트가 어떤 일이 일어나는지 일일이 파악할 필요가 없죠. 모든 것이 타입 안전(Type-safe)하고, 결정론적이며, 모든 것을 추측할 수 있습니다.

가장 좋은 점은 어떤 시스템에서든 구축할 수 있고, 에이전트가 윈도우, 맥, 리눅스 간의 배포를 걱정할 필요가 없다는 것입니다. 원하는 계층을 대상으로 지정하기만 하면 WASM 시스템을 포함한 모든 아키텍처용으로 빌드됩니다.

갑자기 엔지니어로서 엄청난 능력을 발휘하게 되는 것이죠.

더 이상 시스템 아래에서 할 수 있는 일들에 얽매이지 않게 됩니다. 아주 빠르게 움직일 수 있고, 에이전트 속도로 개발할 수 있습니다.