EPISODE 1977

[INTRODUCTION]

[0:00:00] ANNOUNCER: AI coding agents can already reach well beyond the code in front of them. Through connections to tools like Slack, Jira, and Sentry, an agent can pull in issues, discussions, and production signals from across an organization. However, that context is scattered across many separate systems, with no shared map of how it all connects and no common controls over what an agent is allowed to touch. For a large enterprise, stitching that together while staying compliant, auditable, and sometimes fully cut off from the internet is a hard problem. 

GitLab runs one of the major platforms where software gets built, hosted, and shipped. That gives it a wide view of everything around the code, which shapes how it is approaching the agent era. The bet is that AI is most useful when it can draw on the full context of a project and stay under enterprise control, rather than acting as a point tool bolted onto a single repository. Getting there means wrestling with the hard questions about governance, agent identity, and how much autonomy to hand over. 

Tim Zallmann is the VP of Engineering at GitLab. In this episode, he joins Gregor Vand to discuss bringing AI to the full software development lifecycle, why running agents under enterprise control matters for governance and auditing, how to track which human is behind an agent's actions, the realities of shipping air-gapped software, and how the space is shifting as new players move into code hosting. 

Gregor Vand is a security-focused technologist, having previously been a CTO across cybersecurity, cyber insurance, and general software engineering companies. He is based in Singapore and can be found via his profile at vand.hk or on LinkedIn. 

[INTERVIEW]

[0:02:05] GV: Hello and welcome to Software Engineering Daily. My guest today is Tim Zallmann. Thank you for joining, Tim. 

[0:02:11] TZ: Thanks a lot for the invitation. Great to be here. 

[0:02:13] GV: Yeah. So you are the VP of Engineering at GitLab, a company, a platform that I think a lot of our listener base will know about. For those that don't, we'll definitely cover that soon as well. But as we'd like to do, Tim, you've been at GitLab actually for quite a long time. I think nine and a half years at this point. But when I did look at your LinkedIn effectively, I did see you had, I think, a gaming company for a while before that. I'd love to hear just what that journey was doing that and then transitioning to GitLab. 

[0:02:44] TZ: Yeah, happy to do that. Yeah, it's quite a ride at GitLab. I'm here for nine and a half years. I've seen the company go from 100, and I think I was 112 or so employee, and now we are at 2000-plus. And yeah, my career goes back I would say a lot of different stations. I, in reality, started programming at the company of my parents. I learned especially coding from my mother. This is where I started. I started in point of sale systems which was a very different area what I do now. 

One of my first things that I programmed professionally was an interface to a credit card reader in C. That's where I started. I then went very quickly. When I was around 18, I was a little bit naive and had this empowerment on knowing how to write software and started my first own company, which then literally fell into the time of where the internet started. 

I went there, I had a small agency at the beginning, which did a mix of websites, software development, classic stuff. I did a mix of small projects for small businesses to larger businesses, also across the world, a couple of remote projects. Around a year of consultancy work, so coding in the UK. So I spent almost a year in the UK on a couple of different projects for the DVLA, for example. I was the person who programmed the printing on text disks for cars in the UK back then. Yeah, out there working with large software enterprises, learned a lot on working in larger teams, which was completely the opposite of being a little bit of like a freelancer at the beginning and doing small enterprise stuff. 

But then went on, and me and another guy, we had an idea of bringing a board game to the Internet. It was the classic time of browser games. And we said, ""Let's just try it." We built something over a couple of months. We brought it to the German-speaking market. It was quite successful with over 200,000 active players at that time. We were almost in every newspaper and TV station. And you went to an electronic store and saw people playing on the computers, in the electronic store, your game, which was a really exciting time. 

And it's a completely different type of building software at the end of the day because you are much more creative. You don't have an exact plan maybe at the beginning. It's a lot about prototyping and then figuring out something while you are trying it out. And playing it is very different compared to, okay, here's the software to save invoices, which is very straightforward. 

And I think I learned a lot on having also there my own company. I had also another startup at that time, really driving a startup, building your own product, finding customers, having something that is successful. The other startup was not successful. You also learn a lot of things there. 

From there, I did another gaming project. But at some point, it was also I want to do something different again, because having a startup takes a lot of energy and takes a lot of risk at the end of the day. And I was looking at doing different stuff again. I was working for a couple of different startups here in Austria, advising them especially about building teams and building software that were newcomer startups. 

And at that time, I got connected to a group who were setting up for one of the largest banks here in the area. They were setting up an innovation hub, and I was hired there to be part of this innovation hub to rebuild their technical and digital strategy. And I said let's rebuild the online banking. And that was basically my last job. I built at that bank. As a group, we built a complete new banking system from the ground up. We were two people in a small room that started the whole project. And then this grew into becoming now - I think it's the online banking in seven eight different countries with more than 20 million users. 

And after five years, I left there, a couple of weeks before my first son was born, which was also an exciting time. And I was looking for something remote because I did a couple of remote projects before. I really wanted to see how far this has gotten. And I stumbled on Y Combinator over GitLab is looking for engineering managers. I just did a lot of engineering managers with a lot of people, a huge software project. I thought, okay, let's do this. I want to be closer again to an actual product and build things. That's what I enjoy the most. And that's how my time at GitLab started. 

[0:07:20] GV: I guess that was about, what, nine and a half years ago. And so remote. Companies back then still a bit of a unicorn to find those. Yeah, I've worked virtually almost remote my entire life. Luckily - well, I think luckily, and I'm one of the other very famously remote companies now. But yeah, GitLab has always stood out as like having that very forward-looking culture of remote, async, all that kind of stuff. Yeah, very interesting. Yeah, let's get on to obviously GitLab. For those that don't know, I mean, because we do have quite a breadth of experience age across all of our listener base, what is GitLab? 

[0:07:55] TZ: Good question. GitLab is, at the end of the day, a platform for building software. That's how I explain it to my in-laws and friends who were not in the software industry. It's a software for software engineers and software engineering teams at the end of the day. Going a little bit deeper, we are an orchestration platform for DevSecOps. This really means we want to be the platform where software teams can do basically every step from start to finish, from the ideation, to building software, to deploying software, to running software, to maintaining software. Anything that a software team needs should be part of this platform. That's our target at the end of the day. 

By now, of course, and that's what I'm responsible for at the company right now, is all the AI capabilities. So I have done - and over the years, I was responsible for DevOps, especially built out there, the CI/CD and plan and topics like that. And of course, also code review. And now AIs is becoming more and more important to be not just a point thing. So where you say, "Okay. Hey, agent, tell me this," or, "Agent, write this code." We want to also enrich the platform everywhere with AI so that you have AI capabilities across the whole SDLC, everywhere in each step. 

If this is literally just your first steps in AI, basically, I think where a lot of our customers start is not writing code, but getting code reviewed by AI. Or if you go to full autonomous, where everything is fully automated, that's what we want to provide at the end of the day. 

We have built this platform over the years we've really this focus to enrich especially also the secure area. I think we are quite strong in that part. We have security scanners. We can tell you and test code. And I think this is super important for enterprise customers. And that's also our main focus. Our main customer base is in enterprises, especially also large enterprises. 

And one of the specific things that I always say is a huge advantage for us is we provide a self-managed solution. You can literally download a version. You can install it on-premise. We have even customers who run it completely air-gapped. So without any internet connection in very high secure areas. Which is great, because this provides customers, first and foremost, an environment that they can control, which is, I think, very important both from a reliability standpoint, but also from a data sovereignty standpoint, and also from a standpoint how they can adapt the platform and the solution around. 

And we have millions of users across the world. We have thousands of installations that run self-managed. But of course, it's also quite a complex thing to run on-premise software. You have different versions. It's not us that upgrades a version. It's the customer themselves. And I think this is also super important for our engineers who started GitLab to learn exactly this kind of setup and have an understanding on what's the difference between running something completely cloud-based, where you deploy, it's fixed for everyone, versus, "Oh, this person is running a two-year-old version. How do you get them to the fix that you have right here in the hand?" 

[0:11:05] GV: Yeah. I guess for someone like myself, I've been in software, what, about 15 years at this point. My perception, I guess, originally was GitLab is sort of "the open source GitHub". That was sort of how it maybe came on my radar. Is that fair to say that was the origin story as such? Or there was probably more to it than that. But if someone asked me, what is GitLab? I would have often thought, "Oh, I think it's the open source GitHub, basically." 

[0:11:31] TZ: Yes, that's exactly where it started. I think the base where we are coming from is open source. We are still up today. We are a completely open core company, which means you can look at the source code. We also have tons of contributions, both by the community, but even by customers. So companies who say, "Okay, hey, I want to have a certain feature, a certain capability. I'm going to co-create." 

So we have teams that work directly with engineers from the customers who have the capability to build something to the product, which I think is super valuable for enterprises. Because normally if you are buying something closed source, on one hand, you have no idea what's really happening in this black box. Then on the other hand, yeah, you can send somewhere your wishes. But I think with an open core, you can have much more influence on a certain thing. 

We have also customers who live in very specific and niche industries or have very specific setups like embedded software development. So they need to test on devices. And I'm literally speaking about hundreds of devices after a build is done. And building and having then a certain feature that can give them the capability to make their life easier and having this capability to build something the product I think is really awesome. 

At the end of the day, what we have then done is we started of course from the whole git topic and source code management. And very early on, it was like we married it with CI/CD. I think this was also one of the big plus points that we had early on. We went in especially, I think, strong in the code review part. We expanded in planning. We expanded in the security area to really provide these capabilities in one platform. 

And I think, still, we have customers who have tens of thousands of engineers and thousands and tens of thousands of active projects that they are running, compared to, "Oh, I run my three projects as an individual," this is a huge, huge, huge task. And of course, if you have then the capabilities to have a self-managed platform where, of course, your engineers can be steered in the sense of how their setup is much more, and on the other hand you have also the capability to add more features, I think is a really cool thing. 

And now what we are doing in reality is exactly expanding our platform towards these kind of customers and their needs. Which means one of the big topics for AI of course is always context. We can bring much more context to agents than just the source code. If you're running a CLI, if you run it locally against the check.code, it's the code. Maybe you can search on the web. Maybe you can have an MCP to access something. 

What we provide is literally that you have access to everything that happens to the software project. That literally means if you're using our planning tools, we have all the issues, all the discussions around the issues, the designs, the epics, the relationship between topics on top of that. But we then also have like how did the tests run? How was the build? How was the deployment? Where is it deployed? Which cloud does it run? Et cetera, et cetera. We can even go and bring in observability data and allow the agents to access exactly these kinds of information. I think bringing this context together in one platform has a real benefit and especially also in the AI space. 

The other big part is the whole governance topic. Enterprises and large organizations always have the topic of control and being compliant to whatever regulations they are in. That means that they can control what agents can do, what their users can do, who is capable of doing what in a very, very fine-grained control. Because you have customers who are like, "You can't do this." And the next customers, "You can't do this." And we need to build features that allows them to do both. 

And on top of that, also the whole audit part that you have an understanding of what's going on. Because if you have 15,000 engineers who are doing stuff every day and 24 hours a day, you need the capabilities to observe this, understand what's going on. Now with AI, even more, in my opinion, because people suddenly have additional teams that do stuff and sometimes do crazy stuff. 

And I think this combination is super important and is really also one of our focus points that every feature that we build we are able to provide exactly this kind of context enrichment, the governance part and also this audit part. And this has become what GitLab is in my opinion today. 

[0:16:04] GV: Yeah. So this is a good segue. I'd love to talk about two, I guess, products within GitLab. We'll get on to the one that's been released quite recently. I think it's even in sort of beta stage at the moment, which is Orbit. That has been preceded by Duo. And I think if we could just talk a bit about what is GitLab Duo, I believe that is everything that - I guess from the AI and agentic perspective, that was the first big jump in there. 

[0:16:32] TZ: Yeah, I'm always very excited to talk about Duo Agent Platform. That's the main topic that I'm responsible for and my teams are building since quite some time. The vision at the end of the day is really to bring AI to the full SDLC. And that's exactly what we wanted to do, also in the same way as we are doing CI/CD. What does this mean? So we have started also as many others with the classic AI thing of add something here, add something there. But very soon we thought, okay, let's build something that is extensible and allows people to run agentic stuff at any point in the SDLC. 

That means like someone creates a new project, start an agent to fill the project with the baseline and do the right settings. If a work item if an issue changes its status, then kick off a certain agent that looks at all the compliance stuff, etc., etc. And allow this in a way in the same way as we have built CI/DC to build also custom capabilities. Customers are able to build so-called custom flows, which are flows are the combination between agents and deterministic steps, because this allows you to run things with a very clear target. You can also run stuff cheaper. Because at the end of the day, on one hand, deterministic steps like running linting, running tests is not on only one hand. It's binary. The outcome is binary, which is, I think, very important in the AI space. But on top of that, also in a lot of cases, it's much cheaper than having an agent try to figure out something, how to run something. No, it's very straightforward. 

So we can combine these deterministic steps also with agentic setups. And with agentic setups, we have the whole topic of having your own problems. We can have subagent that run on different models. So the two agent platform is also completely model agnostic, which is following exactly this kind of overall strategy of self-managed. We also extend it into the AI space, so you can run literally the whole Duo Agent Platform against any model that you run to some extent if it's capable enough, of course. But we have customers that run it with their own models on premise that run their own commit on GovCloud and stuff like that that allows them to have then also in the AI space a very clear and distinct ownership of their data and how this data is used and where it's going or where it's not going more specifically. 

And Duo Agent Platform allows you to exactly run these agentic things. What does this mean? On one hand, we have the so-called Duo Developer Flow, which, for example, allows you that you can simply mention a Duo developer in any comment in an issue, in a merge request. We are also working, for example, to extend this into other surfaces and simply say, "Hey, implement -" for example, in a code review, if another human or if the AI code review, you have went through all the comments, you simply can say, "Hey, Duo Developer Flow, please implement these things for me." Or that automatically we can kick off that if the pipeline that just ran on NMR is red, we can automatically kick off a flow that tries to fix the tests and fixes the pipeline for you. 

We can also run a flow that is super specific to you, which is running maybe at six o'clock in the morning to provide a standup information. So that if you go then in the morning standup, that you already have an info that has collected all the data from GitLab issues, from your merge requests in GitLab, but also it has received all the information maybe from Incident.io and from Sentry how the stuff is running in production that you have just released. 

That is, for example, something that you can set up with a custom flow, you can add skills, you can add MCP. And this combination between triggers and running something allows you that. We have a lot of foundational agents and foundational flows. This is basically what we provide out of the box. We have a very straightforward AI code review, which is also, I think, a very cost effective setup that you can run. We have fixed pipelines. We have the developer flow, which can implement stuff very autonomously, et cetera, et cetera. We have security vulnerability topics, where if a security vulnerability comes in, it's automatically resolved and goes from there. 

We are now going at the moment in the direction of automating this more and more. For example, one of my teams immediately, if a bug report comes in from the field, from a customer, from internal, a triage spot goes in, looks at the issue, tries to gather all the information around it, tries to reproduce it in its VM, is creating then a video of the reproduction. And based on certain criteria, it will immediately go and try to implement a fix for it. If it is able to create a fix for it, it will again screen record the fix before and after, post this into the merge request. 

So in reality, if this was reported overnight, our engineers come in, see the bug report, see all the triage information, have already a corresponding MR, see the video even. They don't need to check out the code anymore, and can go immediately and approve and merge the fix for that bug fix. And that's how we see that we also get to a much higher level of - I call this no touch, where engineers work much more with agents in the platform directly. They do a fire and forget. They hand this over to an agent. The agent setup, works on this until all the pipelines are green, all the internal AI review is green, et cetera, et cetera. And then they come back to you and say, "Hey, look what you have requested me to do. Here's your merge request. Here's your result. Here's the video of it. We ran all the tests. We ran all the pipelines. All the screen should be ready to merge." And that's where we are currently transitioning and expanding exactly these capabilities towards. 

Coming back to also this huge add-on that is currently in beta phase to GitLab itself, which is Orbit. It is a knowledge graph across the whole SDLC. So it's a knowledge graph that both indexes everything, all the information that we have in the platform itself down to the code. So we can build relationships between these things on existing data. We're using the same data access setup that you are currently using, so the knowledge graph has only the same information that you would be also be able to see as an end user. But you are able to provide this access then to agents. And the agents, through that, can have a much quicker capability to understand relationships without going to each file and looking at it and, "Oh, here is a reference." 

And what we have especially seen also in evaluation, agents have the tendency to be very happy if they find something, and then be like, "Oh, I found something. I should be done to some extent." But of course, if you have huge monoliths, which are multi-gigabytes, and we have that, customers have this, this might mean there are 10 other references where this function that you are currently changing are used. 

And this knowledge graph gives the agents, but also you at the end of the day, the capability to see, "Okay, here's a function. Where is this function used across my project?" And now comes a magic trick that I think we can do, but others have a much harder time, because we not only have that one repository, we have all your repositories of a company, which might literally mean - I know some customers who have 50,000 repositories. If tomorrow there is a CSV come in and says, "Hey, there is a security problem with dependency ABC," this is where orbit can shine, because you can literally go in and ask the agent, "Hey, where do we use this dependency in this version?" And it can literally give you an answer in seconds because it's able to query against all your projects, build a query and ask basically all repositories and find them immediately, which run this dependency on that exact version. 

And this is where I think Orbit has these capabilities that you can't do if you just have a repository on your local machine with your CLI. And this goes way beyond this. This really goes also on issues, MRs, merge requests, CI pipelines, etc. So we can expand these use cases the more we index also around blast radius and figuring out how we do dependency upgrades. 

The other nice thing on the coding side is also that - I mean, almost every project, even if it's not microservices, but always consists of a lot of repositories at the end of the day, which is then also becoming quite hard for agents to understand, "Oh yeah, I'm using this internal UI component library," but the agent itself doesn't have access to it. It might not be published on NPM. It's complex. 

And with the knowledge graph, we are able to reference a local knowledge graph with a remote knowledge graph on your instance and can connect the dots there. And we can literally find the source of the function that you are using in that dependency in your exact project. And this combination is again really going in the direction of expanding the platform and giving you not just point AI solutions for coding or for a review, but allows you to do especially everything that engineers do across their day at the end of the day. 

[0:25:50] GV: Yeah. So my understanding is, as you said, it's very much graph based. And that's sort of almost being positioned instead of RAG, effectively. So what was the - does that sort of contribute to this? You can do magic that those can't. I mean, and also just actually looking at what does it do exactly, which is ingesting software development, lifecycle data, and then probably via change data capture into ClickHouse. And it can parse through 12 languages on that basis. So yeah, just taking those two points, what does that do differently, I guess, to those that are thinking, "Oh, can't we just do this with RAG, effectively?" 

[0:26:28] TZ: Yeah. There are certain use cases that you can also do with RAG and agents. They simply need to look a lot of times. And they need to look very specifically to find everything. What Orbit does at the end of the day is it indexes the existing data that already exists today in GitLab, and it indexes on top of it all its references. The easiest example is epics. So if it indexes an epic, it knows all its child items. And from the child items, it knows all the related items. So this might be an item that has been mentioned in that issue that specifically has been related. 

And from these issues, it's basically then, "Oh, for each issue, I also know the merge request. And from the merge request, I know the diff changes. And from the diff changes, I know which function has been changed." And it creates this graph of relationships between everything that we save in GitLab, also with the code that you save in GitLab. 

And the agents get access either through predefined queries. So we simply say, "Okay, this is what is connected to this issue," for example. Or, and that is where it can really shine and is, I think, the most interesting use case at the moment, we give them the agents access to retrieve the current schema and to write queries against it. 

So the agents are capable of writing any sort of query on the fly against this knowledge graph. So they are capable of traversing. They are able to find all the relationships. They can find similar things on existing data. And that allows then the agent to have a much better understanding what they actually need to take a look at. 

For example, if we tell the agent, "Hey, this file that you have just looked at, this is being referenced in these seven other files." It has an immediate pointer in reality rather than using grep, or using then read files, or looking at directories, where often simply things can get missed to some extent by the agents. Or it takes a very long time because it's literally to some extent, brute forcing what agents then start doing. And instead of the brute forcing and some sort of search, it basically gives the agent a map into their hand. 

And through this, we can reach certain use cases that I think are not possible without Orbit, which is especially around these kind of wide-reaching statistic analytic queries and use cases. And on other aspects, it's literally about precision because you can make sure that all the seven references are literally listed and the agent knows to take a look. And this allows basically the agent to write these kind of cipher queries. All the data is stored in ClickHouse and is basically made available then on the fly through this query building. 

[0:29:25] GV: Yeah, very interesting. And I guess from a just pure product perspective, it is actually available, I believe, over OpenMCP to Claude Code and Codex. It's not completely tied to Duo. What were the kind of thoughts on that one to just not keep it as a pure GitLab thing, I guess? 

[0:29:45] TZ: I mean, it's a little bit also we are not naive in the sense that people just use GitLab and nothing else in the world. This has been always the case. People have still the tendency to use Jira for planning and project management, which is, I think, one of our longstanding topics that customers use Jira for the issues. And we need to figure out how we can connect certain things. 

And I think we are trying to do the same thing on the AI space, which means we see Duo Agent Platform as a platform, which means that we are open to others, we are open in multiple directions to allow customers to bring in other agents. So into agent platform, you can use our Duo Developer Flow, which is tight and gets the right context around what's doing. But you can also run Claude Code to implement something automatically in the platform as a runner job, etc. And we have a full setup for this. We call them external agents. We also support Codex and others. 

But we also want to support if you have a certain setup in the aspect of Claude Code. And we allow you to access data through MCPs. So we have an official GitLab MCP server, which is very close to going to GA to access base data in the classic way of MCP. But we also expose Orbit as an MCP gateway. And right now, in the beta, it's also available to try out directly. And it's in an early beta phase at the moment, Orbit. But it will be expanded and there will be these capabilities to support also simply other setups. 

[0:31:16] GV: Yeah, exciting. Just switching gears to a slightly different part of, I guess, the product stack, dedicated AI gateway, which I believe also more recently it's now that a customer who have their own single tenant can actually - they can bring their own model to that. How has that product, I guess, evolved? I feel like there are not just ends of the, I guess, the space that GitLab's in, but a lot of people are producing AI gateways, effectively. And so what kind of was the initial inception reasons of the GitLab one? And then what does it mean when now someone can actually stand up on their own tenant as well? 

[0:31:54] TZ: Yeah, great question. And I think this is something super interesting about the agent platform in general how we allow you to bring in also models. In general, if you use Duo Agent Platform, either on .com or through your self-managed instance, the default is that it will connect to our AI gateway that we run. It's a multi-tenant gateway. You access the models that we provide to you. So you don't need to take care of having contracts with multiple different model providers. So we support different models, of course, from the frontier side, but also there are other models that we will be able to provide. 

So the default is you simply connect it to our multi-tenant AI gateway. You get everything out of the box and you can get started. But as mentioned as before, we have a lot of customers for very different reasons that want to use other models that they run on their own premise, that they have under their own contract, et cetera. And this is where we allow you as a self-managed customer to also run and self-install an AI gateway. 

Because of course, if we would go from the self-managed instance, go then to an AI gateway that sits somewhere in the cloud and then come back to the model that might be running on your premise, that's a very far ping-pong at the end of the day. And that's what we are trying to eliminate by allowing you also to run your own AI gateway. And especially on top of that, to support an air-gapped environment where there is no connection to the outside world. 

And exactly, we have this functionality already since quite some time. And we have a lot of very happy customers that are running these kind of custom model setups. And now we are bringing this to Dedicated. So Dedicated is our solution a little bit in between .com and SaaS version and self-managed. It's a single tenant version that is managed by us for the customer. 

And there we have now expanded, of course, because customers are also requesting there, hey, we would like to connect to our own models. And this is exactly what we have brought now to GA, where people that have a dedicated contract and are having a dedicated instance are now capable of also simply saying, "Hey, I want to have now a single tenant AI gateway that I then can connect to whatever model they might have." And I think it's very cool because it really allows you this kind of flexibility. And the landscape in AI is moving in a crazy speed, but really allowing you and giving you this kind of flexibility for whatever reason you might have, I think is a really cool thing. 

[0:34:39] GV: Related to this, also related to everything we've been talking about so far, like Duo and Orbit, it's I guess agent identity piece. And I think it's something I'm working on as well where I am. And I think you know everyone's got a slightly different take on how to distinguish an agent acting on behalf of a human. And curious how you guys have looked at that. Sort of how do you represent that? What sort of guardrails are you thinking of or put in already in terms of ensuring it's very clear who or what is taking the action on behalf of them? 

[0:35:11] TZ: Great question and a huge topic for us, to be honest, because customers that we have - and based on their regulations on exactly where they are working and how they are set up compliance-wise need a very clear capability to configure stuff in detail, but they also need a very clear understanding. How did this come along? How did this happen? 

And we have a multi-layered approach on the AI side, especially around the identity. We are doing something that is called - to make it very simple, is the composite identity. Basically, we have a so-called service account, which is the account of the agent at the end of the day that is running. But we always attach which user has started. This task that the agent is executing at that moment of time. 

Especially, as we are going down the lane, as we talked before, around this kind of no touch code, where it's literally you create an issue and you hand over the issue to the agents, we create an implementation plan. And that goes off into implementation. This is autonomous, but it's still that someone has started this kind of work. And we want to know and understand at a later point very differently compared to the changes that you might have made in a chat where you said, "Hey, change that." And I approve this myself, the code changer, the creation of a certain issue. 

And this is also exactly where this composite identity comes in because it allows us afterwards to track back that, "Okay, this has been run by this agent with this setup, but it was initiated by this user." And this is also then what we are allowing as a fine-grained control. And this goes in the direction of tools so that we have the capability to say, "Okay, this kind of agent is only allowed to use these tools, and they need approval, and they need approval all the time," which is something we are currently building. Or these MCP servers are the specific ones that can be used. And this is locked down up to the level of skills, for example. 

We have a solution that allows you, as a administrator of the platform, to simply say, "Okay, these skills are available, and they are even digitally signed," so that you can't tamper around or someone else can't tamper around and change these skills over time easily without that our execution engine, our CLI would know about it. And I think these are really cool features, especially for these kinds of setups with enterprises. 

And the other big topic is where we are, I think, a little bit different compared to others in our setup is that everything that is executed in our platform, even the local code changes, for example, or the local workload is always built up and executed on the server. Because this means that we have a very high level of control on the governance side versus something that just sends LLM prompts to an API. 

Because we send just a question and then the actual execution of the LLM loop in that sense is happening on the server, which means we can ensure certain governance, compliance, auditing trails. And on top of that, this means that every session that you run, is it either in the CLI, in the IDE plugin, in the web-based chat, in an autonomous platform flow, is always creating a so-called two-agent platform session. And these sessions trace and track everything, every message that comes back from the model, every tool call, every approval. And that goes then back also to who has approved a certain thing. And that allows you on one hand this kind of auditing capabilities, but then on the other hand, also the capability, which is also quite nice, which we are currently working on is that you can move workload from local to remote and from remote to local, for example. 

And on top of that, we have the capability to have across all your users as a customer to have a good auditing insight. So you know how many times a certain agent that you have maybe built internally has tried to find an API key or has used a certain tool and so on and so on. As the overall company, you can then control also what is capable and what is possible for the end users and what is not possible, what is possible for the agents and so on and so on. 

I think this is a really cool combination that allows us this kind of traceability. Also, months later, after an agent has written a certain code or has done a certain change, that we can go back in time and know this user on this time with this model. Here are all the steps. Here are all the tool calls. And that's how this code came out or basically this much request came along.

[0:40:10] GV: Also, switching gears, but something you mentioned at the beginning that has always interested me is you talked about air-gapped that people run, which I think is especially in this context because GitLab can be run on the customer's infrastructure effectively because it's a open core model. What challenges, I guess, does that present? How has GitLab - I read a very interesting - I can't remember actually which company it was, but it was another company that talked about all the steps they had to go through to make their platform air-gapped effectively, because it meant basically getting a contract with a big government entity. Was this like a very conscious thing that GitLab has done to make changes that mean it can be air-gapped or was it like a customer has adapted it that way? 

[0:40:54] TZ: I think there are two different angles around this topic of air-gapped. I think air-gapped originally came simply and happened to us. Because on one hand, of course, we had self-managed, and that was always the target and was from the beginning on. But by having the capability of self-managed, then of course, customers who want to be air-gapped or need to be air-gapped said, "Oh yeah, GitLab could be a great solution for us because they have a self-managed version." Do you really focus on this? I mean, still, today, our majority of revenue comes from self-managed. They have not disabandoned it over time, because I know also a lot of our competitors had self-managed and at some point, said, "Oh no, everyone needs to move to the cloud." We have a high focus on it. And this is how we then took the next steps of really getting into a version that doesn't connect anywhere, that doesn't need to ping someone, has no ties to download something. I think these were especially the first steps. 

But what is important for my engineering teams and especially people who started GitLab is to have a clear understanding what does this mean in your day-to-day work. Because at some point in the month, we will cut a release. This release is put into a package. And this package is then picked by a customer. And that might be what they are stuck with for a couple of months. So this means it's not that they will simply update in the next month when the next version comes along. They will upgrade. 

I know a couple of customers who are still on versions that are quite old. And I'm not talking about months. I'm talking about years. And this is something that when you are building software, it's really important to understand this. And I think this is also something we had as a learning over time. And we struggled at some points also with it. But I think we took the right learnings out of it. 

So one big learning is definitely breaking changes. Because it's not only that they need to upgrade, but they also need to be capable of doing the upgrade very smoothly and nicely. Which means that if you have a lot of breaking changes, and this thing gets stuck on database changes and they need to roll back and so on, this is becoming very painful for the customer at the end of the day. So we have brought in more policies over the years to reduce the amount of breaking changes to an absolute minimum. 

We have a very clear guidance that we only do it on the major version. We have once a year a major version. Certain things need to be announced six months or rather 12 months ahead of time, and so on and so on. And I think this is then also going into the direction of quality and testing where this becomes very different compared to a pure cloud service. Because you are not only running the one test In one environment, you need to run it in different environments with different setups and with different settings. 

And exactly as you mentioned, air-gapped, then not having the capability to do a certain thing. And some person forgets about it and simply says, "Oh, yeah, we just download this image from somewhere." And the customer comes back seven months later and says, "Hey, why?" Because then they have upgraded to that version and simply say, "Hey, why are you downloading something? 

And this understanding, I think, is really important for engineers and also the product teams and so on, is that you're creating something that might only be hitting the machine of a customer in four months, and then you figure out what's going on. Quality is really important. Having that kind of mindset is really important and understanding all the different configurations and setups that customers might have. 

And to some extent, the only thing that we can provide is a so-called reference architecture for different sizings of customer bases. But it might be that they run this on different hardware. They run this on - and I still remember, this was many years ago, but I still remember where a customer was running their Git part, not on SSDs, but rather on classic hard drives. And was really surprised where everything was super slow with a couple of thousand users that were hitting that Git server. So you don't have it under control. I think that's really something that is very different to the SaaS or cloud-based development. And I think that is a huge complexity, but it's also a huge advantage because, yeah, this is a market for us. 

[0:45:18] GV: Yeah. Just briefly, is there a pattern of industry that is very - government seems like the obvious case, but others that sort of seem to need to air gap things or want to - 

[0:45:30] TZ: Yeah, I think government and high security topics are the classic ones on the air gap side. I think, also, there are certain industries like automotive, for example. There is a lot of proprietary software that has never hit any sort of open source or GitHub or anything. And of course, they also don't want to, for example, send that kind of source code to AI models. 

And any sort of security financial software, of course, is huge. I think what people are always surprised is about our customer base. I think it's simply not just software companies. All kinds of companies are building software nowadays. And I have a huge department and a lot of people building software on a daily basis to run their business, to provide software to their customers, to build and run their products. And I think this is also then again where this kind of air gap comes in. We also have customers who do both, who have an instance that is not air-gapped and an instance that is air-gapped for more security for some projects. And I think this is also possible at the end of the day. 

[0:46:41] GV: So sort of as we're starting to cruise to the end of the episode, I'm curious about what the feature holds as always, but something that has popped up in the last few weeks is the fact that, for example, Cursor are actually coming into this space as well. I can't remember the name of it, but they're saying we're coming into the code repository space. How do you see the ecosystem evolving over the next, I don't know, two years on that basis? Yeah.

[0:47:09] TZ: Yeah, I think that the speed and amount of change in that space has never been higher than in the last couple of months or one and a half years in reality, in my opinion. And yeah, I think it's really interesting to see how companies are pivoting at the moment and moving also into other spaces. And I think, yeah, Cursor, seeing them move into origin and their code hosting platform is an interesting one. 

Again, I think we are to some extent competitive, but we are also very much complementary. We are doing partnerships with Cursor and others to see that we have a good integration of GitLab in their tools. And we're also looking how we can bring agentic stuff to our partners and vice versa. And I think Cursor is executing very well and they are moving fast and evolving, especially also their capabilities. But we want to see that we can provide. And I think we are very well positioned, especially in the enterprise landscape, to provide a full platform. 

And I think code hosting, this is exactly where we started many, many years ago and have expanded in way more areas and understanding and learning how enterprises at different types of time work and also how they work internally is where we can provide a platform that caters to exactly their needs. 

And I think, yeah, if we see more movement, it's interesting in that space. I think we have also changed a lot to be able and capable of moving much faster and pivoting to certain aspects. I think we are very well positioned not only on the classic platform, but also the AI platform that we have. I think we are making really great progress. 

I'm really excited to see also, especially my teams, use these capabilities, as mentioned before, where we are capable of bringing AI capabilities to things that no one needs to think about anymore, like creating a standup report, creating a status report. We have every status report. And everything is currently completely automated in my department. 

People don't need to spend time on these things anymore. And improving tests and reducing tech debt and really rather focusing on creating real forward value and building these things. I think we are set up, yeah, really nicely on our side. Yeah, I'm looking forward to competition at the end of the day. 

[0:49:38] GV: Yeah, of course. Just to sort of round out, I'm curious if - you've been at GitLab, it's a relatively long time, but almost 10 years, I think. And something I'm actually going to just say maybe from the last couple of years, especially through this huge changes that we've all been going through in all of our companies, but something big that you, I guess, have changed your mind on in the last couple of years, like two years ago, you're like, "No, this is the thing. This is just never going to change, or this is how I think about it." And today, that was wrong, 100%. 

[0:50:07] TZ: Yeah, I think what has completely changed is the landscape. Exactly what we just talked about. I think if you look back maybe just two, three years, our main competitor is GitHub, and looking at Jira and topics like that. And suddenly, there's much more. The space is moving much quicker both from competitors, but also from the technical aspect what would be or what is possible I think is super important to understand. And make good judgment calls to not just hop on every new trend that might be over anyhow in 10 days, because that is the next thing. 

I think this kind of change from the outside and not having much more time to think something through and develop, I think this has completely changed. And the sense of urgency is super important, but you also shouldn't over-index, in my opinion, on it. 

My department was - literally, I changed my complete setup one and a half years ago. We flattened the organization to be much closer to each other, have much more direct access to things that - especially projects in AI. In the past, a feature was developed in one team. You have the code review team, they build a code review feature. Then they build the next code review feature. And suddenly, GitLab needed to change to be much more. We have clients, we have AI clients, we have the IDE plugins, we have the CLI, we have web agentic chat. But on the other hand, we have also the gateway, we have model providers, we have things that change outside. We need to be much lighter and quicker to move and pivot and adapt to certain things. And I think this was something that completely changed how we planned and how the whole process works. 

And overall, I mean, in nine and a half years, this company, of course, with the size change and the scaling, has went through a couple of changes. We had also recent changes, which is exactly to adapt the business on the environment that we need to work in and compete in. And I think they are exactly adapting our business towards that and getting us into a setup that allows us to do stuff quicker. And I enjoyed it. Yeah. 

[0:52:19] GV: Yeah. I mean, it's been - yes, it was sort of fascinating to hear from the inside. Yeah, just like what's going on at GitLab and what the future might hold. So yeah, as someone working in a fellow remote ASIC company, yeah, I've often looked at GitLab in the sense of really being inspired by you guys have a lot of open documentation around how you work together and all that stuff. And so, yeah, again, I think one of the pioneers of that, which was, yeah, I used to run a fully remote company back in the day and there was a lot of inspiration back then as well. 

[0:52:46] TZ: That's great to hear. 

[0:52:46] GV: Thanks so much for coming on, Tim. Obviously, where's the best place for someone to go and just get up and running at GitLab? 

[0:52:52] TZ: GitLab.com. Go and try it out. It's very easy to set up an account. We also have trial accounts, especially to try out all the AI features and more advanced capabilities. Take a look. We have just released our complete new CLI with a complete new agentic loop. We allow you to access all these capabilities directly everywhere where you are in the platform. And I enjoy building stuff also much more with those advancements. And yeah, just give it a try. There's a lot of information online. If you want to go down the route of self-managed, that's also even quite easy to set up simply your instance and get up and running and have your own GitLab to run and adapt at the end of the day. So yeah, thanks again for the invitation. It was great. 

[0:53:38] GV: Yeah, that was fun. So thanks so much. And I'm sure we'll catch up again in the future as well. 

[0:53:43] TZ: Cool. Thanks a lot. 

[END]