GitLab Aktie

Good day, everyone, and welcome to today's GitLab's Second Quarter Fiscal Year 2027 Conference Call. [Operator Instructions] Please note, this call is being recorded. It is now my pleasure to turn the conference over to Nic Edwards.

Good afternoon, and welcome to GitLab's second quarter 2027 financial results earnings call. I'm Nic Edwards, VP of Finance, Strategy and Operations. And with me are Bill Staples, our CEO; and Jessica Ross, our CFO.

During this afternoon's call, we will provide an overview of the business, commentary on our second quarter and full year results and guidance for the second quarter and fiscal year 2027. In addition to our prepared remarks on this call, additional information can be found in our shareholder letter, press release and investor presentation and SEC filings on our Investor Relations website at ir.gitlab.com.

Before we begin, I'll cover the safe harbor statement. I would like to direct you to the cautionary statement regarding forward-looking statements on Page 2 of our presentation and in our earnings release, issued earlier today, both of which are available under the Investor Relations section of our website. The presentation and earnings release include a discussion of certain risks, uncertainties, assumptions and other factors that could cause our results to differ from those expressed in any forward-looking statements within the meaning of the Private Securities Litigation Reform Act.

As is customary, the content of today's call and presentation will be governed by this language. In addition, during today's call, we will be discussing certain non-GAAP financial measures. These non-GAAP financial measures exclude certain unusual or nonrecurring items that management believes impact the comparability of the periods referenced. Please refer to our earnings release and presentation materials for additional information regarding these non-GAAP financial measures and the reconciliations to the most directly comparable GAAP measure. I will now turn the call over to Bill. Bill?

Thanks, Nic, and good afternoon, everyone. Q2 was an exceptional quarter. Let me start with just some of the highlights. Revenue was $286.3 million, up 21% year-over-year, and non-GAAP operating income was $42.6 million, representing a 15% operating margin. Our sales team delivered the largest gross bookings quarter in company history, and net ARR grew more than 40% year-over-year, our highest in several years. We also beat all of our targets on first orders, which grew more than 100% year-over-year.

Underneath those highlights, I'd like to share a brief update on each of the 5 growth initiatives that we laid out for this year. First, we told it was important that we accelerate first orders. Q2 was our largest first order quarter in 3 years. First order count grew more than 100% year-over-year and first order net ARR increased nearly 40%. Our dedicated first order organization is building more repeatable sales motions, while our product-led investments are widening the top of the funnel. The combination is bringing significantly more new customers into GitLab. It's important to win customers of all sizes, including AI start-ups and others with small orders to begin with because more than half of our current $1 billion plus in run rate revenue comes from customers whose first order was less than $5,000. Our strategy is to land customers wherever they're ready to start and grow with them over time.

Second, we said increased predictive sales capacity would be an important driver of reacceleration. And in Q2, we saw that thesis begin to pay off. Account executive capacity increased approximately 30% year-over-year, while productivity per rep improved approximately 10%. Attrition also improved year-over-year for the second consecutive quarter. Adding capacity while simultaneously increasing productivity is difficult, and we believe it demonstrates that the investments that we've made into our sales organization are beginning to compound. The result was the largest gross bookings quarter in GitLab history and net ARR growth of more than 40%.

Third, we told you it was important for us to expand our monetization vectors. Our seat-based business continues to grow and AI is creating an additional opportunity for GitLab to monetize an increasing amount of work happening across the software life cycle. Flex is an important enabler of that strategy. After only 6 weeks in market, more than 130 customers committed more than $20 million to Flex. That early response reinforces our belief that customers want a simpler way to allocate their GitLab spend across seats and new consumption products as their needs evolve. Prior to Flex, customers committed dollars to fixed quantities of seats for premium or ultimate access to our platform. Flex changes that. Customers now make a dollar commitment and each month, they could decide how to put it to work across seats and all of our consumption products.

The commitment is fixed and can be used for any product in the platform. With work accelerating due to agents and more builders coming into the picture, we have a tremendous opportunity ahead to create and capture value. Anything we can do to shorten the time between customer interest and realized value is good for customers and it's good for GitLab. Flex was designed to do this in 3 important ways. First, it helps customers get more value from every dollar they commit to GitLab. Instead of leaving unused capacity stranded as shelfware, customers can redirect dollars toward products creating the most value for them.

We believe better utilization should strengthen our already healthy retention profile by reducing the potential for churn and contraction driven by unused spend. Flex also reduces sales and procurement friction because once the financial commitment is in place, customers can allocate dollars across existing and new products on their own timing throughout the year without requiring a new commercial agreement each time. We've already increased sales capacity and productivity. Flex should help us make that capacity even more productive by allowing our teams to spend less time on incremental contracting and more time helping customers realize value.

And third, it lets usage expand seamlessly as customer needs grow. Customers can consume any eligible product on demand above reserve capacities, including premium and ultimate seats and any usage above their commitment or reservation is billed in the month it occurs. That removes many of the true-up and contracting cycles that are required today to capture that incremental usage and gives customers more flexibility. It creates another potential growth tailwind for GitLab as usage expands. Paid consumption run rate ended the quarter above $40 million, up from $15 million existing in Q1, thanks to the introduction of Flex.

As a reminder, paid CRR is a point-in-time annualized measure that includes GitLab credit commitments, Flex commitments and paid on-demand consumption. It excludes trials and promotional credits. We believe paid CRR gives investors a useful way to track the dollars moving through our consumption model as it scales. Our objective is to exceed $100 million of paid CRR by the end of this fiscal year. We entered this year with a business monetized entirely through seat subscriptions and we now expect to exit it with seats continuing to grow alongside a meaningful and scaling consumption business.

Fourth, we need to improve our performance in our price-sensitive customer segments. And I'm pleased to report that we now have seen stabilization in SMB and mid-market this quarter with performance ahead of our targets for both of those segments in both expansion and first orders. Our thesis was increased focus and investment in this segment could improve performance, and this quarter's results are encouraging. We want to see that performance sustained over the next few quarters, but we're increasingly confident that we're on the right path.

Fifth, we're executing a bold AI strategy. This quarter, Duo Agent Platform CRR grew roughly 50% quarter-over-quarter, inclusive of credit commitments, paid on-demand credits and flex reservations. We also broadened adoption geographically after a more U.S.-centric first quarter. And one top 20 U.S. commercial bank expanded its AI credit pool nearly tenfold this quarter. But I think the broader AI story is even more important. For more than a decade, GitLab has brought together the context of how software is built, secured and shipped across source code, issues, merge requests, pipelines, vulnerabilities, policies, approvals and deployments.

As AI becomes more capable, we believe that connected context becomes even more valuable, and we're seeing early evidence of that with GitLab Orbit, our context graph for the software life cycle. Since opening the beta in June, more than 2,200 organizations have enabled orbit indexing, an increase of 70% in 4 weeks. Customers have generated more than 170,000 queries and roughly 80% of customer query volume comes from customers connecting Orbit to external agents such as Claude Code and Codex. We're also beginning to see evidence that better context improves agent performance. Compare the market tested Orbit against traditional RAG with 79 real merger requests and saw accuracy improve from 58% to 70% and the same dynamic is visible across our platform.

Year-over-year, secure repositories grew 60%, code pushes grew 50%, CI/CD pipelines grew 40%. Among some customers moving aggressively into AI-assisted development, we've seen code bases grow as much as 500%. The pattern is increasingly clear. As enterprises adopt more AI development tools, they use more of GitLab. That matters because our core business remains very strong. Ultimate now represents 59% of ARR and 8 of our top 10 deals this quarter. Premium and Ultimate are the foundation of a business now exceeding $1 billion in trailing 4-quarter revenue, and we continue to see significant opportunity ahead. AI gives us the opportunity to build on top of that foundation with new products, new consumption and entirely new kinds of work flowing through GitLab.

Before I turn it over to Jessica, I want to recognize 2 important groups. First, Ian Steward, our CRO, and the entire sales organization. Ian has now been with GitLab for 5 quarters. The results we're seeing today reflect many quarters of disciplined work, building the fundamentals, sharpening our strategy and creating a team capable of executing against it. I especially also want to recognize the entire GitLab team because at the beginning of this quarter, we made the difficult decision to restructure the company. Many people chose to stay and help build GitLab's next chapter.

Together, we delivered one of the strongest quarters in our company's history. To everyone at GitLab, thank you for your hard work, your resilience and your trust. I'm so incredibly proud of you and what we've accomplished. We're entering Act 2 from a position of strength, a healthy core business, accelerating customer growth, new products gaining traction and a consumption model designed for a world where humans and agents increasingly build software together. With that, I'll turn it over to Jessica.

Thanks, Bill, and thanks to everyone joining us today. Q2 was an exceptional quarter, and we believe an important inflection point for this business. Revenue was $286.3 million, up 21% year-over-year and roughly 5 points ahead of our guidance. We delivered the strongest gross bookings quarter in company history. Net ARR grew 42% year-over-year, our second highest growth quarter in the last 4 years. Dollar-based net retention accelerated sequentially for the first time since 2024, and we did all of this while also beating our profitability expectations. The strength in our business was broad-based across new and existing customers and multiple geographies, every customer size and across our core platform.

That breadth is why we're increasingly confident in the underlying trajectory of this business. Our go-to-market team executed at an extremely high level. We closed significantly more large deals than we forecasted. We saw better-than-expected linearity and sales attainment improved. Deals of $500,000 or more grew more than 150% year-over-year, a clear signal that our largest customers are deepening their commitment to GitLab. Public sector also rebounded meaningfully in the quarter, and we see room for that recovery to continue as buying patterns normalize through the back half of the year. We also saw a genuine step change in new customer formation. We had approximately 1,700 first orders in the quarter, more than double a year ago, and new logo net ARR grew 39% year-over-year.

The magnitude of this quarter's performance exceeded even our own ambitious expectations. We care about all the customers that choose GitLab, large and small. More than half of our $1 billion-plus run rate revenue base today came from customers whose very first order was under $5,000. Landing them early and growing with them is part of our competitive advantage. It allows us to acquire customers efficiently and grow with them over time. GitLab Ultimate had an exceptional quarter as well. Ultimate ARR grew approximately 35% year-over-year and now represents 59% of our total ARR.

Security, governance and compliance are becoming more central to buying decisions as artificial intelligence proliferates across the software development life cycle. We're starting to see demand extend beyond the traditional developer seat entirely as AI makes software creation accessible to a much broader set of builders across the enterprise. We think that expands who GitLab can ultimately serve.

Turning to customer metrics. Gross retention stayed well above 90%, consistent with our historical trends. Dollar-based net retention was 117%, up sequentially for the first time since 2024. Total RPO grew 16% year-over-year to $1.2 billion and current RPO grew 20% to $744.7 million. Calculated billings grew 24%, doubling the 12% growth rate we posted just last quarter. Our emerging products are gaining real traction. Duo Agent Platforms paid CRR grew 50% sequentially and platform-wide paid consumption run rate exceeded $40 million exiting the quarter. Usage trends tell the same story. CI pipelines created and push actions were both up more than 40% year-over-year.

Moving down the income statement. Non-GAAP gross margin was 86.5%. SaaS was 34% of total revenue and grew 36% year-over-year, powered by continued strength in GitLab Dedicated and Duo. Non-GAAP operating income was $42.6 million, up from $39.6 million a year ago for a non-GAAP operating margin of approximately 15%, ahead of our expectations, driven by improved sales and marketing productivity and the timing of certain investments. We incurred approximately $23.3 million in restructuring charges, in line with what we outlined last quarter. On JiHu, Q2 non-GAAP expenses were essentially flat year-over-year at $3.0 million. Our goal remains to deconsolidate JiHu, though we can't predict if or when that will happen.

Adjusted free cash flow was $9.8 million, a 3% margin with the timing of collections weighing on the number this quarter. We returned capital to shareholders by repurchasing approximately 3.5 million shares. We have about $245 million remaining under our current authorization. We ended Q2 with $1.3 billion in cash and investments. Before I get to guidance, I want to spend some time on Flex because it is central to where this business is going and because it changes how some of our results will show up in reported financials. This is the first quarter Flex shows up in our results, and the impact was therefore immaterial relative to the size of our existing revenue base.

However, in the first 6 weeks on the market, over 130 customers committed more than $20 million to Flex. That is a fast emphatic signal of demand for a fundamentally better way to buy from us. At its core, Flex is a single annual or multiyear dollar commitment that customers draw down flexibly across premium and ultimate seats, GitLab credits and other usage-based capabilities without renegotiating a contract or restarting procurement every time their needs shift. We think this is simply a better model for customers, and we believe over time, it becomes the default way customers transact with GitLab. It's a better model for us, too. It means our growth is tied to how much value customers get from the whole platform, not just how many seats they buy. Given the strong signal we are seeing from our customers, we have become more convicted in the growth and adoption of Flex.

It also means Flex may become materially impactful to our financial results as this commercial model becomes our customers' first choice for transacting with us. From that standpoint, there are 2 reporting implications investors will need to understand clearly when it comes to the impact of a more material adoption of Flex by our customer base, revenue recognition and RPO.

First, revenue recognition. Today, approximately 15% of a traditional self-managed license is recognized upfront. Under Flex, the license fee is no longer recognized upfront. Since customers can shift product mix within their committed dollars, that revenue is instead recognized over the contract term. To help you model this, for every $50 million of our self-managed available to renew that converts to Flex in FY '27, we estimate approximately $5 million of revenue that would otherwise have landed in FY '27 instead shifts to be recognized over future periods.

Given the size of the available-to-renew pool in the back half of the year as well as our visibility into the H2 pipeline, we expect the maximum potential impact on our revenue to be approximately $13 million in FY '27. To be clear, this is just a timing change in revenue recognition. It is not a change in the underlying customer commitment, and it is not a change in cash economics. Customer commitments are unchanged and cash billings continue to be billed annually upfront regardless of which model a customer is on. Because Flex is a contractual dollar commitment, the full committed amount is captured in total RPO.

However, Flex is excluded from current RPO because of signing, the customer controls the timing, product mix and pace of future consumption, so we can't reliably say how much relates to the next 12 months. That means as Flex scales, you may see total RPO and revenue growth move at different paces, and you should expect that. This quarter, cRPO saw a 3-point headwind relative to RPO purely from the absence of Flex commitments in that metric. Every quarter, as Flex adoption grows, we will explicitly quantify its impact so you can cleanly separate the accounting effect of Flex from the underlying performance of the business.

Now turning to our outlook. Our confidence in the underlying trajectory of this business has increased following our first half performance. A few things to keep in mind as you think about the second half. First, we're taking a more constructive view of public sector given the improved buying patterns we saw this quarter, and we expect that recovery to continue gradually through the rest of the year. Second, Q2 benefited from exceptional execution, more large deals than forecasted, improved linearity and our best pipeline conversion ever. Our second half outlook assumes a more normalized pace of bookings from here, not a repeat of Q2's exceptional levels.

Third, on Duo Agent Platform, we assume limited contribution in FY '27 relative to our large existing revenue base. Our focus this year remains on adoption, converting pilots into production deployments and building the foundation for monetization ahead. And finally, to remain consistent with the guidance philosophy and forecasting methodology we have had all year, we have not incorporated the potential impact of Flex in our guide, but we do intend to quantify the revenue recognition impacts through the rest of the year. With these points in mind, I am pleased to share that we are raising our guidance to reflect the strong momentum we experienced in the first half of the year as well as the momentum we anticipate will continue into the back half.

For Q3 FY '27, we expect total revenue of $281 million to $283 million, representing approximately 15% to 16% year-over-year growth. We expect non-GAAP operating income of $35 million to $37 million and non-GAAP net income per share of $0.19 to $0.20, assuming approximately 172 million weighted average diluted shares outstanding. For the full year, we now expect total revenue of $1.129 billion to $1.133 billion, representing approximately 18% to 19% year-over-year growth. We expect non-GAAP operating income of $148 million to $152 million and non-GAAP net income per share of $0.85 to $0.87, assuming approximately 172 million weighted average diluted shares outstanding.

There's no change to our underlying investment priorities or how we're balancing growth and profitability. I'd also like to provide a few additional points for modeling purposes. First, we continue to expect full year gross margins to be between 85% to 87%. We expect approximately $15 million of JiHu-related expenses for the year compared with $13 million last year. Stepping back, this was a genuinely exceptional quarter, and it gives a strong foundation as we begin the transition to Flex. We believe Flex is the right long-term model for our customers and for GitLab, even though the transition will introduce some near-term noise in revenue timing and reported metrics.

Our job through that transition is to give you the transparency to see through those timing effects to the performance underneath. During this quarter, we saw record bookings, accelerating net ARR growth, strong retention, broad-based strength across the business and profitability ahead of plan. This performance is what gives us real confidence in where the business is headed. Thank you for joining us today. I will now turn it over to Nic to open it up for Q&A.

[Operator Instructions] We'll take our first question from Kingsley Crane at Canaccord Genuity.

Congrats on what is truly a monumental quarter. Bill, you've talked about how AI labs are building custom systems around their Git providers because Git wasn't designed for agent scale operations. And since then, you're now rebuilding source code management to better service agents. So I was wondering if you could just expand on that strategy. Is this for all customers? Does this allow you to do more with AI natives or labs that you otherwise may not have?

Thanks, Kingsley. This quarter's performance really demonstrated what we've always believed possible with GitLab. And now we're focused on systematically executing that opportunity to repeat that performance. In terms of the product road map, the demands of AI are really creating tailwinds for GitLab and some really exciting opportunities. As you mentioned, one of those is the next-generation Git product. But let me put it into context because we started this year by introducing our first consumption product, Duo Agent Platform. It's been now in market for 2 quarters and been performing really well.

Last month, in August, we also launched Secrets Manager and Dedicated Runners, our second and third new consumption products this year. Adding to that, now we've also got GitLab Orbit, which entered public beta in Q2. That's our Knowledge Graph. It's really the secret sauce of GitLab as we connect code, issues, MRs, pipeline, security findings so that agents and humans get better answers to questions and higher quality Agentic outcomes at lower cost. We highlighted on the call, early beta adoption is really promising. Over 2,200 organizations enabled it, 70% increase in just 4 weeks and 80% of the queries come from external tools like Claude Code and Codex. They drive more consumption of GitLab platform.

The other one that you mentioned is the next-generation Git product. As experts in Git, we're one of the leading contributors to that project. We're now in the middle of rearchitecting that Git infrastructure to achieve roughly 100x scale what humans have ever required. That's really important because agents operate at that machine scale level with one engineer or builder invoking dozens and sometimes hundreds of agents to accomplish a particular task. The other product road map item I want to highlight in addition to next-generation Git is our artifact management product, which is in private beta now, but we expect will be coming in public beta this quarter. It extends our platform to allow for our customers to store, version, govern and sign binaries in artifacts so that we can complete the software supply chain.

We already have their source code. We already build and test that source code, and we help them deploy it. And with artifact management, we'll also help them store those artifacts so that they can have secure end-to-end software supply chain all within GitLab. That's one of the top concerns of enterprises today is how do they trust their software supply chain in an Agentic era where agents are doing a lot of the work. So DAP is our agentic layer. And underneath that, we've got these new consumption-based products, including like you asked, next-generation Git, GitLab Orbit and Artifact Management, all coming into the market this coming year with capabilities that help software engineers and their agents operate at much higher scale. It's a pretty exciting time. And maybe it's a good time for me to also tee up our GitLab Transcend event coming in just about 6 weeks. We hope you tune in for more information on the road map ahead.

Our following question will be from Matt Hedberg at RBC.

Can you hear me okay?

Yes.

Congrats on the results. Really, really good to see. I guess for Bill or Jessica, a lot of things to think about here. The seat growth is really, really exciting to see. And I think when we think about that plus the optimism around Flex, it feels like there could be some increased durability here. I guess I'm wondering on the seat side of it, obviously, developers are a focus. But could you talk about that nondeveloper opportunity? I mean I think we all think that, that could be a pretty significant driver as well. But could you touch on that piece as well?

Absolutely. AI is proving to be a real durable secular tailwind for GitLab and really not just the seats, but every component of our growth algorithm. Maybe this is also a good time for a quick plug. New to this quarter, we published an investor letter, which Jessica and I wrote to give you a look into how we think about the growth algorithm for GitLab going forward. I'll give you a quick summary and cover as part of that, your question around the opportunity for seats. So the growth algorithm really touches on 3 components. First, more customers. And within more customers, more builders than ever. We believe GitLab's opportunity here is enormous.

We're underpenetrated in the global market, and we've been building a stronger competitive position as evidenced by our first -- by this quarter's results. We added more than 1,700 first orders this quarter. That's more than double a year ago, and first order net ARR is up nearly 40%. One of the things that's also inside of that more new customers number is really an increased demand for seats. AI has significantly enabled anyone to become a builder. I'm guessing many people on this call have experimented with AI tools and been able to create dashboards or applications with code entirely written by the agent.

Well, that code has to be stored somewhere. It has to be governed by the organization if it belongs to an enterprise. It has to meet those organizational compliance and security standards, and that's what GitLab is best at. So AI is creating a secular tailwind for more customers and more builders within every one of our customer accounts.

Second part of our growth algorithm is around more products. And you've heard me talk in response to Kingsley's question about some of the exciting product road maps ahead. But this is an important part of our growth strategy because we're expanding beyond just the platform seats capabilities that we've had that led to a $1 billion run rate business that's still growing strong. The proof that this part of our growth algorithm is working is also evidenced in this quarter. We've shared, for example, that secure repositories are growing at 60%, code pushes 50% and CI/CD pipelines at over 40% year-over-year. That's our core platform in action.

Also exciting beyond just the core platform is the introduction of our consumption model and credits. Evidence of this in the quarter, we can highlight is our Duo Agent Platform growth, where sequentially, we saw a 50% increase. Finally, the third part of our growth algorithm is all around unlocking consumption for every customer. That's where Flex comes in because it unlocks friction-free usage across both seats and credits with a single commitment that allows customers to choose every month how they want to consume the platform to solve their specific problems.

Jessica highlighted in our last 6 weeks of Q2, more than 130 customers opted into Flex. They committed more than $20 million and our paid CRR went up, thanks to Flex from $15 million exiting Q1 to over $40 million exiting Q2. So stepping back, AI is dramatically lowering the bar to build software. Anyone can become a builder. Customers are needing more of GitLab than ever, and we've seen that pattern now for several quarters in a row. Thanks for the question.

All right. Our following question will be from Sanjit Singh at Morgan Stanley.

Congrats on an excellent quarter. It's great to see. When I think about how the business model, the pricing model evolves, you guys have a lot of things that you're working on. Bigger picture, Bill, when we think about ultimate versus premium, is that still a relevant construct? I mean you guys have -- you're growing seats. It sounds like the nondeveloper population could be a secular driver for that. So does the model potentially just simplify to seats and then you have these other monetization vectors with these product add-ons, and I'm sure there's going to be a lot more of that over the next couple of years. So just wanted to think kind of bigger picture on how the business model pricing model progresses from here.

Yes. Thanks, Sanjit. Seats absolutely core to our business, continue to grow healthy, and we're excited about continuing to offer those premium and ultimate capabilities that have led to a $1 billion run rate business continuing to grow strong. But to up-level the question a little bit, I think the way that investors should think about our growth going forward is to understand the customer benefits and the GitLab benefits of Flex. So let me unpack the GitLab strategy here because that's core to understanding our business model going forward. We introduced Flex in Q2, and I already highlighted some of the early wins, 130 customers, more than $20 million committed. And you might ask yourself like, why are we introducing that? What is driving customers to adopt at such a rapid early rate?

The benefits are pretty clear. For customers, Flex represents more value for every dollar because every month, they get a chance to redirect unused capacity from shelfware towards whatever products that create the most value for them. So for example, with the emerging need to give GitLab to non-engineering users, they can flex capacity on to more premium or ultimate seats. In addition, those users may have a need for a Duo Agent Platform to provide agents that assist their work across the software life cycle, they can allocate a reservation on Duo Agent Platform.

Second, it also gives them the ability to adopt new products without going through a new contract cycle, without securing more new budget from procurement. This is one of the major benefits of the Flex model because right inside the Flex portal, new products show up, they can allocate reservations against them, and they can even set budgets so they have control over where they spend their commitment. And finally, it also allows customers to seamlessly expand usage even beyond their commitment. So if they see the demand, they can provision more seats and more credits as needed going beyond their commitment, and those are then billed each month.

For GitLab then, the benefits are pretty clear. First, we believe Flex will help us drive an already healthy profile around retention even better. It allows for us to capture any unused capacity into a Flex commitment and then allow customers to redirect that as needed. increasing our retention that's already, as Jessica mentioned, gross retention already above 90%. This also stands to help us with improving our already improving productive sales capacity. I mentioned that we've increased capacity 30% this quarter and a 10% increase in per rep productivity.

Well, now reps can spend more time helping customers realize value and less time negotiating contracts and true-ups and working through procurement. And finally, this also represents a new growth tailwind since customers can unlock usage on demand and we bill them immediately as that usage is incurred, giving us another monetization tailwind. So the strategy around the business model is pretty clear. We want to see customers shifting to Flex because it gives them more value, it reduces sales and contracting friction and allows for on-demand consumption. We started the year with 100% seat-based subscription business. And now we're focusing on ending the year, continuing to grow that core platform, but also want to focus on exiting the year with a meaningful consumption business scaling toward our second billion as we monetize the work that humans and agents are doing together.

All right. Our following question will be from Ethan Weekes at Piper Sandler.

This is Ethan filling in for Rob tonight. Bill, I wanted to ask just how much of the strength in the quarter do you think was driven by internal execution improving versus kind of the overall demand environment just accelerating as all organizations really start to think about the tool chain that they're enabling their developers with?

Yes. Great question. As we mentioned, a record gross bookings quarter in company history. Net ARR growing more than 40% year-over-year. It's our second highest growth quarter in the last 4 years to give you a sense of that. And I think it's really a result of many quarters of investment and some tailwinds kicking in across multiple dimensions. As Jessica mentioned, PubSec rebounded meaningfully. This is a really strong signal after a few quarters of less than ideal results given government shutdowns and other things. We also see AI tailwinds, though, helping drive large deals. Jessica mentioned our $500,000 and above deals grew more than 150% year-over-year.

Our largest customers deepening their commitment with GitLab. Those commitments span both seats and credits for our new consumption products. Underneath all of this, we really do see AI beginning to be a durable tailwind for GitLab. And it really impacts all 3 levers of our growth algorithm. It's leading to more customers. It's leading to the new products getting early adoption as we highlighted with GitLab Orbit and it's leading to more consumption. You should think of net ARR as that output metric for the growth algorithm because it takes into account all 3 of those dimensions compounding one another.

Our next question will come from Koji Ikeda from Bank of America.

Really nice job here with the commentary and the growth bookings. And so with a lot of the focus on Flex over the next, call it, a couple of years, there's a lot of moving pieces in the financial model with Flex. And so what would be the single best metric to gauge the performance of Flex? And just one quick, I guess, housekeeping question on the guide, would the guide have been raised $13 million more if there was no Flex this year? Just around the question of is the guide actually understating what's happening in the business because of what's happening in the shifting with Flex?

Thanks, Koji. Let me just step back and give you some thoughts about like how we thought about guidance this quarter. So first, again, Flex has only been in the market for 10 weeks. So it's just too new to bake into our guidance with precision. At the same time, we've been really pleasantly surprised by customer demand and how potentially impactful Flex could be in the back half of the year. So as we thought about our guide, we didn't want the accounting mechanics to distort the guidance conversation or investors' views of the underlying health of the business. So we've really applied I'd say 2 key principles to our approach, consistency and transparency.

So first on consistency. We wanted to guide the same way all year. So we started FY '27 guiding without the accounting timing impact of Flex, and we've stayed consistent with that methodology rather than changing course midyear. Second, on transparency. In line with our commitment to transparency, we are providing a couple of key data points to help you think about your models.

First, the heuristic, which I mentioned in my prepared remarks. So for every $50 million of self-managed customers that convert to Flex, there is about a $5 million revenue recognition timing impact that shifts out of FY '27 into the future period and then the maximum FY '27 impact of $13 million. So going forward, we will continue to explicitly and transparently quantify the flex accounting timing impact each quarter so you all can separate the accounting effect from the underlying business performance.

We are committed. And I think just in terms of that $13 million, the other thing I'd highlight is we've got a lot of visibility into our business. So in calculating that amount for us, we feel confident in the precision because, one, we understand our self-managed available-to-renew for the back half of the year, and we've also got very clear line of sight on pipeline.

And Koji, in terms of the other part of your question around what metric to look at, that paid CRR metric that we introduced last quarter and updated this quarter with more than $40 million of paid CRR is really the best way to understand how dollars are flowing through our consumption model. Paid CRR captures both Flex commitments, credit commitments as well as on-demand paid usage. So all 3 of those inside of that metric. It does not take into account promotional usage or trials or other unpaid usage. And as we mentioned on the prepared remarks, we are setting a bold target to achieve more than $100 million paid CRR by the end of this fiscal year.

All right. Our following question will come from Radi Sultan at UBS.

Awesome. Now that you have some data points on conversion to Flex, I mean, in sizing those initial Flex deals you convert customers, like is there a higher propensity to upsize their deals because of the increased flexibility and sort of new product consumption? I'm trying to understand how much is just a form factor shift to Flex versus baking in anticipated new product consumption or seat expansion would be great.

Yes. No, again, we're really excited about it. It's been about 10 weeks in market, so it's too early for us to tell. But I just -- I think really leaning into the strategy, Bill, is there anything you want to add there from that lens?

Yes. From a sales strategy perspective, it's an opportunity to do multiple things. First, some customers are early adopters and already testing our beta products. And Flex gives us a way not only to renew their seat-based subscription but shift that commitment into a Flex agreement where they can create headroom to start using those products as soon as they become generally available. And wherever we can do that, create headroom for customers and their commitment, obviously, we want to take advantage of that. It also lets us look at customers who may have unused capacity because they were previously forced to commit to a seat forecast for the full year and rather than take some contraction on the account, keep their commitment the same or even higher and redeploy that budget onto new consumption-based products.

So it really helps us on both the upside as well as reducing or mitigating potential downside, which we're really excited about deploying anywhere we can align with customers on the value of their GitLab commitment.

All right. Our following question would be from Derrick Wood at TD Cowen.

Congrats from me. Bill, could you touch on just what you're seeing across the competitive landscape when it comes to both new AI natives coming on to the scene as well as what's going on with your traditional competitors? And where you feel that you're competing better or gaining share right now?

Yes. Great question. Competitive dynamics have been really consistent in this quarter. We still have one primary competitor. Our position versus that competitor is, I think, stronger than it's ever been. They've struggled with reliability and meeting the needs of customers in this new Agentic era with security and trust and other dimensions. And so we're seeing higher win rates. We're seeing both wins on the first order side as well as the expansion side as reflected in our numbers, 100% growth in first orders and more than 40% net ARR expansion. In terms of AI natives, what I would say there is really, this is an opportunity. They're creating tailwinds for us. They've dramatically simplified the ability for anyone to create code and all of that code needs GitLab.

And so we're now seeing, as I've mentioned, our customers coming to us and saying they need more GitLab seats because of nonengineering people who need access to the platform. And those same users who are now needing seats will ultimately also need credits in order to use our consumption-based products. So we're happy to partner with any Agentic coding tools out there because we see it as creating tailwinds for the business that we have.

Our following question will be from Howard Ma at Guggenheim. Howard, are you there? Let's make sure you're -- Howard Ma, are you there? Let's move on to the next question. Our following question will be from Nick Altmann at U.S. Bancorp.

Awesome. I wanted to follow up on Radi's earlier question. How much of the interest in Flex or the $100 million CRR target is being driven by some of the newer products like Duo Agent Platform, Orbit, Secrets Manager and the Dedicated Hosted Runners? Because I think you mentioned that not all of it will be incremental to revenue, but presumably some of those newer products should be incremental. So just any color on how much those newer products are driving some of the interest in Flex or that $100 million CRR target would be super helpful.

Just on the financial piece of it, it's really too early to tell, but I'll let Bill speak to a little bit more in terms of the interest that we're seeing so far.

Yes, we only had 6 weeks in Q2, so the 130 customers and $20 million is what we've already captured. But I think it's important to step back and understand the strategy because even when customers are shifting to Flex and drawing down on that commitment with seats, it changes the nature of the relationship. And it's an important part of the strategy to understand because the needs today of software engineering teams are changing dramatically every week, every month, every quarter. New tools emerge, new techniques emerge, new models come into market and customers want the flexibility to allocate their spend as their needs evolve. If the current seat-based subscription model was meeting their needs, there would be no need for Flex.

There'd be no demand for it. We wouldn't be seeing the rapid uptake and adoption that we've already seen. So clearly, customers see the benefit of it, and they may start to fund their Flex agreement with their previous seat-based subscription dollars, but they see the value proposition and having the flexibility to adapt and evolve that as our new products come into market. And certainly, some of that is driven by our current consumption product, Duo Agent Platform that launched in January and then the new emerging ones that just launched in August, the Secrets Manager and the Dedicated Hosted Runners. But we have meaningful usage of our beta products already going on. And I think customers are also looking ahead and appreciating the flexibility that we're extending to them via the Flex agreement.

Our following question will be from Shrenik Kothari at Baird.

This is Zach on for Srini. I'll echo our congrats on the strong quarter. So my question on gross margins. It's obviously come down a bit as the business has begun supporting more AI and usage-based workloads, while credits still increasingly monetize both the human and nonhuman activity. So I guess the question is just how much of the recent gross margin movement is actually related to AI inference and infrastructure versus other factors? And then as agent usage scales, what gives you guys the confidence that pricing, model efficiency, orbit and just your ability to route workloads across models can drive attractive incremental economics maybe rather than creating a structurally lower margin revenue mix?

Yes. No, thanks for the question. And just I think in terms of gross margins for the quarter, there's not really a big shift from what we've said previously. So our SaaS dedicated contribution is about 34%. That grew 36% year-over-year. And so that's really in line with what we've been messaging at the time of the IPO, we were at 22%. So we expect those margins to come down over time. And then as we think about going forward, again, this is a year of investment and execution. We have intentionally invested in consumption products and pushing customers to focus on transitioning pilots to production. And so that's what you're seeing there. But Bill, I don't know if you have anything to add there.

Yes. On the -- you sort of alluded to tokens and AI optimization potential within how GitLab looks at AI-native products. So let me talk just a little bit about that because I think we're in the very early days, and we actually have several structural advantages versus maybe typical AI native tools whose almost entire monetization is based on tokens. One of the beautiful things about Duo Agent Platform is that we provide it in a cloud-agnostic model-agnostic way, meaning we support all of the models, including open source open weight models, and we allow customers to deploy it and use it in any cloud, including, for example, air-gapped data center environments that they run.

And what that means is for many of our customers, the token or inference cost is actually not embedded in the GitLab agreement. They pay us for the access to the platform, and they pay for the work done in the platform, the context, the harness, the governance and auditability that we provide, not the inference. Those are all very high-margin products. In addition to that, we're in the very early days of AI adoption. There's very simple things on the road map that we and others are approaching over time, which would allow for dynamic model routing, model optimization to deliver high-quality agentic outcomes in a more cost-efficient way. Those are also things that we want to provide to give customers the very best experience and price to value performance.

So I encourage you to think about gross margins maybe a little bit differently than maybe typical AI natives. And as Jessica alluded to, a lot of the margin changes that we've seen in the business have been driven more by the mix shift to SaaS than the early AI adoption.

All right. Our follow-on question will be from Jonathan Ngo from Truist Securities. Jonathan Ngo? All right. Our last question will come from Miller Jump from Truist. All right. Our last question will come from Lucky Schreiner from D.A. Davidson.

Can you guys hear me okay?

We can.

Okay. Great. This is Lucky with D.A. Davidson. Maybe just on the customer story who expanded their monthly commitments by 10x, was that primarily driven by an increase in usage and the they got? And how much of that was maybe from vendor consolidation and replacement of other tools? And how applicable do you view that kind of expansion motion across your customer base?

Yes. It's a top U.S. bank, and they previously had started with a fairly modest commitment to Duo Agent Platform. And once they started rolling it out across their engineers and seeing the value that it provides, saw the need to increase their commitment 10x this quarter, which we would love to replicate across every single customer. We believe that the value of Duo Agent Platform is there, and it's complementary to other AI native tools that are more focused on the coding aspects of software. So yes, we're really excited by that lighthouse customer. We've got several now that are spending multiples in excess of their premium or ultimate seat price now in terms of credits. And it's a pattern that we're trying to learn and optimize for and repeat everywhere we can.

All right. That's the end of our call. Thank you, everyone, for joining our Q2 call this quarter. We're really excited by the results we're able to deliver this quarter, and thank you for joining us. We'll see you in the investor conferences to come.

Please welcome to the stage GitLab's Chief Executive Officer, Bill Staples.

Welcome to GitLab Transcend. We are broadcasting live from a packed house here in London to more than 15,000 registered people around the world. No matter where you're tuning in from, thank you for spending time with us today.

Now he doesn't know I'm going to do this, and he doesn't crave the spotlight very often, but I'd be remiss if I didn't recognize a very special guest in the audience today because none of us would be here without him. He is our Co-Founder, our Exec Chair, and he is healthy and cancer-free. Please join me in welcoming Sid Sijbrandij.

The company Sid has built is truly amazing. It's a platform in every sense of the word. We just surpassed $1 billion in annual revenue last quarter, serving more than 50 million users and hundreds of thousands of organizations around the world.

In fact, more than 50% of the Fortune 100 trust GitLab to build their software to serve their customers. These are iconic companies in every industry vertical that I know every one of us in our consumer lives and in our professional lives do business with. We use the software that they use GitLab to build every single day. It is such a privilege to be part of this community.

What's really remarkable, though, is despite all of that success inside GitLab, coming to work every day with 2,000 teammates is the passion we have for solving your problems, for innovating new ways of building software. In fact, in this era, reinventing how software is built. It's an incredible community. And the community is growing.

In fact, just last quarter, we added 30% more new paying customers than the same time last year. Thanks to you, we've seen 100%, double the number of code contributions into GitLab from our customers and our community from just 1 year ago. And developers are choosing GitLab to build software more than they ever have.

In fact, over last year, 250% more user namespace is created. Isn't that amazing? What are you all doing with GitLab? Let me tell you.

Platform usage is surging. In fact, CI/CD pipelines have grown 40% 1 year, 50% increase in code pushes, 60% increase in secure repos. And some of your code bases over 1 year ago have grown 500%. What is going on that's driving more value from GitLab than ever before? Can you guess? In a word, AI.

AI is transforming software engineering. And in fact, we launched our Duo agent platform at the start of this year. And in its first quarter, we took more bookings in our first quarter with that platform than any prior quarter with Duo Pro and Duo Enterprise combined.

Clearly, Agentic engineering is in demand. And in fact, since the beta went general availability, we've seen a 1,000% growth in weekly active users on that platform. Agentic engineering is here. We see about it in the news. We read about it in the tech press. We talk about it in the hallways and the virtual hallways around the water coolers everywhere. And it's amazing, isn't it? It's been fueled by our partners from Anthropic, Google, who will be with us on stage today as well as others who've made coding incredibly fast.

In fact, nontechnical users who've never written a line of code can now generate working code 10x faster than a professional developer did 1 year ago. And professional developers are harnessing these tools to take ideas all the way to production in minutes. That is what's igniting software engineering on fire.

But speed can also come with a downside. And just like a race car, it doesn't matter how fast you can go if you can't stay in control. It doesn't matter how fast you can go if you can't trust the steering wheel to get you where you want to be or trust the brakes when you need to slow down around the curves. Speed without control is chaos. And we also see this everywhere we look today. I'm guessing your social media feeds look a lot like mine. With the explosion of code, we see the explosion of bugs and quality issues. We see code review queues get longer and longer. We see more security issues than ever. We see infrastructure and major services that can't maintain reliability. And yes, we see costs explode as well. So speed without control is chaos.

We've been anticipating this problem, and we've been thinking about it for a while. And we think we know the answer. Together with agentic coding, GitLab will bring agentic infrastructure to help you harness speed with control. That's our theme today. Helping you maintain speed with control. How do we do that?

A few weeks ago, I shared a letter to all of our customers and investors titled Act 2. And in that letter, I shared 5 architectural bets that we have been making and that you're going to see today, which are going to change the world, change the way software is built. Let me give a brief overview before we dive in and get a chance to see them.

Number one, machine scale infrastructure. You see the DevSecOps infrastructure that was built today over the last decade, was built for human scale engineering. But machines, agents, they work 24/7. They don't take coffee breaks. They don't get sick. And in fact, they work in parallel to software engineers, sometimes multiple agents per engineer. So the infrastructure on the other side has to scale at machine scale. We're building that. Agents are also great and getting better at performing tasks, but you don't need more tasks. You need quality software that meets all of your engineering standards and regulatory standards, going to your consumers and driving your business. Orchestration is what takes agentic tasks, connects them, passes context to them and gets you working software certified for your customers on the other end.

Context is a superpower of GitLab. We've always been good at capturing all of the software life cycle data and providing that to your human engineers. We're now doing the same in an all-new way for agents. You're going to see GitLab Orbit today because the difference between hallucinations and reality, the difference between false confidence and real confidence is really good context.

With GitLab Ultimate, we've been your trusted partner to make sure that you meet the quality standards, the security standards and the compliance and regulatory standards of your business. We're extending that now to agents as well to ensure that you can govern and audit every single action from every entity building software in your team, whether that's a human or an agent. You're going to see that today as well.

And finally, we're delivering this in one platform for all the ways that software engineers will work. I'm guessing your engineering teams look a lot like our engineering team. We have teams and projects that work with human-led software engineering as they have for the past decade. We have engineers who are using agents like Duo agent platform to do Agentic Assist and they're going 2 to 4x faster than they were just 1 year ago. And we have bleeding-edge teams that are using advanced Agentic techniques to do autonomous engineering. And what's incredible is they're building software at roughly 20x the rate that those same engineers were 1 year ago. We're learning from all of those teams. We're capturing their problems. We're bringing solutions, and we're sharing that with all of you. In fact, you'll meet some of the engineers in all 3 modes today.

What is incredible about GitLab, unlike the cloud era, where you were forced to decide a technology stack in the cloud or on-prem, where you were building different ways of working in the public cloud versus your own private data centers is with GitLab, you can stay in one place for all modes of engineering, have one set of engineering standards, have one security boundary to manage and audit and to serve your customers no matter how your teams want to work. And we deliver it in a cloud-neutral and model-neutral way.

That's the promise of GitLab.

All right. Let's go ahead and dive in now. It is my pleasure to introduce our Chief Product and Marketing Officer, Manav Khurana.

Thank you. Hey, everybody, welcome to Transcend. We're going to do a few demos so you can see how you get speed with control. To anchor these demos, come with me on a 4-part exploration of the new GitLab, which is your Agentic infrastructure. You see whether it's your team or your team's agents, when they are building and shipping software, they need a motor system as in the arms and legs or the execution layer to build and ship code fast. That human and agentic brain also needs a nervous system as in the context to make better and faster decisions. That human and agentic brain also needs an immune system to ship software safely. And then finally, that human and agentic brain also needs an orchestration system so that they can coordinate all the tasks that need to happen across the software life cycle.

Let's start with the motor system. You all use GitLab today because you get all the tools you need in one platform. whether that's planning, source code management, continuous integration, artifact management, continuous deployment, all the tools you need are stitched together in one platform, so your teams don't have the friction of putting everything together and can do their job a lot faster.

Let's dive into source code management. It's been a hot topic recently. I mean, literally hot, literally burning hot because the Git platforms, in fact, the most popular Git platforms in the world are buckling under the load of not just your teams cloning, branching and merging code, but also dozens, in some cases, hundreds of agents working simultaneously and putting a lot of pressure on those systems. You've all seen the same headlines I have seen.

So today, I'm beyond excited to introduce the next generation of source code management. Internally and lovingly, we call this project, Project Switch, well, because switches are better than hubs. If you're a networking geek like me. But really, it is the same Git protocol for backward compatibility, but a completely redesigned back end, new interfaces for agents to work blazingly fast and do so at scale without any disruption.

To show you how this works, please welcome Nick from Anthropic and Kranti from GitLab.

Nick, I'll start with you. Thank you for being a design partner on this initiative. You have the unenviable job of managing the coding infrastructure for perhaps one of the most demanding software engineering teams in the world. Tell us what you're seeing.

Yes. Thank you for having me. At Anthropic, we're seeing development accelerate to the point that a lot of tools that people take for granted, like source control, really can't keep up with the load, the same thing you were describing. We put out a blog post about a week ago that showed that we had an 8x increase in the amount of developer output since a year ago. And I really don't see why this is slowing down. So what are we running into? It's a good question. We're running into 2 major categories of problems. The first are sort of traditional big repo problems.

So things like getting your CI -- getting your checkouts into your CI jobs or even just supporting a large commit rate. We see that a lot of people have these problems, but people don't necessarily talk about them. And it's kind of a shame that everyone has to reinvent the wheel here. We think this should just work out of the box.

The second category of problem that we're seeing is kind of unique to agents. We want to run a lot of checkouts, a lot of developers basically that need the full repo context. So not just like CI jobs, not a single commit, but the history, the blame, the logs. And this is an even bigger problem than just checking out code for CI. Git doesn't really handle this very well. So dealing with partial checkouts of the repo, dealing with slices of context, Git does not support very well. So we imagine that there's new ways of agents interacting with the repo, maybe via rich source control APIs to solve this problem at a bigger scale.

Yes. And this is not just a problem that is an Anthropic problem. All of you, as you scale your coding efforts, your development efforts in the agentic era, these are problems that either you're already running into or will be running into very soon.

Now Kranti, you've been tackling this problem now. I gather you have something to show us.

Absolutely. Hello, everybody. The challenges that Manav spoke about are precisely the ones that we have been set out to solve with a new architecture.

Let me demonstrate that with a harness, lets us compare our current generation system with our next-generation system side by side. On your left, what you'd see is a cluster that is running our current generation system, which is Community Edition 18.0. On your right side, you'd see a cluster that is running the next generation. And both of them are provisioned with the same amount of memory and CPU resources. For the first scenario, let me touch upon one of the common problems that we have right now, which is doing clones at scale.

As you see here, the third generation -- the next-generation system is going to get to the act of doing the clone pretty fast, while the second -- the current generation system feels a little sluggish. When a clone happens on the server side, the server has to compute a packfile from all the files in your repo and all of its history. And if your repo has a lot of files and a lot of history, it's going to take seconds, in some cases, even minutes to get to that packfile. Third -- the next-generation system is efficient at doing that because it's going to convert that into a manifest pointer towards a pre-computed packfile. And if one packfile does not exist prior and your server is getting 1,000 requests at the time, instead of doing this per request, it's going to coalesce the request and compute the packfile once and let the clients stream the output from the object store directly and the clients can scale because the object store behind the scenes is very, very scalable.

As you can see on the right side, the next-generation system is already done. It has finished 100 clone operations within a second on a modest sized repo of our own Gitaly. Now this is going to take a little while on the current generation. So let me show you a run from the previous -- a prior run to show the statistics.

As you can see in this case, it's 42x faster on raw wall clock time. That means your agents and your clients can wait 42x lesser. Not only that, it consumes way less CPU and memory on your server side. That means if you were to run this on your premises, it's going to be very cost effective in addition to being very, very fast.

Now let's look at a right scenario. Let's see how the writes would perform at scale. Again, what I kicked off here is a comparison of performing 100 write operations on both the clusters. And behind the scenes, it has to create a fork, read a file, make some changes and commit the change. And for good measure, it will go and even verify the commit is successful and stuff like that.

Now as you can see here again, it is very stupendously fast on the right side because creation of a workspace in the next generation is super quick. It does this with a clever use of manifests and pointers on a shared pool of objects across all the forks in your repository. And effectively managing that when people are creating forks on like smaller repos, massive repos, it doesn't really scale with the size of the repo anymore. It just like lets you get to the fork and start working on it right away. Now we have looked at both reads at scale and rights at scale.

Let me show you an agentic use case as well. But before that, let me show like how the rights would perform on wall clock time. The second -- the current generation is going to take a little while, so let me show a prior run for you to get a quick understanding. In this particular case, it's finished, both 100 tasks, but it's 17x faster. That means, again, your agents and your clients can get to get -- doing the actual work much faster and not be slowed down by the underlying source control system.

For the third scenario, I'm going to let loose Claude on performing a task. And the task is this. The task is to go and look at some undocumented code files in Git repo and then go and create the documentation and check it in. As you can see here, the next-generation system is chugging along super fast. It's just like going after reading the files, like understanding it, incorporating what has to be documented and like it is also going and checking it in. And the current generating system looks a little sluggish, but it's going to get there. This is going to take a little -- actually, the next-generation system already finished within a wall clock time of 30 seconds. Mind you, this is -- this 30 seconds is being measured from the client side. That means it has the agent inference time, getting the data all over the wire, all of it, right?

On the server side, the stats are even more fabulous, right? The current generation is going to take a little while. Let me show you a prior run just to kind of give you a taste of how it looks like. On the wall clock time, you are getting a massive benefit as it is. It's 22x faster. It is moving much lesser data on the network because it doesn't need to. But I would like to bring your attention to a couple of more interesting stats here. Look at how few tokens it has used.

On the right side, our next-generation system ended up using just 500,000 tokens to perform this task. And with our current generation, it ended up using 1.4 million tokens to get to the same outcome. That is like almost 3x cheaper. And it is going to translate to lesser cost for your agents to do your thing. And behind the scenes, what's happening is the full architectural advantage is coming to fruition. The new access patterns that we created are going to enable the agents to really interact with the code base in more effective ways to get to the act of doing the task much faster. Now how do we do all of this?

Do you want to see the slide?

Yes, I would love to show you the architecture slide. All right. With the next-generation architecture, we got in 3 important advancements in the architecture. Number one, we are letting the compute and storage be separated and allow them to scale horizontally on their own.

Number two, we put a layer of intelligence in between that can bring together the benefits of the distributed compute and storage together and does a lot of hard work behind the scenes like routing the request to the right place, caching what is important, partitioning your objects as your repo size grows, creating packfiles, updating bitmaps, a lot of heavy lifting is done by that intelligence layer. And the third, rather more important advancement that we are bringing in is we are allowing the clients and agents to interact with the source code system using newer access patterns.

Amazing. Amazing. So Nick, you've obviously seen this work in progress over the last several weeks and months. What's your take? Does this scratch the itch?

Yes. I was actually -- truthfully speaking, I was very impressed when I first saw the demo for this. It sort of worked better than I even imagined it would. We've been playing with stuff like this at Anthropic as well. And I think it would be increasingly important to actually scale how these agents work. We're also pretty excited that we now have Sable available into your agent platform. So we expect this to be even more impactful for these large models.

Thank you, Nick. Really appreciate the partnership Yes. Thank you, Kranti. Nice work.

So what you just saw there is the next generation of source code management that is available today in private beta. It is the same Git protocol that you and your teams are used to, but with a redesigned motor underneath for agents to work a lot faster and for your overall system to scale a lot better. You saw things like less than half the number of tokens. In Kranti's example, it was 3x. In our test, we've seen 50x faster wall clock time already and over 1,000x lesser network traffic required, right? Really incredible. can't wait for all of you to use the product.

All right. Let's move on to the next part of the Agentic infrastructure, which is the nervous system. Today, all of you, when you use GitLab, one of the amazing things about the platform is that you have a common data store under everything that you do in GitLab, whether it's your code, whether it's your pipelines, your merge requests, your tests, your security scans, all of those data points are stitched together for you and your teams in one data platform. It makes it easy operationally to correlate what's happening across the software life cycle. Turns out that's also quite useful for agents because they need that context. But here's the thing with context. When you're working on a small project, a bounded project, agents can very quickly get the information they need and deliver a magical experience like we've all seen, where we ask a question and we get a fantastic response in seconds. But I'm sure you've also tried to use agents in a large mono repo, where there are tens of thousands of files that are in your code repository. When you use agents in that setup, you'll see that agents are constantly iterating. They're constantly trying to ping the back end to get the right information to do the task that you have asked. And it goes back and forth. And each time it goes back and forth, it takes more time, it takes more tokens. And agents reach a point where they give up. They don't have complete information, yet they give you a response which honestly is more artificial confidence than artificial intelligence. And you are left the bag to fix what the agent told you. Worse, if you're working across multiple repositories in your business, across different teams and you need not only the code information, but you also need information across the software life cycle, all the related metadata, that's where agents just flat out fail and cannot succeed in doing the job that you've asked them to do.

That's why today, I'm excited to share that we are introducing GitLab Orbit. It is a context graph for the entire software life cycle, where all the context your agents need, whether that's in a mono repo or across repositories with all the life cycle data is available with a single query so that your agents work faster, are more accurate, require fewer tokens and more importantly, you can answer questions that you could never answer before with agents.

To show you how all this works, I'm going to invite the Orbit team, Angelo and Meg to stage to give you a quick demo.

Hi,Meg. How are you? Hey, Angelo, Great to see you.

Good to see you.

You have something to show us.

I think we have a few things to show you. So Manav is right. For a single small local repo, agents shine. But that's not the stack our enterprise customers are working on. With large mono repos or multi repos, agents break down because they're trying to chain together context by calling dozens of tools and running thousands of API requests. But the data quality suffers.

So we had to reimagine context at scale. So Angelo, how about you tell us how we solve this by building Orbit?

Thank you, Nick. And just to touch on that. GitLab itself is a classic example of a mega monolith repo and thousands of repositories within our own organization. So that's where we had a pretty crazy question, what if we took all of GitLab's data and turned it into a graph that agents could query directly. And we did that by building a highly distributed system in just 3 months that essentially is an indexing engine. And as I show you here in the schema, what we can do is we take -- actually, just the other week, we've been able to index 160,000 repositories into code graphs. And as you can see on the right here, we take those graphs and we marry that data to the rest of the software development life cycle. And that unlocks a variety of different questions, which we'll jump into.

But one thing to touch on here is we built this for scale. So all of this can be indexed namely 500 million nodes and 2 billion edges in just 15 minutes. So to touch on that a little bit more and how this improves agentic outcomes, I'd first like to ask everybody, has anyone ever gone through a painful experience of refactoring a code base. I don't know, maybe show of hands. Me too. It's not fun.

So with that, let's pull up a little bit of an example of what Orbit can do for you. So I'm going to kick off this run here or what we call the Orbit benchmark. And as you can see, we'll go into a little bit about what Orbit does. But we've got this orbit benchmark here, and we've asked a very relatable question to GitLab itself. So at GitLab, we are actually currently exploring decoupling, authentication and authorization within GitLab itself. And as anyone knows, if you have a mega monolith, decoupling such a critical service is a huge pain. And if you're doing that manually, that will take months. And if you're doing that with agents, there's high risk involved, right?

And in this repo, how many files are there?

There's around 50,000 files, and it's millions of lines of Ruby code. And so if we're going to make any change, we want to know what's going to be affected and how. So if we go back to the benchmark here that's already running, we've asked a prompt saying, can you get the complete authorization class hierarchy and all of its front-end consumers within the GitLab monolith. And remember, this is 50,000 files.

So let's jump into a little bit of what's going on here. So Claude code without Orbit is doing the normal thing that you would expect any agent to do. It's searching through all 50,000 of those files. It's using the classic tools like grep and text search and essentially assembling the entire picture from scratch.

On the right, the agent has access to Orbit. And what we've done is built a universal code indexing engine that indexes over 11 languages into a unified graph that essentially acts as a prebuilt map for your agents to query directly. And what that means is that agents are able to write their own queries here, as you can see, and get back the entire authorization tree in just a few hundred milliseconds. And so that effectively allows you to pretty much answer most of the questions that you would normally ask an agent, but get that answer back a lot quicker with a lot higher quality.

And as you can see, the agent on the left is still running. And here's the output report with all the authorization classes. And to increase accuracy, we've leveraged a lot of different techniques like SSA and various compiler techniques. So...

And Angelo, I think what I saw when you scrolled up, the agent on the right with Orbit is already done cooking at just a minute and 15 seconds. We're still chugging along on the left. But I have the most important question of all, which is tell us about the data quality.

So that is the most interesting part about this whole experiment that we've been running. So as you said, it's still running, and so we won't bore everybody with the results there. But with this previous run, you can see that in just 1 minute, we completed the results, and we just saw that with the previous run. And it took over 11 minutes. So this is -- Manav, you and I were just talking about this. This is you and I, if we're coding, we can stay in the loop on the right here. And on the left, as a developer, maybe I'll go get some coffee, but we don't want to lose our flow.

So with that, the last thing I wanted to touch on that's very interesting about this benchmark is the accuracy. So we did something to measure in a deterministic way the output of this report. What we did is we took the actual Ruby on Rails run time. We generated a script to get that same class hierarchy. And as you can imagine, both of these Claude codes don't have access to that run time. So what we're doing is comparing the classes that come from the actual run time itself with the results from the agent. And we've instructed the agent to output those classes. And what's very interesting is it's not as complete in the amount of rules that it found from the authorization classes, but Claude Code without Orbit actually hallucinated 1,000 more rules as compared to Claude Code with Orbit.

That's 1,000 more rules that you have to manually go make sure that got right.

Exactly. Yes. And so that's what we're talking about with agent trust. So with that, we can imagine how this is super useful for a developer like myself on your local machine, but we didn't want to just stop there. We wanted to empower all of organizations and enterprises with this technology. And with that, we built a service. So Meg, why don't you show us what else we've been cooking?

Yes. So as Angelo is alluding to, we didn't just stop at indexing the code base. We indexed your entire GitLab instance, which means you have access to all of your rich GitLab SDLC data. So one of the perfect examples is a pipeline analysis. For all the DevOps and platform teams in the room, you might have heard that 1 in 3 CI pipelines fail, which can really add up at scale. And in the paradigm before Orbit, you could really only analyze your kind of pipeline health at a single project at a time. But now with Orbit because we have these traversal and aggregation abilities, you can understand thousands of pipelines and thousands of projects and their pipelines at once.

So another one of our goals with Orbit is to make Duo agent platform even more capable. So we're jumping in here to a agentic chat, and we're going to ask a pretty heavy hitting question here. We're going to ask the agents to deep research our most recurrent failing pipelines and their jobs over the last 60 days.

So in GitLab Org, that's 8,000 projects and it's 12 million pipelines. This is a huge question that we're asking. So we have 2 instances. We have GitLab Duo agent in the old paradigm on the left with access to just the GitLab API, and we have the same GitLab Duo agent on the right with access to Orbit. And I'm going to fast forward into a completed output and show you what we're looking at here as well.

So on the left, let's zoom in for just a moment. The agent says to us, I'll be straight with you. I can't do it. And this is a limitation, not of GitLab Duo, but of all agents today because they don't have access to Orbit. To achieve an analysis like this, it would have to make tens of thousands of API calls and the API would just time out.

But we have Orbit now. So our agent on the right is actually traversing the whole graph and aggregating the job failures. It's understanding the projects, the failed pipelines and the common failed jobs underneath them. It's giving us a CI compute cost attribution and looking at those common failed pipelines and then ultimately taking us to the most important question of all, which is what do I change to resolve this. So as we continue to see the agent with Orbit, it gives us the shared CI template hotspots and points us exactly to what I'm going to work on today, which is resolve these. And with this resolution, we're probably going to save developers a few headaches and maybe a few dollars on CI compute. This is just one of the possibilities that Orbit makes possible. We've been doing a lot of cool stuff. And Angelo, I know our engineers have been asking some crazy questions because Orbit can go further than any agent ever could. How would you tell us some of those wild things our engineers have been looking at?

Thanks, Megan. And that's a great question. And we have the team sat down, and we've been just playing around with it and asking some of the most wild engineering questions that you would ask when you can ask anything about your GitLab instance. And just some examples here that we pulled up off the cup.

One of them is find all the dead repos across GitLab org or find all the critical services within the fulfillment department and who maintains them and who is the expert in those services. And then one of the craziest ones was we actually took the call graph technology that we built and indexed all 5 years' worth of repositories, then use the graph that's available for the SDLC and did a cross comparison and we were able to basically get a trend line of various security fixes throughout GitLab over the past 5 years.

So you basically, whatever you can do with your imagination is the limit. And like Manav said, if the nervous system is what lets your body act coherently, then Orbit is that for your entire software organization. And until today, your agents have been definitely flying blind without one.

And agents in the GitLab Orbit just work a lot better as a result.

Yes, we're sending them to Orbit.

Amazing, amazing. Thank you. Great job, Angelo. So what you saw there with GitLab Orbit that is now available in public beta for all of you to use in your GitLab instance is your agents will work just a lot faster. Getting a response in a few seconds instead of a few minutes using up to 4.5x fewer tokens. And most importantly, you will see up to fewer than 45x hallucinations, which is a real, real important thing.

That's why today, we are also kicking off a community hackathon where all of you here as well as throughout the world can join for the next 2 weeks and see what you can do with Orbit and all the different agents you use inside and outside GitLab and see how -- what you can build with that.

All right. Next, let's get into the immune system. This is about making sure that you, your teams and their agents can build and ship code safely. With GitLab Ultimate, you already can be proactive with security and compliance because every tool you need is already built into your whether that's security scanning, secret detection, software composition analysis, vulnerability management, policy enforcement, making sure you're meeting all your compliance frameworks, all of that's built into the same platform that you use to build and ship code to make sure you're always secure and always compliant.

But here's the thing. In the agentic era, the security and compliance exposure is only multiplying. And that's because agents, just like they are great at writing code, they're also great at exposing vulnerabilities, and they can do that faster than we can react. The typical cycle goes like this. A new vulnerability is found, and there is all this excitement inside a company to decide, hey, do we have that vulnerability? And as you go search for that, it's very common that we find that there are coverage gaps in our testing, and we are not testing all of our code repositories to find if that vulnerability exists.

When we set up those -- that security testing and cover the coverage gaps, we find that there are a lot more vulnerabilities to address. We have to triage them. We have to fix them, and that takes weeks of coordination, expanding the risk window for you. All of us are also using agents across the software life cycle. So the compliance team also wants to know if those agents are acting with the right rules, with the right setup and everything is in compliance. And then we invariably discovered that we need more controls to make sure that anything agents do from this point onwards will always be compliant and meet our regulatory requirements. That's why we have expanded on top of GitLab Ultimate recently by bringing agents to security to automate a lot of these tasks for you, so you don't have to wait weeks. You can address these problems in minutes. And today, we're introducing new governance capabilities for agents so you can always remain compliant. To show you how this all works, please welcome members of our security team, Alan and Michael.

Hey, Michael. How are you?

Great. Thank you.

Let me pick up from the first problem Manav earlier called out. Security can't keep up. And let's walk through a common scenario that we're all familiar with. You wake up on a Monday morning and new vulnerability dropped in. Our team thinks it's in production. This best question isn't how to fix it. It's whether we know where it exists. Alan, what can we do about this?

Sure. We all know the page, vulnerability report based for the project where you know you have your scans enabled. So you can quickly go and solve it either by using resolve with AI or by using one of your specialized agents like security analyst agent or one of the own -- you build for your own organization. But that's not really a problem I would like to solve today because you see the biggest gap in security is rather related with the lack of scans running for your project.

So you don't know if they're running or not. So let's go to security inventory and check that. And you see this is the problem I was talking about. We have scans enabled only on 2 projects where we have this vulnerability found. Let me quickly fix that. So I know I would like to enable those scans, but only offer most critical projects. So let me do that by selecting business impact and then choose business-critical projects. So now I have a list of projects where I would like to enable those scans. And just by going through some -- through few clicks, you can just enable those scanners one after another, fast, secret detection and dependency scanning.

And now you remember, we had those pills, those pills that you see were white here, so no scans were running. Now for every single of the project, health scans are running whenever you push changes to those projects. And on top of that, let's also ensure that we have enabled our Duo workflows like fault positive detection and vulnerability resolution workflows. So these are all enabled for all of those projects. from this moment.

So we got one vulnerability. Now we have hundreds.

Months of coordination, hundreds of vulnerabilities are replaced by one critical action. Your critical asset are covered, the agents are watching. But wait a minute, like you said, we had one critical vulnerabilities and now we have over 200. And how do we know which one we really care about?

Sure. I mentioned agents that are running in the background and understanding if vulnerabilities that were found are false positive or not. So you noticed there is this icon associated with which vulnerability saying if that vulnerability is a false positive or not. And I can use filter to filter out the noise. So let me do that. And just like that, we have reduced the noise. And also, we just heard about Orbit. Security analyst agent was also integrated with Orbit to help you understand everything about your vulnerabilities and how about the code is being exposed in other projects as well.

That's amazing. We've just brought down the vulnerabilities from over 200 down to a little bit over 20. But these are still real vulnerabilities, and we still need to fix them.

Typically, before the pre-agentic era, you have to book your meetings with your asset team, coordinate -- a lot of coordinations and then you need to discuss about what is the best possible path to actually resolve these vulnerabilities. That would take a long time. Alan, I know we just shipped something that could make this even faster.

Yes, I love the challenge. So I mentioned those activity icons next to each vulnerability. So I mentioned they are telling you if there is a false positive or not, but there's also new icons here added. So you see we have information about for each of those vulnerabilities, AI agents already created merge request to fix it. So I can go and immediately go to this merge request, talk with the team, let them review it and merge that change immediately.

Isn't that amazing? Instead of months of coordination, instead of having these meetings with the asset team to discover these vulnerabilities to think about what's the best path forward. The meetings you're having with this asset team is to decide if this MR is good to go. The fix is right here waiting for the developers even before they open their laptop.

Amazing, amazing. That would save everybody a lot of time. What about the second problem? Because invariably, we all have compliance teams in our companies as well. And they want to know if these agents that we are using are doing things the right way. And are we exposing new risk? Are we meeting our compliance regulations? What's the story there?

Manav, that's a big problem. And because of the EU AI Act, regulators and auditors are starting to require that most teams and organizations can prove that their AI agents acted within predefined boundaries. And when auditors walk into the room, most teams have no answer for them.

Alan, do we know what our agents are doing?

Sure. Let me go to the part of the GitLab that we're building, AI governance, where we can have all agent artifacts, all interactions agents did and all tools that they were calling and whenever they had approval or not.

So I'm in a session, and I can view more details about each action that agent did. And I can quickly go to the session details to learn more about what happened. And it looks like we have dismissed vulnerability without human approval. So let's see what we can do about this.

That's a problem. How do we make sure that we can control the agents from now on.

Yes. So that is why we are working as well on the second part of the AI governance called Tool Management. So within Tool Management, you're able to decide how your agents are interacting with you and in this tool. So either you would like them to write, read and if you would like to allow them to do it, if you would like to decide rather, they should always ask or always deny so they will not be able to do that action.

So in this particular case, I was talking about dismissing vulnerability. Let me switch that option from always allowed that was previously configured to always ask. And now whenever I would like to dismiss a vulnerability, the agents will still provide me a helpful guidance, but at the end, it will ask me for my approval.

So agents can still help, but I just need to approve it.

That's awesome. And let's see what the agent just did. It caught the violation, fixed the policy, proved it worked within one platform, GitLab. This is exactly what the EU AI Act asking for. And when auditors want, they want this today.

Yes. And that is just to start. Security policy store that we're working on will also include more capabilities like allowing you to decide about triggers, rules and actions that should be taken based on the situations that are happening in your code, either related to AI, security or compliance. So we fixed the coverage in seconds, then we had remediations in minutes and compliance already built into GitLab.

Awesome. Speed without control is more risk. GitLab gives you both, native security with govern agents. And let's recap a little bit. First, we brought agents to security to improve security coverage, detect false positives and accelerate resolutions. Part one, done. Part 2, we brought governance to agent. We both saw what agents can do and the risks of doing that. I want you to be able to control what those agents can do in the future. Over to you, Manav.

Great. Nice job, team. Very good.

Thank you.

Can't wait for you all to try the new security for -- new agents for security and the new governance for agents.

All right. Let's move on to the last part of the Agentic infrastructure, which is the orchestration system. In January this year, we introduced in general availability Duo agent platform that Bill had referenced earlier. Duo agent platform brings agents, specialized agents and Agentic workflows for you and your team at every stage of the software life cycle, so you and your team can be a lot more productive. Since GA in January, we've been busy making Duo agent platform even better. Now when you go log into GitLab, you'll see several specialist agents available for you that are task-tuned to handle specific goals for you and your team right out of the box, whether that is helping you plan what you want to work on next or fix security issues like what Alan and Michael had just shown and many others.

You'll also see built-in agentic workflows that automate complex tasks by chaining agents together in a predetermined workflow that we know works. For example, you can now with one invocation, with one click or one CLI command, go from an issue to working software and agents take care of everything else in the middle and many other agentic flows that are now available out of the box.

Also recently, we have introduced several agentic triggers. So you and your team can automatically invoke agents when new code is introduced or when things happen in your environment. And we've also introduced several manual triggers across different surfaces that you and your team work in, not only in GitLab, but in your IDE, in your CLI and many other places that your team works.

So let's see the power of Duo agent platform. And please welcome Shekhar, our distinguished engineer.

Hey, Shekhar. How are you?

It's great to be here. So Manav spoke about the platform. What I want to talk to you about today is how our customer and our internal developers are using the platforms. So I typically start my day by looking at my backlog. So I've a little work item assigned to me in the backlog, which talks about adding product search functionality to the home page. Now I can use the UI to do this, but I prefer the surfaces that I use. So I like to use my IDE, I like to use my CLI.

Shekhar, maybe we can get the demo up on the screen first. There we go.

Oh, there we go.

Yes, yes.

So what I'm going to do is I'm going to quickly copy this issue, and this issue is well written, by the way. It's been written by Duo planner. So it's got all the materials I need to actually start iterating on this. So I'm going to go ahead and copy this, switch to my terminal. And then in the terminal, I'm going to go invoke the new Duo CLI.

The new Duo CLI now available.

And all I want to do is go ahead and ask it to implement this issue. So it's going to go ahead and -- because it has organizational context, it has got -- it's got all the rules that we need, it's going to go ahead and actually start implementing this issue. But in the interest of time, it's going to take a bit of time. I'm going to go ahead and switch back and show you an issue that I actually implemented this morning.

So this is an issue I had asked Duo CLI to implement. So what it did, it went ahead and created an MR. And it's exactly what we expect. It made a number of commits. It went ahead and made the changes that I needed, right? It went ahead and tested the MR as well to make sure it worked. But what's really interesting is that as soon as the MR was created, automatically, Duo Code review, went ahead and actually started reviewing this MR.

So it went and it went ahead and made several recommendations. So it said, hey, your styles are not in order. You can make a few changes as far as hard coding is concerned. You can go ahead and actually make some security changes as well. And it's doing this because it understand my organizational context. It's doing this because it saw the review instructions that we've given it. And we can have these review instructions at various levels. We can have it as a project level, we can have it at the group level so that's applicable to all your projects within that group. And that's really powerful.

And that's really powerful because you can provide exactly what you want from an organizational perspective. You can do things like provide it exactly with CSS refactoring rules you want. You can provide the style of code you want, you provide all the security things that are important to you, and it will do that. And these review instructions can be applicable to certain files. And we've been working hard on making the code review agent as good as it can be. So we've been working hard on trying to make this code review agent as good as it can be, and we've been making constant improvements. And now with our own benchmark...

You may have to go back to your podium, Shekhar.

So in our own benchmark as well as third-party benchmarks, we have made tremendous improvements. So now we are top 5 in the Martian code bench, and we're extremely proud of that.

So now I'm going to switch back. And I could have gone ahead and actually gone ahead and looked at these changes. But what I'm going to do instead is I am going to ask Duo developer to implement these changes. So I don't need to do anything. I just go ahead and ask Duo developer, can you please make these changes based on these recommendations, which are great.

And Duo developer actually went ahead and did this. So it went and implemented the security fixes. It went ahead and implemented all the style changes that I needed it to. It went ahead and did all these things for me. And that's really the power of automation. And we've been doing a lot in terms of automation. So as Manav mentioned, we now have triggers. The triggers based on different GitLab events can automatically invoke the agents that you have in your catalog.

And the triggers are really useful. So for example, when a review is mentioned, it can go ahead and invoke an agent. When there's a merged conflict, it can go ahead and invoke an agent to actually fix the merged conflict. And my favorite trigger is the pipeline events trigger. And the pipeline event trigger, what it does, it goes ahead and fixes pipeline. Now as a dev, it's been a constant source of annoyance to actually go whenever a pipeline fails, I have to switch context. I have to break out of my flow. I have to go and look at what the pipeline is doing. I need to go and push a new change, figure out the logs, all of that.

And that takes me away from the flow. It stops me from what I'm doing right now, and I need to then switch context, right? So the pipeline event trigger is something we've rolled out internally and our teams love it, right? It's automatically going in. And every time there's a failed pipeline, it goes fixes it automatically. So this is an example of a real project. So this is our CLI project. And the pipeline fix trigger here is going ahead and running an agent, which goes and says, hey, there's a race condition here. I'm going to go and fix that race condition.

Or in this case, it looks at it and realizes it's a flaky test and it knows that because of the organization context and says, this is a flaky test, I'm just going to restart the pipeline to fix this. And that's really powerful. So to recap, I could have done all of these things, right? I know how to fix code. I know how to fix the pipeline, look at the logs, all of that. But every time I do so, it takes me away from the work that I want to do. And this is where the Duo Agent Platform seamlessly fits in and slots in. It is able to fit into your existing workflow and help you automate the parts that you are interested in automating.

And Shekhar, it's not just you and your flow because it's very common that if I'm writing code, I'll ask somebody else to review it. So I'm taking them out of their flow. But if I'm running into a pipeline problem, it's common for me to go ask the DevOps or a lead engineer to help me fix that pipeline. I'm taking them out of their flow as well, right? So this is all about giving you the right productivity for you and your teams to do what they do best.

Exactly. And there's a cascading effect. And so Duo Agent Platform lets you do -- automate the way you want it to, and it gives you speed with control. Back to you.

Amazing, nice work Shekhar.

Thank you.

What Shekhar shared there was really about helping you and your teams be a lot more productive. We've been looking at how our early customers over the last several months have been using Duo Agent Platform. And here are the top 5 use cases that we see across our entire customer base with Duo Agent Platform. And some of these ROI numbers are staggering.

For example, with code review, we've seen our customers on a per person basis, save a minimum of 20 minutes because agents are doing the code review for them as opposed to they themselves doing that code review. And when you take that and the labor cost of doing that code review and the fact that a code review only costs $0.25 per run, that's 100x ROI. The rest of the ROI numbers are calculated similarly, and I can't wait if you haven't used Duo Agent Platform already, check it out, see how these ROI numbers play out for you in your particular environment.

All right. Let's move on to something else. Now this is not a technical challenge. I want to share with you a new commercial challenge that's showing up in the agentic era. You see the way you buy software, any software and GitLab for that matter as well, you buy software through fixed contracts. But in the agentic era, what you need is constantly changing. And your fixed contracts force you to define what you need for the next year, in some cases, multiple years up ahead. Within the agentic era, I've heard many of you say, hey, I may need more people in my company access GitLab because I want to give product managers and designers access to GitLab so they can contribute and code and help with the various projects that we are doing.

I've heard many of you say that you don't know how much AI usage you will have a few months from now or a couple of years from now because AI technology is evolving. How your teams use AI is changing, how each person is enabled to use AI is changing. It's really hard to predict how much AI usage and therefore, how many credits you need. With all of the new innovation that we just introduced today and many more coming in the months, they're also going to be built on a credit basis. And it's going to be really hard for you to predict how much you should budget for the credits you need for those new capabilities.

The net is that the fixed contract model and the agentic era were not built for each other. That's why today, we're introducing GitLab Flex. It is a new buying program that allows you to commit once, just like you do today and then decide how you use the dollars you spend on GitLab on which product and how much of which product at any time. You can make that change as your needs change. To show you how Flex works, please welcome the Flex team, Courtney and Jerome, to give you a quick demo.

Hey, everyone. I'm Jerome, Director of Engineering.

And I'm Courtney, Group Product Manager.

So Courtney, for this demo, how about I be ACME Inc.'s billing account manager? That way, you can do most of the talking, and I'll just click the buttons.

That sounds good. But hey, don't undersell it. You did build most of those buttons.

So at ACME, we are on a Flex contract. We've signed a $1.2 million annual commitment, and we're currently 6 months in. Let's take a look at our setup. We currently have 500 ultimate seats along with 50,000 Duo Agent Platform credits, both of which are reserved.

That part is part of what makes Flex really powerful. For the products where ACME has a good sense of what they'll need, they can reserve spend upfront and lock in a volume discount. How does that sound?

That sounds great. I love saving money.

For the products where maybe you're not quite as sure about your spend, you can enable per use and pay as you go, drawing from the same pre-committed pool. So Flex offers you both, discounted economics on what's predictable and the flexibility to spin up new things as your needs evolve. Speaking of which, how are ACME's needs evolving, Jerome?

Let's take a look at the seat side first. So for seats, we have 500 ultimate seats reserved, and we're using pretty much that amount. The credit side tells a slightly different story. For Duo Agent Platform, we've reserved 50,000 credits, but we've already exceeded our allocation. Teams are really leaning into Duo Agent Platform and AI usage is growing quickly.

Hey, that's a great problem to have. And that's the kind of split that a lot of customers find themselves in mid-contract. The shape of what you committed to in January is not necessarily how you're pacing come June. Let's take another example. A contracting team rolls off a project and suddenly, the 50 seats they were using last month are no longer needed next month.

So now finance is asking, we have all of this budget locked up in unused seats, but we're getting so many requests for additional AI spend. What do we do? Under a normal contract, nothing. You would wait until renewal when you could readjust. But since ACME is on Flex, maybe we can see how that would work.

Yes. So on Flex, I can change our upcoming months reservations. And here, you can see I've got 500 seats right now. Let's bump that down to, say, 450 to account for the 50 contractors that are rolling off. For the Duo Agent Platform credits, let's increase this from 50,000 up to, say, 60,000 just to account for the increased AI usage. You can see that the overall commitment has stayed the same, but it's been reshaped to match our needs.

Wow, that seems really simple. But I have to ask, what about budgeting guardrails? I know that's top of mind for a lot of customers.

So our usage caps actually live here as well. So I can set a usage cap of, say, 70,000 credits. This is slightly above our reservation amount, but it puts a ceiling in case usage spikes.

Okay. Great. So in finance, you can get predictability at the contract level. And in 18:11, GitLab added per user credit controls, which means that GitLab admins can allocate additional credits to power users while making sure no one user blows through your entire AI budget.

And as you all saw today, we've launched GitLab Orbit. So let's give that a try as well. So I'll allocate some credits there, say 5,000 credits.

Jerome, 5,000 credits? Did you not see the Orbit demo? Let's bump it up a bit.

Okay. Okay. Let's do 10,000 credits.

Better.

So with Flex, Orbit lives on the same rate card. I can just lock it in and the commercial side is all handled.

So ACME's commitment didn't have to change. Their overall contract didn't have to change. But what they're getting from GitLab evolves real time with their needs, without Jerome having to go through another procurement cycle to get there.

So that's Flex, the buying program that evolves with your needs.

With Flex, you commit once and then adjust as your year unfolds. You get volume discounts on what you know and flexibility on what you don't. And whether you're running GitLab in our multi-tenant cloud, in a self-managed instance or in a dedicated tenant, GitLab Flex is available today. Customers can now request orders and your sales rep is eager to get you on board.

Amazing. Nice work. Good job. All right. So as Courtney mentioned, you can use Flex today, whether you are a new customer, you have an existing contract or have an upcoming renewal. If you go to that URL, you can request a quote and move your contract to Flex today and take advantage of everything that we talked about.

All right. So let's recap what we saw today. GitLab, the DevSecOps platform you know is now the agentic infrastructure. The motor system got a lot better with the next generation of Git built for machine scale. The nervous system now has Orbit, so your agents work better, faster, cheaper, but more importantly, you can answer questions that you never could before. The immune system now brings agents to security and governance to agents, so you can stay compliant.

You now have Duo Agent Platform that has gotten a lot better with new agents, new agentic flows and new triggers available to you. And then finally, you have Flex where you can commit once and shape your GitLab usage as things change for you. That is the new GitLab. Thank you.

And now to show you how all this innovation turns into value for you, our customers, please welcome our Chief Customer Officer, Sherrod Patching.

Thank you. Well, we've just shown you some of the latest innovations from agentic infrastructure in action. Agent actions that are able to go through next-generation source code management with rich context, all with the level of visibility and governance that you need. I'd like to tell you a little bit more about a study that was led recently now by Forrester, the Total Economic Impact study on the Duo Agent Platform. We're revealing these results today, and I am thrilled to tell you about what we found. 40% faster time to remediation.

You saw some of what we talked about today, being able to bring context and potential remediation into developer flow and a 40% faster time on average. 80% faster time for developer onboarding. I know many of you in this room look at time to first commit as one of your key metrics. And whether it's a new developer coming on to your team or whether changing applications, being able to find contacts there within flow, we saw an average in 80% faster time.

And overall, we saw a 400% return on investment for these customers. They were expecting somewhere between 20% to 40%. But as a result of the agent platform, we're excited to tell you that they saw 400%. So joining me on stage today, I'd like to tell you a little bit more about a customer story, showing you this in action.

I'd like to welcome on to stage Mercedes-Benz. Mercedes is one of our customers that was able to actually transform how they think about the software development life cycle using GitLab. And they were able to see across thousands of developers the ability to actually go from what was the previous implementation all the way through to the net new generation using software development life cycle in a highly regulated company with GitLab. So to tell you more about this, I'd like to welcome on to stage Bastian from Mercedes-Benz. Welcome, Bastian. Thank you for coming. All right. Have a seat here.

Thanks. Thanks for having me.

All right. So I have a few questions for you. So you recently launched the CLA, C-Class and GLC on MB.OS, Mercedes' in-house vehicle operating system. What does that innovation approach look like? And how is GitLab helping your 20,000-plus engineers on that journey?

Well, first of all, you're right, we launched the CLA last year, followed by the C-Class and the GLC and all run our latest version of MB.OS, our in-house developed operating system. Not so long ago, we had several dozens of suppliers who equipped us with control units and the software and integrating all of them was quite difficult, but we moved towards fewer control units with more capable ECUs where we develop a bigger part of the software.

So we control the crucial parts when it comes to autonomous driving, infotainment, powertrains, et cetera. But of course, this comes with some challenges. So different to maybe web or app development, embedded software development is kind of quirky. So we have to deal with embedded tool chains, some tools when it comes to SaaS and DaaS, which were never meant to run in the CI, but rather on Windows.

But luckily with tools like Fleeting Runners, we can run also those tools at scale, running several million jobs regularly, moving several petabytes of data of artifacts on the platform. Well, we run the platform in different flavors, where we have a greater degree of flexibility when it comes to our back end and web services for the connected vehicle. We can use GitLab Dedicated to use all the benefits of the SaaS product that where privacy is key, and we have the highest level of control of our data also being present in different regions of the world where required, we go with GitLab self-hosted to have this greater degree.

But when we started in-house software development, it wasn't always like that. When we started, we had different instances of Jenkins, Bamboo, Bitbucket, Azure DevOps, et cetera. And over the last years, we all brought this together to GitLab because GitLab gives us this unified user experience. We can govern in one place, can share best practices across all those domains, and we're pretty happy now having more than 20,000 users on our platforms.

Awesome. I love that. And the different flexibility that you're able to bring in that consolidation over time. I think I've been there since the beginning of the journey with you. It's been fun to see. Okay. Like every technology leader here, you were navigating AI for software engineering. But with automotive software, there comes a level of safety, accountability and review burdens that most application teams don't ever face. So how are you approaching the use of agentic AI for your software delivery?

Well, we are doing a lot of different approaches. I think the key is an agent can only be as good as the context and semantics, which are fed to them. And therefore, I'm also super excited about what we saw already. Context and semantics in our domain besides the source code, of course, itself means the functional requirements, but also the nonfunctional ones, safety constraints, architecture patterns, et cetera.

So key is that we move this data out of proprietary tool silos we maybe had in the past, but make it accessible within Git or in graphs so that the agents can operate on that to have the right input. But at the same time, also the validation of what we do in CI becomes even more crucial that we tighten the loop where we see what the agents did, but also agents ideally can correct and that's also what we saw just a couple of minutes ago.

And what we really also like is that with GitLab, we have this flexibility. We can use the GitLab Duo feature set, but we can also connect other harnesses like Claude Code or so because, I mean, it is still a young thing. We're exploring a lot of options and having this flexibility without overcommitting into one lock ecosystem is a great advantage. For Duo itself, I can only echo what we also just saw chat and code reviews are amongst the most loved features on our end.

Fantastic. Thank you. And I know we've been talking a little bit before this also on just the context that Orbit will bring and the ability to be able to make the decisions within the MR and the time savings you'll see there.

Exactly.

Great. Okay. You have an internal framework on AI native engineering. As we launch Orbit public beta today, how does the richer SDLC context fit into that picture?

Well, I think it fits perfectly. I mean, with AI, we can get at such a high pace. But also as we heard already, we need speed with control. And we have automotive regulator standards like ASPICE which require traceability and human accountability. And accountability is especially important for us. I mean, we put people in our cars who trust their life to our cars. So we, as Mercedes, have to stay accountable that the software is safe and sound.

And I think mastering this human in the loop approach, letting agents freely where they can run freely. But then again, having the humans in the loop, reviewing the results, approving, giving consent to what the agent did is right, I think this is key. And there, we see GitLab is very well set up as this control plane where we integrate the software and take that accountability.

Awesome. Thank you. All right. Last but not least, a favorite question. How are you thinking about measuring whether or not AI is actually improving productivity?

Yes. Well, I think, first of all, all the metrics we did in the past in measuring productivity like DORA metrics, et cetera, are more valid than ever because ultimately, AI is a means to an end in becoming more productive. But also at the same time, we have to justify the spendings, of course. And I think everybody who uses it knows there are good and bad patterns, how to use AI. So what we would like to see is a good integration of the DORA metrics or productivity metrics with AI consumption and insights how our users are using that, seeing best practices, where are we efficient? And I think you have also a nice guest coming up who will dive into that looking forward.

Yes, yes. We'll show him in a moment, too. We're excited to have Gene here. Great. Well, Bastian, that is the last of my questions. Thank you so much for joining us today. We're thrilled to have Bastian on stage.

Thank you.

All right. So as you can tell, GitLab has the potential to transform not just software development, but also to what you see on the road and the experience that you have. I love the fact that Mercedes is just a fantastic example of speed with control.

There's one more element as you think about what needs to really happen for rich software development life cycle to be true for customers like Mercedes and others. And that is the -- is our ecosystem partners and their presence in bringing all of our customers from agentic -- essentially agentic testing all the way through to agentic engineering. So one of those key partners for us is Google Cloud. And here to tell you more, I'd like to welcome back on the stage, Bill and Daniel Rood from Google Cloud.

All right. Daniel, thank you so much for joining us today. Google and GitLab have been partnering for years.

We have.

In fact, it's, I think, maybe the best kept secret. I don't know if people realize, but thousands of customers benefit from the partnership every day because gitlab.com runs on Google.

It does.

And I know many of our strategic customers also choose Google as their infrastructure -- cloud infrastructure provider for their self-managed instances. So tell us a little bit more about what new options we're introducing today.

Well, I'm really excited to announce that for providers, GitLab certified managed providers, there's now an option to deploy GitLab on Google Cloud with sovereign deployment options in EMEA. And I think this is really important, especially for regulated organizations as if you think about those workloads that need to be compliant within certain regions or against certain regulations, we now offer you the controls in order to do so and for you to be compliant with your auditors. So I think that is really big news for today.

Customers are going to be really excited about that new option, get out of the toil of managing your own instance on your own infrastructure and take advantage of Google's managed service providers, amazing. Now you're not only a cloud infrastructure provider, you're also a model provider, and we've been proud to offer both Gemma and Gemini model support inside Duo Agent Platform. What else do you have for us on that front?

Yes. So maybe as an introduction, so if you think about the Google AI family, there's a number of models that we offer for your customers. We have Gemini Flash, which is our working horse model for your thousands of times a day workflows, and it's cost efficient, it's token efficient, and it's still a state-of-the-art model. Then we have Gemini Pro. Pro is really a powerful model for your most complex workloads. And then equally exciting is our open-weight model, Gemma 4.

And Gemma is an excellent model for those who want to run these capable models on the edge, maybe even on device or in air gap solutions. Now all of these models come together in Gemini Enterprise Agent platform, which is tightly integrated with Duo Agent Platform. And so we are offering that today. Now the news for today is that we announced just a few weeks ago, Gemini 3.5 Flash, which is now also available in Duo Agent platform.

Awesome. And I know Gemma 4 as well. Gemma 4 for our self-hosted customers in air gap environments because we have many regulated customers who are required to be air-gapped is going to be a really powerful option as well. So thank you. Speaking of the Gemini Enterprise Agent Platform, we were talking earlier about cost and how everyone is talking about the cost of AI and the ROI and being able to understand where the cost is going. Duo Agent Platform provides the visibility into the cost of agents running within GitLab and the use cases that are under action. What does Google provide on that front?

Yes. So if you think about the partnership, there's probably a couple of elements there. So first of all, we talked about cost-efficient and token efficient models. So like a Flash or Gemma 4, they will help you make the right decisions for your AI workload. So I think that's an important one. For those who have a commitment with Google Cloud, through the Google Cloud Marketplace, you're now able to draw down against that commitment with GitLab.

So I think that is really important because what that also does is it gives you the flexibility not entering into new budget cycles. It gives you one view of your cost all the way from GitLab platform to inference and infrastructure with one bill, the other bill and also one view of everything you're doing. And what is really important there is a lot of the tech leaders here in the room and online as well as I'm sure your CFOs, they all are interested to understand how much are we actually spending on AI this quarter or even how much value are we getting out of our AI usage.

Those are all questions that we can now start to answer with that setup. So I think that is really important. And so if you think about as a customer of GitLab, this go-to-market integration between the Duo Agent Platform and Gemini Enterprise Agent Platform as part of the marketplace, you now can manage your AI workloads end-to-end.

Amazing. So really, we've talked about 3 things today: GitLab as a managed service on Google Cloud, now available through managed service partners, Gemini 3.5 and Gemma 4 in GitLab Duo Agent Platform available today and use your Google commitments to buy GitLab licenses and credits. An amazing partnership. It continues to get better and better every single year.

We're excited.

Thank you so much, Daniel.

Thank you very much, Bill. And definitely also really excited about all the things that are coming up in our road map in the coming weeks and months.

Look forward to it. Thanks again, Daniel. All right. The agentic engineering is here. Hopefully, you're starting to see how we're bringing agentic infrastructure together with coding agents to deliver speed with control. You've heard amazing customer stories from Mercedes already and more to come about the proven ROI of what we do, both in GitLab and now with agents and Duo Agent Platform and amazing partnerships like with Google and earlier Anthropic.

It's an incredible time to be part of GitLab. I hope you're starting to see our new mission in action, which is to unlock every team to ship trusted software at the speed of imagination. I think the most exciting part of Transcend though is often not all of the technology, the amazing demos. But what I hear most often from customers is they love hearing from our partners and our customers about how they use GitLab and the benefits they're seeing.

And so it's my pleasure to welcome back on stage, Sherrod and our panelists...

To continue.

All right. Well, welcome. Thank you for coming. So I'd like to introduce you to our panelists. This is Ryan Harvey, he's Head of AI Engineering at Compare the Market. Matteo Figus, he's AI Engineering Manager at AWS. Mans Booijink, Operations Manager at Cube, I think I got it right.

Yes, you did.

And Gene Kim, researcher and author of The Phoenix Project, DevOps Handbook, and most recently co-authored Vibe Coding with Steve Yegge. Welcome. Thank you all for coming.

Okay. We're going to start with one, and we're going to have each of you answer this. We'll just go in order, and then we'll go from there, I think. In fact, no, Gene, I'll start with you.

So to start. When do you think about software innovation in your organization or in those you advise? What has changed the most in the last 12 to 18 months because of AI?

Oh my gosh. What hasn't changed? I mean this morning is probably a proof of that. I mean, so having studied high-performing technology organizations for 27 years, I've had a lot of fun in my career, but I think like so many of you, I've never had as much fun as I'm having right now. And it's so strange where we're entering this area, where coding for planning purposes is becoming free and instantaneous. Well, I don't know about free, but I mean, it's certainly pretty close to instantaneous. And that means like every process we've created is like now wildly insufficient, budgeting, procurement, prioritization, getting access to customers.

And so -- we heard from Nick from Anthropic mentioning how their teams are generating 8x more output than a year ago. But some of you might say it's just the frontier AI labs, but then we heard from the -- Angelo from the Orbit team saying that in 1 month -- I talked to him this morning, they made 3,000 merge requests. That's like tens of thousands of commits in a month. And some of you will be excited by that, some of you will be scared by it, and some of you will just say, "Oh, that's slop. But I think as leaders, we all have to get ready for this era where that's going to be, I think, increasingly commonplace.

Yes, I agree. Thank you. Matteo, maybe we'll have you go next. What are you broadly seeing with AWS?

Sure. So for me, when I speak with enterprises, I've seen that in the last couple of years, the economics of coding kind of flipped. It used to take maybe 1 year -- 1 day to kind of build the feature and maybe a few hours of code reviews to actually get it to a measurable state. Today, we see that with AI, we can actually have code produced in minutes, but maybe still needing hours to actually steer it back to actually get to measurable state.

What I see a lot changing in the last year or so in the enterprise, developers are learning that context engineering, elaborating their intents better and using AI to prioritize helps getting a result faster, that actually looks closer to our intended outcome. And this is basically, for me, a signal that models our rewarding discipline rather than speed.

Fantastic. Thank you. And Ryan, what about Compare the Market?

So I think for me, the most obvious change, especially for a group of engineers, is where people are spending their time. So you all have seen, you're able to produce and write code significantly faster than we were a couple of years ago. And that has kind of forced people's time to move either side of the code writing process in the delivery pipeline. So people are spending more of their time writing and refining specifications and how work will be conducted, and then also reviewing the output, right?

So this is kind of interesting because the bit that we really like about engineering is the code writing in part, right, but it's kind of forced us to go either side of that. And so for us, that's looking at how we address the sort of changing nature of the role and the impact that, that has on a whole bunch of people on what they find valuable in what they're doing.

Yes, of course. Thank you. And Mans, what about you at Cube?

Yes, from my perspective, what I see, it's not about what is changing, but how fast this is changing all right now. So like 1 to 2 years ago, we were talking about how are we going to implement code suggestion kind of tools into our software development life cycle. And right now, we are running multiple agents in every stage of our development life cycle within GitLab, also within Claude. So I think it's not only a developer tool or tools anymore, but it's more like a full organizational shift where we are in right now, where we see that the way we think about even building software is completely changing.

Yes, completely. I think we have a case study that came out just today with you.

Yes, yes.

Some exciting stories there.

Ryan, next question is for you. Compare the Market has been doing some of the most concrete work we've seen on how context changes AI outcomes and software engineering. So tell us more about what problems you look to solve and what you learned in the process.

Okay. Cool. So we saw the same as everyone else, that the volume of code that we were outputting was growing significantly. And that, again, forces the sort of impact on people's time into the code review process. So we have an agent that does code review on every single change we have, and that's in our GitLab pipelines. And one of the things for us that was -- we were really interested in is how can we arm the person who's still doing the code review with as much context and meaningful feedback on the code change that's being suggested. So the agent was performing these code reviews, and we wanted to make sure it had as deep context and meaningful impact as possible.

And so the team -- by the way, a couple of them are in the audience. So you can have a chat with [ Marina ] and [indiscernible], they're awesome. We wanted to have a look at how do we make that -- the code review that the human gets from the agent as meaningful as possible. And so we did a study within the team on how we could do that. And we took a bunch of different approaches. The first was using Knowledge Graph in Orbit with an agent, and the other one was using an agent with RAG tool and the other one was using an agent just on its own, no tools.

And what was really interesting for us was, firstly, using Orbit, using Knowledge Graph, significantly outperformed anything else. So kudos to you, guys. But we get -- yes, the -- sort of evaluations we've done showed that common accuracy was 21% higher than any other option. Most interestingly for us was that using an agent on its own with no tools outperformed an agent with RAG. And sort of digging into this was quite interesting because we found that using a RAG tool with the agent, we were dragging in semantically similar code into the context window, but that was causing a little bit of confusion within the agents. So that's why we see that underperformance for RAG. But for us, it's been a quite a significant unlock. We're getting through, let's say, 1,000 MRs per week. And if you're shaving an hour off of review time because you're providing significant context to the human, that adds up over a [ quarter ].

Yes, fantastic. And then maybe just as a quick follow-up. So speed with control, we've been talking about the speed of government -- governance. How do you think about that one?

Yes, that is interesting. So we were actually talking about this last night, too. The position for us is quite interesting that coming from a sort of regulated government industry, that we find ourselves not in the position where we're having to kind of adapt to AI and tag risk and governance on to the side because we've kind of operated in that space, we find ourselves in a fairly advantageous position that the guardrails and sort of risk and compliance checks that we perform as part of normal pre-agentic software delivery are kind of already there. Sure they're changing, sure they'll adapt. And the risks that we addressed, there will be new ones that we haven't seen before. But the way we think about software delivery is that those things are already part of what we do, predeployment going through our pipelines.

So yes, things are changing. The nature of how we do deployments and how we think about delivery will change, but we're in a fairly good position where we can go fast because we already have those guardrails in place.

That's great. And the discipline is there.

Yes.

Fantastic. Gene, this one's for you. So we talked about some of the study that Compare the Market did, and the surprising result around agents with no context being better performing than that with RAG. So maybe, as you think about -- someone who has studied -- as yourself who has studied the system problems for decades, what do these findings tell you overall?

Oh my gosh. I mean, I think one of the things -- I mean I love the work that Ryan and team did at Compare the Market. And I think one is like just a fantastic primary research about what makes these tools more productive. Secondly, is we're all learning together, and it's one of an incredible opportunity in an era where nobody knows where -- no one knows what the new practice will actually look like. Here's an opportunity to actually define those patterns, and I think Ryan and team absolutely did that.

And the fact that they did that in a regulatory -- regulated environment, I mean, I think it's fantastic. And reminds me about what happened with DevOps in 2010, where organizations, especially in the regulated industries, they were just so scared to even say the word CICD or DevOps because they were afraid that the regulators would crack down on them. And so as we got the case studies like Capital One, one of the largest card issuers in the United States, I mean, we've sort of normalized that and say it's actually better if you're faster and more secure, more in control. So I'm eager for when we get those case studies down, where we can actually make it safe for organizations to say what they're really doing.

And I ran a conference called the Enterprise AI Summit in April where we had Block -- I'm [indiscernible] Block, Netflix, healthcare -- Skypoint healthcare, where companies in regulated spaces are actually sharing that they're working on a regulated mission-critical code, right, using AI. So that's an exciting time to be in the game.

It very much is. And maybe one more for you. So you've written extensively about how organizations create flow. How does context fit into that picture?

Oh, I think it's everything. And I guess the thing that really amazed and amused me this morning is that -- like how intolerable it is when something takes 2 minutes. Like, oh my gosh, 2 minutes. That used to be considered fast. But like now, if you have to wait for -- to get information from a repo and it takes 2 minutes, it is intolerable. And so it's just an exciting time where -- like what does it take to get not just the right context, but get it quickly. It's just exhilarating.

Absolutely. Thank you. Mans, this one's for you. We've heard about context quality, and we've been talking about that now. You described a model where Claude handles generation and GitLab does the orchestration of everything around and across the software development life cycle. So maybe can you walk us through that use case and the impact that richer context had for you?

Yes, of course. So I think like context and quality of the context is the most important thing in our software development. At Cube, we have been running GitLab for over 8 years right now. So our full software development life cycle is managed within GitLab. So from like issue creation to the actual deployment, it's all within the GitLab environment.

So when we started adopting AI over 2 to 3 years ago, it wasn't our question, where is our context at, but more, how are we going to implement AI agents within our existing GitLab environment. So we are doing that in 2 different flows right now. One of them is that we are using Claude code as our daily coding agent for our developers, and we connect that through the MCP and API connection with GitLab. So yes, we keep in control of our software development life cycle.

And when we are doing the actual building of the software, we pull it from GitLab context to in our Claude coding agent. There, we are building the software, putting it back into our software development life cycle within GitLab, and that's how we are currently building our software with our teams. Besides that, we are also using the Duo Agent Platform, where we are building custom agents within GitLab. For example, when we want to have an agent which is gathering context before the actual development starts, we are implementing that in the first stage of our GitLab flow to get the context in our issue before it gets into our Claude code development environment. So yes, what we see is GitLab's orchestrating everything for us, and we are looking in Claude code now to do our actual development work. But for example, it can also be another coding agent in the near future so...

Awesome. Thank you. I know a number of our customers are interested to hear more about how these work together. So thank you for sharing. Maybe one more for you. So as you're shipping faster, what does that mean for your business and for your customers?

Yes, what we see is that we can ship a lot faster, but also the quality is increasing. We are delivering more and higher-quality software. So -- and security is also getting better and better. So from there on, we can deliver faster, for example, prototypes, where we, earlier, needed for like months to weeks to develop the first prototype. We are now ready in days to weeks, so we can show them the value that we can deliver with our software.

What comes with that is that we see a shift from like the hourly-based software development, where we are shifting to more like value-based software delivery, because it's not only about the hours anymore that the developer spends to develop the software, but it's also about the AI cost, the agents that you're running. So yes, we are figuring that out how we are going to make that shift as a company.

Great. Thank you.

If I can just add one more thing about that. I mean what I'm really looking forward to, as the DORA metrics have come up, and that's something I worked on about a decade ago. And I'm really looking forward to the day when we have set -- a set of metrics that can actually share the -- like what you just talked about, like you can conjure up software from scratch in an hour. Right now just talking about merge request and pull -- and lead times just doesn't -- it's like such an incomplete expression of the magic that's happening right now. So we're not there yet, but I look forward to that happening soon.

Oh, yes, me too. Thank you.

Matteo, okay, from the AWS side, how are enterprise customers defining business success with agentic software engineering? So maybe use cases and how these drive investments.

Sure. So what we see with our enterprise customers is a shift between -- from individual productivity to group productivity. I think, over the last couple of years, every developer started using these tools and recorded some productivity when coding, and everyone around them, other roles, tech and nontech roles, started doing the same.

But we saw in the enterprise that in order to achieve greater outcomes, sometimes it is necessary to align tools and technology with people and processes and in general, kind of rituals and ceremonies with people and processes means to -- mostly mean the evolution of roles. We see in many enterprises, some of the responsibilities that used to define clear boundaries of role responsibilities kind of becoming a little bit blurrier. For example, engineers taking over some of the product management kind of duties because this is bringing more efficiency when interacting with AI, just as an example. And when we think about rituals and ceremonies, we see sometimes smaller teams working on shorter sprints in order to actually work a little bit more efficiently.

So when I think about use cases, given this is common for all the enterprises, I would say one prominent one is brownfield modernization. In the enterprises, there is a lot of legacy, sometimes spanning multiple [ repos ] that have implicit dependencies and a lot of tribal knowledge. When AI can help us understand this code, we can actually immediately see some of the ROI because we can see maybe moving from releasing a change that used to take months, now maybe going live in weeks or days.

I would say the second use case that is quite emerging, obviously, we spoke about it today, is infusing every step of the SDLC with AI. So not only coding but also code reviews, everything is related to operations and orchestration of going live into production.

I would say the third use case is also something that goes beyond developer. And maybe it goes and touches in other phases of the SDLC that maybe relate to, for example, product managers or design or user experience experts. So for example, using AI to do data analysis, analyzing customer signals, maybe doing user testing with synthetic personas rather than real personas or complementary to real user testing, the prototyping even. So this is probably something that, again, is quite prominent in the enterprise because we see it is easier to connect that to some kind of ROI.

Fantastic. Thank you.

All right. Gene, I'm conscious we have 3 minutes left. So I'm going to ask you another question. I'm going to do a quick whip around at the end. So in your research, what separates organizations that make AI work at a systems level from the ones that are stuck in just deploying tools?

Oh my goodness. I'll actually quote someone who was part of the dev productivity teams at Amazon for the software builder experience. And there was a cross population study as they try to implement Andy Jassy's edict of like everyone has to use AI. And he said, when you studied like 15 teams about who really excelled, he says it was like really 3 things. It was understand -- AI fluency, how good are they at AI? How much have they practiced? Two is like do I understand where the bottlenecks are? And the third one I thought was really intriguing was like the quality of the leader, right, is a leader focusing on improvement, making time to get better at their craft? And that just really resonated with me. So I think that definitely distinguishes and resonates with me.

Awesome. Thank you. All right. We have got to do a quick whip around with this final question, 30 seconds each. So software engineering is changing fast. So to close out, what is a wild prediction from each of you on what comes next? Ryan, I'll start with you.

This might be unpopular. I think natural language is the only program in language you're going to need to know. We see this internally, teams who are spending their time refining specifications are significantly more productive than those who don't.

Okay. Thank you, Matteo.

So everything is changing super fast. I would say my prediction is that this year, next year, every AI engineer will be raising agents and nurturing them. And my prediction is that this will require more technical skills rather than not.

Awesome. Mans, what's it for you?

Yes. I think every company will have full agentic teams, but also agents which are managing their own budgets, hiring other agents when needed, scaling up when needed, scaling down if needed. And from there on, humans are only setting direction, giving the goal and the right context to get to that goal.

Great. Thank you. And Gene, take us home.

I guess I agree with everyone, and I think we're seeing -- we're starting to see glimpses of a world where everybody codes, right, it's not just developers, where marketing people code, UX, design, CFOs, CEOs. And so I think it means like we're going to 100x the number of developers we have on the planet. And so you do the math, like there's 20 million now times 100, it's about 2.8 billion developers. So it's like about 1/3 of the world population. That feels right to me. So all those graphs that Manav showed this morning of like the growth rate is like, "Oh, get ready, more is coming."

Just the beginning.

Yes.

Awesome. I love that. I love we finished on predictions.

Up next, we have the research agency from Stanford to join us. So I'd like to welcome to the stage as we come...

Hi, everyone. Thank you for having me. Excited to be here at Transcend. So you've listened to what's going on a little bit from practitioners. Now I want to connect that a bit with the research study we're conducting at Stanford. I'm with Stanford SWEPR. It stands for Software Engineering Productivity Research. It's quite a mouthpiece. So

a quick round of introduction. So I'm a researcher with SWEPR since 2020.

I have an industry background. I'm a CTO at a fintech, a neobank. We do AI-based lending. I'm also the former CTO at Crunchyroll, a video streaming platform, and I was in charge of engineering when they went through a very rapid growth and this inspired some of the research that we're doing. I got connected to the people at Stanford. One of them is Yegor. You see him here. Unfortunately, he couldn't be here today, but together we kicked this off.

Just to give you some context, we've been doing this quite a while. Our research has been shared by Elon Musk. It was notably the piece on ghost engineers. Marc Andreessen. We do various events and also the mainstream media picked up on our publishings. And, obviously, we also submit to the major AI and software engineering conferences. So we publish a bunch of papers each year, and all the research is ongoing.

So before we dive into that, I will have to explain you a little bit on the methodology that we're using. Basically, how do you even measure software engineering productivity? We didn't know that when we started. I mean there were things like counting commits, counting PRs, counting lines of code. None of that seems something that is really a good way to measure software engineering productivity.

So we were, kind of, trying many different ways to figure out what could work. And what seemed to work is actually an expert panel that looks at code written by the engineers. They give their feedback. We ask them questions on implementation time, quality, maintainability, complexity. And then that was the first surprise here in the study. The experts were in very high agreement. And if you guys have been in engineering meetings, it's really hard to get engineers to agree on anything. So for us, that was a big surprise. It was exceptional. We used something called the intra-class correlation coefficient to calculate the agreement. And then, okay, so we found a way to actually measure it.

Now can we do that at scale? And in order to do that, we try to train a model that would replicate the expert panel so that we could look at it at thousands commits in very little time. So currently, we have hundreds of companies enrolled in the studies. I haven't updated that number in a bit. I think we're north of 200,000 engineers that were analyzed. The beauty is we can go back. And I think roughly, this represents depending on how you calculate, maybe even 1% of the software engineering population.

Now you have to assume that this is not a perfect way to look into productivity but better than other metrics. And all the following slides are kind of based in that methodology. And if you assume that now we have a way to measure productivity consistently, let's take a look at what AI is actually doing. So we'll have a couple of sections. So we'll be looking into how AI benefits are unevenly distributed, how structured practices are important. We'll look at a real company case study, and we'll give you some benchmarks on AI spending because it seems a lot of people have question marks on what's the appropriate budget allocation and some organizational implications.

So the first finding here really is that like AI is not really delivering benefits to everyone at the same time. So what I can show you here is that like we picked 46 teams that use AI. And when we started this, we had also a control group of 46 teams that didn't use AI. So while we kept doing this, our control group fell apart at one point in 2025 because there were no more teams not using AI. So we kind of had to extrapolate from the control group in the beginning. But initially, we had like a 4.8% difference. And now the recent update really is 59% difference in output. So -- and the gap is really -- it's gotten wider. And maybe some of you saw that Fable is out, the Mythos-class model. So let's see if we see another spike in the gap.

Now if we look at more recent data, then this becomes even more dramatic, right? Like so the bottom quartile teams get almost no benefit still. The top quartile teams often double productivity, the same technology, very different outcomes. So we see a very strong power law effect. The key takeaway here is access to AI is not the differentiator. So if that's what you're using to measure, you've got to start looking into who is successful at using it.

Now if we take that from the team level and also take it down to the individual level, you see kind of like the same effects. So heavy users outperform the light users, but team effects matter even more than individual effects, right? Like so even if you have a top performer in the team, they will likely be slowed down by the laggards in the team and they won't be able to deliver to their full value and possibility. So that means AI productivity is a team phenomenon. And in the same time, this also changes who succeeds inside of organizations.

Now throughout our measurement, when we looked at who is advancing through the performance quartile. So what you see here is Q4, that's the top performing quartile. Q1 is the bottom performing quartile. So we have not seen a lot of movement in the past. So the p-value was pretty stable, 0.70. But now the rank stability, it fell to 0.45. So since AI -- and we haven't really seen that in any period, no matter what the change was, whether it was going remote, whether any kind of transitions we had in the past, the rank stability was never that low throughout the study.

So surprisingly, we see actually a lot of movement upwards from the bottom quartile to the top quartile. And it's interesting in a way because we think -- and we're hypothesizing here and based on interviews that we conducted is that we see that maybe very senior engineers that were doing supporting functions, supporting task code reviews and whatnot. Now they get time to delegate these to a model to an agent and they can contribute and they're outperforming everyone, yes. But then, the takeaway is AI is changing the skills that matter, and that's why we see those changes.

But people ask us like, okay, so if we give people AI, then what happens? Does more AI usage deliver better results? And the answer is not necessarily. So we see that the successful teams, they work in a clean engineering environment and cleaner environments achieve larger AI productivity gains, which is not really surprising. For me, as an engineer, I'm somewhat moderately offended by that because what organizations haven't done for the human engineers, they're now doing for their LLMs. But yes, -- so the key point is the environment quality matters. And the reason is that clean environments allow AI to operate more autonomously.

And you can see that also when you look at the task composition and the environment cleanliness, when you look how things come together, there is a tipping point where if you fall below that threshold, then it's just the agents can't really deliver good results. So AI just amplifies the environment in which it operates, yes. So let's keep moving. How should companies then measure whether AI is actually delivering value. So I think what we could do is -- and ideally, we would look at business outcomes. So ultimately, I think that would be what would be best.

But it's a very noisy signal because there's just too many confounders. So in absence of an ability to properly measure that and correlate that, we recommend looking at the engineering outcomes. That's a relatively clean signal. And then that gives you a pretty clean framework. So you can start using -- measuring the AI usage, you start measuring the AI outcomes, you connect the 2 and you avoid jumping directly to revenue conclusions essentially. And there are several practical ways to measure the AI adoption. So I was hitting on that a little bit earlier.

So there was an access-based way of doing it. It's essentially like companies that are in the rollout phase. They want to make sure everybody can access it, everybody can use it. But in the end, it's not ideal, right? Like what we saw is that access and usage telemetry is the gold standard. So while people having access is good, it's better than not having access, but because of the discrepancy showed on the earlier slides, you need to double down on the people that really are killing it.

We can actually look at that retroactively in our study because we have to get history. And that's that. Then the next thing is, okay, how do we measure the engineering outcomes? And here is how we think about that. So essentially, the primary metric that we're using in the study is the engineering output as per the expert panel and per the machine learning algorithm that we've trained. And what we use as guardrails is rework, refactoring, quality tech at risk. And also the DORA metrics are super important in terms of measuring flow efficiency.

Happiness metrics are useful to check in on your team, but not necessarily as a productivity metric. So the takeaway here is you can try to maximize the output while keeping the guardrails healthy. And with that being said, I think we're ready to move to the next finding here.

So what we did and we submitted this paper to ASE, the conferences in October. We have peer reviews in. They're very favorable. We have defined 4 levels. So ad hoc prompting, rules and project context, task-specific agents and orchestrated multi-agent workflows, which where we saw is kind of like the best results are delivered. And the point here is that the AI maturity leaves artifacts that we can analyze. And so we built a classifier to identify these artifacts and do an analysis of what's going on there and how your engineers and teams are talking to their agents.

So we analyzed hundreds of repositories. We used embedding, paths and content. And we use that to detect the actual AI maturity signals and got really strong validation results in the sense that we saw strong clustering effects that tie into a higher performance, higher output. And that maturity has a measurable impact on quality as well. So when you look at it, repositories with no structure, they suffer a lot more degradation in terms of quality as you keep using your agent and cognitive complexity for the engineers keeps increasing, static warnings go up.

So no matter how you slice and dice it, it's not a good idea without proper harnessing, proper instrumentation and tooling and essentially structure protects your quality. So when we look at individual developers, we see the exact same thing. We see that PR throughput is dramatically improved. duplication is decreased and revert rates are improved. So there is -- yes, there is only benefits that we see here. So there is simple documentation, context practice, those really create outsized return. There is no measurable net negative effect on that. So everything you do in that direction, you will have some gains.

Now in order to validate that, we can look at an actual case study of a company that did that. So it's a real enterprise example. We track output quality and churn together. And the company really started at a below average output. And so at one point, the CTO said, like we want to 2x everything, yes. We had the CTO mandate, nothing much changed in the metrics initially. What really started to change thing was, first of all, like the rollout, the adoption. So access was actually -- it didn't matter. They adopted AI in May 2025. They started in the 25th percentile. Productivity doubled. They move towards the 60th percentile now. So the large gains are achievable, right, even at 600 engineers.

And -- but productivity gains alone, they don't really matter if the quality collapses. When you look here at the quality analysis of the company, so before AI, they were more or less stable. They were -- sometimes it was going down, then it was going up again. When they focus on it, you probably know how it is. You have to ship something quickly, it degrades, then you spend a little time in optimizing, improving it, it goes up again. But then in the beginning of the AI adoption journey, you see a steep cliff when quality went down. So with proper tooling and instrumentation, they essentially were able to reverse the trend.

Productivity remains high while quality stabilized. And recently, in the last few months, they have even achieved an improvement in quality in their agentic workflow. So quality degradation is, in fact, manageable at this point. And the next metric is also giving you an important story. So the churn rate, essentially, we cluster rework and refactoring in that churn rate metric. So that one is also down, yes. So AI improved also execution quality, not just speed. And yes, so understanding what causes these changes is now really the next challenge.

What we are trying to do now is we're trying to put a pilot program together that -- where we kind of tie all the engineering metrics and they show correlations. The correlations are not causes. So the real drivers here may be meetings, calendar load. And we don't really know yet or don't understand yet how these things tie together. So this is kind of for us, the next step in our study to really find the causes and not just the patterns. And if anyone here in the room is interested in joining that effort, feel free to reach out, but let's switch gears from productivity to investment.

So everybody is wondering also like what is an appropriate amount of money for me to spend. So at Stanford, we launched the AI Spend Index, where we have -- we've gotten consent to publish some of the spend from companies in our study. We track AI spend per developer. There's benchmark organizations. And what we see, the high-performing companies, they spend significantly more relative to the ones that are in the lower-performing quartiles. So underinvestment can become a competitive disadvantage.

However, when you look at that, so the benchmark, it kind of becomes more valuable when you can look at your peer and industry data, it's similar concept to levels.fyi. You can compare against your peers, contribute data and essentially, you can unlock more visibility. So the value is really where you sit in your cohort and how you do relative to them. So you can compare based on a few things. I'm just -- you can open up the website and see where you sit and hopefully contribute also some data back if you find it useful.

And yes, so I think this is now the science part that is pretty well understood. We're entering a bit conjecture territory here because we're really trying to tie everything back together. And what we see often is that like AI speeds up the individuals, but a lot of organizations that we have in our study, they actually fail to capture the gains, and we want to get a better understanding on why that is.

So we have a -- we see that like lower success correlates very highly with size. So the hypothesis here is that enterprises spend a lot of time on internal alignment. So it's -- in principle, people know what they could do or should do, but then you need a lot of time to get everybody who needs to be bought in, bought in and get that done. So it's a lot of meetings, decks, approvals, politics and AI doesn't automatically eliminate these costs or improve it. So a lot of productivity gains get absorbed by coordination and network complexity explains why.

So when you look at it, a very simple thing. We published on that like a few years back already. So we see as the number of nodes go up, like the communication overhead just becomes crazy. That's why single-threaded ownership tends to become so important. But every time now, it's amplified by AI. So while you could move faster, you kind of like lose the wins or the benefits in alignment. So this is also like the reason why start-ups tend to benefit more than enterprises. And then you really have a challenge with regards to organizational design.

And what we see is AI native companies are really operating fundamentally differently relative to the classical traditional organizations that we have in the study, like they're really built to capture 24/7 engineering, right? Like so it's nonstop. You got your agent running. It's not just another tool. I think they're scaling through compute, there's persistent organizational knowledge and compounding capability improvements.

So what we see is they tend to have found a good way in order to remove any blockers where a human decision is kind of -- would be the slowdown, yes. And with that being said, so if you're interested in enrolling your company in our research programs, there is a number of ways to reach out. You can participate in the research, you can contribute to the AI spend. You can help us explore more causal discovery, discuss company-specific opportunities. We're also open to that. And yes, so I think hopefully, this was relevant to you. In our view, the organizations that learn fastest how to measure and operational AI, they will capture the majority of the gains. Thank you so much. That's it from my side.

Thank you, Simon. Thank you for sharing the research with us. Well, this brings us to the end of today. So whether you're tuning in online, thank you for joining us to the developers in the room and online as well don't forget the developer show and also the hands-on lab, the Duo Agent platform, that'll be running in just 90 minutes. And for those of you that are here, we look forward to seeing you at the next Transcend. Thank you for coming.

[Break]

Hello, hello everyone. I'm Colleen Lake, coming at you for The Developer Show live from Transcend. That's right. We came across the pond. Now if you've been following along at home, you know that Transcend has been busy. And so this is kind of what I like to call the postgame coverage. For all of you sports fans in the developer show audience, I think that might just be me. I know my audience so well. All right. So today, we've unveiled some pretty cool stuff. First of all, Orbit, then Flex Pricing and Governance. Now I know the developers here really just mostly want to talk about Orbit. So that's what we're going to be doing for the next hour.

Now what it's going to look like is I have 4 guests joining me today. First up, we have William Arias. William is a SaaS Developer Advocate here at GitLab, and he has been going deep into Orbit for the past few months. He is also a data scientist, and he really likes digging into data. Next up, we have a customer of ours, Felix Becker from Deutsche Bahn. Felix is an AI advocate within Deutsche Bahn and a long-time customer and user of GitLab. So I'm very excited there.

Now with Felix, we'll mostly be talking about AI development in general because I don't know about you, but ever since, say, November of last year, all I have been thinking about is how AI has changed development in a way I didn't think it would this quickly and what that means. So we'll be talking about the AI development that Felix has done and what we kind of think it's going to look like in the future, the problems, all of that.

Next up, we have Aakriti Gupta, a Senior Engineer from GitLab. She has been here for about 7 years now, and she does back-end development. Now the thing about Aakriti is she has no involvement with the Orbit team whatsoever, but she's a very good sport. So a few weeks ago, we had her just try out Orbit for the first time, and she's going to talk about her experiences there and what she would suggest to you if you're doing the same. Now again, she does not work on Orbit. She just wanted to try it out. Okay, I might have nudged her in that direction, but she, again, very good support.

And finally, since I know that we really got to play a little risky here, we're going to have a live demo with Orbit from Angelo Rivera, who is the Engineering Lead of Orbit, and we will be taking the questions live from you from the audience. Now since I'm not completely insane, you can submit those questions now, and we will look through them and pick a couple. But we will be answering your questions live at the end. All right. Now let's get started. Let's bring up our first guest, William.

Hello Colleen.

Hi, William. How are doing today?

Hello, everyone.

Now William, you've been digging into Orbit quite a bit. And I've said the word Orbit maybe 40, 50 times now in the 3.5 minutes I've been talking. But for those of us joining for the first time, can you tell me what is Orbit?

Yes. So I will start by sharing my journey when I start playing with Orbit. And I have to say that what Orbit is in a business like answer is that it's a service that significantly enhances the context that your agents will use to generate answers. It can take all your GitLab data, index it and make it available as a graph that you can query. So that's what Orbit is. And this part of this journey and that the concept I have as well, I want to share my screen and then show you and share with you the journey I went through when I was starting using Orbit and the context graph.

So here in my screen, I hope you can see that this is what many of the developers today, they probably are using when they are dealing with agents. So we have a query or that you can as an end user, you can ask or other agents can query to each other. And then what this will happen is that we are using agents that they are backed by an LLM and this LLM will retrieve information, but this information or this data is coming from a model that already has the weights frozen after training. And this will use all of the sequence to generate a response. So this is what most of us when we are using today agents for coding are using are dealing with.

But now the contrast with Orbit or using a knowledge graph to enhance the context is that when we use this, what we are doing now is that the back end of the agents becomes not only the frozen weights of the model, but also the context graph, which has a set of entities and relationships that are factual and that they are built after indexing data, in this case, the data that resides in the GitLab platform. And every time that a query or that an agent needs to retrieve an answer is not only going to use the weights of the model, but it's also going to go through this graph and extract those entities and relationships and give me a grounded response. Does that make sense?

Okay. So what I'm getting from that is Orbit is based in your current reality and your current system rather than historic data that's generated from memory. Is that correct?

So in this case, what it is doing is taking the data that is part of your GitLab as a platform from the data layer of GitLab and indexing it and building all of these relationships that are factual that are the ones that I want my agent to traverse or to read from to generate a grounded response. And also it's using the weights of the model to understand the query that I put in natural language that could be as an end user or from agent to agent. So we can give more context to this by showing how Orbit looks like in the 3 different views, the web UI and also I can show some of the evaluations.

Yes. And could you also tell me why does this exist? What problem is it solving here?

Yes. So the problem that it solves and the reason that you as a developer should care about enhancing your development workflow by using the context graph is that you can see in this sequence that I have here that what we want is that every time that there is a query that we will use the power of the LLMs to understand this question. But I also want that the reasoning that the LLMs or the agents will use is based on the known entities and relationships that come from the knowledge graph that will enhance the context that they will use.

So at the end of the day, the problem that it solves that is a classic problem that comes with the LLMs is that there is a high risk of hallucinations. And what this is doing is reducing the likelihood that my agent will hallucinate something because it's not going to this frozen set of weights or is not trying to do text matching from a huge data lake, but what it's trying to do is traversing a graph from known entities that were calculated beforehand.

So this, at the end of the day, results that you as a developer can have more confidence that whatever your agents are doing is grounded in some data structure that is deterministic and that it will make experiments that you will be doing with this or when interacting with this technology more repeatable, which is one of the main issues today with these systems. So this brings grounded responses and it makes it more predictable at the end of the day.

Okay. So it's grounded in reality and makes it a lot more accurate and less likely to hallucinate or really just kind of lie to you. It tells the truth.

Yes.

And it tells not just the truth, but the relevant truth to you.

Exactly. And that's one of the benefits. Also, as we will see, it requires fewer tokens. It is faster. and so on. So this also means that it will be cheaper, which is also a big topic today when it comes to AI budget.

Yes, because I think every company nowadays has an AI budget or at least every technology company. And we all want to stretch it as far as we can.

Yes. Okay. So this is a GitLab project, GitLab Orbit. As you can see, this is a repository with a set of groups that has thousands of events. There are merge requests, there are issues. There are lots of things going on here. And what we will do with Orbit is that we can take from this view, you can see that this is an agent that it has in its back-end Orbit. And what I was doing was asking to search merge requests that are fixing open vulnerabilities in this group. And this group is made of a lot of projects.

So why am I choosing this one in specific? Because the security issues are the ones that make headlines. And if I want to make sure that I want to have a real state of what are the -- what is the state of the different vulnerabilities that are open in this set of groups and the merge requests that are addressing it, I want to get accurate answers. I want that the correctness of this answer is high. So this is something where I don't want hallucinations. This is something where I need that whatever the agent is giving me is grounded and that is reflecting the reality of my project.

So as you can see here, this is kind of a web UI view where I have this Orbit agent. I ask this prompt, I ask this query. But how does it look like in, let's say, in the middle between this UI and the back end Here, you can see that we have a query editor, and this query editor also provides certain set of templates. And this one, I have this one that I'm asking for merge requests that are fixing open vulnerabilities. And when I execute that query, it builds this graph, and this is showing me here, you can see is that I have this deterministic view where here this dot, this node is a vulnerability and everything that I can see that is related to this relationship that goes from this node is showing me all of the open merge requests that are addressing it.

So this agent on the -- here on the chat, when it's trying to answer this question is not going through lots of pages trying to do text matching. What it's doing is reading and traversing this graph that has this deterministic relationship there and is grounding the response based on this data structure. So this view is giving me that peace of mind that I can tell that, yes, this answer was -- sorry, this prompt was answered given these data structure that is in the back end. And I am asking a question that is about security. So I don't want hallucinations in this context.

You definitely do not want hallucinations in security context or at least I don't. I don't know about our audience, but that's one of the places where I would most like to avoid hallucinations.

Yes.

Now can you tell me how else you're using Orbit? What have you learned from testing it in complex environments?

Yes. So this was a very interesting part as a data scientist. So one of the things that we were playing on and here my screen, I hope you can see, we have built with the team, and I thanks part of the team that built this Orbit Observatory, where what I was doing was playing with a different set of prompts where I wanted to stress out the capabilities and putting into practice the theory that about knowledge graphs and how they enhance the context of agents. So how this now context graph can help me. So you see that this prompt here is asking that across the GitLab or group, which you saw is a very large...

Very large.

Project. What are the -- which are the users that have authored the most merge requests in the last 30 days. So when we run this prompt, you see 2 things I can show here. So first, we have different views. One, where we have the Orbit the service, the one that is running in the cloud, where what I'm doing is asking this question to an agent that doesn't have Orbit in the back end and another agent that has it. And the winner is clear. And here also for the people that are not only -- as the developers, we also sure care about the business angle of all of this. But you can see that it's cheaper, it's faster, and it consumes fewer tokens.

Those all sound like good things to me.

Yes. And those are things that our managers would like to hear. But for me also as a developer, what I would like is that it's more accurate and that is giving me a grounded response. So all of this, we can see in this table that when I run this prompt, it went through all of this, and I can have this comparison where the one in the cloud, we see that in time out. And why this happened? Because the type of question that I'm asking is a question that is very friendly for anything that is graph shaped.

So this is touching different boundaries and domains from GitLab, the platform. This needs to go to one part where there are merge requests that needs to go to another part where there is an authors, where there is code. And all of these hops are things that they -- or the service is aggregating and precalculated for us. So when the agent just needs to answer this, it doesn't have to go to different set of -- it just goes to one point and that run this query, provide this graph and gives you the answer.

What we see now on the screen is that when we only use the API endpoint, what it has to do is to call many different endpoints and then try to aggregate this. And at this point, what the agent did was it said the platform said, I don't -- I cannot do this, I'll come out because it's too much work. So this is one of those examples where we see that these type of prompts or queries that are the ones that we have many times in the day-to-day when we want to understand a code base or we want to answer these questions are the ones that are most relevant. Does it make sense so far?

That makes a lot of sense to me. And I really like what you said about it using less tokens being cheaper, but also that does not matter unless it is accurate because cheap and fewer tokens is great, but accuracy is above everything. I don't want something cheap that makes my life a lot worse. I want something that simplifies and helps me day to day.

Yes, precisely. Because this is another thing that as a developer, I care about it's not only about being faster, but it's also that I am moving faster, but in the correct way.

So the point of the tool is to enable developers.

Exactly. And here in my screen, you can see now that in this evaluation tool, we were not only evaluating what is in the cloud, but also how it will look like when I am using Orbit locally in my computer. So all of this has been the mechanical automation that I'm using cloud code and it's running the same prompt with Orbit and without Orbit. And we've seen that in these 2 cases, Orbit was the winner across all these dimensions that we mentioned before.

And one last thing I want to share is that this evaluation will make more sense when we try and test it through different use cases. So you see that in this one, we were also asking what are the top 10 projects with organized by critical vulnerabilities. This is one of those that I want to make sure that I get an accurate answer.

Yes.

Yes. And also the one that we showed before, the outsource of a merge request failed CI jobs. This is another thing that, let's say, now as a changing hats as a platform engineer, I would like to understand quickly where are those CI jobs failing and being able to diagnose and create a plan for that. This will take a lot of time if I want to do it quite in different ways to API endpoints. This is another use case that I found that is very useful when I have a precompute graph that I can just query and get these answers.

Wow. Now that's a fantastic demo. Thank you so much for that, William. And I have one last question for you. And I do understand that we have some audience questions. If we have time at the end, I'll come back to them. But I had one other question for you, William, right now before we move on to our next guest. And that is, if someone from the audience wanted to bring Orbit back to the team and run an experiment, like if they want to do that right now today, where would you suggest that they point Orbit at first?

Okay. So based on the evaluations I ran, my advice will be go to one of those large projects that you have that maybe you are planning some refactor because this is a very excellent use case for this to measure the impact of what will happen if you change some name of a class. But also, you can go to a smaller project, even though this shows lots of benefits when we're using a large code base. In a small project, what this does is that it allows me to also ask those compound questions, those questions that cross boundaries across the platform that there is not a single resource or API endpoint that can answer.

So even if it's a small project, but I need to combine different domains from GitLab, the product, the platform, I can also use it. So turning on index a very large project, you will see the benefits, but also even if it's small, just go for it because you can see that it will help you to ask difficult questions, complex questions at a more accurate with more accurate answers and with all the benefits that we mentioned when it comes to cost and time.

Okay. Are there any projects that you would suggest steering clear of for now?

Coming in.

Are there any specific projects that you would suggest not starting with, but maybe building towards?

No, at the moment, not. We need to -- I would like to evaluate more and then I can come back with a better answer to that. But for now, just go for a large project and a small project because the benefits are very visible in both cases.

All right. Great. Well, thank you so much, William, for joining us today.

Thank you.

All right. Next up, we have Felix Becker from Deutsche Bahn. Felix, thank you so much for joining us. I'm going to close the computer. Hello. How are you doing today?

[indiscernible] Lots of exciting news that you announced and everyone, hi in the stream.

Now can you tell me a little bit about what you do at Deutsche Bahn, both as a company as a whole and you as an individual?

Sure. We drive standards and harmonization through platforms and development. And one of our platform is the developer experience platform. And my role is being a platform manager to find the right products for the platform and also in governance leads so that we have the right things in place to define our standards and our policies.

Because it is a highly regulated industry you're in because of that...

It is. Yes.

Which as we would want it to be.

Yes. There are life on the line if the things go off the track. So it's really important that we are responsible and have a high reliability and high quality in our software products.

Now, we're here today to mostly talk about AI. I've heard a lot of people go back and forth about use of AI in highly regulated industries. And I know it's a little bit different. Can you talk about your journey with AI?

Yes, sure. We started about 2 years ago, and we started like everyone with the client side agents that helped us for code completion and our journey was twofolded. We had a lot of regulated stuff and compliance and data protective stuff to do, and we also introduced the tools in an internal hackathon so that people can actually use them.

And basically bringing AI into the company is a joint effort. So you don't work as a 1 or 2 main team. You have like legal included, you have data protection, security included. And also, we have like a good connection to our union labors. And they were all really forward-thinking, open-minded so that we got this technology in our company.

That's fantastic. Now it's moving so fast. And you live in a very -- or you work in a very complex environment where your data lives. What does that look like? I know that you face some very unique -- well, unique but weirdly universal problems. What makes it kind of hard to bring AI into your environment?

Yes. To give you a sense, we have around 10,000 developers. We have 70,000 repositories. We run about 2 million pipeline runs in a month. And with this whole set of developers and lots of enthusiasm in that space, we have to make sure that we have like the right security in place. We worked with strong partners in that area, and we built up the knowledge that it actually needed to take the benefits of that technology.

Okay. And what are the benefits to you? Because I've seen a lot of back and forth from people. Now it's no secret that AI creates a lot of code. And now the code is actually pretty good, which we could not say 3 years ago. It is production-ready code. But with a lot of additional code, does it help your productivity? Does it decrease it in some places? Or is it a mixture?

That's a really good question. What we see so far is, I guess, it was around last year November when the models made a huge change. So the quality went up tremendously, and we were now seeing chances that we really have good quality code. But we get, on the other hand side, a lot more code than expected. So the thing is the traditional workflows are still like we had less code and the systems work like we had less code, but all of a sudden, we get a lot of more code. And for that, we have to build the systems around that as well to prepare not only the CI/CD pipelines, but also the workflows in the pipelines with the people that we are able -- we see more merge requests coming in that we need to review. We see a lot more reviewing. So the jobs are changing, the responsibilities are changing, and we still have to make sure that everything has high quality.

Yes. Being a programmer involves a lot more reading and writing than it used to.

Exactly.

I was at an open source conference a couple of weeks ago, and that was the one thing that people were talking about, which is the influx of AI development is great in so many ways, but it can be a big stress on maintainers, especially many of which are volunteers because there's just so much to review now. And now while AI is fantastic at reviewing, you do also want a second set of eyes, a human in the loop in many cases.

Yes, sure. Open source is a whole different game. I think the chances with being a contributor now with AI, with the help of AI is very high because all of a sudden, you can write faster code, you can understand code base very good, but I want everybody to ask to be more responsible with the code that they submit in an open source because the maintainer has still to be accountable for that.

Speaking of accountability, that's the same thing with us in our company. Developers are still accountable for what they write. And therefore, we follow the EU AI Act, and we still have humans in the loop. We might see that changing in the far future or not so far future. But for now, it's very important for us and we still review and we still have seniors looking at the code.

Yes. And what you put in matters so greatly here. Now you and I have talked about this a little bit off camera, but you mentioned that in the past, you've had big differences in quality of code based on what you've put in. Could you talk about some of the problems you've seen or faced in the past and also how to avoid that?

Yes, sure. So in the beginning, we -- first of all, it's very important to understand the models and understand the tooling. So when you start off and just think I can type something out in human language and expect good results, then you get to go through a learning curve. So you really have to understand the tooling. And therefore, we saw at the beginning a small dip. So until everybody is on the page. We doubled down on AI this year. So we introduced a large program where we enabled a lot of people, not only in software development, but also on other side of things.

But bringing the knowledge in and using the models intentionally, asking them to do smaller things and be ready for the results to be reviewable, that's where the effects went better for us. And of course, the better models and the regular better technologies that's improving pretty rapidly.

Yes. The technology is improving as is our ability to interact with it.

Exactly.

You mentioned an AI enablement program and not just developers. I'm very interested in that. What does that mean? How are you enabling nondevelopers at Deutsche Bahn?

Yes. We have basically a product and stream where we find out what does it mean to use AI, not only within development, but also sometimes we call them white collar workers or something. So we think about working with BahnGPT, that's our internal chat application or with Copilot within the Microsoft space and how we not leave behind the workers that actually have important things to do, but do not work only with code. So we do a lot of how can you leverage prompting for optimizing your own work, how can we work with our customers or end customers basically to bring in AI into the products that we see outside of the Deutsche Bahn.

Okay. Now that's very interesting. Do you see major differences between other white-collar users creating code with AI versus programmers?

Yes, sure. We also have like very curious interested people that join the coding space or the arena, I would say. And they experiment. So we are in a phase where we're experimenting a lot. We have like programs where we especially look in how we would work with agents and the team, how would change our way of working together. And yes, this brings a lot of change within the company. And right now, we see the time where we have to build guardrails and security around that so that we can basically industrialize the things that we have in proof of concept so that we make it more reliable and usable for everyone.

Which is what we all definitely want.

And this is the job of the platform for the future, not only developer experience, but also agent experience.

Yes. And what does your actual day-to-day look like with coding? How much code are you writing yourself versus prompting? And can we also talk a little bit about the difference between coding with agents and whiteboarding some stuff? What is the difference there?

I mean that's a really important question, and this is something that's mainly misunderstand that white coding is for me prototyping. It's just getting an idea into life, giving some people a chance to click on it, not having paper prototypes, but make it actually feelable and usable and work with stakeholders together to get in first feedback. So we go away from paper prototype Figma drawings into something that's realtistic in the real world and is usable.

And on the same time, we need an understanding that this is not production code. And we see a lot of expectation because white coders things are really pretty fast over the weekend, over 2 or 3 days. We have something really -- but what chance really good, but this is not production code for us. So what we are thinking about is bringing in a path how to -- what it takes to bring something that is white coded into production. And for this, we have like a lot of supporting technology in the pipelines and in the scanners that we use around so that we can make sure that the things are in a good quality and reliable. And we also have a lot of principles internally what it takes to have good quality software.

Sounds great to hear.

Yes.

It seems like you thought a lot about this.

Yes, we thought a lot of this, but we are continuously thinking about it. And this is so great to be in a conversation with you to learn more in Transcends and bring things home and adapt our thinking and our workflow.

It's great to have you here. Yes. Now I have 2 more questions for you, and we have only a couple of minutes left before our next guest. So we might have to speed run these. So the first one -- I believe in us. I believe in us. The first one is, what is the gap right now between what AI tools promise and what they actually deliver in production?

Yes. That's a tough one for the short.

I know. I believe in you, I believe in you. You've got this, you've got this.

So I mean it's all about using the AI intentionally and have guardrails around it and have good disciplines. If you're good in agile practices, if you're good in DevOps and the practices around that, you will benefit from AI as well because AI for me is a multiplier. And therefore, teams who are good at these practices can benefit more from AI than others.

All right. Now my last question for you. We've talked a lot about how AI coding looks -- has looked incredibly different basically since last November. What do you want in a perfect world? What would it look like for you? What strides would we make in the next 6 months?

Good question again. What I see as everybody else see for sure is that we move from the client into a server side agent scenario where agents run on the service side run more autonomously and basically more agents to work on their own and making decisions on their own.

What I would like to see is that companies like you talk more about the second week, not only the first day and the second day, but the second week. So we usually do not bootstrap from greenfield projects. We have large code bases, and we have being -- we have to be very responsible to make that change and have tooling support and more best practices with working on the second week as would be fine. So for us, it's not everything. It's like easy demos and greenfield. So my wish would be that companies like you focus more on being ready for the second week.

That's what we've been really working to do. And because especially, you're right, it's very rare to have a greenfield project. You can have one for a demo, but usually, you're working within an existing environment and the tooling needs to reflect that. And not to say Orbit Orbit Orbit, but that is one thing Orbit does great. Well, thank you so much for joining us, Felix. Our next guest will be coming up now, but thank you, Felix.

Thank you for having me.

All right. Next up, we have one and only, Aakriti. Hello. How are you doing?

I'm good. How are you?

I'm good. I always love when I have these little microphones. I feel like a member of One Direction. I hope I'm Niall. Basically now, Aakriti, you are a senior staff -- senior back-end engineer, sorry. It's been a morning, guys. You are a senior back-end engineer here at GitLab, and you've been here for 7 years. And Again, I want to stress this to the audience, you did not work on Orbit.

I did not.

Can you tell me about what you do at GitLab?

Right. I'm-- if I get back to [indiscernible], she said, right now, I work in the Tenant Scale team. So I take care of things like groups and projects. So you look up groups and project page, things are slow, it's my job to fix. If things are buggy, it's my job to fix.

You're the fix there.

Yes.

Lady fixit. Amazing. Now A few weeks ago, you used Orbit for the first time. Can you tell me about your experience there and what project you used it on?

Right. I used it on the GitLab project, the one monorepo we have. My first thing I remember of the experience is it was intuitive and easy to understand what it was doing. It was indexing everything, right? And very simple documentation to follow. I could get it set up in very few minutes. I was actually surprised how quickly it indexes the code.

And I tried to understand, okay, should I do this remotely or should I do it on my machine? And I tried both the things. And there is a slight difference between the 2. So if you do it on your machine, it's only indexing the code in your repo. If you're doing it on a GitLab instance, it's going to take into account your merger class issues and everything. So the first experience was, wow, this is quick. It is indexing everything. That was the first idea I had.

Indexing everything?

Yes.

That's a lot of things.

It is.

Were there any things that when you started using it, that kind of tripped you up?

Let's say -- so just -- I think it was just a difference between remote and local that I took some time to understand. And I was looking for examples of what do I use it for, but I'm glad I just started playing with it on my own and put up my own use cases and start discovering it, but nothing really strange.

What was your favorite thing you used it for?

Favorite. Where do I start?

You tell me?

I think it was accessing a large piece of back-end code to see where it could be refactored. There was -- we built a framework some years ago for geo replication where you could replicate any data type in GitLab. So anybody -- any developer from GitLab could come in and use that, not just the team that built it. And I had worked with this code for a long time. But then for quite some time, I've been off that team, so I didn't. So I knew some of it. I don't know all of it. And I went in assessing that big piece of code. What is the setup like? Is it modular? What is the -- how are the classes related? How does the logic flow? Where is the authentication? Where can there be improvements? What can I refactor?

So I was impressed by what a good summary I could get using Orbit and not just the summary of the code, not just the relation between the code, but also about where the architectural decisions were, what were those architectural decisions? How did this piece of code grow over time? As I start asking it more questions like machine is working on it or who are the developers I should talk about this, who are the most active ones, for example? What is the teams priority right now, right? These kind of things plus the context Orbit could have on the code was really powerful.

Okay. So a lot of the developers who are watching this are similar to you in that they're very experienced developers, but they've never touched this tool. And I mean, they haven't heard of it until about 2 hours ago. So that's understandable. What would you suggest how would the team set this up?

Go through the documentation, exactly the steps.

It's very simple to get started. Only thing is decide whether you want it remotely. That is you would need some authorization from whoever manages your groups. to see what projects this is activated for or if you do it directly on your repo, it's just on your machine. So that's really not much to do.

Okay. Great. And what would you recommend for a good first use case for someone?

Okay. First use case, if you are jumping into a new project or if you're new to a team or a company and you are diving right into it, usually, somebody would give you access, you get Git clone, you look at some documentation, that someone handed to you, starting out a little bit. Somebody tells you this is legacy code, don't worry about it. And then somebody helps you a little bit.

But by the time you get to actually contributing to that repo, takes a long time, a lot of steps -- and a lot of times hear things like legacy, legacy. Don't touch it. Nobody knows about it. But legacy code is really just code that nobody is handling right now or all the people who had context on it have left the team.

That is legacy code, right? So it's a really good tool to get into code you've never seen before or a legacy code or asking questions of it. That I think is my favorite use case. When I first started out in tech, I worked in consulting and one job that I kept doing over and over was going to a company right before the one person who knew the code retired. So we could touch it and like document it. And it seems like this is a very good use case for that and I think developers would be very thankful for it in a way, I am thankful.

I am very thankful...

It can plug the gaps in documentation, for example. It can tell you where to plug the gap, and it can also -- it also just has that knowledge.

Showcase clients.

It does. It does. And you can ask questions of it that you can't find in the documentation for example.

On onboarding, I find myself sometimes very shy about asking too many questions. like I think, oh, no, if I ask these people 25 questions in a row, they're going to think that this is just a hat rack up here and empty inside. And so with -- maybe that's just my own confidence issues, but I do think that a lot of people find it a lot easier to just figure it out ourselves or go through Orbit or another tool to just dig in there and find the answers.

That is true. I think it's very different if you give your code base to a person who's just joined your team or there's an experienced engineer with a lot of context on the project, on the priorities of the team, how the team functions the process, everything, and they can sit down with you and introduce things to you or help you get to your first commit. And the thing about asking questions you should. I think it's great to ask questions.

I do ask questions and the team is in the audience, and they can affirm that with you. Yes, that's true. There's a level of question you can ask.

That is true. And well these agents don't feel bad if you ask a lot of questions.

Great. If I ask an agent 45 questions, well, okay, my usage tokens. But if I ask them all at once.

Yes. That will be something.

Yes. Maybe humans get a little bit impatient, but an agent is not a problem, especially because it can't give you answers. Or if it can't, it's just going to say, well, my resources are limited. This is what I have, and I can give you an answer. On that front, actually, I really liked when I started using Orbit in my IDE -- the interesting bit was when I asked of it a technical question, it could choose whether to use the standard tools it had or if you wanted to use the knowledge graph from Orbit. So it could choose between the 2. I don't have to say, use orbit for this task. So I don't have to think about what back end or what tools should go into it. It does.

Wow. That's very useful. Now the main benefit of Orbit is, of course, the overall context that it gives. How have you seen it improve the accuracy or help your development?

That's interesting. So I took 2 problems to it. One was about refactoring in general, the one that I already shared, the example. And the other was interesting. It's a question I would generally take to an agent. I would say, okay, I'm considering adding this method here for calculating the checks. And it came back and said, there's already a method that does something similar, but I see what add-on functionality you're trying to give it.

You can do this here. And generally, what I would do with that agent is say, okay, then go implement it, create it or merge and then we talk. But here, it went a step further. And not only did it say, okay, this is the method you should edit. It found the places where the method was used, which is also what any other agent would do. But on top of it, it could find several other places, 23 in that example, where 23 pieces of the code that are going to be affected by that method, and that method was not directly called from there. So it saved me a few cycles of a broken pipeline where I find, okay, this is not working because of my code change. And it also saved me the hassle of potentially refactoring all those places just to run that line code more efficiently.

So that is, I think, a step better than what agents have been doing so far and what we are doing, which is what excites me about orbit.

Fantastic. Now -- we've got a lot of developers in the audience right now. How would you recommend they use Orbit?

Right. Two things here. First, I recommend using it on your GitLab instance because it comes not just with the knowledge of your code base. It comes with knowledge of what your team works like. Why were certain decisions taken? Was something deprioritized earlier? And why was that done?

Or why is the code the way it is? You can go only so far with git blame, for example, you can't query commit messages. So you need more context. You need one agent that is empowered with all this context. And the other thing I would say is use it for everything. Don't just use agents as you were aging using -- sorry, as you were using, let's say, in March 2026. This is June. This is different. Go for it.

Empower agents...

Yes, that too. Empower your agent with that knowledge, and you will see a difference in accuracy, which is really important right now and just fewer cycles of going through your code and pipelines.

Fantastic. Now is there anything else you want to say to our audience about Orbit or about development in general right now?

Same thing for both is what I use in my daily work life as well is push your agents, keep pushing them, keep extracting more and more, see how far it can go before it breaks, before the tokens run out or before it says, I don't know any more or I've hit the API limit, just keep pushing it, pushing and see how far it can go and use Orbit especially for bigger projects.

And I don't just mean technically complex. I mean for product managers or engineering tech leads, if you've been sitting on doing a major refactoring and thinking, I have to go look into what will it take, how many cycles of work, how many people, this is not that important.

Go in, these are the projects that bring you value, but you can do it for -- with fewer resources. Now is the time to go in, especially projects that include work across several teams. We've had those at GitLab before, where it took several milestones just because we had to communicate with so many different teams. This is something that can be done really well with one agent that has context on teams as well. So I really recommend pushing it to wherever its limits are, keep trying a diversity of projects.

Fantastic. Well, thank you so much for joining us.

Thank you, Colleen. Lovely.

Lovely, as always. All right. Next up, we've got Angelo Rivera, the engineering lead for Orbit, the tool that you have heard, I don't know, me say maybe 9 million times today already. Hello. How are you doing, Angelo? Orbit.

Orbit Orbit Orbit...

Orbit Orbit Orbit

Too much orbit for sure.

I don't think that's a thing. Come on.

Nice to see you.

Nice to see you...

I just saw you 10 minutes ago.

Don't break the illusion. Also as the clock says, I've clearly been here for 48 minutes. So, come on. All right. Now Angelo, I know you have a demo for us that you're going to answer some of the questions that we have from the audience.

But first, I actually have a question earlier that one of the audience members said. And I'm going to read it to you because I think that's a really good question that we weren't able to get with William, but that you will be able to answer. And that is, since Orbit is basically creating a graph of my repo augmented with metadata from GitLab and is also capable of the parsing of 12 programming languages, can I use it for analyzing the architecture of my code/application?

Yes, definitely.

I mean that's one of the main things. So one thing that was really cool about like what the team built is we kind of built it for ourselves, right? And one -- our service at GitLab actually was one of the first services at GitLab to be as decoupled from the monolith as possible. And so when you're doing cross-service architecture, you have to know all the integration points. And of course, there's like RPC communication and internal endpoints and all that stuff. And so as soon as we got orbit wired, we immediately started dog fooding it ourselves. So we started asking all the various architecture questions. And of course, you need like all the issues, MRs and then on top of that, all the codes. So we could -- I could even show you that too while we wait for some of the audience questions, but I don't want to bore you too much with it.

All right. Well, let's do -- I believe we have some audience questions. Let me pull those up.

Should I get plugged in? Maybe...

Yes, please.

I don't know if we're going to be -- so we should do the demo first.

All right. Now everybody in chat, just remember, make your sacrifices to the demo gods now, so this works.

Okay. Should we pull up some of the questions?

All right. Yes. So do you have that first question there?

So there was one question that I thought that was -- there were 2 questions that I thought were really good from the audience. One of them was -- and we were checking to see beforehand.

Yes. Angelo has been on his laptop in the second row this whole time, just [indiscernible] in case you all were wondering.

And let's -- so I picked 2 of them that I thought were really good. So let's do the first one. All right. Let's do it. Can I tell you what the first one is. So -- and I tried to come up with a cool prompt. They were asking basically in their company, there's a lot of times where sometimes someone will create a project and then basically just leave the pipeline running, even though there's like no one using the project after a long time, and that could cost like a lot of money after a certain amount of months, if not years. So I was like, what if we have the same thing. So I made like a little prompt. I made like kind of a crazy...

Let's see.

Let's go ahead and run it here. You can see all the other tabs that we had up for the demos earlier in Transcend.

That's nothing. You could still read words on there. You know it's bad when you can't read the word...

Words right now.

Don't tell all my secrets. Come on. No, I can look at that. Yes. Also, I can still see icons. You know it's bad when you can't see the icons. That's when my problem has gone so far.

Yes. I try to use group tabs, but it gets pretty bad. So I made one little prompt right here saying, use orbit to find the scheduled pipelines that keep failing on dead projects. And then I added like a few other filters here, any project that's basically abandoned and then rank them by the longest running and show each project path for that.

So -- and this is in GitLab. So we'll see how it goes here. It might take a while for it to run, but maybe we can walk through like kind of Orbit.

I don't know how much William went as far as the UI here, but what are you saying?

Yes. So go ahead. Walk us through.

And while we do that, I want to kick off the other one because, yes, these things take a while, especially because we're using -- they just launched Fable on Duo agent platform, which is awesome.

When did they launch that?

Literally like the hour that it came out. This is really cool to play with it, especially with Orbit because you probably can ask even crazier questions now. So I'll let it do its thing. All right.

Angelo, I know that we've mostly been showing Orbit today in the website version of GitLab, but where else is it available?

So the one thing that we did is we are making this available to any coding agent. Of course, -- the specific product stuff will be outlined later on, but you can use it with pretty much every coding agent.

So I actually was going to pull a VS code here. And so let's pull up VS code here. And I'm just going to run it here on the root because this is all touching the API. And let's go here. So I already ran this question once just to make sure it runs correctly, but...

[indiscernible] Yes, but not that much.

Yes. So I'll just write the prompt. It was really funny, and I'll give the context of why I picked this one. So they're asking, could you find all of the MRs that have been rejected basically? And I thought that was really funny because I'm working with the team a lot, and I try to help out as much as I can. And they get mad at me because sometimes I'll [indiscernible] some MRs to them and...

I'm [indiscernible] that guy.

Yes, they'll get mad at me saying, Angelo, clean up your agent slot. And so I thought this would be a really funny one to see how many MRs got rejected from.

So how many times your name in particular [indiscernible] .

Exactly. So I'm going to just say something like my team sometimes rejects my MRs because they say I'm violating an agent slot. My team is shout out to the team, of course, Michael Tsai, Michael Uen, Jean-Gabriel, let me get this right. and Dmitry and [indiscernible]. And then I'll say, can you find all MRs in the past couple of months? -- that have been rejected by the team. And wait, find all my MRs. In the past couple of months, I've been rejected by the team. So let's kick that off.

And drop your guesses in the chat for how many you think it's going to be. Over under 500 -- over under 10.

Okay. All right. Let's see. That's a good one. That's a good one. So let's go back and see.

The first one.

First one ended. Okay. So that was pretty quick. So here are some random project in GitLab where we can actually break that down. Let me just make sure this is running. I forgot the -- the #1 thing I forgot to tell it to do. So Let's re-prompt.

We only have 3 minutes left to type that.

Yes. So basically, we made the skill called Orbit, and you just install it once and then it has the full API. So I'm just going to say, use only Orbit. So now it will use the Orbit skill. And so that's already, of course, built into the Duo Agent platform here. And so yes, so we found pretty much all of the projects. And you can see this monitoring project has had over the past 6 months, 7,000 failed runs. And the last time anybody touched it was 18 months ago. And these are -- it's a good number of projects here.

And you can see like this is super useful. You can just go in. And of course, we're going to go in and use this tool to do things we couldn't do before, which is cleanup stuff like this. So I thought that was pretty interesting. Hopefully, this will run within the actual time frame that we want. But happy to chat while this is running. or we can maybe talk a little bit about the queries here that it ran.

Yes. Let's talk about the queries. We have 2 minutes left, though. So we'll talk about the queries. We'll see if it finishes. And I have one -- I have 2 things to remind the audience of before wrapping up. So talk fast. Marg, I'll talk fast.

Okay. I can't. So if you look in here, it's pretty cool. The agent is able to write its own queries. So that's the one thing that maybe hasn't been explained in depth. Definitely watch the video that the team did did a video on. It goes super in depth. But what's really cool is because it's a schema and it's an ontology, it can do aggregation and filters across pretty much every dimension across GitLab. And that's how you're able to do these cool reports. So anyways, no more about my boring stuff.

I think that's amazing. All right. So thank you all for joining, and we should have this up on the screen just to see how it's doing while we're wrapping up. Thank you, everyone, for joining us here today, both at Transcend and for the Developer Show.

Now if you want to try Orbit out as I really want to dive into it even more now, go on to the GitLab docs and just dive right in. They're very straightforward, and it's a great way to get started. And if you really want to show off your skills and play with it, we do have an active hackathon right now on Devpost, so check that out too. And as always, if you have any questions, go to forum.gitlab.com and say, hi. Thank you all. And how is our demo going? We have 30 seconds left.

Still running. We're still running up the previous one, and we'll...

I'm like. Angelo, how many times did you say did your MRs get rejected? This -- I think it's good.

Maybe too much...

2 months. You're blowing your team too much with AI.

Yes, there's too much here. Well, maybe it's here. Maybe they'll come back with something. All right. Well, so it's a little bit slower.

And we've got it. Thank you all. Angelo will post the real answer on LinkedIn and online. Thank you so much for joining us today. And it looks like we've got it almost done now. Fingers crossed.

If not, we'll pull up the old one. the old one. models will do this.

Models will do this. We did try Fable for this one, but here's what it would look like.

I'll pull up -- here we go, that's not I can't find it.

That's okay. -- thank you so much, Angelo. Thank you, everyone, joining finish right now. All right. That was terrible.

AI and what you can do I have a couple of slides the for the preparation so you can participate hands on.

This is me if you want to connect on social media as [indiscernible], but rather much it's about you today. You need a working gitlab.com account to follow the workshop exercises if you want to participate hands-on or if you just watch -- want to watch and maybe practice it anything later on, you can also just sign up and continue following the stream wherever you're watching.

The session is being recorded, and we will be providing a recording afterwards, same for the slides. And there will also be a Q&A session at the end, but please also feel free to ask a question any time in the Q&A section and I think chat might also be open. And also if you're stuck. So if any exercises don't work for whatever reason, please let us know so we can unlock you while we are doing the workshop. F

rom the setup perspective, there is a code that will be redeemed for our Learners platform. This grants you an ultimate license, also access to GitLab Duo platform

And credits, GitLab runners and also experimental features and so on. You will have access to the workshop environment 7 days after, so you can continue practicing, finish the exercises and later on also move or transfer the project into your own GitLab environment, whether it's on gitlab.com, self-managed or on dedicated. Now the most important part is you need to redeem the code. And I think it's -- yes, it's in chat already. And I just copy paste that over. Can I do that?

No, for some reason, it doesn't work for me. I will ask my colleagues in the background to do that for me right now. But you need that code, go over to the GitLab cloud and redeem that. So in essence, it will look like this. You need to enter the GitLab virtual redemption code, copy paste that in, submit the code. and it should look like this. So when the redemption code is successful, you need to click on the Open [indiscernible] workspace button over here, and then it will get you with a new project overview. The ID here is random generated, but the most important part is like seeing the provisioned group and project over here. That being said, hopefully, this is working for everyone and it's provisioning and testing our environment right now. When you see the project, one important step for this exercise of workshop is to set up your default name space. So you might be using a different name space already. But for this exercise, we specifically need a Duo default name space being set. So on the right-hand side, you can navigate into your preferences by clicking on the icon and select preferences. And within the user preferences in the behavior type, please select the default Duo namespace which should be GitLab Learn Labs.

This is a preparation so that later on, any credits or any agentic chat that will be leveraging that name space works out of the box and you don't have to worry about any errors. That being said, let's jump right into the workshop, which I have over here. And I hope I need to zoom in a little I'm already quite zoomed in. Maybe let's collapse the side bar here. The project itself is a Python application with [indiscernible] content and the run book for following the exercises for this workshop, so everything that I do now can also be accessed in the runbooks here, click on run books and then the-workshop.md. These are the instructions that we will be following in the next couple of minutes. And essentially, let's quickly go in. What we will do today is we will be working exclusively in the browser.

So no IDE, no terminal required and work on the swag shop here. In this workshop. Like I said, it's a pipeline application with the front end. And there are some issues with that. So we want to analyze the project, prioritize any work that's available. There are fixing -- sorry, there are broken pipelines that we need to fix. We want to implement a new feature and also accelerate code review. Last but not least, there will also be security remediation and resolution.

So we are touching the top 5 use cases here, specifically around the Duo use cases. So like ask anything from a design pattern and algorithm to debugging how to implement something or even like create issues and leverage custom agents or specialized agents for that and then go deep into like fixing pipelines, implementing features, doing code reviews or automated code reviews with help from AI and the generic AI and then later on, vulnerability resolution, which also includes the false positive detection, which you might have seen in the keynote demos earlier today. So there's also a hands-on exercise for that. Also as a matter of time for this workshop, so I could probably go 3 hours and talk about everything. We will be touching on the majority of the use cases, but everything that's marked as a bonus or as an optional exercise, I will ask you as a homework exercise and do it async and we focus on the learning exercises.

Now what makes Duo platform different? We actually work directly on the platform here. We have access to work items like issues and epic, merch requests, CICD pipelines and even more data from the background like metrics, data vulnerabilities and whatnot. So we don't need to have to do any contact switching. Every action that we perform, we will see in a bit needs a human in the loop. So we need to approve that, verify that and also verify whether it can be applied, merged, run and so on.

The learning curve is important. So we will start with autantic chat and then continue to dive deeper into foundational flows and also custom agents, which are often an interesting way to explore and Everything that agents do on the platform is also transparent and you can observe and trace the agents, the behavior, the reasoning, the tool execution. And we will be using sessions do agent platform sessions in that regard and also practice that and how to verify that on the platform. Terminology is here listed agentic mode, like a ganticat on the right-hand side, anything that agents might autonomously execute to fetch context, better understand the user question and get up to speed faster than a chat prompt could ever be.

A quick win is a low effort high-impact improvement. So we will be looking at sort of quick wins that we can solve in this project -- another term that I will be using throughout the workshop is flow, which is an automated sequence of AI-driven actions. So it could be multiple agents in one flow of specific steps in order to solve a problem which needs more reasoning, for example, like implementing a feature or fixing a CI/CD pipeline. Last but not least, human in the loop means you as a human, you need to approve things before agentic AI is able to execute that. Okay.

The setup comes -- or the workshop comes preceded with configuration, but we also need to do a little work from the settings perspective. So this is raw as you would start with GitLab dent platform in your own environment. One thing we need to do is we need to check the Duo settings, the prerequisceedts here before we do anything else. So we need to enable GitLab Duo in the settings. And for that, we actually -- the settings are over here, and let's go into general and I'm pressing command now to open a new tab.

So we try to keep the run book, the instructions for this workshop open in this top and then switch into the actual exercises now.

If you're working on a large screen, you could also open 2 windows and move that in parallel. But for this live stream, I need to switch between tabs and the browser right now. Now go into GitLab Duo and check that GitLab Duo is enabled. We allow flow execution. So we can later on use the CI/CD the fixed pipeline flow and others, which is a foundational flow. We want tool approvals for sessions. And the thing we need to enable is these are for false positive detection, the secrets detection and also the vulnerability resolution.

So these 3 are important to have enabled for the later vulnerability remediation examples. and exercises and then press save. So this is step 1 of the preparation for this workshop and your own environment to enable these agent platform features. This is part of more high-level governance. So you can also enable that on a group level setting or instance level and verify that only specific agents and flows are available where they should be available. The next thing we want to talk or talk to do is we've heard about GitLab Orbit today being in public beta. And in this workshop, we also want to make use of that. So it's important that Orbit as a knowledge graph indexes your project. It might have been created just now, so the indexing might just be kicked off in progress.

But what you can do, what we need to do is we need to click on the profile icon on the right-hand side here. And in our preferences, so the preference here and let's open it in a new tab. -- didn't work in a new [indiscernible] it down. There is the behavior next to the GitLab namespace. So there should be GitLab Learn Labs. You can see GitLab Orbit and GitLab Duo. We want to use it. And we also want to make use of it in a gantic chat, use chat. So basically tick all the boxes. So we ensure that GLatuo has orbit available, and that's it. And once we've done that, click on safe changes and navigate back into the run book. Okay.

Sorry. So we are -- right now, we are here -- the next step is we want to trigger a failing pipeline in order to then use the fixed pipeline workflow and we can do that in the pipelines over here. So on the menu, navigating to build pipelines and open that click on new pipeline. We don't need any inputs and no variables. Great. Click on new pipeline. And then we can see the CICD pipelines have kicked off. The stages are test, build, security, deploy and also cleanup. This will take a while. We don't have to worry about this. Let's focus on the other things required to run the workshop. Agentic chat is available in this workshop.

So on the right-hand side, you can access Atlantic chat every time. If you close the panel, you can always open it up by clicking on the pen in the paper icon. I don't know what the exact term for that is, but click on new chat. and you can then use it. From a model perspective, it for whatever reason, it's using a different model from earlier tests, can search here for SONET 4.6 and we want to use the default, which is Vertex. I think by default, if you created a new account right now, you should have that, but you can certainly switch.

For this workshop, Claude SONET 4.6 has been tested. So if you change the model, you might have a different experience. And yes, my advice is don't change the default model for now. Okay. There is a lot of things to discover here. We will chat or talk about the different agents available in Agentic Chat in a bit. For now, no, there is foundational agents and those are custom agents available, and we will make use in the next minutes.

The last thing we need to prepare is actual work items and merge requests and why this sort of looks a little too much. It also shows the exercises will have code blocks. We can copy the code blocks using this small Hover icon over here. And in order to prepare issues and merge requests for this workshop, we use instructions for a generic chat, which tells it to read a specific specification from the repository and then create GitLab issues.

And I will show you what this exactly means by just walking through the exercise. So let's copy that and then paste that into a generic chat and then send that with the prompt or you can also press enter. And the idea here is to let a generic chat generate or create the issues and merge requests. This could also be helpful if you, for example, have an Epic with a specification and ask Agentic Chat to break it down into smaller durations, issues, tasks, whatnot.

The thing that now happens is a generic chat wants to create an issue. So it calls the tool for creating that and asks for our approval. We can read the description it has generated. And also like if we want to dive deep down into it, we can also see the raw request that's being sent. So now let's approve that. And the result should be 3 issues and 3 merge requests. So in the end, it created issue #2. Then it wants to create a commit and push, which is a preparation for the merge request. Let's approve that again. And we just continue with the creation.

Sometimes it can take a little bit depending on what we're asking or how many people are pressing approve right now on the platform. And you don't have to wait until I press approve the exercise is to approve all the creation of all issues if it gets stuck or for whatever reason, doesn't continue, can also write and chat, please continue or hey, are you doing okay? Can you please help me finish the problem? And it might then do an inventory or does an inventory and recreate that.

I saw that when I was practicing for this workshop last week. So again, gigantic AI is sometimes a little unpredictable, but it's your partner, you can make it work together. The other things you will also see here is that it takes actions, for example,it reads the README.md into context in order to better understand it. And the reason why we do this exercise is that we can actually look at issues and merge requests we want to fix review and inspect for vulnerabilities in a bit.

Other thing to know what is important from the instructions here. Yes, you could type if anything gets stuck to read the current context or also start a new chat and say, I did this specific exercise before, please do an inventory and help me continue.

This is a different tool, a different command creating a merge request. So we see the target branch, the branch and it also automatically assigns labels for us, which is nice. And I can do all that just by using agentic chat right now. There is no different work items issued or merge request required. Okay. Now it's processing the final one with note. And I hope this is working for everyone.

I do see a question in chat. No credits remain available in agentic chat. Please check the default name space in your user preferences. This should be Gab. I think it's truly in chat. #4 has been created and we want to create a new commit and branch, and I think this should be the final request that we want to see. And usually, when I practice this, everything is fast and now it's a little slow.

So sorry for the inconvenience. What else can I share while we are waiting? Maybe I can just ask things. Okay. So I was doing that in the background and now I was a little impatient and just got confirmation. Here we go,We have the GitLab merge request, which is about fixing improved text contrast. The thing you can also see is it creates the merge request and renders the URL and it will add a note to the issue and merge request in this specific case, merge request note. Okay. And it is rendering that. And if this becomes a little unreadable, you can also maximize the chat panel in order to see that. Okay. We have the issues created with the merge request created. Now that this is working or this has been created, we want to actually leverage the issues and merge request by asking GitLab Orbit about the relationships that have been added to the merge request and issues. Therefore, we need to open a specific agenda chat, sorry. So click on the pen and paper icon and select Orbit as an agent. And this opens a new agentic chat with a specialized agent. And then let's copy the instructions here.

So it asks whether we have requests with running or failed pipelines, pace that into chat, send and see how it executes. The difference you can see here is it's taking the action to query GitLab Orbit directly. So it analyzes the comments, aims to get the graph schema and also the DSL and then query the knowledge graph or GitLab Orbit directly, doesn't have to go the route using the rest API or graph in the background, but rather much get the answer immediately.

So we have a failed pipeline for the Flake8 line length.

And there is also a running pipeline, which started 1 minute ago or 2 minutes ago. Would you like me to dig into why the pipeline failed?

Yes, we could totally do that, but let's keep that up for later for an additional analysis. I hope I'm not talking too fast and chat is -- that everyone can follow along. If I do talk -- speak too fast, feel free to slow me down and ask a question chat. Specifically for the custom agent, we want to make use of a custom agent that's called the daily Compass agent, which provides us insights on what we could be, what needs our attention, what could be a quick win and so on. We need to enable that agent in our project.

In our workshop, we can navigate into AI and agents, and let's open that in a new tab where we can see the default agents that are enabled or the foundational agents, but we can also access the AI catalog here and then search for the daily Compass agent, which is a custom agent maintained by -- so it's a custom agent maintained by the Duo Labs Group uses specific tools as a system prompt where we can see the quick win and for now let that into our project.

Yes, everyone will be able to use that. And we can see there's the latest version, okay? So this is also something that you get with custom agents. There's versioning involved, and we can update to the latest version.

Yes. So it's similar to, for example, CICD components that provide new updates. You can pin custom agents to an older version, but you can also certainly manage that. And the agent itself, we will be using an agentic chat, but it's important that it's enabled in your project. So when we go back into the project menu here, we can see that the daily Compass agent is enabled. Also stay hydrated if you don't have any like class of water or juice or something around, get something and take a sip in between. For now, the workshop is in a good shape. We do have orbit enabled and tested it that it works. We have the daily Compass agent and now it's actually time to get to work and start with the first use case.

So a little more deep dive into agentic chat and the specific use cases. One way to get started with the project is understand the project structure, what to improve, what needs attention right now, anything that comes to mind. This is especially true if you, for example, inherited the project from a different team or the teammate who created the project has left the company 10 years ago, which often -- which could be the case like with some Fortran code

Or some code that I have my career never seen like COBOL or any other older things, but also certainly projects where no documentation exists yet.

For this specific workshop and swag workshop, there is documentation available, but certainly agentic AI can be helpful to understand that. So we want to copy the prompt or should actually follow the instruction first let's have a new chat. So again, selected Duo as a default and then copy the instructions and pace them in here and execute or let agentic chat analyze the environment. You will also see it's using or it's adding more context here. So it's referencing the current open page, but also agents for md and chat rules, so customer instructions, which help the agents navigate the repository faster. And we will do a deep dive in a bit on that. But for now, let's focus on the analysis. So we have -- let's make a little bit bigger. We have the code base is clean and well organized.

The main areas are code application, data quality issues in the DPY, which is, I think, the database probably structural gaps. So there's a duplicated card logic, there are wrong categories, okay? It also knows about that code. So there were functions defined but never called. and there is also other things. So it provides us a summary of the recommendations and also potential effort to fix. Okay. That's good. What should we do next? Yes, we actually want to put this into action and say, let's create an issue for that or let's create issues for these type of things. So let's copy the second prompt here and instruct it to create issues based on the recommendations. -- waiting for to execute is similar to waiting for CICD pipelines to compile, like if you know XKCD-303, this is sometimes true.

But every time I call out agentic AI, it comes back. So that's a good thing. It creates the issue, let's approve that and created the vote item for us. Now we want to open that issue. So let's click or press comment and open that in a new -- and we can see it extracted the things it found directly into an issue. Next thing or next action item can be working on the fixes or we could also say, please break it up or promote it into an Epic and then split it into specific reports and so on. But let's see what the instructions tell us to do right now. I will leave it open, okay.

Next thing to discover is the AI catalog. So before we actually use a specific agent now, let's go back into the AI catalog, and we have quite a few instructions here. To get into that and some things I've mentioned before, okay. Anyhow, let's follow the instructions. Let's go back into agents, open that in a new tab and I will close some of the remaining tabs.

With the agents here, you can see the foundational agents that are available that we will be using in a few minutes and the AI catalog. When we inspect, for example, search for the planner agent, you can see that this is managed by GitLab. There is also a specific label or on that highlights that this is an upstream and GitLab maintained agent. It was updated 2 days ago. So it's current, the latest version, and this is the current release. We have a description and also documentation being linked here so we can learn about this. The visibility is public. The type is foundational in this case. And the agent has specific tool permissions, which are mostly read only in this case, except for like it can create a work item but -- and also update them, but for example, it cannot delete a work item. And the work item in this case is issue Epic and different other types. MCP servers would allow this custom agent to communicate with external tools or external context in that way. Nothing has been configured yet, and there is a system prompt, which we can see and we will test in a bit. This is relatively long. So could use that as an example for your own custom agent development, but this is a foundational agent that's available for us. The benefit here is that the AI catalog is a central place to manage agents and flows within the GitLab Duo platform. And you can also verify which projects or which groups are allowed to use these agents and flows, but also share that, maintain that over time, provide bug fixes and even more. And it's a central repository marketplace for anything that's required in your environment. Okay. Next one. We want to focus on quick wins and use a custom agent for that. So we previously enabled the daily Compass agent in the project, and now we want to use that. So let's create a new chat on the right-hand side here and then search was scroll down depending on what you want to do.What is the name? okay lets double check. Did I make a mistake in my agents? No this is here. Can I open a new chat? There it is. Probably I should have pressed refresh. Okay. Let's open a new chat and the Duo agent -- the agentic mode is active, and we want to use this specific prompt. So given the quick wins for this project, I'm lazy, so I will just copy-paste that, not type that.

Given the quick wins, why this is navigating or running the projects, we can see it searches the merge requests, the work items, and also vulnerabilities. And this workshop has failed merge request pipeline. This is label blocked. Okay. Let's make this bigger again since it's rendering a little more text. And there is also a way if you make the window even bigger, you can have a wide version of chat next to a wide version of GitLab in the same window. But yes, this is the full screen. Quick win [indiscernible] , a comment by -- this is me call this out explicitly but it should be your user if you see that. Depending on the output, agenda AI is not predictable. So it might look a little different in your responses here.

There's also maintainability improvements to fix those specific tasks we identified earlier, and there is a review needed for merge requests that we created. So it provides with a recommendation, unblock the team by fixing the pipeline and even comes with the conclusion of -- or conclusion, a proposal of what we want to do next in the workshop. But let's quickly go back.

Give me the link to the merge request... priority one. Okay, let's try that. Is this priority one? Maybe it's... I guess, okay. This is priority from an analysis perspective. It renders the link. So we can click on that and open it in a new tab. And it's fixing which it needs to be fixed. Okay. This is good. What are the next steps? Yes, the next step is like expected. We need to fix the pipeline. And in order to do that, let's follow the instructions here in the workshop as is. We open -- we have the merge request open. The merge request has a pipeline tab at the top here. Click on that, and you can see the stages where it failed.

So the stage is failing with two jobs. We don't want to navigate into the job itself or both jobs and then run AI on the log, but rather much get help from fixing it from this level. And there, we have the Fix pipeline with Duo button, which we will click on. And you can see every flow that runs in the background -- sorry, creates a new session. This will take a bit as it runs in the background on the [GitLab Runner] infrastructure. And we will come back or see how Agentic AI and GitLab Duo will fix that. Let's quickly inspect that I'm following the exercises as proposed. Yes, for the sessions themselves, this opened automatically.

So you can see here on the right-hand side, you can access it directly using the GitLab Duo sessions icon. And you can see that previous sessions were running here. The most important part around sessions is you can see what the agents are doing. So the agent reason here is it's fetching context and continues Okay. Yes. And sorry, I'm losing my voice now. You can also access sessions on the left-hand side here. This gives you an insight on I will talk slowly. The session is running. And then it will also attempt to create a fix. And yes, while we wait for that, we should actually be continuing with the dark mode opportunity, which Compass surfaced as a bonus idea. Okay, let's go back into the GitLab Duo chat history. And the chat history is on the right-hand side here. For some reason, I used a different agent. We can see the bonus idea. I'm not sure which part I'm hitting now, but let's refresh maybe Okay. Pressing refresh brought in the part agent into the current context.

It seems like I have a good hand for finding bugs while doing live workshops. Okay. We have been doing this, the quick wins. We want to fix the pipeline. The pipeline is running, and we are now here in this specific context. Okay. We have the comment. Next step. And it instructs us to use a [voice chip] and create an issue with that. Okay. Sounds good. The next step is to actually understand the context that's available in this project. So the?agents.md?that's added into the project here helps the agent navigate and understand the context faster, which includes the tech stack, the deployment and a little more than that. So let's open that. On the left-hand side, we have the agents and have opened in a new tab again.

This is a full-blown example now, but you can start by defining the development style guide, a summary of the tech stack like a flask application for the back end, templates for the front end, but also specify how it's deployed in production, what are the important targets here. And most importantly, how to build and run the project. Specifically, it is a Python project. So it needs a virtual environment. And these are the instructions to help agents determine the exact same environment as, for example, CI/CD would be using it: lint commands, test commands, and so on. And specific design patterns, project structure, style guide and so -- so this is helpful to help for agents and any agents, whether they're on the platform or in an [IDE] or on the terminal to better understand the code base and the project.

The important thing to know about?agents.md?is this gets loaded into every session by default. So it might consume too much of the context window. There are alternative ways developing right now with Agentic AI, which are skills that can be demanded -- sorry, can be loaded on demand by agents when they deem they need a specific skill for building a Python application, for instance, or generate documentation. But this doesn't pollute the context window by default and it can be in an alternative way. The other thing to mention and highlight is the code review flow, which we will practice in a few minutes, doesn't read?agents.md?right now.

This is an open feature request, but it uses its own customization file where we can provide specific instructions that matter for code review. Okay. So this is an example. There are more examples available in the documentation. Next one. Next use case is implementing a feature using the developer flow, specifically the dark mode feature that we have been looking at. And let's follow the instructions here open plan and work items. So we have planned work items over here and then create a new chat with the instruction to create an issue for the dark mode. Could have clicked here, but essentially to open Agentic chat and create an issue for the dark -- there's a question in chat, which I didn't see.

The user asks, "When I create an issue through Agentic chat, does it use my identity?". So it's using a service account, but also a composite identity. In this regard, it's my identity. So I act as the issue creator. So when we create this now and open it up, we should see that I'm the author -- and I'm also the assignee in this case, practice it with the teammate and follow up on this. But essentially, yes, it's me the author here for the dark mode feature, which we could totally now start working in our local development environment, the repository, get started with Code, Codex, whatever tooling you're using or even like CLI with platform, but we can also do that directly on the platform. And one way to follow up on that is the developer flow.

So the developer flow is more or less an issue to merge request automation which can be helpful to get started with proof of concept, but also specifically an issue that implements a new feature, generates architecture documentation like Markdown files, Mermaid charts, anything that's currently missing, and add tests. I'm a developer myself for like 20 years now.

And the most hated thing for me is writing tests. I don't know what you think about that, but this can also be a way that gets automated with the developer flow and can be helpful. For the dark mode, we want to practice that now. So scroll down the issue. And at the bottom here, you have implement with GitLab Duo and click on that. Again, same behavior as the previous fixed pipeline workflow. It kicks off a session, which locks the agent reasoning for the analysis and so on. We can also click on the session information on top, get more insights. it locks the user that triggers the session or the flow, and we can also see the job ID. So I could go even deeper and inspect the CI/CD infrastructure, where this is being run on in a sandbox in a environment.

This is totally deep down, not made or not important for the normal user. But if you want to look into that, why something isn't working, you can do that. It's also important to know that you can run that in your own infrastructure. So there is a specific tag needed for GitLab runner. And then you can isolate the flow execution on a dedicated runner platform. and use that together with the existing GitLab platform.

So there is nothing new to learn from an environment perspective or maintenance perspective for Salesforce, the GitLab Duo platform, except for maybe running LLMs, but the Agentic run time uses a well-known infrastructure and framework. Now this is starting, and you can see the developer agent lists the directory, reads the files, has a good understanding of the code base and creates files and continues. This might take a couple more minutes, so we can put that in the background and come back to that once it's finished. And by finished, it's creating a merge request, which then triggers CI/CD and code review, which we can jump in. Now while this is waiting to finish, we can have a look into the fixed pipeline session.

And for that, let's go into AI and sessions. And we can see the fixed pipeline session has finished. which is great. It's trying to understand why it failed, a lot of reasoning in there. And there we can see it created a fix and then pushed the fix into the merge request. And there is also added a comment to the merge request, okay? What are the I don't have -- no, the merge request isn't directly here, but we can access the merge request from the code. Merge request top here. Okay. I've analyzed this and created a fix. Okay. This is a behavior change. I wasn't expecting. But when it determines it cannot push the fixes directly into this merger request, it will create a follow-up merger request, which is sort of a stacked merger request, if you will.

So it's not targeting the main branch, but rather much the Git branch from merger request to, and I can actually merge that into the merger request just now. Sometimes it commits directly into the other merger request. So yes, this is something we actually want to approve and merge. Our approval is optional. Everything is green. Let me quickly chat and say," Get ready merge into the target branch". Okay. Let's merge that in. Why is it failing? This is tie up match. It's a draft should follow the instructions.

First, we need to mark that as a ready. Merging is now not okay. It introduces some vulnerabilities. Please ignore them for now. We will lose -- we will use them in a bit. Okay. So in the original merger request, we can see the merge and now the pipelines have kicked off again. And then we should see that the merge request has been fixed once the pipeline continues. And actually, we can see flake and so on are green now. This is what we saw earlier. That being said, let's move on. Since there are a couple of more exercises, we can use the planner agent, which is a foundational agent to help us with planning, create issue estimates, set due dates and so on.

The way to handle that is to create a new chat and then specifically select the planner agent over here and copy the prompt directly here, which asks which work items are missing estimates, due dates, and assignees. And now we get an overview of specific gaps for the planning a little bit bigger and review the recommendations. For example, we don't have a milestone yet. Let's go back to the run book and then check how we can act on those gaps. So for example, I could say, please assign all unknown issues to me, which we can do over here. And it should fire in action. It's actually looking up the user ID. Yes, this is me. I cannot remember my ID, like my ICQ number. But yes, it's now executing the assignment let's approve that. It fires set up in parallel. And you should see the same for your user name and an estimate.

Would you like me to suggest StoryPoint values based on that? Okay. No, not now, but thanks. I follow up in that conversation. But we want to look into another foundational agent, which is the CI expert agent, which is currently in beta. And this is helpful to analyze the current pipeline, figure out if there are inefficiencies and get a better understanding of how this actually works. In my career, I've seen GitLab CI/CD pipelines like 10 years ago, which were created and then never touched again, so like never change your running system. And everyone was living with a run time of 1 hour. But this is an opportunity to maybe optimize that and analyze it in the beginning.

So let's create a new chat, sorry, I was too fast with the CI expert, beta as a custom agent, as a foundational agent and then copy paste TCI on the prompt here to analyze the pipeline. And why this is running, there is another exercise, for example, to do a pipeline tour. So get an understanding what each pipeline -- each stage of the pipeline does. And security investments, okay. Let's make that a little bit bigger again while it's running, and there's certainly a lot of things to fix and do. This is interesting. Interesting in a way, I didn't see that yesterday when I practiced the workshop. So sometimes it comes up with more pressuring ideas or identifies something that should be fixed.

The?pip?cache key, yes, the parallel jobs share the same cache, which can be a problem if one job installs dependencies from Python and another one again, creating a collision and not a reproducible environment. This is something that should be fixed. Obviously, we don't want to fix it by ourselves, but continue the conversation and then ask Agentic chat to do that for ourselves and use a lighter image, okay? -- because we're using a default Python image could use an optimized container image that we build and maintain using the GitLab container registry in the background then and other optimizations, okay? There's also an estimated risk in there and the summary table.

This explanation is in beta right now. So let us know how -- what are your use cases in that regard. Moving on, there's another agent. to practice is the data analyst agent. And this comes in handy if you want to get an insight on, for example, the merge request throughput or open issues in a project. The great thing is in the background, it's using the GitLab query language, and it can also output that. So let's practice that by create a new chat us the data analyst agent copy the prompt. And the ask is to get a GitLab query language view, which then I can embed in my week, but I could also embed it in issues and Epics to have a live view on the data and not just a static Markdown output, which I always need to update later on. And this is great, so I don't need to learn the query language itself, but it knows that from its trained context or the context in the background from the GitLab documentation and the scope.

Okay. I remember that it has in rendering for that. So you can immediately see this is a live fetch. So it's like a macro markup language. If you're familiar with Confluence Macros, this is a similar implementation to fetch live data from the platform. We get an overview of merge request activity, which in this case, I offered the merge request, but everything that was offered by the flows is actually attributed to that specific service account. If I -- I think I didn't explain it in an earlier step. Okay. Now let's dive into the fourth use case, and I know we are running a little bit out of time. So let's focus on code review. But there are some merge request that might require code reviews. By default, the flow for code review does not trigger automatically for merge request in this project.

If we want to enable that, and let's do that for a second. In the settings, we want to navigate into merge request. Let's open it in a new type. There are the code review settings at some point. I should remember that code review and then enable the code reviews. So every merge request, which is not a draft automatically triggers a code review. We didn't create any merge requests yet, but we can also request a review manually. Let's see which one should we use from the instructions.

Open the merge request about the implementation of product search and filing. I think I've seen that before in the keynotes today. Let's go here into code and merge requests and open new Open this specific merge request -- and I could either edit the reviews here or the other way, which I'm confident or which I feel confident is request review and then say GitLab Duo, which is a quick action in GitLab and this then requests a review. Same pattern as before, it kicks off a flow, which locks everything in the session. So if we never get on the right-hand side into the sessions here, we can see the code review session is being triggered and we can follow along. Again, here the details.

And what happens in the background is it starts with specialized flow, which takes into account not just the much request description and title, but also the differences and the repository context and specific other references from the software development life cycle SDLC context, discussions like if there is an ongoing review already happening in order to make informed code review suggestions.

It will also comment with suggestions or with remarks. And while it is doing that, let's quickly have a look into the actual instructions. -- we have code repository, let's open that. And within the tree, we do have?.gitlab?and the?mr_review_instructions.yml. This is YAML format file, and there is also documentation for that with the instructions. And for example, for CSS, can match on files or file pass and directories and then provide the instructions for review. So specific style guides, examples to catch even -- this is a lot of front-end code. I'm not super confident with front-end engineering. So -- but this sounds good. The Python/Flask back-end security and best practices, code quality using PEP 8 compliance, Flask-specific things, performance, so like which database queries should be optimized or look for specific query problems, memory leaks and whatnot, tests and a whole lot more.

In the GitLab documentation, there's also a lot of more examples on different programming languages. So I think I added like plenty of these recently, which will give you a quick start on the specific things. Now let's see if this code review finish. No, not yet. that's still reasoning things. Okay. Let's check -- what else can we do while we are waiting for that. I mean, in reality, you shouldn't be waiting, but rather much keep it in the background, focus on the next important task on your agenda. And when it's automated, you don't even need to use any handholding for those reviews because they happen automatically similar to a pipeline that's being kicked off.

Managed activity is something we can check out. Let's open that from the managed menu. And we can see now that we've opened GitLab Duo or the code reviewer, has commented with feedback, but we can also see the user activity. And there is also a developer who started implementing a feature. So this is using the service accounts and composite identity here. The fixed CI/CD pipeline flow has run and even more than that. So this is a small inside of like governance and compliance to see what the agents are doing. Now that I know that there is feedback, you can see it's following the instructions such as a placeholder is missing, a label's missing, an accessibility label.

Okay and a whole lot more. So we can add those suggestions to [indiscernible], apply them and then continue the review. It's interesting. It follows an exception. it's also following good practices on style guide for Python. And finally, after looking at the code review use case, the last use case, we want to look into today's vulnerabilities and not just like analyzing them, but understanding whether it has an impact on the products on the application or if it's a false positive and then also get a Agentic help for implementing a merge request and implementing a fix.

The first thing to do is to inspect the vulnerabilities for this project. So let's go into secure and vulnerability report, open that in a new tab. And over here, you can see there were some critical vulnerabilities, high and so on. And we need to filter them in all status still detected and advanced fast, okay. So click that away. And the status is all status. You need to click outside of that [dropdown] to actually mark that. This is a known [indiscernible] problem. Activity is still detected can answer. And then we need to look into we actually don't want to look into anything. Let's open a new chat -- and in this case, use the security analyst agent and copy it prompt list all critical and high vulnerabilities with the locations.

Okay, let's make this a little bit bigger because there's a lot information coming in. Okay, secret detection and so on. What else can we look into -- okay, we could also use the orbit agent as a secondary step, kind of create a new chat with orbit and then repeat that question which vulnerabilities are detected and which can found them. Again, the difference here is it uses orbit, gets the schema and fetches the information directly. and it explores project and vulnerabilities and breaks down the information.

So it doesn't use any rest APIs or anything else in the background, which would take more time or even more LLM around trips and cause more cost. And we have an insight in a similar fashion. Okay. Next step, we want to triage everything. So let's go back into our chat screen the security analyst and say, triage all the SAST vulnerabilities, confirm real risks, dismiss false positives, do not dismiss vulnerabilities used in tests, and create work items for confirmed findings that need remediation, okay? This is a lot to unpack. First confirm everything which is real, dismiss the false positives and keep everything that's used for testing and then also create a work item for anything that needs remediation, okay? So it reads all the vulnerabilities and the source code and more context has a complete picture.

Okay. Dependency scanning is a?pip?vulnerability, so that needs an update. And for dismissing the vulnerabilities. Well, this is not a confirmed version. Now it's dismissing everything that's intentional. So I don't need to select that over here and figure out what is currently right or wrong. This is an automated action for that specifically. Okay. Why this is thinking. What else should we do? Okay. positive detection. -- and we got stuck again. sometimes I'm a little impatient. Okay. While this is thinking, let's look into false positive detection. Let's go into the vulnerability report again. And this time, we want to filter, copy-paste the filter over here scanner:sast advanced fast to the URL a quick cheat. There is no activity the medium severity active debug code finding in?app.py. Active debug code, there it is. And yes, this is -- runs the fast web server with the debug flag. So in a developer environment, you get more output what's happening like listing or logging requests and whatnot.

The exercise here is to remediate whether this is a false positive or not. So the icon, what the step we need to take is click here and not resolve, but check for false positive. This triggers a flow in the background. So we have another session running. So if we access the sessions here, we should see there's a false positive action running. And yes, it will also take a minute or so to continue that. while we are waiting for that in the background, the next exercise is about fixing vulnerability. And this time, it's about an SQL injection. So for example, the web application reads a user input directly and puts that in an SQL query. And the next day, you're wondering why the database is deleted or it might be sold in darknet because someone created a dump with some SQL injections and there are scanners available that help detect that.

And it's actually practice that let's follow the instructions, secure vulnerability report. And we want to modify the URL [indiscernible] and I need to cheat which line is 213. Okay 213 is the proper one. there we can see the Duo is verifying a false positive. So we always have that insight what's going on in the background, which is nice. Here is the improper neutralization. And do we need to explain it? No, we want to resolve it. No, first, we explain it, then we resolve it. We can click explain here, which opens an Agentic chat session that we can follow along.

It reads to vulnerability into context and also the source code explains the vulnerability and how an attacker can exploit that and how to fix it. Yes, I could totally continue in this chat session. But the other thing we can do is leverage resolve with Agent AI, click that. And again, we can see a new session has been started for fixing that, leveraging Agentic AI in the background. So essentially, it's running a flow, which analyzes the source code, creates a fix, creates a merge request, which then kicks off the CI/CD and security scanning again. So you can immediately verify that the vulnerability is gone in that created merger request.

And while we wait for that one, we can actually go back to the false positive detection, which is running over here and can also just access that in the session. Let's scroll to the bottom can see the reasoning and the analysis and then it updates the explanation specifically in the vulnerability report. So when we press refresh, we can see there is an AI false positive confidence score, 15% in this way. This is not a false positive, so we should fix that. And it provides a lot more insight and risk assessment to remove that. So like if you put that in production, the debug mode should be disabled. It should be even removed from the parameter.

This is a lot of information. We can also take -- remove the flag if you want. But yes, the agent helped us understand whether it's a false positive or not. And this is not just true for this specific merge request, this specific vulnerability, but certainly for any that's open and helps triage a backlog of vulnerabilities like, I don't know, maybe 100, maybe 1,000 depending on how big the code base is -- and you don't need to sit by that and review that one by one, but rather much use GitLab Duo platform [empty] the security remediation vulnerability capabilities for that. Now the vulnerability resolution flow was running. Is it this one? Yes, press refresh. The session is still running. Yes, it's still going on.

So I would ask you, as a matter of time to verify the fix by yourself. There are follow-up exercises or follow-up thoughts around how to implement like monitoring, alerting, audit logging for security vulnerabilities, which metrics to confirm anything to check. Yes, that's about it and some optional exercises from a playtime perspective. So there's so much more you can do with the GitLab Duo platform, which doesn't fit in those 90 minutes like adding MCP and so on. If you want to see more of that, we do have more workshops coming up, more live sessions. If you're in the Germany, Austria, Switzerland, I will be at the [indiscernible] to next week in Frankfurt and then the week after in Berlin, doing live hands-on demos and hopefully not losing my voice. But that said, this brings us to the end of our workshop.

Here is it. If you want to transfer the project -- so when a transfer, you lose access to the LearnLab. So right now, probably continue in the project and finish the exercises. But there is an instruction in the transfer.md, which helps you move everything to your own environment if you want to. And if you have any further questions, let us know either here, can join our community forum, Discord, social media, meet us in person, ask the sales, your account executive, ask our support team, we are here to help you adopt GitLab Duo platform. Yes. And thanks for joining today, participating, and I hope you have a great rest of your week, fully empowered now with what you have learned today. Thank you.

I'm Koji Ikeda. I'm one of the software analysts here at Bank of America. Welcome to day 3 of our tech conference. I am absolutely thrilled to be hosting GitLab for a fireside chat. We have Bill Staples, CEO; and Jessica Ross, CFO, with us today. Thanks so much for joining us.

Absolutely.

Hello, everyone. Thank you.

Hello.

So I think you guys just reported results this week. It's been a busy week. I've been running around the tech conference. And so maybe even just to help me, would you recap the first quarter results, kind of the big news coming out of it and how we're thinking about guidance going forward?

Yes.

Why don't you kick off with the numbers, and I'll fill in color?

Yes. No, we had a very strong first quarter, very excited. We beat on both revenue and profitability. Revenue was $264 million, growing 23% year-over-year. We delivered 14.2% in NGOI margin, which was a 200 basis point increase year-over-year. Our enterprise business is strong. We are growing seats. We saw strength across all geographies, and we saw some particular strength in PubSec in EMEA. So we're very, very excited about that.

A couple of other just data points. Our $100,000 customer cohort grew 18%. We just crossed a big milestone with GitLab Dedicated with $70 million in ARR. And overall, the business is very strong.

Yes. Maybe I'll just add a few other data points and color around leading indicators for growth. We shared, this quarter, we had 30% year-over-year increase in first orders, so new customers coming into the business. That's been a focus for us because we've traditionally been a land-and-expand business, but have never focused as a company on winning new logos per se, it's always been take what comes. But now as a $1 billion revenue company, we've decided to specialize our sales force and have dedicated focus on first orders as well as a product-led growth motion that we've kind of rebooted, and that's starting to pay off. Customers tend to land small with us but grow over time. But it also demonstrates our competitive position and ability to win in this very dynamic market.

Second, we also shared a number of activity metrics in the platform. We're the beneficiary of all of the AI coding dynamics that are underway with Claude, Cursor, Codex and multiple other players. All of that code that gets generated drives demand for GitLab. And while our business model currently doesn't capture that because we've always had a seat-based business model, that allows engineers to use whatever coding tools they want to use GitLab to productize that code, we see the platform usage surging.

So last quarter, we shared, for example, 60% growth in projects that use our security capabilities. This quarter, we shared nearly 50% increase in year-over-year in code pushes. So more code getting pushed into GitLab, also significant growth in pipelines. Those are the things that take code and verify it, secure it, get it ready for deployment, and then push it out. We saw that go from the 20s in the last half of FY '26, growing month-over-month now to 38% year-over-year growth in Q1. So those are all leading indicators that we're really benefiting from the AI coding work that's going on around the industry. And I shared during the quarter, 5 new architectural bets that we're making that set us up not only to deliver more value for customers, but also capture that value over time.

One last kind of data point for the quarter, which is it was the first quarter that we've actually had our new agent platform product in market. This is us taking LLMs and providing agents across the software life cycle to help with all the tasks that engineers have to do to not only write the code, but actually ship the code out to their customers. And in our first quarter, we captured more net new ARR than any previous quarter combined across our prior 2 AI products. So it was a very strong start. We also shared an interesting early data point around consumption because this new agent platform is a new pricing model. That's a consumption-based model, not our seat-based model. And in the first quarter, we saw a $20 million consumption run rate. That's a measure of both committed credits and on-demand credits that were built up both pre-GA and then in our first quarter of business.

So I felt that was a very strong start. Nothing that you should depend on in terms of $20 million on the other side. It's a run rate based on one quarter only. So we're not building it into our forecast. But we thought it was valuable to share nonetheless.

I guess maybe a couple of other things. I mean there was a lot of goodness in the quarter. We did also highlight, though, that the quarter saw some churn and contraction related to layoffs and also some unique contraction related to M&A. We view those both as temporal, especially the M&A side, unique. But without that, the quarter would have been even stronger.

And I think just -- I know you asked about guidance, too, so just maybe stepping back for those newer to the story. When we gave guidance at the beginning of the year, we gave a very wide range of 15% to 17% in terms of revenue growth. There's a lot of moving parts, which we'll talk about as we have this conversation. We really positioned this year as a year of investment and execution. And I think the big message this quarter is that is playing out as planned. Our assumptions are playing out. This is a quarter of tighter execution, which gave us confidence to raise the guide. So we've narrowed that to 16% to 17% and really just again, excited about the year ahead.

Is there a metric that investors should be focusing on as the best leading indicator of the ability to not only achieve the guide but potentially beat it? Is it billings, RPO, the Duo Agent Platform, $20 million metric? I mean what should investors be focusing on as an indicator of health?

I think we really laid out 5 growth initiatives. I don't think it's 1. I think with our business, you've got to -- it's really about us having all -- firing on all cylinders. And so I think that's why we're very intentional about laying out the metrics that Bill talked about. At the end of the day, though, in terms of our guide, we have a ratable revenue model, and that gives us a lot of visibility. And so we really focus on revenue as our forward metric that you should also be focused on as well.

Okay. So a couple of weeks ago, you guys announced that there might be some changes within the organization, and then you fully laid it out on Tuesday of this week. And so help us understand the strategy behind it, the benefit -- what you think will be the benefits of it? And then how to think about headcount growth going forward?

Yes. So a couple of weeks ago, I published a letter. If you haven't read it, it's published on our website. It's called Act 2. GitLab Act 1 has been an incredibly successful effort, right? We're now over $1 billion in revenue, growing at 23% this quarter, and we serve over 50% of the Fortune 100. Some of the largest companies and organizations around the world depend on GitLab. We're incredibly proud of what we've built and what we have.

At the same time, you all see it, I'm sure, the way software engineering is happening is changing. It's changing rapidly. And we sit down with our customers all the time. But this quarter, in particular, we had several opportunities to have our advisory board. These are some of our largest, most strategic customers, come together in person with us and talk about the future of software engineering, where we believe it's going and what the opportunities are for GitLab to add value and solve their problems. And we came up with 5 architectural bets that we believe set GitLab up to benefit from the AI structural tailwinds that are happening around coding.

These are investments that often relate to the scale of infrastructure that we provide as well as the capability that we already provide for humans, but now are needed across humans and agents. I can walk through them if you're interested. But the bet starts there, the Act 2 starts there, is we realize in order to serve our customers going forward in this agentic era, we need to focus on the scale and the capability of what we do across both humans and agents. So that work was laid out.

We also, as a management team, this is the first quarter since I became CEO, is 6 quarters ago now, where I've had the entire exec team together. We've gone through some executive changes since I joined. Jessica joined just a few weeks before the quarter began, as did my CTO. And as an executive team, we got together, we looked at that strategy, those architectural bets, and we feel very confident and convicted that those are the right things for us to go laser focus on and execute.

We also asked ourselves, though, like what else do we need to change to move faster as an organization to capture this opportunity while it's right here in front of us. And that led to a discussion around a restructuring and changing both the operational footprint of GitLab as well as the organizational layers and some of the culture dynamics. So when we looked at the operating footprint of GitLab, GitLab really came into its own amidst the COVID era. It was really unique in kind of defining a remote-first async culture that was native to that era. And the hiring strategy at one point was hire in any country where there is talent. We ended up with 60-plus different countries where we have employees. And for a company our size, that is pretty unwieldy. We had a long tail of countries where we had 1, 2 or 3 employees, and we've decided to shrink that. So we reduced the number of countries by 22. And now we're smaller in that regard.

We also looked at our management layers. We had 8 layers of management. And we decided in order to streamline communications, prioritization, decision-making, we wanted to shrink that to 5. So we've done that. And then third, we looked at how we execute, how we focus as an organization. And our previous core values were really centered around flexibility, again, born in that COVID era when everyone was struggling to figure out how to do remote work and how to work from home, and we decided that for the agentic era, the #1 thing to focus on is speed. So we're shifting from flexibility to speed with quality is our #1 operating principle.

Second operating principle that we've defined is ownership mindset. We want to empower -- truly empower every individual in the organization to think like an owner of the business to be able to own decisions and execute versus just take actions and check boxes on tasks. And then third, our third operating principle is all about customer outcomes. We want every individual in the organization thinking about the reason we exist is to serve customers and deliver value to them. And so everything we do, can we clearly define the customer benefit or customer outcome that, that work produces.

So those are the 3 new operating norms that we created or operating principles. Those are the structural changes we made. And when I introduced these changes to the company, we decided, given the magnitude of opportunity and the magnitude of change that we're introducing, we would explain all of that to our company transparently and also do the restructuring openly. So we spent a couple of weeks with all leaders in the hierarchy to work through exactly how the reorganization would work. And we offered the opportunity for every employee to decide to if they wanted to opt out of all of this change and be part of the restructuring. We felt like that was important because, again, the magnitude of change is great, and this is an opportunity to exit the restructure with an aligned, committed team versus a team that feels like change is being thrust upon them and then they have to go find something different if they don't like it.

It's been a tough couple of weeks at the company, but I can say I think we're coming out of it much stronger as a result of the approach we took to the restructuring and new energy kind of infusing in the company now. Next week, we have a customer event. It's an annual customer event that we do at the start of every major release. It's in London, but it's broadcast here if you'd like to it -- if you'd like to watch it. And we're going to be unveiling a bunch of new innovation, including several of the architectural bets that I shared in that Act 2 letter, which you're definitely going to be interested in watching. If you get a chance, I recommend it.

Maybe just kind of layering on how that kind of works from a financial impact perspective as well. So just to be clear, this restructuring was never intended to be a cost-cutting or margin exercise. This is really about aligning the organization strategically to win in this agentic era. So ultimately, with all the decisions, we ultimately reduced our workforce by about 14%, 350 of our team members, and we are recognizing a restructuring charge of about $30 million to $35 million, $19 million in Q2, with the remainder through the rest of the year.

But we are reinvesting, the intent is, all of those savings in the architectural bets that Bill has outlined. We're really looking at it in 3 ways: people, technology, process. This is a big cultural shift for GitLab, and we are asking a lot of our Act 2 team members. So we're investing in our people. Secondly, again, from a technology lens, I think, Koji, you were asking about headcount strategy, especially in R&D, this is about making sure we have the right talent to really capitalize on this moment. We're probably going to be growing and investing in R&D. And then from a process lens, we are looking at every single workflow across the business and reconfiguring that to be AI first. So really excited about those and the opportunity ahead.

With such a big change, one thing I think about is culture, maybe near-term risk, but also long-term benefit. And I love the speed with quality. For any technology company that makes a lot of sense and especially anybody working in software development, I mean, speed with quality is paramount. And so how do you -- as much as you can, how do you think about building culture from here going forward within the company?

Yes. One of the things that's really interesting is I've been building software for 30 years, and I've been working with software engineering teams. I came up through a product and engineering background. And so I've seen a lot of software and how teams build software. And even within GitLab, it's been interesting to watch how the engineering team has evolved in accepting new ways of building software with agents. And on -- even within GitLab, I see the full spectrum of attitudes, skill sets and approaches, right?

On the one hand, I have an engineering team that we'll be shipping next week at Transcend, who literally writes and delivers more code than the average of the organization by 20x. They have the luxury of a brand-new service built from scratch in a modern stack using AI tools. And what they built is phenomenal. I have other teams that are struggling because they have an enormous amount of legacy code that was built over the last 10-plus years. There's technical debt there. And they're using AI. Their usage of even our own platform, Duo Agent Platform, has accelerated them 2 to 4x faster than our historical average. So that's awesome to see.

But I also see others in the engineering organization who feel like AI is a threat, AI is taking over their jobs, reducing the importance of the skills that they've spent decades building. And I understand how that can feel. At the same time, over 30 years, I've watched how the engineering practice has changed so many times that I feel like this is just another evolution of the same thing, right? And so we've tried to give the coaching, the encouragement, the space to adapt toward this new modern ways of engineering.

But to your culture question, what we're now saying is, "Look, we've identified what it looks like to be highly successful in agentic engineering. We have several of these teams that are going multiples faster than our historical norms. Let's snap that as the cultural icon. Let's find ways to train and enable and give tools to everyone to reach that new standard because that's going to not only benefit you in your careers, your ability to harness the best technology to build software, but it's going to help us prove our platform, live it first as customer zero and share with the rest of the world that depend on us how to take advantage of AI tools in this new era." So that was what Act 2 was about, was taking those bright spots, those early wins that are already within our organization and setting that as the new standard for everyone. That's how we got to where we're going.

So Transcend next week. I'd be excited to tune in. As much as you can tell us, what should we be focusing on? And I know there's somewhat of a new pricing model you alluded to on the call, Flex. Tell us as much as you can about Flex because I know you're going to talk about it a lot next week.

Maybe I'll talk about some of the cool technology. You can talk about Flex?

Yes.

So next week is going to be amazing. We're going to have incredible customers on stage, partners on stage and do demos of a whole bunch of new innovation that we've been building out over the last quarter. And it is -- I'm so excited about it. So you can expect to see, for example, one of the architectural bets that's really unique to GitLab is the first part of our name is git. It's same as GitHub, our competitor, based on an open source layer where code gets stored and version control. GitLab has -- is the #1 contributor to that project in the world today. The top -- I think 3 of the top 5 contributors are GitLab employees.

And we have decided that, that scale of infrastructure that was built for humans is not going to meet the needs of agents. We believe agents are going to push it 100x beyond what it is capable of doing today. And so we've joined forces with an AI lab, and we are building a new architecture and a new set of capabilities for agents for that infrastructure layer, and we'll be demoing it next week with our partner at 100x scale. It is impressive to watch. You'll see both Duo Agent Platform and Claude Code and other external agents driving volumes of code that is impossible today. So that's an exciting one.

We are also going to be debuting our new Orbit service. GitLab Orbit is we take all of the data inside GitLab, everything from all of your code, obviously, but all of the connections to that code. So the people who wrote it, the changes over time, the plans and bugs against it, the security scans, the builds, everything. We stitch it together into this graph, and we then provide an API for agents to read that context. The reason that's so important is agents thrive on context. The better quality context you give them, the better quality outcomes they produce, and they can do it at lower cost. And you'll see just how much quality and cost GitLab Orbit provides next week. There will be several other amazing demos. I don't want to steal the whole show, but those are some of the highlights to look forward to.

And then just on Flex pricing, not much to share here. You'll have to tune in. But as we're thinking about the future for our customers, it's really about providing optionality, and we're really solving for cost, value and predictability. And Flex pricing will be a contract that will allow customers to have both seats and GitLab credits, so to be able to access our consumption-related products, which we'll be talking about some of those more next week, and we are really excited about this offering. We've had early conversations with customers. I think they're very excited about it. Our sales force is excited to sell it. But we'll come back with more next week. So please tune in and then follow up with all the fun financial details when we get to Q2.

Bill, I wanted to follow up with you on the AI lab that you mentioned. So both bullish, but I want to be measured here. Any time a company says AI lab, we could kind of get over our skis. So I want to stay measured. And I really want to ask around why would an AI lab want to partner with GitLab because a common bear thesis out there is an AI lab could just build the entire software development life cycle tool chain themselves?

Yes. Yes. Sometimes nontechnical people look at how powerful AI agents are and LLMs are and think, "Oh, well, they can build anything," right? And theoretically, that's true. But practically speaking, it's a lot harder than it looks. And as I mentioned, for this infrastructure layer where we're partnering, we are the #1 contributors in the world. So there's both domain expertise and historical momentum and buy-in from the community that they get by working with us.

Second, we actually are the git provider for a number of the AI start-ups and AI labs. And so in particular, this one is a customer of GitLab. And it's the respectful and beneficial partnership in action, I think, as we work together because we're also a consumer of their products and services. And then third, I think, as I said before, we support hundreds of thousands of organizations around the world. We have more than 50% of the Fortune 100 that use GitLab today. They see us also as a distribution channel. When we can support agents at 100x load, that's going to mean they can drive more volumes of tokens through their agents. And so it benefits them by partnering with us because then their agents running on our infrastructure go way faster and lead to more value for everybody.

I can't believe we made it 26 minutes without talking about Duo Agent Platform or DAP that you guys always talk about it on the calls. And so you guys gave a $20 million metric. It's a CRR consumption run rate.

That's right.

What exactly is in that $20 million? How do we think about it? And with any time a company gives a metric that's -- what is the expectation on the frequency of when we might hear this metric?

Yes. No, so we're very excited about this. It is an early green shoot. Essentially, what consumption run rate is, is it takes our committed DAP credits plus overages over 28 days and annualizes that number as a run rate. We are very, very excited about it. But again, this is -- we're quarter in, it's data that is just a signal of product-market fit. It's a signal of -- we're excited. It's -- the product is launched. It's doing very well. Just I think one point of clarification, because on the call, there was a couple of questions about this, so it doesn't include any of our prior AI products, Duo Enterprise or Duo, but it does include a small minority of conversions from those products into DAP.

I think the big takeaway is that this is, like, additive. And I think the other thing that Bill highlighted at the beginning of the call is that first quarter out, we have higher ARR from Duo Agent Platform compared to either of our prior AI products combined. So again, very excited about it. And as the business evolves, we will continue to come back with metrics on a more frequent basis.

Not a quarterly metric, but a milestone.

A milestone metric. I think that's a great way to think about it, yes.

That's great. Okay. So how do we -- how are you guys -- Duo Agent Platform has been out in the market for some time with your beta customers, and it went live earlier this year. And so how are you going to market with it? And how should we broadly be thinking about adoption, consumption? How does it show up in the model?

Yes. We go to market both product-led motions as well as sales-led motions. So on the product-led side, we introduced $12 in premium credits for every premium seat and $24 for every ultimate customer seat, which allows engineers that are already in GitLab to begin to experiment and try the platform without having to have their organization make a commitment. The organization does have to unlock the feature. But once they've unlocked it, there's no monetary commitment required. That is kind of a product-led growth motion.

The sales-led growth motion is we have now enabled our sales force this quarter, Q1, once again, our first quarter, to go and sell a Duo Agent Platform as repo side, so server side, agentic engineering across the software life cycle. And that is in contrast to what Claude, Cursor, Codex do, which are more client side or developer side, authoring the code. Where we run on the organization or the server side where the code is stored to do all of the actions, not just coding, but all of the security, all of the planning, all of the pipeline remediation on the repo side. So it's a complement.

Our sales force often goes in and helps educate the customer on the use cases that we provide, that are different and additive to what Claude or Cursor or whatever their tooling strategy is and how those 2 can come together to accelerate the full software engineering life cycle.

And then there was another part of your question I'm missing.

I forgot, too.

Okay.

But in the last 30 seconds here, I wanted to ask you on security. I mean, security offering is very good, very, very strong from GitLab. And so what is top of mind for your customers around software development and security?

Yes. You probably see in the news a lot of software supply chain attacks going on. Hackers or attackers are using LLMs now to discover and exploit software vulnerabilities in record time. Agents make that easy, too. And so it is more important than ever that companies put security practices in place, not on production code, but before the code ever ships. Because once it's in production, you're exposed, and the hackers' time to find that and exploit it is lower than ever. What GitLab does is we provide the real-time security scanning in the code pipeline before the code gets deployed. So that's a really powerful value proposition and always has been, but even more critical today.

Got it. We're all out of time. Bill, Jessica, thank you so much for doing this. We appreciate it.

Thanks, Koji.

Koji, thanks.

Thank you so much.

See you next week at Transcend.

Good afternoon. We appreciate you joining us for GitLab's First Quarter 2027 Financial Results Conference Call. With me are Bill Staples, our CEO; and Jessica Ross, our CFO. During this afternoon's call, we will provide an overview of the business, commentary on our first quarter and full year results and guidance for the second quarter and fiscal year 2027.

Before we begin, I'll cover the safe harbor statement. I would like to direct you to the cautionary statement regarding forward-looking statements on Page 2 of our presentation and in our earnings release issued earlier today, both of which are available under the Investor Relations section of our website. The presentation and earnings release include a discussion of certain risks, uncertainties, assumptions and other factors that could cause our results to differ from those expressed in any forward-looking statements within the meaning of the Private Securities Litigation Reform Act. As is customary, the content of today's call and presentation will be governed by this language.

In addition, during today's call, we will be discussing certain non-GAAP financial measures. These non-GAAP financial measures exclude certain unusual or nonrecurring items. -- that management believes impact the comparability of the periods referenced. Please refer to our earnings release and presentation materials for additional information regarding these non-GAAP financial measures and the reconciliations to the most directly comparable GAAP measure.

I will now turn the call over to Bill. Bill?

I'm pleased to report Q1 results. Revenue of $264 million, growth of 23%, operating profit of $38 million and a 14% non-GAAP operating margin and 1,519 customers paying us more than $100,000 a year, up 18% year-over-year. Dollar-based net retention was 117%. These results helped crystallize what has become increasingly clear. The opportunity ahead is massive and speed matters. We announced GitLab's Act 2 a few weeks ago. Jessica will get into the details of the financial aspect of the restructuring shortly. I'll spend my time highlighting the signal we're getting on the opportunity and the strategic bets we're making to unlock GitLab's advantages against this structural tailwind.

Our core enterprise DevSecOps business remains strong. Gross bookings growth rate hit its highest level in 4 quarters. GitLab dedicated crossed another milestone of $70 million in ARR. Ultimate now represents 57% of ARR and 7 of our top 10 deals. [ DAP ] contributed more net new ARR in its first quarter, then Duo Pro and Duo Enterprise combined in any prior quarter and it was attached to 4 of our top 10 deals.

Over the course of FY '27, we intend to transition Duo Pro and Duo Enterprise subscriptions into DAP, consolidating our AI portfolio into a single agentic platform and onto the consumption business model. Platform activity is also surging. Code pushes across our paid SaaS customer base are up 49% year-over-year. CI pipeline growth accelerated from the mid-20s in late FY '26 to 38% in April. One of our most advanced agentic customers grew the volume of code in their repositories by 2.5x in just 6 months and still accelerating. The agentic era is creating structural tailwinds for DevSecOps platforms, and GitLab is on the critical path to scaling agentic engineering in the enterprise.

Let's talk about the 5 growth initiatives I introduced last call. First, accelerating first order growth. We delivered 30% higher new logo growth versus the same period last year. The dedicated first order team is ramping ahead of schedule and a strong resurgence in product-led growth produced our highest absolute first order count in 10 quarters. The reason this matters is simple. The changes we've made this past year are enabling GitLab to compete and win new business at a dramatically faster rate. And while net ARR contribution from many of these customers is small in year 1, history is unambiguous about what comes next.

For example, our 2016 cohort has expanded more than 100 times over the past 10 years. That is the type of customer journey we're working to replicate with all of our new customers. Second, we told you we're scaling sales capacity. Our FY '26 quota-carrying headcount investments are already benefiting gross bookings as planned, and we continue to grow capacity. Based on the timing of these hires and our historical ramp time, consistent with what we shared last quarter, we expect most of the benefit to land in the second half of the year.

Third, let's talk about our expanding monetization vectors. There are really 3 dynamics to highlight. First, our customers are starting to ask nontechnical users, product managers, designers, security teams to begin using GitLab and agentic workflows which translates to more seats needed over time, governance, version control, audit trails and approval workflows are now their problems, too. That's a new footprint to grow into.

Second, agentic workloads are pushing DevSecOps infrastructure harder than it was designed for. The outages and reliability gaps of our competition you've all been reading about are showing up in customer conversations. Our cloud-neutral architecture and platform reliability are real differentiators in those conversations and a few of the architectural bets I'll talk about in a minute, will position us to capture the agentic infrastructure opportunity ahead.

Third, our consumption business is off to a really solid start. Consumption run rate is an internal metric we track to gauge uptake of GitLab credits. We're sharing CRR this quarter as an early signal. However, it's important to note that 1 quarter is not sufficient to establish a meaningful trend at the end of our first full quarter of consumption. Dual agent platform paid consumption run rate was nearly $20 million. Included in this number are minimum usage commitments made pre-GA and during Q1 as well as on-demand credits. As dual agent platform adoption expands and we bring new products to market, paid CRR will likely become a more meaningful forward indicator of where our commercial model is heading. We'll provide more formal metrics and disclosure cadence as this motion continues to mature.

Fourth, we're continuing to support price-sensitive customers. headwinds have persisted with this cohort, which makes up about 20% of our ARR, the initiatives around increased coverage and faster time to value are underway and will take time to manifest.

Fifth, we're executing our AI strategy. GitLab dual agent platform reached general availability 2 weeks before the quarter began. And as I shared at the top of the call, contributed more net ARR in its first quarter than Duo Pro and Duo Enterprise combined in any previous quarter. As cogeneration accelerates, the AI paradox is real. Every customer I talk to describes bottlenecks, across code review testing, security remediation, pipeline management and more dual agent platform handles the repetitive engineering workflows across the software life cycle, so engineers can focus on consequential work.

The pattern underneath these numbers matters, though, even more. DAP is unlocking access to incremental AI budgets beyond existing DevSecOps spend. That's a different commercial dynamic than seat expansion, and it changes our addressable opportunity inside accounts.

We also announced expanded relationships with AWS, Google Cloud and Anthropic this quarter. Duo Agent platform spend is now eligible against committed cloud budgets on Google, AWS and Anthropic marketplaces, which removes a real procurement friction point. One customer story makes the dynamic concrete a top 10 U.S. bank ran a dual agent platform pilot across everyday engineering workflows.

In Q1, developers averaged 1.5 hours of savings per task active rollout is now underway across hundreds of developers with adoption and daily credit consumption climbing fast. Each cohort ramps faster than last. And based on the customer's current rollout plan, the active user base is expected to grow nearly 20x upon full deployment later this year.

Next, I want to share our learnings from the evolving environment and where the market is going. We recently hosted our Executive Advisory Board meeting, where we brought together leaders from our largest and most strategic customers. I wanted to share 3 insights from this event, which help illustrate where the market is heading and GitLab's growing value proposition.

First, the Head of Engineering at a major technology platform, put it this way, agents are like psychopathic interns. They lack good judgment, a human to go to jail for certain decisions, but what about an agent? That question doesn't have a legal answer yet. Governance and control is a systems level problem that needs a platform level answer. And that platform is GitLab.

Second, the Head of Software Engineering at a top 10 bank after hearing our road map, told us he buy the full platform tomorrow. His 1 condition was tool optionality for developers. In other words, GitLab's value is twofold. Cloud, model and tool neutrality and everything that happens around cogeneration, the tests, the controls, the governance.

And finally, one customer managing over 200,000 repositories told us they simply can no longer configure governance project by project. What they need is what they call mission control logic, policy injected at the platform level across the entire state. That's a machine scale problem and one of our architectural bets I'll describe in just a minute.

The signals in our Q1 performance and from our customers are strong, maximizing our ability to capture this opportunity requires change to our infrastructure monetization and how we operate. I laid those out in my Act 2 letter.

Here are the 5 architectural bets we're pursuing to create new value for customers, position ourselves to benefit even more from AI structural tailwinds and expand our monetization factors. Transcend next week will be live streamed on our website and really bring these to life.

All right, bet number one, machine scale infrastructure, agents work at machine scale and they're pushing competitors to the brink. This quarter, we began a generational rebuild of Git to support the scale and features required for 100x Grove. This is a scale requirement that didn't exist before and has become a real pain point for every team on their agentic journey. We're partnering with an AI lab on the design and implementation of the new service, including APIs that are optimized for agents to store and retrieve context, including code. As the leading contributor to get today, we have a right to win this layer of infrastructure. You're not going to want to miss the demo next week.

That number 2 is around orchestration. Agents create activity, what businesses need is software that drives business outcomes. Orchestration is what connects the 2. We've been connecting and automating the steps of software delivery for years with our CICD pipelines. We own the assembly line for code, building, testing, shipping and securing it in a defined sequence with dual agent platform, GitLab can now coordinate software development life cycle tasks between humans and agents.

The next step expands our agentic infrastructure across artifact management, governance and compliance and continuous deployment. For these new services, the value scales with the work performed just as it does with dual agent platform.

Architectural bet #3 is all about context. Cogeneration is commoditizing fast and enterprise AI bills are climbing as fast as adoption. What doesn't come out of ties is the connected data model across every project, every repo and team accumulated over years. We're building a first-class API accessible service called GitLab Orbit that improves outcome quality and reduces the cost of agentic actions. Access to orbit will be monetized through consumption credits and will be valuable to both DAP users and external agents, cloud code, cursor, codecs, whatever the customers choose. Context is a compounding asset. Every human and agent action actually makes it richer.

Architectural Bet #4 is about governance. For enterprise scale adoption, governance is nonnegotiable. -- we're designing identity, audit policy and deployment flexibility as core platform services from the start. So every agent pipeline and merger quest runs through them by default. This builds on the work that already differentiates GitLab Ultimate, and you'll see more advancements in this area at Transcend next week.

Architectural bet #5 is that 1 platform for all modes of software engineering will be incredibly valuable for customers. There are trillions of lines of code that exist in the world today, and most of it can't and won't be rewritten anytime soon. software teams will build and manage software 3 ways for the coming decade. They'll do it the manual human software development life cycle approach that we have led for the last decade, values agents on tasks as they do today with dual agent platform, and they'll embrace autonomous agentic engineering.

Just like the cloud era, choosing a vendor strategy that splits your infrastructure and your developer experience is a painful and costly choice. GitLab customers don't need to. GitLab is the 1 platform that already spans planning, coding, reviewing, securing, deploying and operating with 1 control plane, 1 data plane and governance underneath. adding autonomy is an extension of the platform, not a separate stack.

Customers get 1 place to manage all their software systems with cloud and model neutrality. That's the structural advantage others simply can't match. I want to also talk about GitLab Flex. You see as AI workloads change the relationship between cost, value and predictability, our business model will need to follow suit.

Consumption is the right model for it. which is why we added GitLab credits to our business, it's becoming increasingly clear that customers need even more flexibility in how they use our platform. That's why next week at Transcend will be unveiling GitLab Flex, a buying program that lets customers mix, seat-based and credit-based products in ways we believe that will be exciting for them and for GitLab. We look forward to sharing more with you then and in the quarters ahead.

Let me close with 2 customer stories from the quarter. They illustrate a simple point. The problems that GitLab solves, security, compliance, governance at scale only get harder in the agentic world ahead. Zillow Group operates the U.S.'s largest real estate marketplace and has been a GitLab customer for over a decade. Their internal AI-powered pipeline engine generates thousands of GitLab projects and pipelines. AI scale workloads added to Zillow's coding agent providers and Zillow's internal agents have meant fundamentally different infrastructure needs as AI-assisted workflows help engineering teams ship 40% more code per engineer and focus on broader development priorities.

This quarter, they're migrating more than 2,000 engineers to get lab dedicated to strengthen security and compliance with platform-level enforcement and scale with AI-driven growth. They're also piloting GitLab Duo Agent platform as the context layer that makes their AI investments even more effective.

CSL Behring, a global biotech leader, is another long-time GitLab customer who signed a multiyear commitment to GitLab Ultimate and dual agent platform this quarter, further deepening the relationship. Their challenge was not just consolidating fragmented tools, but doing it while standing up an AI development capability that their AI Governance Board could approve and GitLab's unified platform, provided enterprise model controls, logs and security analysis, embedded in the same pipeline developers already use.

Before I hand it over to Jessica, I want to take this moment to thank all team members who have helped bring GitLab to where it is today, including those departing in connection with the workforce changes announced as part of Act 2. The work you've done here mattered and it continues to matter. You came to GitLab when we needed you. You laid the foundation on which we stand today. Thank you.

The opportunity ahead is an incremental growth on a devs -- platform. We are now on the critical path to scaling agentic engineering in the enterprise and building towards becoming the trusted enterprise platform for software creation in the agentic era. I'm really excited for our Transcend event next week. You'll see Orbit. You'll see Flex. You'll see agents pushing Git at 100x scale and our first delivery of autonomous engineering. That's where the next chapter starts. Our very best days are ahead.

With that, I'll turn it over to Jessica.

Thanks, Bill, and thanks to everyone joining us. I'll now cover 3 things: our Q1 results, what's driving them? And how you're thinking about the rest of the year? Revenue came in at $264 million, up 23% year-over-year and 4 points ahead of our guide. Enterprise performance was strong, with strength well distributed across all geographies. And Public sector performance also outperformed our expectations and GitLab dedicated across another milestone of $70 million in ARR.

In addition, the quarter also benefited from $2 million of nonrecurring overages and early renewals. We delivered this against an uncooperative macro backdrop. As we expected, our price-sensitive cohort, roughly 20% of ARR remained under pressure. Across the business, we saw more see contraction than we anticipated, mostly tied to layoffs in our customer base. M&A-related contraction was an additional headwind. Without those dynamics, the quarter would have been even stronger.

Where GitLab's platform really shows up is in our enterprise business. where we continue to see resilience. Our 100,000-plus customers grew 18% year-over-year to 1,519 and now represent just over 75% of ARR. We now have 10,831 customers paying us at least $5,000 in ARR, representing over 95% of our total ARR base.

Gross retention remains well above 90%, in line with historical trends. Dollar-based net retention was 117%. As expected, the tale of 2 cities we've talked about before continues to play out. We saw healthy spend dynamics from our larger customers and pressure in the mid-market and SMB segments that weighed on net retention.

Total RPO grew 18% year-over-year to $1.1 billion. Current RPO grew 24% to $724 million. Now moving down the income statement. Non-GAAP gross margin was 88% as SaaS continues to grow as a share of our revenue mix. It's now about 1/3 of total revenue. and grew 37% year-over-year, driven by continued strength in GitLab Dedicated and Duo. Q1 non-GAAP operating income was $38 million versus $26 million a year ago. Non-GAAP operating margin was 14%, up roughly 200 basis points year-over-year.

On JiHu, Q1 non-GAAP expenses were $3.1 million compared to $3.1 million in the prior year. Our goal remains to deconsolidate JiHu, though we cannot predict the likelihood or timing of when that may occur. Adjusted free cash flow was $147 million, a free cash flow margin of 56%. Here, we benefited from timing of collections.

Before turning to guidance, I'll provide a quick update on capital allocation. The framework I laid out last quarter is the same one guiding us today, invest first in growth, maintain balance sheet resilience, and these buybacks to drive shareholder value and manage dilution. Q1 reflected all 3. We ended the quarter with $1.36 billion in cash and investments, we repurchased about 2.4 million shares and have $350 million remaining on the authorization.

Now turning to guidance. Let me lay out our key assumptions for the balance of the year. I'll begin with our Act 2 plan announced last month. A key component of this plan is a restructuring of our workforce. This is to ensure we have the right operating structure to capitalize on the opportunities ahead of us. As detailed in our initial announcement, we have engaged closely with our teams to reshape our company in the most effective and transparent way possible. We are finalizing these decisions and anticipate that approximately 14% or 350 of our team members as of January 31, 2026, will be impacted.

We also expect to exit 22 countries and reduce our team member geographic footprint by approximately 37%. We are flattening our organizational structure with up to 3 layers of management removed. We expect to incur $30 million to $35 million of pretax restructuring charges, of which approximately $19 million is expected to be incurred in Q2.

The majority of the remainder is expected to be recognized over the following 3 quarters. We expect to reinvest the vast majority of the savings from this restructuring into several specific initiatives designed to accelerate our Act 2 strategy. These include investments in our team members, a reallocation of resources to lean into the architectural bets that Bill outlined and further building out internal AI tooling and associated costs.

Additionally, our outlook reflects prudence on 4 key items. First, macro. While we did see an improvement in public sector performance this quarter, we continue to not assume a meaningful bounce back in FY '27. We also continue to expect the price-sensitive cohort, which represents approximately 20% of ARR to remain under pressure.

Second, while we are pleased with the early progress, we continue to assume no material revenue contribution from GitLab Duo Agent platform in FY '27. The focus this year remains on converting pilots to production and ramping new adopters.

Third, we see accelerating lay ops concentrated in the tech sector and heightened customer caution associated with these changes.

And fourth, the potential for some near-term disruption associated with organizational changes as we operationalize Act 2. We carefully considered business continuity when reviewing any restructuring affecting our quota-carrying sales force. We intentionally undertook a voluntary separation program. This was to head off future potential attrition associated with the changes we made. That said, changes of this scale carry some near-term disruption, and our guidance reflects that.

Given our Q1 performance and the continued progress we are making across many of our 5 strategic priorities, we are raising our guidance for the full year. For Q2 FY '27, we expect total revenue of $272 million to $274 million, representing approximately 15% to 16% year-over-year growth. We expect non-GAAP operating income of $30 million to $32 million, and we expect non-GAAP net income per share of $0.17 to $0.18, assuming $168 million weighted average diluted shares outstanding.

For the full year, we now expect total revenue of $1.112 billion to $1.118 billion, representing approximately 16% to 17% year-over-year growth. Non-GAAP operating income of $135 million to $141 million, and non-GAAP net income per share of $0.79 to $0.82 assuming a $166 million weighted average diluted shares outstanding. I'd also like to provide a few additional points for modeling purposes.

First, we continue to expect full year gross margins to be between 85% and 87%. Second, we expect profitability to trough in Q3 due to timing of investments post restructuring. Third, we are forecasting approximately $50 million of expenses related to JiHu compared with $13 million last year. This is a year where we are investing deliberately to capture the Act 2 opportunity. The financial profile we've achieved over $1 billion in run rate revenue, strong cash generation and $1.36 billion on the balance sheet is the foundation we're investing from not toward.

That's what gives us the flexibility to rebalance resources behind our highest return initiatives and return capital to shareholders, all at the same time. The opportunity ahead has never been greater and the foundation we're investing from has never been stronger.

Thank you for joining us. I'll now turn the call over to Yao to moderate Q&A.

[Operator Instructions]. We'll take our first question from Matt Hedberg with RBC, followed by Sanjit Singh from Morgan Stanley.

Congrats on the quarter. Really great to see the stabilization this quarter. I guess, my question, Bill, for you, with all of the innovation that you guys have been delivering upon, can you talk about the competitive landscape? I guess specifically, looking at GitHub, how win rates trended there? Is pricing holding up? Just any color on that, it feels like you guys are having quite a bit of success these days.

Thanks so much, Matt. Yes, it's a very interesting environment we live in. Agents are really driving infrastructure load higher than humans ever did or could and taking some of our competitors to the brink as we've all seen. It's important to remember, competitors have a different mix of audiences. We're squarely focused on enterprise customers. And so there's different communities in our case, a different pace and much higher stakes with our customers. We do see real opportunity here.

Remember, though, for our customers, this workload is mission-critical. It's hard to migrate and it takes time, especially at enterprise scale. That's because the decision of GitLab as a platform is a core infrastructure decision. It requires the entire organization to align and make that decision. It's not as simple as someone downloading a tool onto their laptop. So I don't expect to see an overnight swing here, but here is what we're seeing.

In Q1, we saw a notable increase in enterprises looking to adopt GitLab as their platform, including new first orders as well as consolidation within our existing base. That did result in a small but meaningful improvement year-over-year against historical win rates. And as I shared in the prepared remarks, we also saw an inflection in first order count. We're now 30% year-over-year higher as a result of the combination of product-led and sales-led growth efforts that we've been investing in for the last few quarters. We are running targeted go-to-market campaigns to seize this opportunity, and we're seeing early results from that.

But I think what I'd point out for investors that's even more important is what I mentioned on the call. We're partnering with an AI lab on the design and development of the future of our Git infrastructure. Our design requirement for that project is 100x scale versus what humans need today because we anticipate that's going to be required for enterprise customers as we move from the early adoption phase of agentic engineering to full teams embracing agenda engineering practices. So that's a really new exciting opportunity for us. You'll see more about that next week at Transcend and encourage you to tune in.

Next question, Sanjit Singh from Morgan Stanley, followed by Radi Sultan from UBS. Sanjit, go ahead, please.

This is Oscar Savara for Sanjit. Maybe if I can touch a bit more on the guidance and maybe any changes on the philosophy. So you've spoken to expected benefits from the scaling sales capacity in the second half of the year. But also there's commentary around an uncooperative macro backdrop and just you accounted for that not improving going forward and maybe also some potential execution disruption. So maybe I wanted to get a sense, maybe a finer point on the increased conservatism maybe that is being embedded into the guidance versus what you're seeing out there play out today?

Yes. No, thanks for the question. A couple of things. Just kind of speaking to last quarter, we deliberately did give a wider range, which we cited many, many moving parts in the business. And just as we think about how the quarter played out, our so far assumptions have largely played out as expected. So we're now through the quarter where we'd be both on revenue and NGL. And again, a reminder, the business is largely ratable, and we have very, very strong visibility.

As we're thinking about additional prudence, right, there's -- as we talked about, we did have some impact from churn and contraction related to risk and we had some unique to the quarter related to M&A. And again, with a large -- even though we've been very, very intentional on the risk about protecting sales quota-carrying sales capacity and our engineering head count. We know at any large-scale risk. There is some risk of disruption. So we have embedded that into the guide as well.

So I'd say the 4 things, again, so 2 carries over from last quarter. We don't -- still while we saw some strong performance in pubs this quarter. We still don't expect an immediate bounce back. while we're very, very pleased with the results that we're seeing on DAP so far, we're not expecting material revenue there. And then the additional new pieces are the risks and the execution risk.

Next question, Radi Sultan from UBS, followed by Ethan Weeks from Piper.

Awesome. Bill, in your prepared remarks, you mentioned the opportunity to bring more nontechnical users to the platform. My question is, how do you imagine monetizing those users? Do you think the current SKUs properly reflect the needs of that cohort? Maybe if you could just walk through how you're thinking about shaping the product and monetization opportunity to capture that emerging cohort of nontechnical users?

Yes. It was a notable increase this quarter in our customers asking for and exploring additional seats for those nonengineering users. I think it's been asked a few times in recent quarters, are we seeing that possibility -- and while we've had a few conversations this quarter, there was more of a pattern forming, where we do see teams electing to ask project managers, designers, program managers and others to begin contributing code using a genic tools. And of course, they need GitLab seats in order to do that to contribute to the code repository and take advantage of the CI pipelines and everything else we give.

We currently are in several conversations along those lines, and we're putting forward the same seat-based pricing model that we provide for engineers, given the value and the requirements are the same. So we think our seat-based model is going to benefit from these conversations as well as our dual agent platform. approach because those users have the same requirements in terms of agentic engineering across the software life cycle.

The next question, Ethan Weeks from Piper Sandler, followed by Derrick Wood from TD Cowen.

This is Ethan going in for Rob tonight. Bill, I wanted to ask around kind of this rebuilding of GIT and a much larger scale that you're trying to build this at. And specifically the points you made around partnering with an AI lab on kind of this vision. And there's been some worries in the past around these AI labs looking to kind of do this in-house or become competitive with you. And so I was wondering if you could talk on why they decided to partner with you in building this rather than trying to compete with you.

I think there's probably multiple factors there. Number one, we are, I believe, the leading contributor to the open source good community today. And we also serve several of the AI labs with GitLab. And so both being a customer and a notable GitLab get open source contributor, probably help them make the choice to partner with us. I think in addition, we serve more than half of the Fortune 100 today. We're a serious DevSecOps vendor in this market, have hundreds of thousands of organizations that use get lab today, and they want to be able to deliver a great experience to their customers through GitLab. So it's been a great partnership. You'll see the demo in next week that will share the current progress on that and more details there.

Great. Next question, Derrick Wood from TD Cowen, followed by [ Matt Caletti ] from Needham.

This is Cole on for Derrick. Bill, could you just talk a little bit more about the kind of see compression that you're seeing and how you guys expect this to unfold? And then secondly, just on that same point, how do you think the new monetization can help offset that in the mall.

Actually, we've seen seats growing this quarter. Obviously, with the growth that we delivered, we did see seats growing. That's our primary monetization model today. I think Jessica mentioned a few churn and contraction and M&A activity that was unique to the quarter, which had we not seen the quarter would have been even stronger, but definitely seats are growing. And in terms of new monetization, our lab credits consumption program is also helping us start to take on new AI budgets, as I shared. It's also delivered our highest net ARR quarter, AI quarter ever.

As I mentioned, it outperformed in its first quarter, Duo Pro and Duo Enterprise combined over any previous quarter. And I think we've been in the Duo business 2 or 3 years. So an impressive start with the GitLab credits program and dual agent platform and seats continue to grow.

Yes. And I would just add, again, I think to that point, I were both there really changing the relationship between cost value and predictability, and we look at it all as additive and providing our customers with more optionality and flexibility.

Great. Next question, [ Matt Klite ] from Needham followed by Kingsley Crane from Canaccord Genuity.

Great. This is [ Matt Letier ] on for Mike Cikos over at Needham. Thank you for questions. Can you provide specifics on where you intend on reinvesting restructuring savings in order to drive the architectural strategy that Bill laid out? And how will you measure ROI on these changes?

Yes. No, great question. Thank you. So we're really looking at it in 3 places: people, technology and process. From a people lens, we are asking a lot of the people who are staying on the -- for Act 2. And we want to ensure that we're investing in them and retaining for them because they're going to be -- play a really significant role in this journey.

Second, on technology. We're really leaning into the architectural beds that Bill outlined in his script. And we're going to be reallocating and investing in R&D resources to accelerate our road map. Again, we're really excited to share more at Transcend next week. So definitely check that out. And then finally, from a process lens, we are reviewing our processes to take advantage of AI and go faster as an organization. And I think this is very much in line with our capital allocation strategy. We have high conviction that it's really the best patent to durable growth, operating leverage and long-term shareholder value.

And then I think on the second point, from an ROI lens, look, it's really too early to provide details, but we are -- like everything else, is going to be very intentional about how we invest with clear guardrail and the right trade-off. I think we're very clear eye on both the risks and opportunities, but I believe that the market opportunity here is too big to not capitalize on it now.

Next question, Kingsley Crane from Canaccord, followed by Howard Ma from Guggenheim.

Great. Look, Bill, there's a lot of noise out there, but I just want to start by commending you for the candor and the Act 2 letter, the open approach that you're taking and how you've led through what's a difficult but pivotal time and you've navigated transitions before. So I think we know how much it's about people interested not just technology.

So few angles on that. First, I just want to touch on talent. Can you talk about deep technical problem longer says this year just going to tie a resource. How do you feel about attrition over the past couple of weeks and just generally retaining a engineers? And then on disruption, I know the guide have had some sort of market disruption, but the letter talks about many -- customers are so -- can you just also get more confidence on that come?

Yes. Thanks, Kingsley. Definitely, these moments are difficult for any company to undertake. And maybe I should just pause for a second and express again my gratitude for all those that we separated with and our undergoing consultation with starting yesterday. We really appreciate the contributions from all of those who've been part of GitLab those who we separated with as well as those who chose to undertake the voluntary departure.

They came when GitLab needed them. They've delivered amazing things, and the foundation that they built is what we're going to continue to build on. We were very careful in terms of how we went about the restructuring. In fact, as you can probably tell from the leader -- from the letter, we started by clearly articulating the why, the way we see the market, the future of software engineering, the first principles around our investments going forward.

We then explained what the product strategy, business strategy as well to go after the opportunity. And then we talked about the how with team members. And some of the tough challenges that we're trying to solve in order to allow us to go faster as an organization and capture this opportunity.

And that includes some of the things that I shared in the letter like reducing our operational footprint as well as reducing management layers so that we can make faster decisions and flow communication faster. We're also forming smaller teams in R&D.

So all of that -- I share all of that context because it goes towards your question around retention. -- it's really important that team members understand the changes we're making and the opportunity ahead and are as excited about it as we are. which is another reason we actually issued the voluntary departure program because we understand this is a lot of change and maybe it's not for everyone, and we wanted to head off future attrition by giving those team members who came maybe in a different era with different expectations and opportunity to move on if they weren't excited about the new direction.

So we've executed that now. We were very careful in protecting our sales capacity to ensure that we can continue to deliver on the targets that we've set for this year. And as we shared, we're also investing in team members and in particular, in R&D, we actually expect to grow our ability in that in the coming quarters. And so to execute on those architectural bets. We're investing in our team members, and we'll continue to invest in R&D to make sure that we can deliver as quickly as possible.

And then just on your comment on customer exposure, it's very limited. We had no sales presence in the geographies that we've exited, and where customers exist we're managing transitions very deliberately with a very focused communications plan.

Great. Next question, Howard Ma from Guggenheim, followed by Nick Altman from BTIG.

I just wanted to clarify 2 items. I'll ask them together. The first is the $20 million of Duo Asian platform annualized consumption I just want to be sure, is that a clean number in that it doesn't include any Duo Pro or enterprise spending that converted into DAP commitments? And then my second question is the 30% new logo growth. Can you help reconcile that with the greater than 5,000 ARR customer net adds because I'm seeing it's about 149 but that was down maybe that reflects the onetime tech-related layoffs and M&A-related churn.

First, just on DAP, it is a clean number, but I do want to just be very, very clear that this is not something that anyone should be looking at in their models. It's a very early signal. One we're excited about, but at the same time, it's like 1 quarter's worth of data. And we're not basing our forecast on that, and I hope that you are not as well.

And then just on the customer count, again, we -- the bottom layers can get pretty noisy. I just would again point to -- you've got to look at it holistically. I think the big message is our enterprise business remains strong. Our 100,000 customer grew 18%. And I just, again, encouraged that the way we look at it is really more of a holistic line.

Next question, Nick Altman, BTIG, followed by Raimo Lenschow in Barclays. Nick, go ahead, please.

Awesome. And Jessica, can you just provide some color on the bookings because I believe you noted that the gross bookings were very strong, but it seems like there's maybe some noise in the deferred revenue in the total RPO growth on a sequential basis was a bit lower versus historical levels. So can you just parse out the gross booking strength that you guys alluded to versus the RPO and the billings growth.

I'll focus on the leading indicators. And again, I think the general comment here is the combination of billing, the RPO, RPO and aggregate, you can take those to look at the business. but they all have their own nuances. So at the end of the day, I think the best -- visibility we have is into revenue, which is where we guide.

But yes, first on guidelines, there's -- those were at 12% growth this quarter, which was coming off a really tough comp. We had growth in Q1 of FY '26. As I referenced, we had some larger seat contraction there than anticipated, which was mostly tied to layoffs in our customer base. And in addition, we had some M&A contraction that was really unique to the quarter. Without those dynamics, the quarter would have been even stronger, and we're very clear eyed on that.

In terms of the other leading metrics, I'd talk about RPO for a second. I think there's a few things to note here. Yes, we are seeing some more uncertainty in the market, which is driving some more customer hesitancy on longer-term contracts but we've also always tied ourselves on customer choice and meeting our customers where they are, which provides providing flexibility in contract terms is of the ways that we've done that. At the same time, we are really looking to incentivize the field to drive greater multiyear contracts, order makes sense.

But again, kind of getting back to the conversations around monetization, we think longer term, there's an opportunity to evolve how we monetize with our customers. as developer unit economics evolve, this is really why we are continuing to expand our portfolio with Flex and other monetization vectors, which are going to learn more about at Transcend. But then again, stepping back completely. It's always worth looking at the -- lens of our retention rate, which continues to be well above 90%, which really is, I think what speaks to the overall health of the business.

Great. Next question, Raimo Lenshow from Barclays, followed by Ryan Williams from Wells. Raimo, go ahead, please.

This is [ Amy Cann ] from Raimo. Can you help us understand how we should be thinking about the recent momentum in your self-managed business. We noticed that the self-managed subscription revenue was roughly flat quarter-over-quarter for the first time since -- was that tied to Core Pacific see contraction and M&A?

Yes, Mike, when we go to market with customers, we offer them the choice of self-managed, dedicated or multi-tenant cloud. And really, that's one of the strong value propositions of GitLab as you choose the cloud that you want to deploy and that's up to our customers then to make that decision. And I think we noted that the multi-tenant and dedicated cloud growth was higher this quarter, which then, of course, offsets the self-managed growth I think you're indicating there.

So we see those fluctuations from time to time. Customers are in control of where they want to deploy. And we're seeing strong signal on the cloud side, which has been a trend since the IPO. So nothing more to note there than the dynamics of what customers are choosing where customers are choosing to deploy.

Great. Next question, Ryan MacWilliams from Wells, followed by Lucky Scheiner from DA Davidson.

I love the shift to see pricing for humans and consumption pricing for agents. I think we'll see that more from other software vendors. Just on Duo agent platform, the credits are included with the premium and ultimate plans. And I know it's early days, but how common is it to have overages above the credits that are included. And do you think, as a result, users will shift to annual credit plans across their business? And then are there any use cases that customers are seeing more spent adoption of GitLab deal -- at this point?

Yes. What you're referring to there with included credits are promotional credits that we've given in this first quarter of availability that less individual developers and engineers experimenting to agent platform before the organization needs to commit. And we do see healthy usage of those in some of our customers that are early adopters. It's important to note that, as I've shared in prior quarters, a large amount of our revenue, 70% of our revenue is self-managed and it takes up to 2 quarters for them to upgrade to a build that includes new capabilities like Duo Agent platform.

So the early adoption we saw in Q1 is really largely from our SaaS customer base on GitLab.com. We're not sharing numbers in terms of the way of the patterns that we're seeing. It's just too early to share how many customers are going over those promotional credit amounts and where they're leveling out on usage, but we do see healthy early adoption, and we'll continue to drive that.

In terms of the use cases, you asked about we're seeing really healthy adoption across our top 5 use cases that include, for example, code reviews, which is something that basically every code change requires fixing fill pipelines. Also, we have an amazing feature around security vulnerability resolution where once a security vulnerability is found by our scanners, you can enable due agent platform to automatically create a merger request on that vulnerability so that the engineer just needs to step in and review the vulnerability and accept it.

And we also have do developer capabilities that allow engineers and nonengineering users to take requirements and define a set of tasks for the agent to do and the dual developer agent will take us all the way through creating an MR and ultimately for deployment. So top 5 use cases, we've had a lot of success with, and they have a proven ROI that we sell now with customers when we go to market.

[Operator Instructions]. Next question from Lucky Schreiner, DA Davidson. Go ahead, please.

I wanted to follow up on one of the earlier answers on deal duration and duration declining. Is that to clarify, is that purely macro driven? Or is some of that customer conservatism around the pricing changes you made and making sure with the consumption, they feel comfortable with the visibility they have or maybe just double click a little bit more on some of the deal duration changes.

Yes. I think what you're asking about is multiyear contracts, and Jessica shared kind of 3 dynamics there. The first is, especially in our category around software coding, there is a lot of uncertainty as the software engineering life cycle changes as new tools emerge as increasing spend shifts to AI and customers see all of those options and especially in budget in situations where budget is tight. They're choosing to make shorter agreements because the space is changing so fast. That uncertainty is well understood.

Second, we are very flexible with customers. If they are able to make a multiyear choice. Obviously, that's good with us, and we incentivize our field teams to go after those. But if they want to make a single year agreement, that can be driven by multiple factors on their side, then we're happy to do that as well.

And then finally, there is real opportunity here. The unit economics for developers are changing quite dramatically. If you think about looking backward, our ultimate seat price right now, retail price is $99 per user. But if you look at the numbers inclusive of AI tools, the amount of spend that companies are paying per engineer is changing dramatically. And so in many ways, I think customers see that as well. They're making decisions thoughtful decisions about what they're willing to spend this year and keeping a close eye on those trends to make sure that their multiyear agreements stay in check.

And that's also an opportunity for us. As I mentioned, we're going to be introducing Flex next week. And that's going to open up new ways for customers to come in across seats and credits that we're excited about. And we'll share more next week.

And with that, I'm seeing no further questions in queue, and that concludes the Q&A. We will be at the Bank of America Global Tech Conference this week and look forward to meeting many of you in person. Thank you for attending GitLab's first quarter and fiscal '27 earnings call. You may now disconnect.

Good morning. Day 4 of the Morgan Stanley TMT Conference. Keep the presentations going. We're super thrilled to have the management team from GitLab, CEO, Bill Staples; and new CFO, Jessica Ross. Bill, Jessica, thank you for joining us at the TMT conference.

Absolutely.

Thank you so much. Great to be here.

So before we get into the discussion for important disclosures, please see the research disclosure website at www.morganstanley.com/researchdisclosures.

So with that out of the way, I wanted to sort of level set the story and give us a sense of what the problem that GitLab solves for customers. Maybe we start with there and then I have a couple of follow-ups.

Yes. For those who are new to GitLab, GitLab is an intelligent orchestration platform for software engineering. That's our new positioning that we just launched about a month ago. But for the last decade, what we provided organizations is the ability to manage their entire software life cycle in one unified platform.

Historically, this space has been very fragmented. Developers have chosen lots of tools, a blend of both open source and commercial tools to do specific tasks to build software, everything from the tools they use to plan, the tools they use to code, the version control systems that they use, the build systems that they use, the testing systems, the deployment systems and so forth. There can be in any given enterprise, a dozen or more tools to accommodate those tasks.

What GitLab offers is one unified platform with an opinionated software engineering process that helps them take their code from planning all the way through deployments. And it's had proven ROI. Last year, we launched an independent survey that showed a 6-month payback period for our Ultimate product and 483% ROI in the first 3 years. So that is the foundation that we're building on. We just announced this last quarter, just a few days ago on the earnings, $1 billion in ARR. We delivered 26% revenue growth year-over-year...

[indiscernible]

You want to jump in...

Well, I could jump in there. Yes. No, we just delivered $955 million in revenue, which is 26% year-over- growth. We delivered $220 million in free cash flow, which is an 83% increase year-over-year and 7 points of margin expansion. Excited -- our customers are viewing us as more strategic to their core operations than ever before. Our $1 million customer cohort grew 26% year-over-year. Our $100,000 customer cohort grew 18% and Ultimate is now 56% of our ARR. And we also just announced our first ever share repurchase program.

That's fantastic. Bill I was wondering to also -- when we think about this part of software, the software delivery life cycle, I think there's a lot of confusion on like what goes in. You mentioned that there's a dozen plus different workflows. Coding is sort of one of them. Can you give us a sense of like in terms of getting from idea to coding versus the workflows that you automate?

Yes. As we've done multiple surveys on this, and there's other sources as well. The best estimates I've seen are between 10% to 20% of the time developers spend, they spend writing code. The other 80% to 90% is spent doing all of the other tasks around that code, and that's where GitLab is today. We've never provided coding tools specifically like an IDE or a code authoring environment. We provided all of the things surrounding the code and the process or flow by which that code gets pushed all the way through to production.

When you think of the -- you've been CEO for over a year now. Can you share the insights that you've learned in terms of the pace of change that's happening in this market and how you sort of think about GitLab evolving with that pace of change?

Yes. We've seen, obviously, this explosion in code authoring. What's interesting is I've spent about 30 years building software with engineering teams and often with vendors like Microsoft, where I spend a lot of time in their developer division building tools for developers. So I've studied this space for a long, long time. And I'll say a couple of things about what we're seeing today.

First thing I would say is it's definitely the most fast-paced innovative time that I've experienced in 30 years of building software. Every single day, every single week, there are new technologies, new tools, new innovation patterns emerging with the help of AI, which I think are really exciting. That's leading to this explosive growth in new techniques, new tools, new things to try.

But that pattern is actually age old. At least as long as I've been around, the code authoring space has always been very fragmented. There's always been different ideas and ways of doing that. Everything from very old open source tools. In fact, some of my developers in GitLab still use eMACS and Vi and Vim, which maybe some of you who've been around this space know that those were built 30-plus or 40 years ago, something like that in open source.

And everything from that all the way to the latest coding agents like Claude Code and everything in between. And so that fragmentation is a natural part of the developer community. And I think it will always be that way. That's part of just a developer preference in terms of having a tool that's fit for purpose for how they want to work.

What's really important about this, though, is one of the evolutions that's happening is more code is getting generated. That code is now creating more bottlenecks downstream. So the code reviews, the ability to secure that code to ensure it meets the engineering and organization's business standards, make sure it's compliant, make sure that the organization trusts the code, in particular, since it's not a human that's -- they're employing to build it, but rather an independent agent that's autonomous and potentially not trusted, they need to have auditability. They need to have governance. They need to have control over the code even more than they have in the past. And so what we see in GitLab is it's pretty interesting that all of our customers are adopting these various tools. And it's an and. This is not in any way impacting GitLab other than it's actually driving more engagement than ever.

Last couple of days ago, we shared, for example, our CI/CD pipelines are up 35% to 45% year-over-year. The number of secure projects the customers are creating inside GitLab Ultimate are up 60% year-over-year. So all of that code getting generated is actually driving more engagement in GitLab and more value delivery. Our business model today didn't anticipate this. It's a seat-based model. And so customers get unlimited platform access per seat. So we're happy that we can provide that additional value delivery to them.

What we're now doing to help accelerate the rest of the life cycle is bringing agentic AI across every task. Just like we've seen the success with the Claude Code and other tools for coding, code authoring. We just launched 7 weeks ago, what we call Duo Agent Platform that offers agentic AI across the software life cycle so that customers can intelligently orchestrate their entire software delivery.

Yes. The important point -- you're seeing more usage, higher velocity usage that you ever have before. Now the game is how we capture that value. And so I want to revisit that topic. But before, let's also revisit -- you just reported earnings this week. And so there's a couple of themes coming out of that.

Jessica, as you mentioned, bookings is really strong. Your momentum with the large customers in Q4 was particularly strong. The trend line and the multiyear trend line of bookings has been slowing down. Can you talk about some of the forces weighing on growth, particularly for your Premium customer base?

And then, Bill, could you speak to the sort of 5-point action plan that you are going to be putting in place or have already started to put in place to reinvigorate growth in the business?

Yes. As I shared in my FY '27 guide, there's a few components as we're thinking about growth acceleration going into FY '27. So majority of our revenue is ratable, which means that the revenue we're recognizing today is based on booking trends that happened 2, 3 years ago. And one of the things that we shared in our call is that bookings have not paced with revenue growth over the past 3 years. So there's an element as we're thinking about growth deceleration that is purely math and nothing that we can change operationally in there.

There's also some elements of some onetime. We had announced a couple -- or a couple of years, we implemented a pricing increase on our Premium product and have been benefiting from some of those tailwinds over the past couple of years. And so that's also flowing through to FY '27.

And I think going in last quarter, we did have strong bookings, but there was also some pressure that we saw coming out of the government shutdown in Q3. We only saw a partial recovery in Q4 as well, we've really identified this price-sensitive cohort that makes up about 20% of our ARR that especially with budget proliferation and a lot of context and choice, there's been some more budget pressure there that is -- that we are addressing through some very specific ways to increase value to that cohort.

Yes. So let's talk about the growth ahead. As Jessica mentioned, we've studied the business deeply to understand that bookings pattern. Why hasn't bookings kept pace scaled with revenue? And we've identified 5 specific areas that we believe we need to invest in to reaccelerate bookings, which then would have a corresponding impact on revenue in the coming years as the ratable revenue model kicks in.

The first area we started investing in last year, and it's first orders. If you look at GitLab, it's historically a very strong land and expand business. In fact, we shared a few quarters ago, our 2016 cohort that landed has expanded 100x, you can believe it, 100x and every cohort since continues to expand about the same rate. Many of those customers have landed historically at very low contract sizes, $5,000 and less, but then expand 100x. And so as we studied the first order patterns, we identified that first orders had also been decelerating over the last couple of years.

And the root causes of that are pretty clear. The sales force had always taken a more general field approach to both land and expand, meaning there was no specialization. The sellers were able to fulfill their quota any way they could. And as the business grew larger and as we moved upmarket, the easiest way to meet your quota is to do a large expansion.

So without that dedicated focus on first order as well as the shift upmarket, some of the product-led growth initiatives as well, we have a very large and vibrant open source community also didn't get the care and attention that we think they deserve. And so our first focus here is on reaccelerating first orders. The good news is in FY '26, we already stabilized first order growth, so it had been decelerating for multiple years. But on the sales-led side, in Q2, the first orders had stabilized.

We also then in Q3 and Q4, announced that we're putting a dedicated first order team in place in the sales organization for the first time with compensation that's aligned specifically to landing new logos. And now we have a global leader in place reporting to the CRO. We've got 4 regional leaders in place, and we're rapidly hiring and onboarding sellers there. So for FY '27, we see a path to sustained reacceleration on first orders.

In Q3, we also brought in a new product and marketing leader, who has the entire funnel from top of funnel all the way through product conversion inside the product for monetization. And they also have put in place a set of improvements in that funnel that have led to stabilization and the beginning of reinflection on product-led growth, new logos. So that's super important because every time we bring a new customer in, it expands the cohort of those who we believe will grow with us for years to come. That's number one.

Number two is, as we looked at bookings growth, we also saw a really interesting correlation between our investment in sales capacity and the bookings growth itself. They're very highly correlated over multiple years. And we believe that, that represents a supply constraint to the increasing demand for GitLab. We see, again, increasing demand in terms of first orders. We see an expanding TAM with AI, and we want to have the capacity to go after that with full focus.

So we began expanding the sales and marketing envelope and hiring in FY '26. We enter now FY '27 with the highest capacity we've ever had, and we see line of sight to a Q3 step function increase in terms of productive capacity. So we're excited about that as a growth lever.

Number three, as we studied bookings, we realized one of the things that's been trending as well is customer feedback around the pricing and packaging. Customers are saying they want to do more with us, but we have really 2 core screen products, Premium and Ultimate. Premium at $29 per user, Ultimate at $99 per user. So it's a 3x jump for a lot of capability, and they have been requesting for some time more granular ways to opt into value.

And we believe the right way to do that is to start introducing new monetizable SKUs this year as additional value points and additional monetization levers. So we've announced artifacts management as one very commonly requested capability that customers today have to go to outside vendors to fulfill. We have their source code. We build their binaries. We don't store them today.

And they're saying, "Why don't you just store those inside GitLab? Give me the versioning and the signing right inside GitLab. I will pay more for that Als." So we're going to deliver that this year. And they're excited because we're going to meet them where they are along with the rest of the platform. They're going to be able to run that on-premise in their own environment, in air-gapped environments as well as in the cloud. The choice is theirs.

Another one that we're delivering is secrets management. This is really important because every bit of software has embedded tokens in it that connect to various systems. And to do that securely is super important for the safety of the business. And we have not provided a solution there. We've referred them to external parties. Now we're going to have a paid solution directly within GitLab. We see multiple other opportunities. I won't go into all of them, in addition to Duo agent platform that we just launched for additional monetization in FY '27.

The fourth one is around the price-sensitive cohort that Jessica just described a little bit. There is a cohort of customers that we raised prices on about 3 years ago by 50%. They went from $19 to $29. And we did that at a time unknowingly when the AI coding tool boom happened. And that as well as other AI tools that those companies are wanting to spend money on puts pressure on their ability to expand with us or to upgrade to Ultimate. And so we're asking for more price. We're not necessarily delivering more value in the last several years.

To address that, we're doing multiple things. First, we're including credits to our new agentic platform for every Premium user. They now get $12 of included credits to explore and hopefully fall in love with Duo Agent Platform before they have to make any kind of commitment or pay for any additional value. We think that's a significant investment in their value.

Second thing we're doing is we're adjusting coverage ratios to give them more connection to GitLab. Historically, we've been pushing more and more up enterprise, and we're going to continue to invest there, but adjusting a little bit more to give them additional connection points. We've had some reps with hundreds of customers. We're going to bring that down so that they have someone that they can contact as well as additional technical services to get adoption and value realization better. That should also stimulate growth in that price-sensitive cohort.

And then finally, we're making the add-on packages also available to them. So rather than have to step up 3x to get to Ultimate, they can buy the artifact management. They can buy additional capabilities at incremental price.

The fifth and final one is Duo Agent Platform. Historically, we launched a few years ago our Duo product line, and we focused on specific AI use cases that we thought would be interesting to our customers. And what we realized last year is that agentic was the future of AI, and we needed to build a platform approach that could unlock thousands of use cases and that customers can adopt and use for any task across the life cycle.

So rather than build those as turnkey use cases one at a time, we embedded AI directly into our platform, and we've now launched that 6, 7 weeks ago, and customers now have access to multiple things that really can accelerate their entire software life cycle. So for example, we provide out-of-the-box agents as well as deeply integrated Claude Code and Codex agents right inside of GitLab. They can apply those agents to any phase of the software life cycle to planning, to CI, pipeline creation to troubleshooting those pipelines, to analyzing security vulnerabilities and everything else.

And then finally, we also provide a stitched context for all of the life cycle data that's inside GitLab. So not just your code, but all of the capabilities that you interact with and use within GitLab are being stitched together as a service that can, in our testing, accelerate agentic outcomes at higher quality and at lower cost. Really excited to bring that to market and excited to see the adoption ahead.

Awesome. So one follow-up question. So on the kind of new add-on module capability, are both Premium customers and Ultimate customers, are they going to be able to buy the artifact management capabilities? Just in terms of how you're sort of pricing that or making that...

Absolutely, yes. They get the incremental value for incremental cost without the big steps required.

Excellent. So Jessica, Bill just laid out a strategy to reinvigorate growth. It's going to require some investment. In the context of your margin guide, it did come down about 400 basis points versus what you delivered in fiscal year '26. Can you speak to the factors driving the margin guidance? And how will you know and when will you know that the investments you're making will generate the return you're looking for?

Thank you. It's a great question. And I would just step back again and frame this as a year that we are viewing as investment and execution for long-term growth. So as you think about that step down in margin starting from the top of the P&L, I look at gross margin, there's about 300 bps of margin evolution that's happening there. Some of that -- and there's really 2 factors.

The first, when we IPO-ed, we disclosed that with the shift and growth of our SaaS business, we would expect margins to evolve closer to 85%. So in 2023, SaaS was about 22% of our business. It's now 32% of our business. So some of that is intentional with growing that business as intended.

The second part, as Bill just shared, is we launched DAP, which is our AI product. That comes with a higher cost structure. And so this is a year, again, of investing as we are turning pilots into production and growing that business. So that accounts for the rest of that gross margin.

And then kind of going down to the P&L, I also shared with our earnings a very clear capital allocation strategy. Our #1 priority is organic growth, R&D, sales and marketing and then G&A. And so with the priorities that Bill laid out, there's an investment cost in there. But I also want to be clear, like one of the reasons that I joined this business is because it's been very disciplined in how it's grown over the past -- since inception. We've delivered 1,700 bps of margin expansion over the past 2 years. So with these investments, we're monitoring them very closely internally. There's an expected ROI, but that muscle of margin discipline is not going away.

I want to come back, Bill, to the question around capturing value. And wherever we land on what's going to happen to developer seat counts, I actually think it's going to be -- we're going to see more developers. But wherever we land on that debate, I think there's no debate that there's just a ton of software being developed and created.

And so we think about these dynamics through the lens of a pricing model, market seems to be shifting towards a hybrid pricing model combining both seats and usage. And with Duo Agent Platform being the clearest example of that for GitLab. So can you share the aspects of the pricing model, specifically with respect to the Duo Agent Platform? And how are you striking the balance between facilitating adoption and usage and then Ultimate monetization?

Yes. So with Duo Agent Platform, we now have that hybrid model. It's seats plus credits, usage on credits. And the way it works is for every Premium and Ultimate user, we've decided to make a promotional credit available for every user. They get $12 in credits as a Premium user, they get $24 in credits as an Ultimate user. We've done that because we want to remove all friction from adoption. They don't need anything other than a version of GitLab that supports Duo Agent Platform, and they need to unlock Duo.

From there, they can start using the agents and getting value. And once they've reached the limit on the included credits, they can make a choice. By default, they can opt into on-demand credits where they pay effectively $1 per credit, and they can use those as many as they want at any time, and we bill them monthly on demand for those credits.

If they want an additional discount, this is where our salespeople can come in, and we'll take that as a product qualified lead. They can come in and say, "Hey, I see you're spending this much on on-demand credits. I can give you a discount. And if they're willing to commit to a monthly minimum number of credits, then they earn a discount on credits themselves.

The other really important thing here to realize is we believe our pricing model is more transparent and fair versus other AI alternatives at the moment in that when you make a monthly commitment, you're making it on a shared pool of credits that the entire organization can depend on. So rather than having a per seat upfront price and then charging overages on top of that, you're buying a shared pool and you can spread the distribution of usage across the entire organization.

That's definitely a unique angle to pricing. When -- a lot of the investor conversations that I have when it comes to GitLab and broadly this part of software kind of relates to competition and competition from AI start-ups as well as some of the research labs. And so I'd want to get your perspective on are the start-ups focusing more on the code generation, agent code development? Or do they expand beyond code assistance as the broader software development workflows that you guys play in? And so could you speak to the defensibility of GitLab on the potential for the -- for some of the AI natives and the research labs to move into -- expand beyond code development into more of the CI/CD workflows and the other areas that GitLab is involved in.

Yes. I get this question a lot, and I think there's -- it's easy to confuse if you're not deep in the technology, what the AI start-ups and AI natives are doing versus what GitLab does and how they relate. So the best analogy that I've heard and that I share often is to think about it like our bodies. And you should think about agents and AI as like our nervous system, right? It starts with our brain and it goes down through our body and it innervates all of our bodies. That's what our nervous system does.

And you could think about artificial intelligence as exactly that, an artificial brain that does reasoning and can drive action. But a brain without a body, without muscles is nothing, right? Like you can't do anything. So what these coding agents do is they can take source code out of GitLab and they can work on it locally, but then they have to push it back to GitLab to do the rest of the software life cycle.

And that's why we're seeing, as I shared, increased engagement in CI/CD pipelines and security projects and everything else. So you should think of GitLab, if we're carrying on with that analogy, the GitLab DevSecOps capabilities as the motor system in the body. In order to have a full platform that's capable of functioning and building software and deploying it, you have to have both a nervous system and a motor system. And that's what Duo Agent Platform does for GitLab.

We now have both the nervous system with agents, including Claude Code and Codex embedded directly within GitLab. And we also have the motor system that we've been building up for more than a decade. And that platform, that infrastructure is incredibly complex and sophisticated. It's tens of millions of lines of code. It's been built up for more than a decade. It's operated largely as a duopoly despite multiple attempts by large cloud providers to try and provide alternative services here. And I think that speaks to both the technical, the data and the business moat that GitLab has for that motor system.

Yes. Great context. I'd love to hear about how the AI code development boom is -- what impact that's having on your own product engineering organization in terms of their productivity and how it impacts your hiring plans? How is that impacting GitLab internally in terms of your own engineering efforts?

Yes, like every engineering team, our team sees those tools, experiments with those tools and uses Duo internally as we've been building it out to do their own work. In fact, we've been building the platform and then using it internally, which is always a little bit fun because you're not getting a finished product, you're getting a new product effectively every day that gets a little bit better and sometimes has bugs. But we've been seeing an increase over time as the platform has gotten better from our own engineers' productivity.

In fact, those engineers who heavily use -- moderate to heavily use Duo internally, we see up to 4x more MRs per developer than those who don't engage heavily. So think about that kind of acceleration in terms of innovation velocity, that's pretty exciting.

We're also now using what I said earlier about the full value proposition. We're using it across the software life cycle. So whenever epics or issues, those are kind of the documentation around the code are created. Most of the time, I'm seeing those created agentically now.

When pipelines fail, that's when the code is actually being built and tested, I've got so many stories, anecdotes of our own engineering team saying, "Oh, my goodness, like I had a pipeline fail and it took like 2 hours. I sat there and tried to debug it for like 2 hours. And I even brought Claude in and tried to fix the pipeline and I couldn't get it resolved. And then I remember Duo has this new workflow that can fix pipelines. I tried it. And 2 minutes later, it was fixed."

And like stories like that just warm my heart because I think that's what we're -- that's the value that I'm looking forward to customers seeing and realizing because we fundamentally have a structural advantage versus external agents. External agents, again, can sync the source code and work on that locally, but GitLab agents are where the work happens. It's right next to the source code in the same compute and data layer that GitLab runs in. And they have access not just to the few files that you want to make code changes, they have access to, if you want, the entire repository to all of your projects, to all of the issues related to this code, to all the security scans that's been done on this code to past failures. And that additional context can drive higher quality outcomes at lower cost.

Yes. That's definitely a strong foundation to build on. As you wrap up, let's talk a little bit about, Bill laid out the growth strategy. When we think about the capital allocation side of the question, the company has north of $1 billion in cash. How should investors think about your prioritization, Jessica, between organic investment, share repurchases, M&A? And maybe speak to how -- what's your latest thoughts on stock-based compensation and where that trend?

Yes. No. So again, I just shared, we just announced our first ever share repurchase program, $400 million. And in terms of capital allocation, we really have 3 priorities. So first is organic growth, and I laid out that's R&D. It's R&D first. So how do we advance the product road map and innovation, sales and marketing and then G&A.

The second is balance sheet resilience. And I really think in an environment like today, you want to have resilience and optionality. We do have about $1.3 billion of cash and short-term investments on our balance sheet. And then finally, share repurchases and returning cash to shareholders, which I do think it's a great lever to both manage dilution, and that's something that we are watching, but also return cash and value to shareholders, especially in times of share price dislocation.

So again, I think the theme for us is we're in a great position. We do have a lot of optionality, but organic growth first, and then we've got flexibility to manage capital in a very effective and strategic way.

Well, thank you, Bill. Thank you, Jessica, for giving us an update on the GitLab story. Fiscal year '27 looks to be exciting. And hopefully, we see better growth ahead. Thank you so much.

Thank you.

Thank you so much.

Good day, everyone, and welcome to today's GitLab Fourth Quarter Fiscal Year 2026 Conference Call. [Operator Instructions] Please note, this call is being recorded. It is now my pleasure to turn the conference over to Yaoxian Chew.

Good afternoon. We appreciate you joining us on GitLabs Fourth Quarter and Fiscal Year 2026 Financial Results Conference Call. With me are Bill Staples, our CEO; and Jessica Ross, our CFO.

During this afternoon's call, we will provide an overview of the business, commentary on our fourth quarter and full year results and guidance for the first quarter and fiscal year 2027. Before we begin, I'll cover the safe harbor statement. I would like to direct you to the cautionary statement regarding forward-looking statements on Page 2 of our presentation and in our earnings release issued earlier today, both of which are available under the Investor Relations section of our website. The presentation and earnings release include a discussion of certain risks, uncertainties, assumptions and other factors that could cause our results to differ from those expressed in any forward-looking statements within the meaning of the Private Securities Litigation Reform Act.

As is customary, the content of today's call and presentation will be governed by this language. In addition, during today's call, we will be discussing certain non-GAAP financial measures. These non-GAAP financial measures exclude certain unusual or nonrecurring items that management believes impact the comparability of the periods referenced. Please refer to our earnings release and presentation materials for additional information regarding these non-GAAP financial measures and the reconciliations to the most directly comparable GAAP measure.

I will now turn the call over to Bill. Bill?

Thank you, Yao, and good afternoon, everyone. Fiscal 2026 was a significant year for GitLab ARR surpassed $1 billion. We generated $220 million in free cash flow, an increase of over 80% and nearly 7 percentage points of margin expansion year-over-year. FY '26 and Q4 delivered our highest absolute net new ARR year and quarter ever, and we intend to build on that momentum. I'm really proud of the work the team is driving.

Given our deep technological and structural advantages and the growing TAM ahead, we believe we can do even better. I believe we have the right team in place to execute the opportunity, and the rest of my remarks will lay out our plan. Jessica will then walk through the financials. Let me address our FY '27 outlook directly. We aren't satisfied with our revenue growth guidance.

Like many companies reaching $1 billion in revenue, our focus has been shifting to scaling our growth. We've identified 5 specific strategies where we see the greatest opportunity to improve our growth at scale in FY '27. The 5 are: Number one, reaccelerating first orders to fuel long-term expansion; number two, scaling sales capacity with dedicated leadership and investments; number three, expanding product packaging to unlock new monetization vectors; number four, engaging price-sensitive customers with greater value and coverage; and number five, continuing to execute an AI strategy aligned with our core platform strengths.

We've already begun acting on all 5. FY '27 is all about execution and proving our hypothesis with results. Let me walk through each one. In FY '26, we reversed a long period of first order deceleration. This is critically important because our customers often land small and extend steadily, a pattern that's held for over a decade. Sales led first orders began reaccelerating in Q2 FY '26 right after [indiscernible] joined.

On the product side, Manav has reinvigorated product-led growth. First order logos inflected in October, and we've seen 4 consecutive months of improvement. For FY '27, we now see a clear path to sustained acceleration in first orders, driven by continued sign-up momentum, new product like on-ramps and a dedicated first order sales team with a new global leader for regional leads in place and rapid hiring underway.

In fact, the team has already closed their first deals in Q1. As a proof point, this quarter, we secured a landmark deal with one of the semiconductor industry's most strategic players, a cornerstone supplier in the AI super cycle. After a competitive evaluation against incumbent tooling and AI-powered alternatives, they chose GitLab premium and dual enterprise for over 5,000 users, validating our unified platform and AI capabilities.

With regard to sales capacity, we began increasing headcount in FY '26, and we're entering FY '27 with more capacity than we've ever had. And we have a path to even stronger ramped capacity beginning in Q3. With FY '27 kickoff, we've overhauled territory design to also better serve all segments and strength and enablement. When it comes to innovation, GitLab has a long history of delivering ongoing value with 172 consecutive months of new releases.

Customers who consolidated repos and CI on GitLab consistently want to do more with us [indiscernible] pricing is 2 core screen. In FY '27, we plan multiple new monetization opportunities each quarter built in artifact management, software supply chain security, integrated secrets management and more. These will be opt-in a la carte offerings that provide intermediate options for both premium and ultimate customers.

We've been asking for ways to opt into more value at incremental price. Most of these are anticipated throughout the year. So we expect modest FY '27 contribution, but meaningful impact for FY '28 and beyond. Our 50% premium price increase a few years ago also coincided with rising AI code experimentation and flattish SaaS budgets. Simultaneously, our upmarket shift, reduced technical resources at the lower end of the market.

Together, these have slowed premium growth, particularly among price-sensitive customers, which we estimate at roughly 20% of our ARR, including the SMB weakness, that we've been discussing recently. We're responding here on multiple fronts. We now have an AI product and platform in market since mid-January that helps accelerate the full software life cycle. And we're including compelling GitLab GAAP promotional credits with premium and ultimate users to increase the value they see.

We have adjusted coverage models as well for this cohort and we're investing in onboarding, adoption and self-service experiences that will help all customers get value faster. GitLab sits at the heart of how enterprises build and deliver software. In January, we launched GitLab Duo agent platform and repositioned GitLab for the AI era. Our Intelligent Orchestration platform lets users deploy AI agents across the software life cycle using the same context, permissions and security model that they already have in place today.

This platform rests on 3 core pillars: Workflows, a unified place where teams and AI agents collaborate on tasks across the software life cycle. Context, rich semantic access to full SDLC data for high quality and more efficient outcomes, guardrails. With GitLab, you can deploy anywhere and have security and compliance embedded directly in your software factory.

GitLab is positioned where AI systems are best leveraged the point of execution. We bring together the missing context and take action where the code lives where it's merged, built, deployed, where compliance is enforced and where corrective actions prevent downstream bugs technical debt and security issues. Before AI, our platform reduced friction for developers. Now it can unlock step function productivity gains by reducing friction for agents and the humans managing them.

Duo agent platform also introduces usage-based pricing alongside our seed model. Customers pay for agent work, where every engineer can delegate tasks to multiple agents in parallel. As agents automate more across the software life cycle, revenue grows with the value we deliver. Take one of our airline customers with a 3,000-person technology organization, [indiscernible] platform to automate vulnerability remediation, dependency updates and cloud migrations, roughly 90% of their component updates now run autonomously, frame developers for customer-facing feature work.

We have an ambitious road map and plan to deliver new value every single month. with focused go-to-market to accelerate adoption. As a reminder, nearly 70% of revenue comes from self-managed customers who require an upgrade to release 18.8 or better and we typically see it taking 2 quarters for over 50% to adopt the new release. We're investing alongside our partners to accelerate upgrades wherever possible. FY '27, is about converting pilots to production, not significant revenue contribution.

We'll share metrics as they become material. The software development market is undergoing a fundamental shift AI is accelerating, it's increasing code volume, delivery complexity and the stakes of getting it wrong are just higher than ever. Security, compliance and governance aren't optional they're existential. This is the environment GitLab was built for.

The changes I've described, rebuilding our go-to-market capacity, creating new monetization vectors and positioning GitLab at the center of Agent AI, these aren't separate initiatives, they're one integrated plan to capture a market that's moving in our direction. And our data confirms this. In Q4, we added the most $1 million customers in GitLabs history.

Gross retention is consistent with historical trends and churn is at the lowest it's been in 4 years. Ultimate is now 56% of ARR and accounted for 9 of the top 10 deals. We've seen more than 60% year-over-year growth in ultimate projects with security scanning and nearly 30% more security projects per seat. Indeed, operates the world's #1 job site. They started with GitLab in 2015 for source control expanded the Premium in 2020 to support CI/CD adoption and upgraded to Ultimate in 2024 for advanced security, compliance and governance capabilities across thousands of GitLab users and saw an 80% increase in pipelines with lower infrastructure costs.

This quarter, they're deepening their strategic partnership with a move to GitLab dedicated as part of their infrastructure modernization journey. Mercedes-Benz expansion this quarter also illustrates our compounding growth potential. Today's vehicles contain more software code than fighter jets, driving companies like Mercedes to hire thousands of engineers. Our relationship began years ago with Source Code management.

Today, GitLab serves as a central platform, powering their software-defined vehicle transformation, supporting thousands of developers across regions. Now investor uncertainty is understandably high. When every developer has access to the same models, cogeneration becomes a commodity. The bottleneck shifts to everything after the code. Reviews, security, pipelines, compliance, deployment, acts precisely where we live, and that position gets harder to replicate as AI [indiscernible].

Some of our customers already carry decades of technical debt, thousands of repositories and compliance obligations tied to policies written years ago. GitLab holds all of that context, history, ownership, risk intent, it's all getting indexed and connected across the software life cycle. In the world of autonomous agents, context is the difference between useful action and a potentially catastrophic one. every commit, every scan, every deployment makes our graph richer and our agents more accurate. The longer a customer runs on GitLab, the smarter the platform gets. That is a moat that widens over time.

And with GitLab Duo agent platform, we're not just a tool that agents use where the environment where they run, the orchestration layer that governs what they do in what order and within which guardrails. We have the ingredients for a generational company, a growing market, trusted distribute at scale, deep customer relationships, and platform capabilities that have been built up over years. We operate from a strong financial position with approximately $1.3 billion in cash and investments and are sustainably generating free cash flow.

I'm pleased to share that our Board has authorized GitLab's first share repurchase program at $400 million, reflecting confidence in our fundamentals and the growth plan ahead. We believe GitLab shares represent attractive value and remain committed to disciplined capital allocation. FY '27 is about demonstrating that this foundation can deliver value to customers, momentum through consistent performance and progress quarter-by-quarter. With that, I'd now like to turn it over to Jessica to walk through the financial results.

Thank you, Bill, and thank you to everyone for joining us today. This is my first earnings call as GitLab's CFO, and I'm excited to be here. I joined GitLab because I see an incredible business at the center of unprecedented industry transformation. The opportunity to help shape how AI transforms software development through intelligent orchestration is compelling.

In my first few weeks, I've been impressed by the passionate customers and team members the platform's technical depth and the leadership team, Bill has assembled. My focus is on building the financial discipline and operational rigor to support our next chapter of growth. I look forward to getting to know many of you in the coming weeks. I'll start with our full year and fourth quarter results and cover our capital allocation framework and FY '27 guidance.

Fiscal 2026 was a strong year. Revenue grew 26% to $955 million. Non-GAAP operating margin reached 17% and up approximately 680 basis points year-over-year. Adjusted free cash flow grew 83% to $220 million with over 7 points of margin expansion. We now have 10,682 customers with ARR of at least 5,000, contributing over 95% of total ARR.

Our $100,000-plus cohort grew 18% year-over-year to 1,456 customers, representing just over 75% of ARR. And as Bill mentioned, we added the largest number of $1 million plus customers in GitLabs history in Q4, now more than 155, up 26% year-over-year. Now let me move to our fourth quarter results. Q4 revenue was $260 million, up 23% year-over-year, 3.5 points above guidance. Non-GAAP operating margin reached 20.5%, 5 points above guidance. The revenue beat was in part due to approximately $3 million of onetime items related to favorable foreign exchange and [indiscernible] performance.

First order bookings were healthy with particular strength in Asia Pacific. Enterprise win rates improved quarter-over-quarter and sales cycles remained consistent. We did see softer performance in the U.S. More broadly, we experienced a few large deals slipping from customers facing budget constraints and industry challenges. We also saw only a partial recovery in the public sector following the government reopening and continued weakness in the price-sensitive cohort Bill alluded to earlier.

Dollar-based net retention was 118%. Gross retention remains well above 90% and consistent with historical trends. Our largest customers continue to expand though we're seeing pressure in the mid-market and SMB segments that weighed on net retention. Total RPO grew 20% year-over-year to $1.1 billion. Current RPO grew 24% to $719.4 million. Non-GAAP gross margin was 89%, and SaaS now represents approximately 32% of total revenue and grew 38% year-over-year, driven by continued strength in GitLab Dedicated and do well. Q4 non-GAAP operating income was $53.4 million, with operating margin of 20.5%, up approximately 280 basis points year-over-year.

Q4 adjusted free cash flow was $41.8 million at a 16% margin. We ended the quarter with $1.3 billion in cash and investments. On JiHu, Q4 non-GAAP expenses were $3.9 million compared to $3.2 million in the prior year. Our domains to deconsolidate JiHu, though we cannot predict the likelihood or timing of when that may occur. Before turning to guidance, let me briefly cover our capital allocation framework.

First, investing in growth. Capital goes first to high-return investments that accelerate our product road map and strengthen our go-to-market motion. Scaling sales capacity, building our first order team, accelerating Duo agent platform and deepening security innovation. We're reallocating resources towards the highest return initiatives while balancing growth with profitability and cash generation. Second, balance sheet resilience. We're maintaining a strong liquidity position. With sustainable free cash flow and approximately $1.3 billion in cash, cash equivalents and short-term investments, we have the flexibility to invest in ourselves and inorganic growth through cycles without constraint.

Third, share repurchases. Our Board has authorized GitLabs first $400 million share repurchase program, reflecting confidence in our fundamentals and a disciplined approach to capital allocation. We look at repurchases as a meaningful way to drive shareholder value and manage dilution, particularly around periods of share price dislocation. Now moving to our FY '27 guidance. Guidance represents our clearest view of the business, given the current operating environment.

Let me frame the key assumptions before getting into the numbers. First, ratable model dynamics. In a ratable model, revenue reflects the cumulative effect of bookings activity over multiple prior periods. As Bill shared previously, we aren't satisfied with sustaining historical growth rates and are executing all 5 growth opportunities he identified. However, a significant portion of our FY '27 guide acknowledges that the bookings growth rate has not scaled with revenue over the past 3 years. and that reality flows through mathematically.

Second, nonrecurring FY '26 tailwinds. FY '26 benefited from several items we are not embedding in guidance for FY '27. We in aggregate, approximately 300 basis points of growth. In order of magnitude, these include the premium price increase from 3 years ago, positive FX dynamics, and specific clauses in certain customer contracts. Third, segment caution. We expect better public sector performance in FY '27, but are not assuming a bounce back. We expect the price-sensitive cohort of approximately 20% of ARR to remain under pressure given the trends we observed in Q4.

And finally, prudent assumptions on newer growth drivers. We're assuming minimal revenue contribution from GitLab dual agent platform in FY '27. We launched 7 weeks ago and need time to convert pilots to production deployments. Additionally, approximately 70% of our revenue comes from self-managed customers, which dictates a measured adoption curve.

With that context, for Q1 FY '27, we expect total revenue of $253 million to $255 million, representing approximately 18% to 19% year-over-year growth. We expect non-GAAP operating income of $32 million to $34 million. We expect non-GAAP net income per share of $0.20 to $0.21, assuming $173 million weighted average diluted shares outstanding.

[Audio Gap]

and GitLab dual agent platform, which carry different cost structures. For FY '27 modeling purposes, we forecast approximately $5 million of expenses related to JiHu compared with $13 million last year. We are operating from a position of strength. Our TAM continues to grow. Customer retention remains best-in-class our largest customers continue to expand and first orders have returned to growth. We are building new multiyear growth drivers with GitLab Duo agent platform and hybrid pricing.

Our FY '27 guidance reflects where we are today, early in a transformation with clear priorities: scaling sales capacity, stabilizing net retention, addressing the price-sensitive cohort and converting depth pilots to production. As we make progress, we'll update you. Thank you for joining us. I'll now turn the call over to Yao to moderate Q&A.

[Operator Instructions] Our first question comes from Koji Ikeda, Bank of America, followed by Matt Hedberg from RBC.

Jessica, great to meet you on the call. So I had a question on security. And security is a big driver of ultimate upsells and presumably agenetic Duo Security usage in the future. And so with [indiscernible] security making a lot of noise and with the chance that other foundational model vendors potentially releasing their own code security products, how should we be thinking about the differentiation GitLabs brings with its security portfolio and why it should continue to drive ultimate upsells and a genic usage in the future?

Thanks, Koji. I've been getting that question a lot. And it really comes down to the difference between suggestions and certification. Cloud code security helps developers write better code at offering time and that's really valuable. But the tool that suggests SecureCode and authoring time can't be the same tool that certifies it's ready for production. And that's where GitLab comes in. GitLab is that independent system that answers a different question. It answers the question, is this project? Is this source code ready to ship? A developer can ignore cloud's recommendations during authoring time. In fact, Anthropic's own page says developers always make the call. But with GitLab, they can't bypass the execution policy for the pipeline they can't ignore the merge request approval rules. Companies ship what is secure and meets their engineering standards and GitLab is the platform they rely to uphold those standards. So really, these are complementary. Cloud improves source code at authoring time and GitLab governs whether the software is allowed to ship.

Next question, Matt Hedberg from RBC followed by Rob Owens from Piper Sandler.

Bill, you started the call indicating you're not happy with current growth targets for the year. But I certainly do appreciate the 5 initiatives you outlined it seems like you guys have a lot to -- that could benefit growth. Kind of thinking about some of the considerations that Jessica outlined around fiscal '27 guidance. I guess the question is, how should we think about timing of acceleration? And you were kind of that path back to 20% or better growth. I'm sure you're aspiring to.

Yes, fair question. As I think about those 5 growth initiatives, and I think about what has the biggest immediate impact on FY '27. It really starts with the investment we're making in go-to-market. That increased capacity to both cover our existing customers better and win new logos at an accelerated rate. As I mentioned, we're entering the fiscal year with the highest capacity ever, and we expect a step function increase in ramp capacity starting around Q3. So that's how I think about GitLab for FY '27, but really stepping back and thinking about long-term growth. Let's remind ourselves, we just delivered the highest new net ARR year and quarter ever. The core business is really healthy. Gross retention is at its best in the last 4 years. Every customer cohort since inception continues to expand. Win rates are stable. Engagement is growing. This is a business that's been decelerating based on bookings patterns and lapping mechanics over the last 3 years. It's not losing relevance. In fact, its relevance is only gaining momentum in the AI era. To address the value capture equation, that's why we're pursuing multiple new strategies in addition to the increased capacity to go after the TAM, we're also introducing those new SKUs to provide additional adjacent value for customers to opt into. It's why we've also now launched dual agent platform with a new hybrid pricing model that allows customers to get value and automate full life cycle tasks and we get to charge based on work and value delivered, not just based on the seats. It's also why we're adjusting our coverage models and investing in included DAP credits for customers in that price-sensitive cohort to increase their value equation as well and their stickiness and growth. So long term, I believe this company has everything that needs to be a high-growth generational company and it's ours to execute starting here in FY '27.

Next question, Rob Owens from Piper Sandler, followed by Sanjit Singh from Morgan Stanley.

Bill, I wanted to build on one of your comments there around gross retention being at its highest levels. But yet your net retention comes down. And I know that you had mentioned some weakness in the mid-market. Maybe on the front of the question, you can unpack that NRR number for us a little bit what's driven that overall? Obviously, there's some concern about seats out there and potential seat expansion at customers. So Help us understand that dynamic. And I guess, number two, as we look forward and you're guiding to a total revenue less than where your retention rate is now, your expansion rate, I should say. Maybe some guardrails around where NRR could go over the coming year.

Yes, I'll take the first part and then maybe, Jessica can talk a little bit about where to think about in FY '27. So Yes. dollar-based net retention is not something that we guide to or focus on. We think of it as an output of the business. And as we look at the mix of deepening our across segments. We see enterprises really healthy. Our 100,000 cohort, as I shared, grew by 18% year-over-year, and it represents 75% of our ARR. The $1 million cohort grew even faster at 26% year-over-year. So our largest customers continue to expand and that signal is really strong and consistent. The pressure that we see is concentrated in that price-sensitive cohort. We estimate around 20% of ARR, which includes the 8% of the business that we have previously discussed, which is an as well as parts of mid-market and premium. And we're addressing that in FY '27 with now including DAP credits with every premium seat. We've adjusted coverage models to give them better connection into GitLab, including technical services to accelerate value adoption and value realization, and we're investing in better time-to-value experiences. Jessica, do you want to talk a little bit about the number itself where we expect it to go from here?

Yes. As you indicated, as Bill indicated, it's not a number that we guide to. But I do want to reinforce this is a year of stabilization for GitLab and so I would expect DBNR to trend down slightly before stabilizing.

Next question, Sanjit Singh from Morgan Stanley, followed by Karl Keirstead from UBS.

Just congratulations on the role. Bill, I had a question on essentially pricing. How do you sort of came to the pricing equation for DAP for Duo agents. And I guess the context that I'm thinking about is that the coating agents, the popular coating agents A lot of them are still kind of seat-based pricing, right, whether it's $20 a month or higher. This is more DAP seems to be priced more on a consumption-based model. So how you sort of arrived at the pricing mechanism for DAP? And then when you play this forward, how do you think about capturing more value in the GitLab platform?

Yes. Let me first start with that observation you made around competitors seem to have more of a seat-based price. That's actually not entirely true. They may have a seat-based entry costs, but then they either throttle usage or charging for overages, which is actually a less efficient model than what GitLab offers, which is we offer customers the ability to start with included credits. Every premium see gets $12 in credits, every Ultimate [indiscernible] gets $24 in credits, and that's because we want to win their hearts and minds with this phase of the platform. They can use it with now having to sign new contracts or get new agreements. And if they're finding value, they can then choose to opt in to on-demand credits. And you can think of on-demand credits as effectively pay as you go, we do a monthly bill based on actual usage at around $1 of credit. What this does then is it creates a demand model for our sales force where they see the signal of customers using and getting value and they're able to go have a conversation with the customer and offer additional discounts for committed credits as a monthly minimum. That then drives the flywheel of ratable revenue and ARR because those monthly minimum commitments turn into a subscription that we recognize ratably. This is a really powerful model that we think is better value for customers than having to pay on a per seat basis for throttled usage or overages, it's more efficient. And I'll just offer this. The existing competitive tools are heavily subsidized by venture capitalists, I don't think that's going to last forever. In fact, I would predict this year, you'll see many of the enterprise tools beginning to move to API-based charges instead of seat-based charges, which could raise bills for enterprises in the years to come.

Next question, [ Karl Keirstead ] UBS, followed by [indiscernible] from Baird.

Jessica, I wouldn't mind probing a little bit on the initial fiscal '27 non-GAAP margin guide of it looks like 12% at the high end, which would be a 5-point decel from the year you just put up. Can you unpack that a little bit and talk through some of the investments? I'm guessing sales capacity and perhaps even some DAP free credits could be weighing on that margin guidance, but I'd love to hear your views. And then just if we zoom out understanding you're not going to give guidance, but how are you and Bill, just conceptually thinking about the margin structure at GitLab. And if you think that this year could be the trough and how important is it for you and Bill to get those non-GAAP EBIT margins up to, say, 20% plus.

No, I appreciate the question, Karl. So our FY '27 margin guide reflects 3 discrete well-understood investments. 1 of which we committed to at the IPO, and we believe we have clear line of sight to expansion from there. At the midpoint, approximately 300 bps of the step-down comes directly from the gross margin mix shift that we've discussed. So the fab mix transition, which we redisclosed and then the remaining compression reflects 2 very deliberate investments. First, we're rebuilding go-to-market capacity, as Bill just talked about, that has been underinvested for several years. And so we're scaling sales capacity, building our first order team and continuing to deepen partner coverage. Second, we are accelerating the dual agent platform and deepening security and innovation. So our investment priority is [indiscernible], I highlighted in my remarks about the capital allocation framework, R&D first. than sales and marketing than D&A. None of these are structural central and each has a defined time line and a clear return as the business scales. So as we look to the future, this is really a year of investment, and we believe it's the right thing to do for long-term value creation and we're going to be watching payoffs very closely and empowering the business with the right [ guardrails ] that discipline has not changed. I think one of the reasons that I joined this business that has really demonstrated an ability to grow profitably and responsibly. The evidence is the 1,700 bps of margin expansion that we've delivered over the past 2 years. And in the long run, we're not managing to a margin percentage. We're managing to gross profit dollar growth. and the durable returns that come from scaling our platform.

Next question is [indiscernible] from Baird, followed by Jason Ader from William Blair.

Welcome about Jessica. Looking forward to working with you. Bill, you mentioned that, of course, fiscal '27 is largely about converting to a action and the financial contribution still remaining modest I know you touched upon the time line a little bit in the previous question from the standpoint of scaling the sales and rebuilding go-to-market. But just per some early customer feedback and there's a customer you mentioned about -- can you tell a little bit about just at a very high level, what are the potential gating factors on the customer side that you're seeing so far? Is it the [indiscernible] workflows? Is it more governance approvals? And what, in your view, help successfully scale these into production environments.

Yes. Let me start with the early customer feedback on DAP and then remind investors what it is that will take to convert those early pieces of feedback and trials into revenue. The first is we're getting really clear signal on the feedback that customers appreciate a full life cycle approach to agent AI Customers want to use DAP to handle highly repetitive and mundane tasks engineers do every single day as they manage code manage builds and deployments and manage the security of their software. So for example, an airline, I think I heard some of this in the prepared remarks, they're using app already to automate security vulnerability remediation, dependency updates and cloud migrations, and they now have approximately 90% of component version updates now running autonomously. Think about what that means, work that used to require a developer to contact switch and understand those component updates are now done completely through agents. Another example is an insurance company that used App to run an AI Hackathon, and they saw measurable improvements across compliance violations legacy modernization, developer onboarding time and their security posture. These are just some of the benefits that customers are finding as they evaluate and trial to agent platform in order to convert and become a paid customer with committed contracts, our customers have to be running a version of GitLab that supports the Duo agent platform. About 70% of our revenue is supporting customers with self-managed deployments. It's not like a cloud native, multi-tenant SaaS service GitLab is a very diverse portfolio with 70% running their own infrastructure and GitLab on their own premises, including many who have air gap environments that can't even connect to the cloud. Those customers typically take about 6 months for up to 50% of them to be running a version like the 18.8 release that we just announced Duo agent platform GA with -- so that's the first kind of time line to keep in mind. Obviously, the 30% of customers that are running in our multi-tenant cloud can start adopting today, and we're seeing early adoption there. But the bulk of the revenue won't have access to dual agent platform for another couple of quarters. And then secondarily, think about the fact that committed credits is really subscription revenue that we recognize rapidly. So even if we are able to start converting the trials to production and committed credits in the back half of the year, that revenue won't be recognized until the following quarters going into FY '28. So that's the reason for -- that's the early feedback that we're hearing from customers, and that's the reason for the conservative projections on Duo agent platform revenue for FY '27.

[Operator Instructions] Next one comes from [indiscernible] Blair, followed by [indiscernible] Truist.

My question for Bill. Has customer decision-making changed at all over the last few quarters in the face of kind of all this massive change. I guess what I'm asking is like have you seen sales cycles shifted all more focused on the enterprise with this question, but maybe just talk about how customers are navigating all this onslaught of change.

Yes. In my customer conversations, they're navigating it like most of the rest of us, which is every day, every week, there seems to be new innovation, new and exciting opportunities with AI and they're excited about the potential, and they're trying to navigate the many challenges that come with it, starting with the privacy and security concerns with their business. and also the increased costs and expense of investing in AI versus other traditional workloads. What's interesting is, I think there's a ton of experimentation going and obviously, Early results are really promising within certain workloads, especially around cogeneration and software development, and we're excited to take that early promise of building software using agents and turn it into actual software innovation with Duo agent platform. I don't see customers' behaviors changing. Our win rates are consistent. As I shared earlier, our gross retention rate just hit the highest level it has in 4 years. our competitive rates remain strong. And so really, this is about focusing our increased capacity executing a product strategy with increased pricing and packaging granularity to go after that opportunity in FY '27 even stronger than we did in FY '26.

Great. Next question, [indiscernible] followed by [indiscernible] from [indiscernible].

Bill, I think you mentioned your overall territory design I guess I'm wondering, has the number of accounts per rep changed? And how do you ensure that those handoffs go smoothly? And then just for Jessica, have you baked in any conservatism to guidance for that?

Yes. It's a fair question. Every year, the territories end up getting reslice to some degree, and this year is no exception. But I believe it's going to pay off in the long run. We found we had more accounts than reps could effectively manage and our upmarket shift a few years ago left the lower end of the market underserved. So the overhaul territory design does reduce the number of customers the rep has to manage, which should result in better customer intimacy accelerated adoption and value realization by the customer. We're also investing on the technical services side. So with the increased overlay support, in particular, for all segments, but also around 2 areas, especially 1 around that price-sensitive cohort with additional technical services to support their evaluation adoption and around AI, many companies are needing help to adapt their workflows to AI with Duo agent platform. There's a new set of technology and new set of techniques to use with your software life cycle. And so our technical teams are getting highly trained on that to help customers unlock the value, and we're also going to begin investing in forward deployed engineers who can go in and support that customer adoption cycle.

And then the short answer to your question is yes. We've been very holistic in terms of how we're thinking about prudence as we evolve the go-to-market motion.

Next question, Kingsley Crane from Canaccord, follow by Howard Ma from Guggenheim

Legacy code monetization has been in focus in the past couple of weeks. But when you rewrite millions of lines of cobalt, for example, that's not in a vacuum, it's still going to need to be version-controlled, run through CI/CD purview tested. Bill, you've been a developer for a long time. How much weight do you give to the idea that we're going to rewrite a lot of existing code versus creating that new code? And then how could this be expansionary for [indiscernible]?

That's a great question, Kingsley. I think in theory any software can be rewritten, and I see tons of really exciting experiments where developers are taking cogeneration tools, putting them into a closed loop and giving them instructions to iterate until the code emulates another existing piece of software. And I think there are certain places where that can be done, for example, discrete -- the discrete library or a simple application. For the scenario you described, for example, a legacy [indiscernible] application, maybe that's running on a mainframe or a piece of enterprise software that integrates with multiple third-party SaaS back ends, maybe Salesforce or Zendesk or other systems, I think it's a lot harder. So much of the context of that code is in people's heads. It's not written down, it's not documented. It's been built up over many, many years. And it's very hard to discover those integrations and assumptions purely through the code. And so the way I look at sort of the future of software engineering, I think of it as kind of 3 modes that we're going to be in for quite a while. And there's parallels here to what we just lived through with the public cloud area. And if you remember, when we started kind of the public cloud era, there was a big question of our Enterprise is going to leave their on-premise data centers behind and lift and shift everything to the public cloud? Or are they going to build just new applications in the public cloud and leave everything where it is. where we've ended is a similar place, I think, to where we're going with software. I think we're going to have 3 modes. The first mode is there will be a set of software that is so mission-critical for the business maybe especially to financially regulated and public sector companies where agents are just not allowed to touch the code either for security, privacy or just sensitivity reasons. That's a Mode 1. Mode 2 is where we're at today, and that's what Duo agent platform supports, which is human and agent collaboration on brownfield code bases. And these are orchestration patterns that are emerging and being used today. And I think that they will continue, especially for brownfield [indiscernible] like the one you mentioned for some time to come. And then as we get better at orchestration and enable more closed-loop iteration on code, especially with new greenfield projects, those code bases can become increasingly fully automated through the intelligent orchestration platform that we're delivering, and there will be less involvement from humans in touching and managing that code other than steering agents and orchestrating from above the loop. I hope that answers your question.

Next question, Howard Ma from Guggenheim, followed by Ryan MacWilliams.

Bill, I wanted to ask you more about Duo agent platform. In some of our conversations with engineering leaders. There seems to be a hesitance in adopting too many agents from multiple third-party software vendors out of the gate. And meanwhile, larger enterprises may also be debating between a build versus buy approach to agents. And then on the pricing side, you have the new usage-based pricing for DAP, but you also still have the seat-based pricing for Duo Pro and Duo Enterprise, which could cause some confusion for your customers. So how do you address these potential challenges? And are you exploring a further evolution of the model that combines the currency-based and usage base for Duo for DAP to make the pricing and packaging more seamless. Yes. So to be clear, the Duo Pro and Duo enterprise capabilities are already part of Duo Agent platform. And Duo agent platform represents a massive super set on top of that. Think of it as like 100x kind of capability beyond what Duo Pro and Enterprise provided. Those packages are still in market mostly for continuity perspective, any customers who have already been planning or in the process of buying those. We didn't want to disrupt and force them to reevaluate the new platform before making better purchase decisions. And we'll be incentivizing both customers and our field to turn those contracts into Duo Agent platform credits in the coming year ahead. So think of this as a transition period since 2-agent platforms just 7 weeks in market, and over the next couple of quarters, it will be clear, customers will see dual agent platform as our AI offering going forward. Great

Next question Ryan MacWilliams from Wells Fargo, [indiscernible] from BTIG.

Two-part question. For Jessica was just nice to meet on the earnings call. And I would just love to hear about how you built up to this guide on the top line side and any changes to the guidance philosophy there. And then for Bill, we'll love to hear about barriers to entry around CI/CD, why this is a strategic advantage for GitLab and why this would be difficult to replicate for enterprise customers like to replicate with CI/CD with AI.

Well, maybe I'll start with the guidance philosophy, especially with this being my first quarter [indiscernible] so I think there's a lot happening this year. In addition to me joining, there's a lot of moving parts. This is an investment and an execution year for GitLab. As we've talked about -- we're moving from a seed to hybrid model. We are in a new product cycle, the DAP launch, and we're also scaling our go-to-market motion. So a lot of moving parts. The first thing, I want to be clear, our process has not changed internally and is as rigorous as ever. And I've spent my first few weeks getting into the details of the business, specifically so that I could stand behind the numbers with conviction. Additionally, when I joined, I ran an intentional listening campaign with investors, and the feedback is very clear investors want more insight and transparency in how we arrive at the numbers. And so we heard you and I'm hoping that you all see that reflected in our prepared remarks, and I expect to carry that forward with my guidance velocity. And then finally, I would just reiterate that this business is ratable, which gives us strong board visibility, and we apply that visibility into our approach so that when we give you a number, we have high confidence that we will achieve it. So as it relates to the revenue build out, I think we gave you all the building blocks within my prepared remarks, but I do want to reiterate FY '26 and Q4 delivered the highest net new ARR year and quarter ever. And so because our model is ratable, a large part of the step down in our guide is mechanical. So it's not a change in the underlying health of the business. The guide reflects an honest SKU of where we are today, not where we hope to be. So I will just break down again, what's driving that step down from 26%. First, the mechanics FY '26 benefited from approximately 300 bps of nonrecurring tailwinds, premium price, favorable FX dynamics and specific contract clauses that won't repeat. Strip those out and then the comparable growth rate gets you closer to 2%. Beyond that, the ratable model means revenue today reflects bookings decisions made 3 years ago, and bookings growth has not [indiscernible] with revenue growth over the past 3 years. So that mathematical reality flows through for FY '27 regardless of what we do operationally this year. Second, what's embedded in the guide. As we've discussed, our first order team is coming online now, but won't be fully ramped until the back half of the year. We've talked about the fact those investments take time to show up in bookings and bookings take time to show up in revenue. So we've embedded prudence there. And then we've also been very deliberately cautious on both pub-sec and mid-market where we saw softness in Q4 and aren't assuming an immediate bank bounce back. And then obviously, we also talked about DAP. Customer reception has been strong, but we're in the very early stages of the adoption cycle. And on a $1 billion business with a ratable revenue model, we're not embedding any meaningful revenue contribution from something that we just launched 7 weeks ago.

Thanks, Jessica. Let me try to answer the first part of your question, which I'll paraphrase as how does the core GitLab platform stack up in a world where agents are quickly iterating, growing, getting stronger and better. And I think this is a common confusion with it. So let me try to use an analogy, and I hope this makes it more clear. You should think of the core DevOps platform that GitLab has as core infrastructure that both humans need to take action as well as agents need. So for example, there are many coding agents that can generate code. But that code needs to be stored. It needs to be version controlled. It needs to be tested. It needs to be reviewed. It needs to be secured and checked against all of the standards, the compliance frameworks and everything else the business is accountable for. That infrastructure is what GitLab has been building for over a decade. It's what businesses rely on to ensure the integrity of their software, and it's not going anywhere. What agents do is offer an artificial intelligence alternative to the human intelligence that's long gone into both riding the code and managing that software complexity. So you can think of Duo agent platform as that alternative for GitLab customers. They can now use dual-agent platform to automate tasks to do seamless handoffs between humans and agents and between agents and other agents to do all of the tasks that are required to move that software from planning all the way through deployment. Competitors can obviously offer alternative agents but they don't offer a placement for the infrastructure that is [indiscernible].

Great. We're almost up in time, Nick, you're going to be wrapping up the call here with the last question. Go ahead, please.

Jessica, just on the net new ARR strength you alluded to in 4Q, it sounds like the public sector improved sequentially. I know you said there was some deal slippage this quarter, but can you just give us a sense as to how much of the strength this quarter was driven from some of the 3Q public sector weakness we saw in that kind of getting across the finish line in Q4?

No, thanks for the question. Yes, as you alluded to, we delivered the highest net AR quarter ever, but the reality is results were mixed. First order bookings were healthy with strength in Asia Pacific and enterprise win rates improved quarter-over-quarter in sales cycles held steady. So the softness was really concentrated in 3 areas. First hub set, which is about 12% of ARR. And I want to be clear here that the long-term thesis has not changed. We remain the preferred partner to the U.S. government, and they continue to view us as mission-critical. That being said, we only saw a partial recovery following the government reopening. Some business moved into FY '27, and visibility still isn't where we'd like it to be. I think the budget picture has been interesting. We've had increases in certain departments and a lot of uncertainty in others. So again, that's been built into our guide. The second piece is the price-sensitive cohort at that Bill talked about. And as we shared, we said this at about roughly 20% of ARR. It does include some of the SMB weakness that we've been discussing as well as parts of mid-market premium and customers with budget flexibility. But again, we feel like we size this rig. We're not seeing that in the rest of the business. I think that's been reinforced by our 100,000 customers growing 18% year-over-year and that $1 million cohort growing 26%. And enterprise DBNR remains very healthy. And then you get into the U.S. performance and deal slippage that you were referring to, and this is very customer-specific. We experienced a few large deals slipping from specific customers facing budget constraints and some industry-specific challenges. For example, there was one retailer that had some Q4 challenges and another large customer that face some layoffs and restructuring. So these are real issues, and we're continuing to meet our customers where they are, but we found it to be something very specific. And that's all been embedded into our guide going forward.

Great. Thank you. With that, that concludes our Q&A. We will be at the Morgan Stanley TMT conference this week and look forward to meeting many of you in person. Thank you for attending GitLab's 4Q and fiscal '26 earnings call. Have a good evening.

Hey, everyone. It's Bill. Welcome to GitLab Transcend. We're hosting our community in 12 cities around the world with thousands more tuning in online. Thanks so much for joining us today. Growing up on a small farm in rural Utah, I loved science fiction. And I remember dreaming of the day when machines could interact with us like our friends and family and colleagues at work and elevate our lives in really profound ways.

GitLab started its journey over 14 years ago, focused on bringing the software development life cycle on a unified platform with modern agile principles. We serve more than 50 million users and over 100,000 organizations worldwide today. But in many ways, it feels like we're just getting started. As you can tell from our event title, we are seeing software engineering rapidly transcend the evolutionary improvements of the past decades. This is the most exciting time ever to build software and to power software-driven businesses. For us, it's about bringing everything our customers love about GitLab into the AI era. If you're a technology leader tuning in, I'm sure one of your primary questions is how you can increase the innovation velocity of your teams and get real ROI with your AI investments.

I've been in your shoes building software for decades, and I truly believe AI holds the potential for step function acceleration and innovation. And even though I'm a CEO of a company that builds AI technology for engineers, I can tell you this innovation velocity won't come from just adding AI tools or issuing top-down mandates on AI. That's because our main challenge in building software is not just a tooling problem. It's a really complex people, process and technology problem.

Software teams need to get comfortable with using AI. Their workflows need to be redesigned for agentic collaboration, and they need AI across the entire software life cycle. This transformation needs to happen while maintaining the quality, the security and the compliance of software we already have in place today.

Let me show you why. Let's start by talking openly about some ugly truths in software engineering. Let's put ourselves in the developer's shoes for just a few minutes. It's Monday morning. You open your laptop, coffee in hand, ready to go. You're a software engineer. You write software, right? Well, that's theoretically the job. But first, look at your calendar, sprint planning, backlog grooming, design reviews, architecture reviews and that daily standup that somehow takes 45 minutes. The average software engineer spends up to 11 hours per week in meetings. That's nearly 1/3 of your work week gone before you write a single line of code, and there's more.

One study of 250,000 developers found they spend just 52 minutes per day actually coding, 52 minutes. That's less time than it takes to watch a Netflix episode. So you finally escape your meeting and it's now 2 p.m., which statistically is when 45% well code actually happens and you start coding, you're in the zone, you're flowing and then Slack pings, a quick question. There's no such thing as a quick question. Research shows it takes 23 minutes to refocus after an interruption. That question just cost you half an hour of work. So you finally finish the code.

You create a merge request. It sits there on average for 5 days waiting for all the approvals. Did it merge? No, like a flip of the coin, 50% of the time, the pipeline fails, flaky tests, environmental drift, the build that worked yesterday, but for some unknown reasons, it doesn't work today. Okay. So you moved past that issue. But now the SaaS scanner flags 500 vulnerabilities. You're losing context. A survey found 62% of developers would rather reduce false positives than catch more real issues. That's how bad the noise is. Eventually, you just stop listening.

And beneath all of that, works technical debt. Engineers spend 84% of their time on maintenance, on tech debt and only 16% building new features despite 93% saying building new things is the most rewarding part of the job. So let's recap Monday.

Meetings, waiting for events, pipeline failures, security false positives, bug triage, technical debt and somewhere, if you're lucky, 52 minutes of actual coding. And tomorrow, we'll do it all again. But here's the thing. It doesn't have to be that way. AI coding tools have reenergized software engineering because they promised 10x productivity gains. And that may be true for some people, but only for the 52 minutes a day that they actually spend coding.

Let's unravel our software life cycle and see how that plays out in a real-world project. I'll play a project manager for just a minute and pull up everyone's favorite Gantt chart. Here is a representative project with approximate time spent by developers within each stage. And here's what it looks like with AI coding tools. This is what we call the AI paradox.

You see for a given developer's project, where they only spend 10% to 20% of their time coding, you see that even if you're 10x that slice, you've only improved total delivery by a little bit. Meanwhile, the real bottlenecks haven't moved. Your developers are now just faster at getting stuck in the same queues. That's because while the technology for one stage of the software life cycle has advanced, we need to advance all stages, and streamline the people and process handoffs across every stage.

With the help of AI, it's time to move from stage-based software life cycle, full of people and process handoffs to continuous software development, where agents can run continually, managing the handoffs and iterations, while humans remain above the loop, intelligently orchestrating their agents across the software development process. That's what we're building towards.

Let's envision what that might look like. Today, a GitLab Epic is a way to define a large project for humans to manually execute. Tomorrow, it's a spec for your agents. You create the Epic with the help of agents. GitLab Duo Agent Platform reads it, ask clarifying questions, breaks it into subtasks, respond to the right agents and links commits and merge requests automatically. You orchestrate the work, you define the intent and steer it.

Here's a critical principle. Agents don't decide if code is good, pipelines do. Just like today, when an agent pushes code, GitLab CI becomes the objective definitive arbiter, tests run, scans execute governance checks, verify compliance. The pipeline doesn't care that an AI agent wrote the code, it applies the same rigorous validation applied to any commit. And here's where GitLab's unified platform differs. System events are raised Azure work flows through GitLab triggering more agents and flows to automatically pick up and handoff work as needed, 24/7, 365 days a year.

This enables software engineers to be in a continuous flow, and it enables their agents to continuously iterate and improve until they meet business requirements. Every change has artifacts. Images, packages, software, bill of materials, providence, signatures because GitLab manages the entire life cycle, every artifact is automatically traceable to its source and validated by policy.

Security and compliance aren't separate workflows. They happen continuously as software is built. Audits become queries. Risks become manageable and visible. Supply chain risk becomes manageable at scale. A deployment using GitLab is not the end of delivery. That's where the learning begins. Every release is progressive by default, aware of the environment, policy and impact signals from production flow directly back into the platform. Performance, errors and user impact becomes inputs. Not afterthoughts.

Agents observe and recommend or even decide based on your policy, whether to proceed, pause, roll back or roll forward. You move to consolidate the stage-based life cycle filled with people and process handoffs at every step towards a continuous innovation loop where agents help your team go faster. Not just faster coding, but higher leverage, more effective software innovation. This changes more than developer productivity. It changes the economics of teams. We would love to show you this pace of innovation in action.

Let me hand it over to John, Fatima and Cesar for a demo of intelligent orchestration.

Thanks, Bill. There's so much work that goes into building software across teams beyond coding. And when you're doing that work manually, it holds you back from shipping faster. Let me show you how intelligent orchestration can ease these bottlenecks in real life. I'm John, a project lead and this is my dev team.

Hi, I'm Fatima.

Hello, there. I am Cesar.

We're going to tackle some challenges in one of our projects. Doing all this manually would take hours. We want to show you what we can do in a few minutes. So we're working on an application that generates Aura cards. Currently, the Aura card is based on the name and role that you enter into this form, a card with a random Aura is generated for you to download the share. But this is 2026. So we want to add cloud integration. With these integrations, we can generate custom Auras based on data from your GitLab profile and add an enhanced version of your profile picture to really personalize the card for you.

Of course, we also need to make sure it's secure before we can ship it. We've got a lot to do, but I think we can pull this off. So here's the Aura agent project. This contains not just our code, but everything that goes into building a production-ready application, security scan results, epics, issues, pipelines, analytics, dashboards, all the good stuff.

Look at all these issues. Thankfully, I have a foundational agent built by GitLab to help me out. I'll enter my prompt. What should we work on to get this ready to ship? Duo Planner Agent has access to tools and context from across the project. This agent is purpose-built to help with planning and product management. It makes my life so much easier. And here comes the plan. It normally would have taken me at least 30 minutes of scrolling issues and comments just to understand what's going on. Now I don't even need to look at my issue list. I can access this agent from anywhere in GitLab. Planner identifies the issue for making our app agentic as top priority, agreed. Let me assign this issue to Fatima, who is the developer for this app.

I am on it, boss.

Thank you. Appreciate it. All right. Now I'm going to check out the open MRs to see if we have any work in progress that needs attention. I see there's a failed pipeline in merge request 32. Our data shows that pipeline failure rates can be as high as 50% for some teams. You can imagine how much time and money is spent on these failing pipelines. Cesar owns testing and deployments on this project. So I'm going to assign this MR to him to review.

I'll start working on it right away.

Thanks. Fatima, how are things going with the issue?

Hey, things are moving along. I decided to use Duo CLI for this because I live in my terminal. Duo CLI Is our AI native assistant for the command line, which we are currently dogfooding and will be available to the public as an experiment in the next few weeks. With Duo CLI, I can ask questions about the code or use agentic workflows. And the conversations are synced from the CLI to the UI, so I can talk to the CLI and then pick it up in the UI later.

It's so awesome. I love providing these developer experiences and meeting them where they're at.

Yes, exactly. Now while you were planning, I asked Duo CLI to review the issue and come up with a phased implementation plan and then post it on the issue. So let me show you the plan that it came up with. It has 5 phases from creating the back-end service to the back-end logic, including the fallback strategy and updating the front-end UI and stylization to make this app look AI generated.

All right. That sounds again. Why are we taking a phased approach?

Just like you like to use the Planner Agent to prioritize and aggregate your issues. I like to use Duo CLI to help me break up my work into parts so that I can tackle them one at a time.

Okay. So switching back into my terminal. I'm going to ask Duo CLI to start implementing Phase 1 and Phase 2 of the plan. So while this is running, you can see that it's actually doing multiple things. It's reviewing our project structure, reading through the existing code to understand how everything connects and then writing some new code that matches our team's coding patterns.

And it's doing all of that context gathering automatically?

Yes. And that's what I love about Duo CLI because we don't have to manually feed it every file. It will navigate the code base and pull out the information that it needs. And it's like having a really good pair programmer to augment your work. And then when it's done with all the things that you've asked it to do, it will give you a summary of all of the changes across the files. Now whenever I get that summary, I want to look at the code changes before they're committed. So let's take a look at the git diff and walk through that code.

All right. That's great. Tell me more about the changes.

Yes. So we can see that it created a function to pull the data from the GitLab profiles, and then added some validation and implemented the back-end logic for Claude to generate those customized Agent Aura cards. I might need to update some of this code in the generate agent module, but I'll keep working forward with these phases, and I'll let you know when it's ready for our view.

All right. Sounds good. Cesar how it's going with the pipeline?

Yes, John. While Fatima was working. I was able to fix the pipeline failure quickly using one of GitLab's agents. I started by clicking on the Fix pipeline with Duo button. Let's head to the agent session log that ran this flow. Here, we see that the agent took several actions to understand the context and then it generated a pipeline failure context report that includes the test failure summary, merge request changes, root cause analysis and more.

The agent uses this report to come up with a pipeline fix plan that provides a root cause, task to fix the pipeline, expected outcome and technical details. The agent then generates a pipeline fix complete section, which includes what was fixed, verification results, and why this works. Finally, the agent creates a brand-new merge request with a corresponding fix.

Nice. Can you walk us through that merge request?

Sure. Let me open it up. So notice that this MR merges into the original request with the broken pipeline. Also under the changes tab, we see the fix that the agent applied to test-api.js file. And under the overview tab, we can see that the pipeline for this MR has run successfully. Notice that the merge has been blocked because this MR is in a draft mode. So let's mark it as ready and merge it. So merging will launch a new pipeline. Let's drill into this running pipeline and the job test API, which was failing before now it should pass.

So a quick question. Why did you use a flow for this?

Well, foundational flows like fixed CI/CD pipeline are designed to solve specific problems and are built and maintained by GitLab. So I know they are tested and production ready.

That's actually my favorite foundational flow because broken pipelines are so difficult to deal with. And GitLab provides a few other flows, such as the Developer Flow, which takes an issue description and writes all of the code for you.

That's right. We also have a Code Review Flow, which I'm going to show you next. Okay. It looks like the pipeline passed. Let me show you the code review now. So Duo has automatically reviewed the updates in this merge request. For code reviews, we are using the custom instructions you see here for this project. This means that the results will be specific to the things our team cares about. I can see comments in this MR that follow our team's coding standards.

So the pipeline is fixed, and we did a code review already. That's awesome. How long would this normally take?

Well, fixing our pipeline could take hours normally, you'd need to determine the root cause of the failure for starters and also read the documentation then apply the fix and then test the pipeline. And with respect to code reviews, if my reviewer is out sick, our code review could be waiting days before they get to it. But with GitLab Duo Agent Platform, both of these can be done in a matter of minutes.

Speaking of a matter of minutes, guess who has everything working for the AI integration.

I'm guessing it's you.

It is me. That's right. Your AI engineer. So I have got the app successfully running on my local host. And as you can see here, I can authenticate via GitLab and the app will generate an Aura card for me. And the Aura that I got is the Merge Request Diplomat, which is on point, given how many MRs I open.

Very nice. So we've got this working. Are we ready to ship to prod?

Not quite, John. Security scans are enabled for this project. And while checking the vulnerability report, I notice that there are three outstanding high severity vulnerabilities, which need to be addressed before shipping the application.

Yes, that's a good idea. So which vulnerability are we going to start with and how are you going to approach it?

So let me work on one of the Server Side Request Forgery vulnerabilities. I'm going to open the Security Analyst Agent and have it work on this. I'm going to ask it, what is the recommended fix for this SSRF vulnerability?

Ooohh, the Security Analyst Agent. I love that agent. As a developer, who understands the value of security, but is not an expert, I really love how that agent breaks down the vulnerability and helps you understand the remediation steps. I always learn a lot when I'm using it.

That's right. The agent responds with a detailed description of the vulnerability, options for how to fix it, implementation priority, and testing checklist. The Security Analyst Agent is giving us options for what to do next. Let's tell it to go ahead and create a merge request to implement this fix.

I love how approvals are required in these agentic ensuring that you have a chance to review the changes before the agent starts making adjustments to your code base or your project or issues.

So from the agent's response, we can click on the link to the newly created MR. We can see that the MR has implemented the fix. And once the pipeline passes, this vulnerability will be resolved and verify that its pipeline has already been kicked off.

Nice job, Cesar.

Thank you, John.

Wow, so we built out the AI integration, fixed a broken pipeline and resolved the security vulnerability in just a few minutes. This shows the power of intelligent orchestration with GitLab. We're going to publish this app for you to go build and share your Aura cards in just a few minutes, and we'll share the link at the end of the event. Stay tuned. Back to you, Bill.

Thanks, team. Isn't that amazing? Hours of work, condensed to minutes, developers delegating work to agents and working in parallel across multiple stages to get things done faster. And these are just a few of the use cases that GitLab can handle today. The real power of intelligent orchestration lies in its extensibility. Teams can create custom agents and flows tailored to their specific engineering standards, compliance requirements and organizational workflows.

With hundreds of use cases already documented, GitLab helps transform not just how software teams operate, but drives real business impact. 2025 was all about agentic AI. And I believe 2026 will be all about orchestration. This is the future. Swarms of AI agents working alongside teams across the entire software life cycle. So you may wonder why GitLab? Why not stitch together the latest open source or AI native best-of-breed point solutions that make it to Hacker News every day.

We started building our intelligent orchestration vision last summer and Duo Agent Platform represents just the first step in a long-term approach to providing customers the best platform for software engineering. There are 3 key reasons we believe you'll get the best solution from GitLab.

First, we're your system of record, your pipelines, your code, your security scans, your issues, merge requests, deployment history, all of that's already here. The problem point solutions have is that AI agents are only as good as the context they can access. A coding agent on your laptop sees local files, but can it see a pipeline that's about to break? The security vulnerability flagged last week? The issue explaining why this code exists in the first place?

GitLab connects your entire software life cycle into a single queryable map accessible by both humans and agents. It captures your current source code, pipeline configuration, security and compliance policy rules, issues, Epics, it's all here. And we're also building a historical view that can help agents understand a time line of your projects, giving them critical information about how your software has evolved over time.

Why it's changed? And who changed it. This is the level of nuance and quality context that point solutions simply can't match. If you're an existing customer, we're not asking you to adopt something new. We're inviting you to unlock what you already have.

Now here's the second reason. In this new AI era, the tools you choose will not only affect your developer experience, but will have an impact on the quality, the speed and the cost of your agents as well. Every time an agent crosses a vendor boundary, authentication handoffs, rate limits, security policy and token management, among other things apply. But even more importantly, you're mixing disconnected data sets with limited context windows, which will directly impact agentic outcomes.

What was once just a matter of developer preference can now impact business outcomes. This is the outer loop problem. With GitLab's inner loop architecture, compute and data are co-located in a secure enterprise cloud, one coherent context graph, one permission model. So when an agent fixes a pipeline, it operates within the same system where the pipeline runs and has access to all the same context across the software life cycle that your software engineer has.

You simply can't to do enterprise version control on a laptop, running enterprise CI/CD pipelines or compliance auditing locally. Workloads must happen where your software life cycle data lives. And GitLab is where the data lives, which means it's where agents can do real work, not just suggest code, but ship code with full governance, visibility and control.

So how do you bring all your existing tools together with GitLab? You use outer loops for exploration and connect to GitLab for inner loop execution. That means your team can keep using their IDE agents and specialist tools and use MCP together with Duo CLI to exchange context and take action. Then GitLab closes the loop where it matters. Pipelines validate, policies are enforced, artifacts are trusted, deployments are controlled and auto trails are complete. You start anywhere and you deliver through GitLab.

Our third reason is GitLab provides enterprise-grade protection. Your intellectual property is your most valuable asset. You may not be ready to let agents touch anything or you may want a human in the loop for oversight on specific projects. And for new projects, you may decide to go full agent swarm mode someday and let AI do all the work. No matter where you are in your AI journey, GitLab gives you the level of control that you need, you decide, which users, projects and groups can use AI capabilities.

When AI agents operate, you need to know who accessed what? What actions we're taking? And are we still compliant? Every agent action is centrally logged, including reasoning tools called and actions taken, and your proprietary code is never used to train models. One platform, one place to enforce policy, one audit trail, and one security boundary. To share how our customers are modernizing their software life cycle with GitLab, let me pass it over to Sharon.

Hi, everyone. I'm Sherrod Patching, VP of Customer Experience at GitLab. You've seen what the intelligent orchestration can do. Here's what it delivers in the real world. Ericsson achieved 50% faster deployments and saved 130,000 hours over 6 months, translating to faster innovation for telecom operators worldwide. Deutsche Telekom integrated security scanning into their software life cycle. The result release cycles cut from 18 months to 3 months. Barclays grew AI adoption across their software development life cycle with GitLab Duo, resulting in over 80% developer satisfaction, which enabled them to focus on higher value problem solving instead of manual tasks.

These modernization journeys aren't theoretical. They're happening right now. To help you accelerate your journey, we're launching a new assessment program next month. It will enable you to measure your organization's speed of software innovation and get customized reports on recommended next steps. This program is built based on real-world lessons learned from more than 300 organizations worldwide with onboarding playbooks, service catalogs, success plan templates and more. We can't wait for you to try them.

One of our customers who are partnering with GitLab as part of their modernization journey is Southwest Airlines. Southwest Airlines is one of the largest airlines in the world, operating 4,000 flights per day with 72,000 employees. The technology organization of 3,000 is tasked to ensure the reliability and resilience required for 24/7 operations.

Now with the recent investment in GitLab Duo Agent platform, they are taking one more step towards shipping mission-critical software faster. Please join me in welcoming Grant Morris, Managing Director of Technology for Business of IT platforms at Southwest Airlines. Welcome, Grant.

It's a pleasure to be here. And congratulations on your general availability announcement of the Duo Agent Platform.

Thank you. I appreciate it. Your support and partnership along the way has been invaluable. I'd like to share a few notes from our journey together with this audience here. How about a few questions just to guide our discussion.

Absolutely. Sounds good.

I know you've been at Southwest for 26 years. That is an incredible journey. You've seen a lot of change in how software gets built. Can you tell us what you were experiencing when you originally sought out a DevSecOps platform? And also what was important for Southwest and why was GitLab the right strategic partner?

It has been quite a journey over the last 26 years and the way that we build and deliver software has changed immensely. We started off with individually built and deployed applications. And now as we've grown to support over 4,000 flights a day and an engineering community of over 3,000 across the globe, our requirements are much different today than they were in the beginning. AWS and GitLab have become 2 of our strategic partners as we work more aggressively towards a cloud-first ecosystem. And in order to do that, we needed a platform that would scale and also provide the security and the governance that we require being as part of the airline industry.

Moving forward, our dedicated deployment option of a single-tenant SaaS offering from GitLab was very important to us. It provided the security and the regulatory compliance that we needed. But beyond the infrastructure and how we utilize the platform, what it really enabled was our teams to leverage the platform capabilities that we provided and instead of having singular siloed teams with each with their own deployment process, really let the application teams focus on the business value that they are trying to deliver while our platform products mature and take that burden off of our application teams.

Additionally, we're really challenging ourselves to leverage as much of GitLab's wide array of out-of-the-box capabilities as possible. In addition to the single-tenant SaaS solution, which has taken some of the burden of managing our own self-hosted solution off our plate, we continuously look for our platform engineers to deliver more capabilities to our application teams to further allow them to focus on what matters most, which is delivering business features for their customers.

Awesome. That is an incredible transformation. And now you're adding agentic AI to the mix with your recent investment in the GitLab Duo Agent platform. What are the real problems you're aiming to solve? And how is AI making a difference for software delivery across your organization?

We're looking for use cases such as security scanning and automated CVE remediation, smarter Renovate for our Docker-based images and a better pipeline component upgrade path, leveraging the capabilities of Duo Agent platform. We think if we can have an agentic workflow that is scanning our code bases for security vulnerabilities and then proposing an automated merge request for our developers to review, that will take a lot of toil and one-off time from our developers. We also think that by using something like our Smarter Renovate capabilities, we can reduce the toil associated with the upkeep of our Docker-based images. And then finally, we anticipate that we can automate approximately 90% of our pipeline component upgrades for our customers.

Again, all these things using the agentic workflows as part of Duo Agent platform that will reduce the toil and the repetitive task of our engineers and allow them to focus on what's most important, which is delivering business capabilities to our customers.

I love that these are really tangible use cases. I'm looking forward to partnering with you and your team and measuring the impact of these agents to your workflows. So to close our discussion, I'm curious, where do you see this going? What would software engineering look like at Southwest just a few years from now?

I think that's a great question and something that we're really trying to figure out right now. I think from a team perspective, we'll see the advent of more persona-based AI agents. We really want to focus on our engineering productivity and being able to supply our engineering community with specific domain-based personas will allow them to really optimize their workflow. Everything from creating a better story, better user documentation to getting to chat with a security expert or a deployment expert will help them really optimize the software delivery flow around how they want to work, being able to leverage agentic DevOps, not only in a persona-based format, but really to help orchestrate the overall software delivery life cycle, including inputs and agentic signals from our observability solutions because we all know demand comes from everywhere. And we need to be able to have our agentic capabilities receive that demand and have it flow through our normal delivery processes in an accelerated manner.

And then finally, imagine being able to have our agentic workflows, look at our repos in the background, propose tech debt upgrades and take care of minor or bigger version upgrades without our developers having to get in and search the code base and really spend time doing that. So we think by leveraging Duo Agent platform and the agentic workflows that it provides, tech debt will eventually become a thing of the past.

That is an incredible vision, especially your comment on making tech debt a thing of the past. I know that is very much desired and sounds like great potential for all of our customers. So thank you again for sharing, and thank you for partnering with us on this journey. It has been an absolute pleasure having you on Transcend. I truly appreciate your time and sharing your insights with everyone tuning in.

Of course. Thank you for having me.

To tell you more about GitLab's intelligent orchestration, let me pass it over to Manav.

Thanks, Sherrod, and thank you, Grant. We're all excited about your vision and appreciate the trust you've placed in GitLab. Hello, everyone. I'm Manav Khurana, GitLab's Chief Product and Marketing Officer. Earlier, Bill talked about the future of software engineering as a continuous innovation loop with AI agents helping your teams go faster, not just faster coding, but higher leverage, more effective software engineering. So let's talk about how you can make that real. Beyond pilots and experimentation across your entire organization. Today, I want to show you how GitLab is making that happen with security built in at scale and inside the guardrails you already operate under. We call it intelligent orchestration.

Intelligent orchestration has 3 parts: first, the Agentic Core, the foundation that makes agents actually work inside GitLab; second, unified DevOps and security tooling, where we are deepening the capabilities you already rely on; and third, enterprise guardrails, how you can stay in control while moving faster. Let's start with the Agentic Core. This is the beating heart of GitLab. We began our AI journey a couple of years ago with GitLab Duo, offering code suggestions and chat assistance. It worked. But we learned something really important. You don't have a handful of AI use cases. You have hundreds. And AI added feature by feature does not scale because your work doesn't happen in one tool within GitLab. It happens across entire workflows from idea to production.

So in 2025, we made a deliberate shift to a platform approach with Duo Agent platform. So you can orchestrate AI agents across the entire software life cycle using the same context, permissions and security model as your team has in GitLab. To get there, we evolved GitLab in 3 layers: Experience, control and data. At the experience layer, there is agentic chat, which you saw firsthand earlier in the demo. Agentic chat doesn't just answer questions. It reasons across issues, merge requests, pipelines, security findings and a lot more. It's in the GitLab UI, your favorite IDE. And as you saw earlier, soon in the CLI. Instead of having to ask multiple questions to get something done, you get one answer for the task at hand and the action behind it.

We've also built foundational agents for the tasks that slow every team down. For example, the planner agent turns a list of issues into structured prioritized work in minutes. The security analyst agent, translates vulnerabilities into plain language that helps your teams fix them faster. And coming soon, the data analyst agent that quickly gives teams insights from their GitLab data. But look, no 2 organizations or even 2 teams in an organization work the same way. That's why we built the AI catalog, a central place to create, publish and manage custom agents that reflect your workflows, your standards, your domain knowledge. This is the same platform GitLab uses internally to build the agents for you.

So AI doesn't exist as a side experiment anymore. It becomes operational, shareable and governed across your organization. Now some of you are already using tools like Claude Code from Anthropic or Codex from OpenAI. That's why we have integrated them as external agents. These are best-in-class agents now tightly integrated in GitLab without you having to give up on governance or auditability. Next is the control layer. We extended GitLab's existing control plane, Git APIs and Webhooks into a control plane for agents. This includes Agentic flows, which lets you chain agents together to automate real work. We've shipped prebuilt foundational flows for things like creating a merge request from issues, fixing broken pipelines or even migrating pipelines, automating code reviews, amongst others. And planned for a future release, custom flows for you to author workflows yourself plus event triggers to invoke flows in the background, not just when someone clicks a button. That's how manual effort turns into repeatable processes.

Now interoperability is also essential here. That's why GitLab has native support for model context protocol. With our MCP clients, agents in GitLab have a governed way to pull context from tools you already use like Jira, Confluence and Slack, amongst others. With the planned general availability of our MCP server, you can extend capabilities and context in GitLab to your favorite tools. Our goal here is to make GitLab a part of your broader AI ecosystem bidirectionally and always with governance. All of this is powered by unified context from the data layer. Every repo, every merge request, every pipeline, every security signal and all the related metadata is now accessible to agents with enterprise-grade security.

The new agent sessions is a complete audit trail of every AI interaction. You can see what the agent planned, what decisions it made and what actions it took. So AI and GitLab is observable, inspectable and compliance ready.

To go one step further, we are building the GitLab Knowledge Graph with planned availability this year, indexing repositories and related metadata, producing a semantic search API. You see agents operate under constraints of the context window and often have latency. In our early testing, with agents working alongside Knowledge Graph, we found that agents are responding notably faster and with increased accuracy. Behind the scenes, we're also upgrading the underlying data stores for broader insights and higher performance. That's what powers our engineering intelligence dashboard designed to help leaders see where teams slow down, where quality is improving and where AI is actually helping.

Let me show you a preview. I'm sure you can see a big difference right away. Instead of looking at metrics project by project, you can now see aggregated insights across the entire organization. 234 groups and about 1,500 projects. Just in the last 30 days, 6,500 users and their agents have opened about 16,000 issues, merged 470,000 MRs and had over 600,000 pipeline runs. With your intelligence dashboard, you don't need to piece together different views to know if you're getting better your craft. You can get a snapshot of DORA metrics and the trends in the same place and see the AI adoption across all your teams. And what impact is that having to your DORA metrics. That's really useful to measure how the AI rollouts are going and resulting in business impact. You can dive deeper to compare projects for each metric.

For example, let's take a look at the 10 projects that are scoring lowest on lead time for changes and see what's going on here. This table shows me that the number of pipeline runs is declining. But more notably, the failures are surging. That's not good. Because of the unified context you have in GitLab, you can dive in further by tapping over to projects. It looks like the issue with the payment service is the one that's most acute. From here, you have a connected workflow to see the details before reaching out to the team manager and asking them how you can help.

Now I'm familiar with this dashboard. You may not be. You could have also done the same exact thing in a different way by simply asking the data analyst agent to do this work for you. What you saw here in this demo is the power of GitLab's next-generation data layer, bringing unified context across groups and projects to unlock unique intelligence for your software life cycle.

Now let's talk about the DevOps and security tooling that sits on top of the new Agentic core. GitLab's strength has always been to stitch together the end-to-end software engineering process, replacing the friction of disconnected point solution. Taking into account feedback from all of you, our customers, we are now going deeper in several areas. For instance, with CI/CD, over 550 million pipelines are created inside GitLab every year. But building the right pipeline is hard. Fixing the failing one, well, that's a huge time sick. That's why we plan to introduce an AI-first CI/CD visual builder, enabling you to create and optimize complex pipelines without wrestling with YAML.

Next, artifact management. I hear this constantly. Why are we managing artifacts somewhere else when all my repos and my CI workflows are in GitLab. It makes sense. especially since legacy vendors are sunsetting self-managed options and forcing migrations to the cloud that increase your costs substantially. With built-in artifact management planned for this year, you will be able to host your artifacts where you deploy GitLab. When artifacts live alongside your code and your pipelines, you get one view from commit to deployment, no off handoffs, no sync failures.

Next, software supply chain security. Especially with AI-generated code, software teams are increasingly asking, what components are we using? Can we trust them? How do we prove it to auditors? Well, that's why this year, we plan to add a new software supply chain security module, building trust within your software life cycle to show you where code came from, highlight what's inside it and help block anything risky or unsigned at the artifact registry before it ever reaches production.

Related, secrets management, API keys, certificates, passwords, you need them encrypted, rotatable and visible. While you can manage secrets outside GitLab, having it integrated is just much more efficient and helps enforce stronger compliance standards. With the planned introduction of GitLab's Secret Manager, you'll be able to manage your secrets directly within GitLab, where your code and policy already lives. So that's where we are deepening the tooling you have from GitLab today. Before we continue, here's a quick video on our value in enabling automated security and compliance across your software life cycle. We'll be right back after that.

[Presentation]

Now let's talk about enterprise guardrails because none of this matters if you can't deploy GitLab on your terms and align with the regulations and compliance requirements that are only getting harder to satisfy. Diving into deployment flexibility, I've heard horror stories. Vendors are sunsetting on-prem tools, forcing cloud migrations, changing pricing models. Well, GitLab is different. We believe you should choose how and where you run GitLab. GitLab self-managed. So you are always in full control with your infrastructure. GitLab.com, our multi-tenant SaaS offering where you can get started instantly, GitLab Dedicated, single-tenant SaaS with data isolation and GitLab Dedicated for government, FedRAMP authorized for critical national infrastructure. The same flexibility you've had with GitLab deployments now also extends to AI, giving you the option to bring your own models. These models can be on your infrastructure, air gapped if needed, so inference stays in your environment or through the AI gateway or model provider of your choice, so you're not taking on new risk or forced to adjust your compliance posture.

So that's intelligent orchestration with the Agentic Core, unified DevOps and security tooling and enterprise guardrails, working together to help you create your continuous innovation loops across your organization. For over a decade, we have consistently delivered new capabilities across our unified platform with more than 180 monthly releases in a row. That commitment continues with intelligent orchestration. But I don't want you to take my word for it. I want you to try it. Starting today, every premium and ultimate customer gets monthly GitLab credits, $12 and $24 in credits, respectively, for every user at no additional cost. And if you're not a customer yet, start your trial at gitlab.com. And for everyone in our community, we're kicking off a virtual hackathon. A huge thanks to our partners at Anthropic and Google for joining us. Build custom agents, build agentic workflows, the best projects earn a permanent spot in our AI catalog, plus continued support from our team. We can't wait to see what you build.

And now to show you how you can scale adoption of intelligent orchestration in your organization within your time lines, let me hand it back to Sherrod. She's also got a special guest you won't want to miss. Thank you.

For those of you who are inspired by Southwest's journey with GitLab, I also want to take a moment to dive into GitLab's value acceleration services, how they work and how customers get started. We don't just sell you software, we partner with you to deliver measurable outcomes, reducing time to value from months, all the way down to weeks. For example, as part of your AI modernization journey, we start by identifying your highest value use cases for GitLab Duo agent platform. Our forward deployed engineers become part of your teams to build custom agents aligned with your engineering practices and compliance requirements. Hands-on training gets your teams creating agents, configuring workflows and managing the platform independently and governance frameworks that we build together ensure you can scale agentic AI safely across your organization.

We integrate with your existing systems. We customize for your compliance needs. We enable your teams to accelerate their innovation cycles. With GitLab value acceleration services, you can choose the level of support that fits your time line, self-serve resources, guided workshops, all the way through to full implementations with engineers embedded in your teams. Whether you need a rapid 90-day outcome for specific use cases or a multi-quarter transformation that changes how you deliver software, we're here for it.

As we look to scale our ability to solve challenges for all our customers worldwide, we rely on our partner ecosystem. Built on 4 pillars, it is designed to give you choice, flexibility and extensibility. Starting with technology alliances where we work with independent software vendors who integrate with GitLab, giving you the ability to build the stack that fits your unique requirements.

Next, cloud provider partnerships. GitLab is cloud agnostic, deploy on AWS, Google Cloud, Microsoft Azure, Oracle Cloud Infrastructure or your own infrastructure, choose based on cost, compliance, geography or existing relationships. Next, our partnership with AI providers, including Anthropic, OpenAI, Google and AWS. Some customers choose model by task, Claude Code for coding, others for different tasks, all tightly integrated with GitLab with embedded security and subscriptions. And finally, GitLab's open architecture. With our open source core, GitLab's code base is transparent, auditable and yours to deploy, customize and extend. This unique approach powers a thriving community of contributors and integrations, giving you the freedom to adapt GitLab in your own way.

One of our key partners in bringing GitLab to market at enterprise scale is Oracle. Together, we are collaborating to expand customer choice with streamlined GitLab deployments on Oracle Cloud Infrastructure, OCI. This partnership brings GitLab together with OCI's industry-leading cloud economics, extensive global footprint and flexible deployment options, including specialized environments for regulated industries. Please join me in welcoming Victor Restrepo, Group Vice President for North America OCI Engineering, to discuss this exciting collaboration.

Victor, thank you so much for joining us today.

Thanks for having me, Sherrod. Great to be here.

It's probably well known by now that both organizations have a strong commitment to open source technology and customer choice. What else do you think is driving OCI's focus on DevSecOps partnerships? And what other factors played a role in your decision to partner with GitLab?

At Oracle, we focus our cloud strategy around delivering open source technologies as first-party services. And GitLab exemplifies exactly what we mean by that. We're seeing that companies can't afford fragmented tool chains or security as an afterthought anymore. They need integrated platforms that actually move at the speed that the business requires while maintaining enterprise-grade security and compliance. So what this means for customers is dramatically simplified modernization journey. Our joint teams work directly with customers to understand their specific requirements, whether that's they're trying to drive cost optimization, regulatory compliance requirements or scale requirements in their business.

So instead of having to piece together the infrastructure, the platform and the tooling separately, they get a pre-validated enterprise-ready solution that is architected together. The real value is that you get the best of both worlds. So GitLab gives you all of the DevSecOps features that you need and then OCI brings the cloud economics that make it possible to fund and scale the deployments.

Awesome. That is such a powerful combination. It's clear that many organizations could benefit from the freedom of choice that you're highlighting here. I'm glad you touched on cloud economics. As we all know, cost optimization is always top of mind for every CTO and engineering leader. So taking into account OCI's global footprint, how do you see this partnership influencing the way organizations think about scaling their GitLab deployments?

That's such a powerful and top-of-mind question that everybody has. So cloud economics is absolutely critical. And it's an area where OCI has a distinct advantage. So in building our cloud, we made several key architectural decisions that enable us to deliver stronger, more modern platform for customers at a lower cost than other hyperscalers. So when our customers can reduce their infrastructure spend by 40% to 50%, they could actually free up the budget for the development teams to drive real business outcomes and transformations. So as an example, you could afford to give developers access to more resources such as running a more comprehensive security scans or maintaining more environments for testing and staging.

But it's not just about lowering the cost. It's about having predictable costs. Our global footprint and price parity gives customers the flexibility to deploy GitLab closer to where their development teams are as well as where the data resides. And that gives us the opportunity to help reduce the latency and improve developer productivity. What this means is that developers aren't just waiting for bills or deployments that could actually translate that directly into business value.

I totally agree. Thank you for sharing your strategy there. So to close our discussion, speaking of developer productivity, as we look at GitLab's Duo Agent platform and OCI's AI services, what opportunities do you see for integration that can benefit our joint customers?

So this is where things get really exciting. So what GitLab's Duo Agent platform represents the future of software development, intelligent agents that can actually automate complex workloads across the entire application life cycle. OCI's AI capabilities enhance the Duo Agent platform by delivering enterprise AI infrastructure for organizations so that they could accelerate their code creation, testing and remediation while keeping the proprietary source code private and governed. So looking ahead, we see opportunities for GitLab to leverage various OCI deployment models such as government cloud, dedicated cloud region to better support our customers in regulated and government industries.

This partnership positions our joint customers to be leaders in that AI-driven future. And frankly, I think we're just scratching the surface of what's possible when you combine GitLab's platform approach with OCI's infrastructure and AI capabilities.

I couldn't agree more. This has been an incredibly exciting partnership for GitLab, and I'm looking forward to serving many of our joint customers in the days ahead. Thank you again, Victor, for joining Transcend.

Absolutely. It's been a pleasure to bring this collaboration to life, and thank you for having me in the room.

To close our show, let me hand it back over to Bill.

Thank you, Sherrod. To close, I want to express my heartfelt thanks to the entire GitLab team for making this moment possible. Your dedication, passion and commitment to our customers and the entire community is truly inspiring. Thank you to Grant Morris from Southwest Airlines and Victor Restrepo from Oracle for sharing your insights and experiences with our community. And thank you all who are attending Transcend today virtually or in person. You've seen the problem, engineers drowning in ceremony, waiting in queues, fighting systems and triaging noise. And you've seen the solution, agentic AI across the entire software life cycle, shifting developers from drudgery to high-value work, replacing status theater with automated visibility and collapsing the friction between idea and production.

Now you've seen how GitLab delivers it, your system of record with complete life cycle context and interloop architecture that optimizes your workflows and enterprise-grade protection within your guardrails. The future of software development isn't just faster coding, it's faster everything from idea to production with AI agents as trusted collaborators at every step. The question isn't whether agentic AI will transform software development. The question is whether you're in position to harness it. We've spent a decade building GitLab. Now there's an agentic layer at the heart of it, bring everything you love about GitLab forward into the AI era.

As we close our show, here's a look at the new GitLab. Let's roll the video.

Okay. Hi, everybody. I know you guys are thoroughly sick of looking at me, but you'll be very pleased to know this is the last time you'll do so. I've saved the best to last. So this is my last fireside, my last chance to learn a little bit more from a couple of software executives in Bill and James. So proud to have GitLab here. I think it's a very public knowledge that UBS is an extraordinarily large customer of GitLab. So I think we've got a pretty happy IT executive team as well. And I trust, Bill, we've been paying our bills lately.

Yes. You're a great customer.

Okay. Great. So Bill, you haven't been in the seat for that long, but as you sort of close out your first year-ish, I think, do you want to kind of give us a little bit of the state of the union, look back at the year, what went well, what could have gone a little bit better?

Yes, I was just looking at my phone because tomorrow is the 1-year anniversary.

Okay. Congratulations.

Yes, it's been such a fantastic year. I came to GitLab because I spent most of my career building developer tools and platforms and the opportunity to do that at GitLab, which is kind of one really rare and unique opportunity. It's a world-class company that's really the backbone of our customers' software factories. There's only 2 companies at scale for DevSecOps like GitLab.

And so the opportunity to be part of that, but also part of this AI wave, which I truly believe is going to change all of our lives in the coming decades, both as consumers and as professionals. And that all starts with the software workload, bringing AI to the software workload. So not only being part of an amazing DevSecOps company, but the ability to shape the future of software innovation is why I'm here. And it's been an incredible ride. We've made a ton of progress as a company, and I'm even more excited today than I was a year ago.