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 handwrite 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 will have 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:00 a.m., someone shipped a new design doc, three people started reading it right away cuz it's just interesting. Then, 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 and 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 were incredibly high quality. But what about the battle of architecture? You how do you have your code base converge? We built another tool. This tool basically visualizes our dependency graph internally with some external dependencies as well, and allows us to watch the code base 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 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 just 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 BAML programs. We take these BAML programs. 1 second. And we have agents try and spin something up from scratch. We then look at the entire Claude 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 aren't 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 to 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 data-driven systems without ever writing a single line of code. And the thing that really I care about the most over here