# How to build an agent that builds the culture โ€” Zach Bruggeman โ€” session 2026-11-12T00:50:00.000Z โ†’ 2026-11-12T01:10:00.000Z _68 transcript lines ยท 40 slides_ ## Transcript Yeah. Thank you. And this is your good. Yeah. Perfect. Alright. Good. Well, thanks so much for waiting everyone. My name is Zach, and I'm an engineer at Ramp. I'm just really excited to tell you all a bit about how Ramp has evolved. Engineering culture this year through the help of our robotic friend, InSpec. As a quick introduction, InSpec is Ramp's collaborative coding agent. About a year ago, we decided to take a bet on building our own coding agent with every session running remotely and being fully multiplayer. Inspect can work alongside you and your team, whether that be in Inspect itself, Slack, Linear, or any other of our integrations. And now it goes far beyond just writing the code with the built in design primitives, review agents, and verification. That let any builder go from prompt to shipping all inside inspect. Inspect is also connected with all of our integrations company wide, so everyone's automatically connected to the to the data and tools that matter most, whether that be telemetry, databases, or any of the other tooling available. Through this, we now see around 75% of all of the RAMPS code, being written and shipped by InSpec. When we started sharing InSpec publicly at the start of the year, the technology itself was the more Whole part, spinning up sandboxes in under five seconds, wiring up all that internal context, having agents work together in a multiplayer setting. People had a lot of questions about the plumbing. But now with much broader adoption of these concepts and Inspect itself now being a product on the market, the technology isn't nearly the barrier that it once was. Instead, I wanna talk about the other angle, the lessons we've learned around building a culture around InSpec and what you can take away to inspire the people and teams that you work with. I'm not gonna As much about those technical aspects of inspect today. But if you are curious about that, you can read our blog posts or take a look at Pragmatic Engineers deep dive that they did with us a few months ago. You can also follow my boy Dylan Garcia on Twitter. He's on a social media grind, but he's also been posting a ton of really great inspect insights, since we've launched it. So shout out Dylan. Please give him a follow. One thing about working at Ramp is that it really makes you start thinking about everything through the lens of saving time and money. And Though I think it is important to understand the systems that you work with and understand how your tooling works, if you're a multi 100 or multi thousand person organization and everyone has to go through, say, fifteen minutes of setup, once you start multiplying that across an organization, this is days lost for what is very rote work. Then, if you consider how fast the frontier moves here on best practices and new ways to set up an agent, you realize this setup cost isn't just one time. Not to mention These advancements won't always spread equally. So now you have an indeterminate amount of time and effort spent on this maintenance without an equal spread of knowledge, leading to disparate outcomes across an organization. Well, you can perceive this as an advantage on individual level. When you're trying to win, you need everyone on your a game. So this was our first lesson, build tools that kill information silos. When we found patterns that worked well or tools that benefited everyone, we could push it to our entire organization. Immediately. If you wanna spend time tweaking your own setup, that's fine. But inspect is always available as a very solid baseline. And what we found is that we've never needed to mandate usage of inspect because it existing as this baseline reduced the need for people to reach for their own setups all the time. Part of what I think makes this powerful as well is that the reality of this industry is that it's unlikely that you, as an individual, always know the absolute best way to work with agents across everything. Even if keeping up with us is your full time job, we all miss things, hold biases, and have blind spots. So part of the design of inspect is that there's just one single inspect for the whole company. When people figure out better ways to use it or have ideas for what would make it better for the work they do, we're able to bring it to the entire company. The best part of this is that for most changes, this is invisible to everyone else. You just keep using inspect as you normally would and benefit from the improvements that everyone's making. Over time. What we found is that we really don't have to run these formal sit down, here's how you use AI effectively training sessions for inspect. With every inspect session being public within the company by default, it's actually easier to work in public than in private. As such, you default to working in public, and you can learn how to use it by watching how your teammates use it in the channels that you're already in, and your teammates can learn from you. You can literally ask inspects to Through their recent sessions and tell you about how they work, how they structure prompts, or how they break down gnarly problems. I I think this has not just been helpful for the builders at Ramp, but also for the inspect team itself. We frequently see the way, that people use inspect in ways that we didn't originally imagine. This then informs what we should build towards, whether that should be more native primitives for common patterns or where tools and data are missing. All in all, it creates this self sustaining loop. Where we're able to build towards what makes inspect the most successful by seeing what people are already achieving with inspect. This feeds into the second lesson that we've learned. It's all about building trust. I think it's fair to say that adopting agentic driven coding has been a massive trust building exercise for every engineer this year. It's helped that the models have become more competent at writing high quality code, but there's a large part of this that's just learning to trust what an agent builds. So Much of building trust in tools comes from learning from other people. After all, that's why most of us are here. Right? You wanted to listen to people you respect, or at least I hope you respect, teach you about the things that they learned. But if we limit our corpus of knowledge to just those who find the perverse enjoyment in public speaking, we're still not getting the full picture. This democratization of knowledge sharing is just fascinating to me as a concept. Instead of grouping around a select few few leaders, can we build systems that inherently Share the knowledge of everyone. This is what InSpec has, built towards. Every time someone ships something with InSpec, people can see it right there on the work you've done. The session itself isn't easy to share. It's a living artifact of how that change came to be. When a pull request goes up, anyone reviewing it doesn't just see the 400 line diff dropped over the wall and hope for the best. They can see the exact somber... Conversation that you had, all the tools and spec used. Before and after screenshots or even a video recording of the verification agent clicking through the app in the browser to prove its work holds up. It makes it effortless to show not just what changed, but why you can trust it. It also just makes it easier to bring people you don't work with all the time into the fold. A fun moment on this one, it was back in February. One of our engineers, Andrew, reported a bug in inspect. So naturally, I reached for inspect and asked to investigate. What's Funny here is that, although inspect had access to Datadog for a while, we'd only just finished instrumenting inspect itself. I mean, inspect was primarily built by front end product engineers, so tracing is a little bit of a foreign concept for us. But in any case, it was a great time for us to put it to the test for inspect. And inspect says the instrumentation was causing the error. Yes. The very instrumentation that was letting us debug this error was actually causing this error. So Dylan and I were not exactly Convinced by the robot here. And Andrew is just like, whatever. I'll use quad code. And and while we don't have a mandate to use inspect, I mean, personally, these were not the words I wanted to hear. So nobody here is really trusting anybody. Dylan and I don't trust the robot's explanation. Andrew doesn't trust us to build something that works. And inspect, well, I I don't know if inspect trusts anyone, but that's okay. That's okay. But because this is happening Together in public, we keep prodding at it. Dylan asked inspect to look through the code of the telemetry library we're using and see if this was just something that was happening before without visibility. Because surely by now, coding has been solved and there can't be bugs that we introduced. And this time, it comes back with something a bit more specific. The OTEL library calls fetch, but it never reads or cancels the response body. This was just a CloudFlare platform limitation at the time, albeit happening in a library specifically made for CloudFlare workers. But Happens. This library was written pre AGI after all. At this point, we ask inspect to make a patch. It updates the exporter to explicitly cancel the response body. We grumbled in the thread a bit while it was deploying. But we see after it deployed, there haven't been any errors since. So great. Inspect fixed the bug, which at this point, it's nothing special in itself. But there was a much more important story playing out in this thread. Before Inspect, a report like this might have been acknowledged. To get filed, and then one of us would have gone away to debug it. Andrew might have received a message later saying it was fixed, but the interesting work would have been done in private. Now though, it's easier to do all of this in public. And as such, Andrew naturally starts becoming engaged, wanting to chime in with his thoughts and experiences. And then in that same thread, this leads to ideas coming up about how inspect could power other work, and none of this required any prodding or pressure to work together. Instead, it was just like, These guys are doing something cool, and we could work on it together. So in the span of an hour, we go from a skeptical user with a broken user experience to an engaged colleague wanting to build together and a more stable inspect. So once you have a tool that gives everyone the best setup on day one with no information silos and you've built a system of trust that brings innovation together, what happens next? This is the last lesson I wanna share. I think the only thing Is to think bigger together. Something that's pained me this year, is how much reverence has been built for the lone wolf operator. It's great that we can all do more individually with the help of AI, but this can't be the end game in my opinion. If we don't build outwards, collaborate with other people, and continue to share the progress and learnings we make, I think this is all gonna collapse in on itself. We'll only consider ourselves as our target audience, and we won't grow through the consideration above. There's perspectives and experiences. This is not to say I'm all doom and gloom about this. The fact we're all here hopefully is a testament to the value of connection. More importantly though, I think we can shape our tools to enable these connections to flourish even stronger than before. That story I told about Andrew has played out so many times within RAMP. It's probably the most inspiring thing about Inspectomy, honestly. Sure, it's a coding agent, but remarkably, it's become part of the culture. Everyone at RAMP knows its face. We dress it up on holidays. We throw in Easter eggs over time, and we evolve it as ramp itself has evolved. Not all iterations have been perfect as any ramp engineer could tell you, but I do think every iteration has been together. Going back to earlier this year, inspect didn't have nearly the amount of functionality it has today. Great example is its code review agent. Before this, we were using various off the shelf code review products, frequently rotating between them to find a Fit. At some point, though, a couple engineers, Daniel and Frangel, realized that we could probably build it ourselves as inspect already had automation triggers that fired from a variety of sources, including when a pull request was opened. With just what we built already, they got to work building another beloved agent at ramp review buddy. And what was so cool about this is that much like InSpec's own origins as a side project, these engineers were working on this. They didn't need to ask for permission to build it. They just Challenge themselves to build something better, used inspect to move faster, and quickly built an agent that was better for all of Ramp. This really did force us working on inspect to think about inspect differently. At that point in time, we were pretty okay with inspect quote unquote just being a coding agent. But once we saw what others were pushing it to do, it got us thinking about how inspects could become full circle. Circle. If this push didn't happen naturally, I think it would have taken Spec team a lot longer to get there. This is what I mean about thinking bigger together. Especially with the continued improvements in model performance, now's the time to push yourself and the people around you to think bigger. I encourage all of you to take some time in this coming week to ask everyone that you work with, what have we been waiting to do that we haven't done yet? And once you've found those things, try to build them together. There's really not an excuse to not just try. More. You have access to the same models as everyone else, but you have to start somewhere. And I believe that there is so much potential in unlocking wins, not just for yourself, but for the people around you. Inspect itself was born this way. Not only as something that I wanted to build and Jason wanted to build, but I would want to build something for a team that I truly love and truly respect, that would just make their jobs a little more enjoyable. Now if you'd like to use a coding agent that has embodied all these lessons That we've learned, I'm happy to say that inspect is now available outside of ramp. If you go to inspect.com/aie, we'll prioritize you and your team on the wait list. We're actually moving through this wait list pretty quickly, so expect to hear from us soon. But otherwise, I hope you've enjoyed hearing about our robotic friend inspect. If these topics interest you, feel free to reach out here or an x, but otherwise, thanks so much for listening. From building developer tools to exploring the future of autonomous software development, our next speaker has spent years. Pushing the boundaries of what's possible. Ladies and gentlemen, please welcome Steve Yeggi, independent AI advisor and creator of Beads and Gastown. Hey, everybody. Alright. Exciting times. Thank you. The room is really full. That's awesome. Thank you all for coming at the end of the day. I'm really excited to be here and to chat with you. I write a a u... A custom speech every single time. So this is... The speech was written just for you today based on talking to a bunch of you. I've been in the industry for about forty years. I worked at Amazon and Google for about twenty years. I've been all over the place, done all kind of stuff. And, and, for the last year or a little bit more, I've been independent and just kinda, like, playing. With, playing with software factories. Yeah? So, I kinda invented them. Right? On January 1, I launched Gastown. I don't even think we called them software factories back then. I think I called it an orchestrator. But I knew that I wanted Claude to run Claude. Right? And it turned out to be a little trickier than, than I thought. I spent all last year on it and I wrote... That's interesting. So I can't see my slides, but you can see my slides. So that'll work. So I wrote two orchestrators last Here. They were an attempt to make the LLMs smarter. Vibe coder and VC. You know, to do engineering stuff, like, you know, do code reviews and all that stuff. Right? Really, really bad idea. Just complete failure. I just built these huge monoliths. I was fighting the bitter lesson. Don't try to make LLM smarter. They will get smarter. And after a couple of months of this, although beads did fall out of it and beads was a really cool discovery, and beads beads is is life. Who here uses beads? A few. Yeah. Pretty good. Actually, pretty good. Yeah. We'll talk a little bit about it. Excuse me. And then I had Gastown, and then I had... In June, I had WheelHouse, which was my own, so I decided to build a a factory from scratch just to work on my video game. Right? Because, like, everyone's building factories to build factories. It's kinda naval gazing. It's kinda like, yeah. Right? You know, it's like, what? They're not, you know, it's, I think more people need to build stuff. Not just tools for building stuff. Right? And I and I think this is gonna be a theme today. Right? And and the thing is the one pattern that I've seen here is all of them go through a phase where the models get really excited and they build something really cool for you and then it just turns into garbage mountain. Every single time. It happened to Gas Town, it happened to Wheelhouse several times. I had to burn the whole thing to the ground a couple times. Right? It's almost like like every Model family, every model generation comes in and can build something that's just a little too big for it to handle. And then the next model generation comes in and goes, yeah, we're gonna have to burn that. Right? And I've... It's a pattern. I've done this over and over again, and I can tell you some things about it. But first, let me tell you about my game. It's a fun little RPG. I've been working on it for thirty years. It has players that started in 2001. So I literally have players that have been playing for twenty five years. They're still playing. Like, you can log in right Now I'm fine probably 10 people just screwing around doing quests, live quests, and and whatever. It's a it's a player, you know, the players contribute the content. Right? It's a mud. Like, they were really big in the nineties. ## Slides ### 00:00:06 # How to build an agent that builds the culture Zach Bruggeman / Principal Software Engineer ramp [https://ramp.com/blog/how-to-build-an-agent-that ### 00:00:31 # AI Engineer Code Summit ### AI Engineer Code Summit 2026 Corey Quinn / Chief Cloud Economist duckbill ๐Ÿฆ† ### How to build an agent that builds the culture Zach ### 00:01:03 # How to build an agent that builds the culture ## Chat Interface: Inspect AI Agent ### Conversation with Inspect - **User:** Help me show how Inspect re-shaped Ramp's engineering culture ### 00:01:31 # How to build an agent that builds the culture ### Screenshot of Ramp application: Card transactions [https://ramp.com/](https://ramp.com/) [Screenshot of a ### 00:02:03 # How to build an agent that builds the culture ## The technology was the novel part - Sandboxes in under 5 seconds - All the internal context, wired up - Agents working ### 00:02:35 # How to build an agent that builds the culture ## AI Engineer Code Summit Presented by Google DeepMind ### Slide Navigation - Intro - Kill silos - Build trust - Think bigger ### 00:03:02 # 15 minutes of setup - Search - Intro - **Kill silos** - Build trust - Think bigger - Closing 15 min 1 engineer 1 ### 00:03:35 # ...and it never spreads equally - Search - Intro - **Kill silos** - Build trust - Think bigger - Closing **1,000 hours** ### 00:04:03 # Build tools that **kill information silos**. - Search - Intro - Kill silos - Build trust - Think bigger - Closing ### 00:04:35 ## One Inspect for the whole company - Search - Intro - **Kill silos** - Build trust - Think bigger - Closing ## How to build an agent that builds the culture ### 00:05:02 # How to build an agent that builds the culture ## Kill silos ### Easier to work in public than in private - Every session is public inside the company - No "how ### 00:05:35 # A self-sustaining loop - Search - Intro - **Kill silos** - Build trust - Think bigger - Closing People build with Inspect Zach Bruggeman [ ### 00:06:03 # It's all about **building trust.** ## Presentation Sections - Search - Intro - Kill silos - **Build trust** - Think bigger - Closing ### How ### 00:06:35 # We learn from the people on stage - Search - Intro - Kill silos - **Build trust** - Think bigger - Closing ## How to build an agent that builds the ### 00:07:06 # Every change shows its work - Search - Intro - Kill silos - **Build trust** - Think bigger - Closing ### How to build an agent that builds the culture ### 00:07:35 # Every change shows its work ## Navigation - Search - Intro - Kill silos - **Build trust** - Think bigger - Closing ## Details - The conversation ### 00:08:07 # How to build an agent that builds the culture Zach Bruggeman / Principal Software Engineer **ramp** [Screenshot of a chat interface with a sidebar menu. The "Build trust ### 00:08:36 # How to build an agent that builds the culture Zach Bruggeman / Principal Software Engineer ramp [Screenshot of a chat application showing a conversation between "dyl", "Zach Bruggeman ### 00:09:03 # How to build an agent that builds the culture ## Zach Bruggeman / Principal Software Engineer ramp ### Chat Application Interface - Search - Intro - Kill silos - **Build trust ### 00:09:35 # Patch otel-cf-workers exporter to cancel response bodies ```js headers: this.headers, body }; - unwrap(fetch(this.url, ### 00:10:03 ## The interesting work used to happen in private - Search - Intro - Kill silos - **Build trust** - Think bigger - Closing ### Before - Bug reported - ### 00:10:36 ## One hour later - **Zach & Dylan** - an engaged colleague, building together - a more stable Inspect - **Andrew** - ideas for what it ### 00:11:03 # The lone wolf operator - Search - Intro - Kill silos - Build trust - **Think bigger** - Closing ## How to build an agent that builds the culture Zach Bruggeman / Principal Software Engineer ramp [https://ramp.com/](https://ramp.com/) [Diagram showing nine distinct colored circles, each surrounded by a dotted ring and three smaller grey dots, suggesting individual agents or operators] ### 00:11:36 # Build outwards instead ## Think bigger [Network graph showing multiple interconnected nodes, some large and colored, others small and grey] ## How to build an agent that builds the culture Zach Bru ### 00:12:04 # How to build an agent that builds the culture ## AI Engineer Code Summit Presented by Google DeepMind ### Agenda - Search - Intro - Kill silos - Build trust ### 00:12:35 ## Inspect already had the trigger - When - Pull request opened - Run - An Inspect session ### Presentation Outline - Search - Intro - Kill silos - Build trust - **Think bigger** - Closing ### Presentation Title How to build an agent that builds the culture Zach Bruggeman / Principal Software Engineer ramp [Flow diagram showing a trigger "Pull request opened" leading to an action "Run An Inspect session"] ### 00:13:04 # How to build an agent that builds the culture ## Presentation Sections - Search - Intro - Kill silos - Build trust - **Think bigger** - Closing ## Agent ### 00:13:35 # How to build an agent that builds the culture ## What have we been waiting to do that we **haven't done yet**? ### Agenda - Search - Intro - Kill ### 00:14:04 # What have we been waiting to do that we **haven't done yet**? - Search - Intro - Kill silos - Build trust - **Think bigger** ### 00:14:36 # Closing - Search - Intro - Kill silos - Build trust - Think bigger - **Closing** inspect.com/aie Thank you! X @zach ### 00:15:03 # AI Engineer ## Code Summit [Large screen displaying "Code Summit" surrounded by a grid of many small sponsor or partner logos] [Abstract dark imagery on a side screen] ### 00:15:35 # AI Engineer Code Summit [Grid of numerous company logos] [Large 3D letters spelling "AIE"] ### 00:16:05 # AI Engineer Code Summit [A large screen displays a grid of company logos, with "Code Summit" prominently in the center. Large 3D letters "AIE" are on the stage.] ### 00:16:38 # AI Engineer Code Summit [Event branding for "AI Engineer Code Summit" displayed across multiple screens, with a central screen showing "Code Summit" surrounded by a grid of sponsor logos] [Large 3D letters "AIE" on the stage] ### 00:17:07 # Code Summit ## AI Engineer ### 00:17:39 # AI Engineer Code Summit ## Keynote Steve Yegge / Independent Advisor & Creator of Beads & Gas Town Presented by Google DeepMind [https://codesummit.ai/]( ### 00:18:08 # Six orchestrators in 18 months - **Aug 2025**: vibecoder - **Sep 2025**: vc - **Nov 202 ### 00:18:35 # Six orchestrators in 18 months - **vibecoder** (Aug 2025) - **vc** (Sep 2025) - ** ### 00:19:05 # Six orchestrators in 18 months - Three years of accurate AI predictions - Gas Town: the first Software Factory - Today: my predictions and guidance for 2027 Escape from Trash Mountain - Steve Yegge ## Keynote Steve Yegge / Independent Advisor & Creator of Beads & Gas Town [Timeline showing six orchestrators over 18 months: vibecoder (Aug 2025), vc (Sep 2025), Python Gas Town (Nov 2025), Gas Town (Dec 2025), Wheelhouse (Jun 2026), Alamos (Nov 2026)] [QR code for live translation] ### 00:19:35 ## Six orchestrators in 18 months - **Aug 2025**: vibecoder - **Sep 2025**: vc - **Nov 20