A panel conversation at GitLab After Dark Singapore

On 24 September 2026, I joined the GitLab After Dark Singapore panel at Rasa Space. The conversation was titled Earning the Right to Autonomy, a theme that connects directly with my work in site reliability engineering: building foundations that let teams move forward with confidence.

Preparing for the evening gave me a chance to step back from individual tasks and connect our GitLab migration experience with DevSecOps, controlled automation and AI governance. These are the ideas I want to keep from that preparation.

A migration is more than moving repositories

Our move from a self-managed GitLab environment to GitLab SaaS was one part of the story behind my preparation. The practical work extended beyond source code to the history, permissions, pipelines and integrations that teams depend on.

Pilots helped us understand what needed attention before cutover. Testing representative projects, including the unusual and complex ones, made the plan more useful than assumptions alone. A clear recovery approach and shared understanding of the work also mattered.

The distinction I keep returning to is between completing a transfer and restoring an engineering workflow. Validation needs to continue afterwards: can people work with the right access, run their pipelines and use the connected tools? That is the outcome that makes a migration meaningful to the teams using the platform.

Shared foundations make DevSecOps practical

The migration also gave me a way to think about the delivery process around the platform. Centrally managed security policies can help establish a shared baseline, rather than asking every team to maintain its own version of the same checks.

For me, consistency is practical. Checks need to work with real projects, findings need to reach the right owners, and engineers need a clear path through review and delivery. SRE, application and security teams all have a part in that. Good controls should support the work people need to do, with clear ownership when something needs attention.

AI assistance still needs engineering judgement

One concrete example from my own work is using GitLab Duo to help understand pipeline failures. An explanation can help me decide what to investigate next; I still need to check it against the logs and configuration, review any proposed change and validate the result.

That distinction matters as automation becomes more capable. Advice and action need clear boundaries. Approved tools, appropriate access, human review and an audit trail are part of earning trust in the process. The engineer accepting a change remains responsible for it.

AI readiness, in that sense, begins with a delivery process we understand. More automation should make that process easier to follow, while preserving the controls that make it safe to use.

Keep the outcome in view

I want to evaluate a platform through the work it enables: whether teams can deliver reliably, investigate failures and apply security standards consistently. Those questions keep a migration or automation initiative connected to everyday engineering rather than just a completed project checklist.

Thank you to the organisers and everyone who took part. It was a useful occasion to bring these connected themes into one conversation, and to record a moment from my engineering journey.

Read the event post on LinkedIn.

This is a reflection on the themes I prepared, rather than a transcript of what was said on stage. The date above is the website publication date; the event took place on 24 September 2026.