GitLab Epic Tour Amsterdam 2025 at the Heineken Experience

On Thursday 27 November 2025 I spent the day at the GitLab Epic Tour Amsterdam, held inside the Heineken Experience. The wall next to the Epic Tour screen listed the building’s rooms (Koelschip, Heritage Quarter, Haystack, Henry’s, Molenzolder), and a green sign outside read “Welcome to the home of Heineken”. The talks took place in a room under a sloping roof with a podium in Heineken green.

My GitLab lanyard from that day is already in my conference badges year in review. This post covers the talks, written up from the slides I photographed. I didn’t record any of them.

Arriving at the GitLab Epic Tour in Amsterdam.

The agenda

The full programme on one slide.

The agenda slide set out the day’s programme:

• 09h15 GitLab introduction and welcome: Louise Fellows (AVP Enterprise Sales) and Nasser Mohunlol (Director Enterprise Sales)
• 09h45 “Your one stop shop for security & compliance – with the power AI”: Viktor van den Berg, Senior Solutions Architect, GitLab
• 10h30 “From Self-Managed to SaaS: Booking.com’s GitLab Migration Playbook”: Wesley Yarde, Engineering Manager, Booking.com
• 11h30 “Flipping the paradigm: from assisted to agentic coding”: Michiel Fokke, Enterprise Technologist, AWS
• 12h00 “Code Smarter, Not Harder: Boosting Efficiency with GitLab and Google Cloud’s AI-powered workflows”: Hala Emadeldin, Solutions Architect, Google Cloud
• 14h00 “The Next Era of DevSecOps: Building High-Performance Teams with autonomous AI Agents as Partners”: Corina Patachia, Solutions Architect Manager, GitLab
• 14h45 wrap-up, then networking drinks from 15h00

Opening: from DIY toolchains to one platform

The welcome talk included a slide titled “When we started our journey…”. It showed three stages from left to right: “Bring your own tools” (a scatter of tool icons), “DIY DevOps” (the same icons, roughly grouped) and the GitLab DevSecOps Platform, drawn as the infinity loop of plan, create, verify, package, secure, deploy, monitor and govern. It is GitLab’s usual opening argument: one platform instead of a toolchain you maintain yourself.

Security and compliance: “Some facts”

Viktor van den Berg’s session started with a disclaimer slide: the presentation contained information about upcoming products, and the audience should not rely on it for purchasing or planning. Then came “Some facts”:

• “Modern software development moves fast, but security sometimes lags”, which may lead to breaches, compliance violations and slower time to market.
• “8/10 of the top data breaches last year came from attacks on the application layer.”
• “Only a fraction of critical vulnerabilities are truly worth prioritizing.”
• “The average data breach cost $4.4M USD in 2025.”

The footnote cited the 2025 IBM Cost of a Data Breach Report, the 2024 CrowdStrike State of Application Report and the Datadog State of DevSecOps 2025. Next to the text were three images: the NIS2 logo, an ISO 27001 badge and, in between, a cartoon of Dora the Explorer, presumably standing in for the EU’s DORA regulation.

“Some facts”, with NIS2, DORA and ISO 27001 on the right.

My take: the slide’s most useful line is “only a fraction of critical vulnerabilities are truly worth prioritizing”. Most teams I work with don’t lack scanners. They lack a way to decide which findings matter, based on reachability, exposure and whether a fix exists. Regulation such as NIS2 and DORA makes that triage auditable, which is a better reason to centralise it in the pipeline than the scanning itself.

Booking.com: from Self-Managed to SaaS

Next was Wesley Yarde, Engineering Manager at Booking.com, with “From Self-Managed to SaaS: Booking.com’s GitLab Migration Playbook”. I only photographed the title slide, so I won’t try to reconstruct the playbook from memory.

Wesley Yarde opening Booking.com’s GitLab migration playbook.

My take: the title alone describes a decision many platform teams are weighing: stop running your own GitLab instance and move to the managed service. In my experience the hard parts of that move are rarely the repositories. They are the runners, the integrations and the CI configuration that grew around the old instance. That is where shared pipeline building blocks pay off. GitLab’s CI/CD components are reusable pipeline configuration units, published in the CI/CD Catalog and included with include: component. If every team includes the same versioned components instead of copying YAML, you have far less to rewrite when the platform underneath changes. My GitLab CI tutorial covers the pipeline basics.

AWS: from assisted to agentic coding

After the coffee break, Michiel Fokke of AWS presented “Flipping the paradigm: from assisted to agentic coding”. His first chart, “A new Moore’s Law… Much faster”, plotted test scores of AI systems against human performance across capabilities (data from Kiela et al., 2023). Handwriting recognition took around 15 years to reach human level, and the newer capabilities on the chart got there much faster.

Left: three years of AI in software development. Right: why assistance alone doesn’t deliver the speed-up.

“AI is changing software development” was a timeline:

• 2023, auto complete: helping developers write code faster
• 2024, assistants: generating larger pieces of code and answering questions
• 2025, agents: completing development work end to end (part of this column was hidden behind a head in my photo)

A slide titled “Agentic, crashing!” followed: a comic-book picture of two robots in a car heading for a crash. Then the core argument, “AI-Assisted”: “Developers still perform the intellectual heavy lifting and apply AI in narrow tasks”. The diagram ran from business intent to requirements, design, build and software systems, with AI helping only on specific tasks. The warning box read “Not delivering the AI agility promise” and “Manual inefficiencies”, with the line “Time saved in coding is still lost in other SDLC rituals.”

My take: I agree with that last line. When code generation gets faster, the bottleneck moves to review, testing, security sign-off and release. If those steps stay manual, the lead time hardly changes. That is why the afternoon session, which put AI on those steps, was the more interesting half of the day for me. I wrote more about this in AI coding agents and platform engineering.

GitLab: the next era of DevSecOps with AI agents

The afternoon session was “The Next Era of DevSecOps: Building High-Performance Teams with autonomous AI Agents as Partners”, which the agenda listed for Corina Patachia, Solutions Architect Manager at GitLab. Its slides, under the heading “AI across the SDLC”, walked through GitLab Duo features one by one.

“One workflow to unite your developers, security, and operations teams – powered by AI.”

The summary slide, “One workflow to unite your developers, security, and operations teams – powered by AI”, drew the whole lifecycle as one path: epics, milestones and issues (with “generate issue description”), write code, create a merge request (“issue to merge request”), push code, automated test (with the Fix Failed Pipelines Flow), scan (vulnerability resolution), collaboration and review (code review), approval, merge (merge commit message), release and deploy. GitLab Duo Chat ran along the top of the diagram and the GitLab Knowledge Graph along the bottom.

Left: the Fix Failed Pipelines Flow. Right: the Knowledge Graph, shown as a beta.

Three of the feature slides in more detail:

• Fix Failed Pipelines Flow: “Helps you automatically diagnose and fix issues in your GitLab CI/CD pipeline.” The bullets were business-aware detection, contextual root cause analysis (correlating logs with business needs, recent changes and cross-project dependencies), integrated resolution (“automatically creates MRs with proper review and business context for prioritization”) and the outcome: “keeps pipelines green and strategically aligned, not just technically fixed”.
• GitLab Duo Code Review: “Automatic reviews from GitLab Duo ensure that all merge requests in your project receive an initial review.” You can assign Duo for a first review, iterate with it on the merge request, and customise its instructions per glob pattern of files.
• Knowledge Graph (GitLab Duo Agent Platform, marked beta, Premium and Ultimate): “Map files and dependencies to enable rich code intelligence across your codebase”, so Duo agents can understand relationships across the development environment and answer complex questions more precisely.

What the docs say a year later

GitLab’s documentation has moved on since that afternoon, so I checked it against the slides:

• The GitLab Duo Agent Platform docs now list it as generally available from GitLab 18.8, for Premium and Ultimate. They describe a set of foundational agents and flows.
• The pipeline feature is now called the Fix CI/CD Pipeline Flow. It examines pipeline logs, merge request changes and repository contents. In a merge request it applies inline suggestions or opens a new MR with the fix, and in some cases it only posts a comment describing the failure and next steps.
• Code review now also exists as the Code Review Flow, which the docs say “helps you streamline code reviews with agentic AI”.
• There is also a Convert to GitLab CI/CD Flow, which is directly relevant to the migration theme of the morning.
• The Knowledge Graph documentation page now redirects to GitLab Orbit, which “indexes your GitLab instance and exposes your entire SDLC as a queryable property graph”. It is still marked beta.

My take: of everything on the slides, the pipeline-fixing flow is the one I’d pilot first. A failed pipeline already holds most of the context an agent needs: the log, the diff and the job definition. The fix comes back as a merge request, so a human still reviews it. That is a much safer starting point for agents than letting them write features. Measure it the boring way: time from red pipeline to green, and how many of the suggested fixes get merged unchanged.

Afterwards: Amsterdam AI

Later that afternoon I joined an Amsterdam AI session (“technology for people”) about its public engagement fellows. One slide said the programme had built a network of 95 people, from students and PhD candidates to full professors and professionals, and another pointed to amsterdamai.com/fellows. A slide titled “AI Agenda: model for conscious intensive automation” placed trust in AI on one axis and the preferred interaction (human to system versus human to human) on the other.

“Among Peers”: the questions the fellows had collected.

The “Among Peers” slide collected the questions people had raised, including “How do we design for the terrible possibilities of AI?”, “Why should I as a citizen trust any institution?”, “How can we as a democracy keep up with the fast changes and govern it well?” and “How can builders become accountable and can we make sure that humans are not guinea pigs?”. After a day of slides about autonomous agents in the delivery pipeline, it was a useful change of perspective.

Related

• GitLab CI Tutorial: Complete Pipeline Guide (2026)
• GitHub vs GitLab 2026: CI/CD, Security, and Pricing
• GitLab CI vs GitHub Actions: CI/CD Compared 2026
• A Year of Badges: My Superpower Is Staying Current