GitLab and the Evolution of DevSecOps

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 https://gitlab.com/ 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 hard questions about governance, agent identity, and how much autonomy to hand over. Tim Zallmann https://x.com/tpmtim 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. Sponsorship inquiries: [email protected] mailto:[email protected] The post GitLab and the Evolution of DevSecOps https://softwareengineeringdaily.com/podcasts/gitlab-and-the-evolution-of-devsecops/ appeared first on Software Engineering Daily https://softwareengineeringdaily.com.

• 0:00Speaker 00

  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,

• 0:43Speaker 00

  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 Zalman is the VP of Engineering at GitLab. In this episode, he joins Gregor Van 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,

• 1:27Speaker 00

  the realities of shipping air-gapped software and how the space is shifting as new players move into code hosting. Gregor Van 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 van.hk or on LinkedIn.

• 2:04Speaker 01

  Hello and welcome to Software Engineering Daily. My guest today is Tim Zalman. Thank you for joining, Tim.

• 2:11Speaker 02

  Thanks a lot for the invitation. Great to be here.

• 2:13Speaker 01

  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 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.

• 2:44Speaker 02

  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 a hundred and I think I was 112 or so employee and now we are 2,000 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. So this is where I started. I started in point of sale systems, which was a very different area of what I do now. So one of my first things that I programmed professionally was like an interface to a credit card reader in C. That's where I started. I then went very quickly when I was around 18.

• 3:28Speaker 02

  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. And I went there. I had a small agency at the beginning, which did a mix of websites, software development, classic stuff. I did then a mix of small projects for small businesses to larger businesses also across the world, a couple of remote projects. I did 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.

• 4:09Speaker 02

  For the DVLA, for example, I was the person who programmed the printing on text discs for cars in the UK back then. Yeah, so 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.

• 4:51Speaker 02

  We were almost in every newspaper and TV station. And you went to like an electronics store and saw people playing on the computers in the electronics 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 like an exact plan maybe at the beginning. It's a lot about prototyping and then figuring out something while you're 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,

• 5:35Speaker 02

  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 like, 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. And I was working for a couple of different startups in Austria, advising them especially about building teams and building software that were like 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.

• 6:15Speaker 02

  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, erste Gruppe, 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.

• 6:58Speaker 02

  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.

• 7:20Speaker 01

  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. So yeah, I've worked virtually almost remote my entire life, luckily, or 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. So yeah, very interesting. So 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?

• 7:54Speaker 02

  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 are 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. So 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. So anything that a software team needs should be part of this platform. That's our target at the end of the day.

• 8:37Speaker 02

  But 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,

• 9:19Speaker 02

  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 with really this focus to enrich especially also the secure area. I think we are quite strong in that part. So 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 like we provide ourselves.

• 10:00Speaker 02

  Managed solution. So 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 severity standpoint, and also from a standpoint how they can adapt the platform and the solution around it. 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.

• 10:45Speaker 02

  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?

• 11:05Speaker 01

  Yeah, I guess for someone like myself, I've been in software, what, about fifteen years at this point? My perception, I guess, originally was GitLab is sort of, quote, 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 as a sort of my, if someone asked me, what is GitLab? I would have often thought, oh, I think it's the open source GitHub.

• 11:30Speaker 02

  Yes, that's exactly where it started. I think the base where we are coming from is open source. We are still up to date. We are a completely open core company, which means you can't 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, 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 that 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 you wishes.

• 12:14Speaker 02

  But I think with an open core, you can have much more influence on 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 to product, I think is really awesome. At the end of the day, what we have then done is like, 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.

• 12:59Speaker 02

  We went then especially, I think, strong in also in the code review part. We expanded then in planning, we expanded in the security area to really provide these capabilities in one platform. And I think still for, we have customers who have tens of thousands of engineers and thousands and tens of thousands of active projects that they are running. And that 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.

• 13:39Speaker 02

  And on the other hand, you have also the capability to add more features. I think it's 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 like, 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 a check dot 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

• 14:18Speaker 02

  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? Is it on which cloud does it run? Et cetera, et cetera. We can even go and bring in observability data and allow then 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

• 15:01Speaker 02

  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 then 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 what's going on, because if you have fifteen thousand engineers who are doing stuff every day and twenty-four 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.

• 15:47Speaker 02

  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.

• 16:04Speaker 01

  Yeah.

• 16:05Speaker 03

  This episode of Software Engineering Daily is brought to you by VariaCode. If you're an engineering or IT leader, you know how painful this is. An open rec sits unfilled for three months. Your tech lead is burning out, covering the gaps, and your product roadmap gets pushed back again. VariaCode solves that. For over ten years, they've been embedding senior Latin American engineers directly into US engineering teams in under ten days at up to forty percent less than local hiring. We're not talking about generic contractor pools. These are pre-vetted, high-quality engineers with real on-call and SLA experience. They work directly in your Slack, Jira, and daily stand-ups in your exact US time zone with zero friction.

• 16:45Speaker 03

  If you're ready to stop losing sprints to open recs, head over to variacode.com/sed right now and get a custom shortlist of senior candidates in forty-eight hours. That's V A R I A C O D E dot com slash S E D.

• 17:02Speaker 04

  I'm a voice agent powered by Deepgram. I don't just understand words, I understand context. Like when you're fixing the sink and say, we've got a leak. You're talking about a pipe. But when you're a new parent and you say, we've got a leak, you mean that you're going to have to change into a clean shirt. Oh, it's everywhere. Deepgram understands words and context across STT, TTS, and voice agents. That means better conversations at production scale. Learn more at deepgram.com/contextiseverything.

• 17:33Speaker 00

  Every visitor on your platform looks the same at first. Can you trust them or are they a threat? Fingerprint lets you answer this question right away with one API call, no model to maintain, and implementation in minutes. Fingerprint recognizes bots, AI agents, VPNs, tampering, and over one hundred more unique signals to give you durable risk scoring and threat detection in real time, even as human and agentic activity blends together. You can identify suspicious traffic faster and build safer and more secure sites and apps. Over six thousand companies rely on it every day. Join them now at fingerprint.com.

• 18:14Speaker 01

  So this is a good segue. I'd love to talk about two, I guess, products within GitLab. We'll get on to, there's a 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, and I believe that is everything that, I guess, from the AI and agentic perspective, that was the first big jump in there.

• 18:41Speaker 02

  Yeah, I'm always very excited to talk about Duo agent platform. That's the main topic that I'm responsible for. 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 like, add something here, add something there. But very soon, we thought, okay, let's build something that is extensible and allows people to run the Gentic stuff at any point in the SDLC. That means like, if someone creates a new project, start an agent to fill the project with the baseline and do the right settings.

• 19:25Speaker 02

  If a work item, if an issue changes its status, then kick off a certain agent that looks at all the compliance stuff, et cetera, et cetera. And allow this in a way, in the same way as we have built CI/CD, to build also custom capabilities. So 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.

• 20:09Speaker 02

  But on top of that, it's 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 prompts. We can have sub-agent that run on different models. So the dual-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 dual-agent platform against any model that you run, to some extent, if it's capable enough, of course.

• 20:50Speaker 02

  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 the dual-agent platform allows you to exactly run these agentic things. What does this mean? On one hand, we have the so-called dual-developer flow, which, for example, allows you that you can simply mention at dual-developer in any comment, in an issue, in a merge request.

• 21:28Speaker 02

  We are also working on, for example, to extend this into other services 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, dual-developer flow, please implement these things for me. Or that automatically, we can kick off that if the pipeline that just ran on MR 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 stand-up information, so that if you go then in the morning stand-up, that you already have an info

• 22:10Speaker 02

  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, 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.

• 22:54Speaker 02

  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. So, for example, one of my teams, immediately if a bug report comes in from the field, from a customer, from internal, a triage bot goes in, looks at the issue, tries to get 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.

• 23:39Speaker 02

  So in reality, if this was reported overnight, our engineers come in, see the bug reports, 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 reviews 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.

• 24:24Speaker 02

  We ran all the tests, we ran all the pipelines, all is green, 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,

• 25:06Speaker 02

  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 they go, 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 ten 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,

• 25:51Speaker 02

  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 with, I know some customers who have 50,000 active 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,

• 26:32Speaker 02

  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 C line. And this goes way beyond this. This really goes also on issues, MRs, merge requests, CI pipelines, et cetera. 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,

• 27:15Speaker 02

  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 locally knowledge graph with a remote knowledge graph on the 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 review, but allows you to do especially everything that engineers do across their day at the end of the day.

• 28:00Speaker 01

  Yeah, so my understanding is it's, 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 others 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 that can parse through 12 languages on that basis. So yeah, just taking those two points, like what does that do differently? I guess to those that are thinking of, can we just do this with RAG effectively?

• 28:37Speaker 02

  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 like 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 is 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.

• 29:22Speaker 02

  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.

• 30:06Speaker 02

  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. So for example, if we tell the agent, hey, this file that you have just looked at, this has, is being referenced in these seven other files. It has an immediate pointer in reality, rather than using crap or using then read files or looking at directories. Where often simply things can get missed to some extent by agents. Or it takes a very long time because it's literally to some extent, it's brute forcing what agents then start doing.

• 30:51Speaker 02

  And this is literally 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 this 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 this kind of cipher queries. All the data is stored in ClickHouse and it is basically made available then on the fly through this query building.

• 31:34Speaker 01

  Yeah, very interesting. And I guess from a just pure product perspective, it is actually available, I believe, over open MCP to Cloud Code and Codex. It's not like 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?

• 31:53Speaker 02

  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 their 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.

• 32:31Speaker 02

  So in Duo agent platform, you can use our dual developer flow, which is tied and gets the right context around what's doing. But you can also run Cloud Code to implement something automatically in the platform as a runner job, et cetera. 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 Cloud Code. And we allow you to access data through MCP. 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.

• 33:13Speaker 02

  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.

• 33:26Speaker 01

  Yeah, exciting. So just switching gears to a slightly different part of the, I guess, the product stack. Dedicated AI Gateway, which leave also more recently, it's now that a customer who have their own single tenant can actually, you know, they can bring their own model to that. How has that product, I guess, evolved? I feel like there are not just into the, I guess, the space that GitLab's in, but a lot of people are producing AI gateways effectively. And so like, what kind of was the initial inception reasons of the GitLab one? And then like, what does it mean when now a, someone can actually stand up on their own tenant as well?

• 34:03Speaker 02

  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. So in general, if you use the agent platform either on dot 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 all 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.

• 34:45Speaker 02

  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.

• 35:29Speaker 02

  And that's what we are trying to eliminate by allowing you also to run your own AI gateway. And especially to on top of that, to support then air gap environments where there is no connection to the outside world. And exactly this fact, 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 dot com and SaaS version and self-managed. It's a, 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.

• 36:14Speaker 02

  And this is exactly what we have brought now 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 your eyes 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.

• 36:48Speaker 01

  Related to this, also related to everything we've been talking about so far, like Duo and Orbit, it's the, I guess, agent identity piece. And I think like it's something I'm working on as well and 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 like, curious how you guys have looked at that sort of like, 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 what, who or what is taking the action and on behalf of them?

• 37:19Speaker 02

  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. So it's basically, we have a so-called service account, which is the account of the agent at the end of the day that is running.

• 38:03Speaker 02

  But we always attach which user has started this task that the agent is executing at that moment of time. So especially as we are going down the lane of, 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 approved this myself, the code changer, the creation of a certain issue.

• 38:48Speaker 02

  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. So we have a solution that allows you to, as an administrator of the platform,

• 39:32Speaker 02

  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 kind 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.

• 40:13Speaker 02

  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 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,

• 40:57Speaker 02

  every tool call, every approval, and that goes them 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.

• 41:41Speaker 02

  And you can then, 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.

• 42:19Speaker 01

  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 an open core model. What challenges, I guess, does that present? Like, 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 or?

• 43:02Speaker 02

  I think there are two different angles around this topic of air gap. I think air gap originally came simply and happened to us. Because on one hand, of course, we had self-managed and it was always the target and was from the beginning on. But by having the capability of self-manage, then of course, customers who want to be air gapped or need to be air gapped, said, oh yeah, that's, GitLab could be a great solution for us, because they have a self-managed version, they really focus on this. I mean, still today, our majority of revenue comes from self-managed. They have not disbanded it over time. We also know a lot of our competitors had self-managed and at some point said, oh no, everyone needs to move to the cloud.

• 43:47Speaker 02

  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.

• 44:31Speaker 02

  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.

• 45:15Speaker 02

  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.

• 46:00Speaker 02

  And some person forgets about it and simply says, oh yeah, we just downloaded 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. So 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

• 46:45Speaker 02

  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.

• 47:28Speaker 01

  Yeah, just briefly, which is there a pattern of industry that like is very government seems like the obvious case, but like others that sort of seem to need to air gap things or want to air gap or?

• 47:40Speaker 02

  Yeah, I think government and high security topics are the classic ones on the air gap side. I think there is 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 that what people are always surprised is about our customer base. I think it's simply not just software companies. All kind of companies are building software nowadays. And I have

• 48:18Speaker 02

  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 who do both, who have an instance that is not air gap and an instance that is air gap for more security for some projects. And I think this is that, yeah, also possible at the end of the day.

• 48:50Speaker 01

  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 is the fact that, for example, Cursor are actually coming into this space as well. They, I can't remember the name of it, but they're, you know, they're saying, we're coming into the code repository space. So how do you see the ecosystem evolving over the next, I don't know, two years on that basis? Yeah.

• 49:18Speaker 02

  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 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 and to see that we have a good integration of GitLab in their tools. And we're also looking

• 50:00Speaker 02

  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 have 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.

• 50:43Speaker 02

  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 stand-up 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

• 51:28Speaker 02

  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. So yeah, I'm looking forward to competition at the end of the day.

• 51:47Speaker 01

  Yeah, of course. Just to sort of round out, I'm curious if, you know, you've been at GitLab, it's a relatively long time, but you know, almost 10 years, I think. And something I'm actually going to just say maybe from the last couple of years, especially through this like 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 you just, that was wrong, 100%.

• 52:16Speaker 02

  Yeah, I think what has completely changed is like 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 it's 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 there is the next thing. I think this kind of change from the outside

• 52:57Speaker 02

  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. We 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

• 53:42Speaker 02

  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. So, yeah.

• 54:27Speaker 01

  Yeah, I mean, it's been, yeah, so we're sort of fascinating to hear from the inside, yeah, just like what's what's going on at GitLab and what the future might hold. So yeah, as someone working in a fellow, you know, remote ASIC company, yeah, I've often looked at GitLab in the sense of really being inspired by, you know, 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. So.

• 54:55Speaker 02

  That's great to hear.

• 54:56Speaker 01

  Thanks so much for coming on, Tim. Well, obviously, where's the best place for someone to go and just get up and running at GitLab?

• 55:02Speaker 02

  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 also the AI features and more advanced capabilities. Take a look, we have just released our complete new CLI with agentic, 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 in 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.

• 55:48Speaker 01

  Yeah, that was fun. So thanks so much. And I'm sure we'll catch up again in the future as well.

• 55:52Speaker 02

  Cool. Thanks a lot.