Developer Clients Group

The Developer Clients group owns and maintains the editor extensions for VS Code and JetBrains IDEs, as well as the Duo CLI, bringing GitLab’s core features and AI capabilities directly into developer workflows.

🚀 Vision

We bring GitLab’s core features and AI capabilities directly into developer workflows, unlocking productivity by making GitLab accessible in the tools developers use every day.

This group is part of the AI Clients stage.


👨‍💻 Team Members

Engineering Manager: Amr Elhusseiny

Product Manager: James Casey

UX: Yi-Ann Chen

Name Role
Amr ElhusseinyAmr Elhusseiny Engineering Manager
Alejandro Metke JimenezAlejandro Metke Jimenez Senior Fullstack Engineer
Andrei ZubovAndrei Zubov Senior Frontend Engineer, Create:Editor Extensions
Juhee LeeJuhee Lee Fullstack Engineer
Karl JamoralinKarl Jamoralin Backend Engineer
Laura IonelLaura Ionel Senior Backend Engineer
Malte HeuserMalte Heuser Fullstack Engineer, Create:Editor Extensions
Mohammed OsumahMohammed Osumah Fullstack Engineer
Tomas VikTomas Vik Staff Fullstack Engineer, Create:Editor Extensions

🤝 Stable Counterparts

Below are our stable counterparts:

Name Role
James CaseyJames Casey Director of Product
Yi-Ann ChenYi-Ann Chen Senior Product Designer, AI
Jon GlassmanJon Glassman Senior Technical Writer.

💬 Where to Find Us

Slack

Shared Calendar

We use AI Clients’s shared calendar


🏠 Functional Teams

Team Scope Channel
Duo CLI AI-powered command-line interface #f_duo_cli
VS Code GitLab Workflow VS Code extension & Web IDE #f_vscode_extension
JetBrains GitLab plugin for JetBrains IDEs #f_jetbrains_plugin

💻 Scope

Products owned by this group

  1. GitLab Extension for JetBrains
    1. Repo
    2. Docs
    3. Backlog
    4. Slack Channel: #f_jetbrains_plugin
  2. GitLab Workflow Extension for VS Code
    1. Repo
    2. Docs
    3. Backlog
    4. Slack Channel: #f_vscode_extension
  3. Duo CLI
    1. Repo
    2. Backlog
    3. Slack Channel: #f_duo_cli

📚 How We Work

Issues’ State

We use the issue Status field to indicate state, following the Product Development Flow.

Expand for more details

To keep things simple, we focus on the main states below and optionally use others when appropriate.

  • New → Not yet prioritized or refined.

  • Planning breakdown → Needs team attention soon (within ~1–2 months); gather scope, risks/deps, acceptance criteria.

  • Ready for development → Immediate priority; clear scope; should be picked up next and ideally completed within ~2 weeks.

  • In dev → Assigned DRI(s), milestone set, work in progress.

  • In review → Implementation complete; MR opened and under review/verification.

  • Blocked → Cannot proceed due to a dependency or external constraint; comment the blocker and next check-in date.

  • Closed → Done (or closed as duplicate/won’t fix) with outcome noted.

Note: We chose Planning breakdown & Ready for development as these statuses exist on both Issues and Tasks, letting us build one unified set of boards and embedded tables with a single status filter easily.

Issues Boards

Weekly Issues’ Refinement

  • Purpose: Keep our backlog focused and up-to-date
    • We re-prioritize and adapt to the changing requirements
    • Create clarity about what customer support issues we need to implement
    • Give everyone a chance to surface and champion issues (new/urgent bugs, tech improvements or tech debt)
  • Format: 3 stage process described in the “Flow” section below
  • Cadence: Every week
  • Output: Up-to-date Rolling Backlog + possible weekly updates to the milestone planning issue
Expand for more details

Rolling Backlog Wiki Page

This rolling backlog page is the output of this refinement process. It serves as a visible, prioritized, and team-reviewed top-of-backlog list for every scope we own (could be the next 1-2 months of work).

Note: We also take into account most thumbed up issues to make sure we also capture community feedback.


Flow

  1. EM & PM async weekly pre-pass: prepare for the next 2 steps

    1. Some issues sources to consider
    2. Add the label workflow::scheduling to the issues to discuss in step #3 (EM + PM Sync call)
    3. Update issues as needed to make sure Rolling Backlog is up-to-date.
  2. Team async bi-weekly review (timebox ~1 hour):

    • EM will create an issue to trigger this review and assign all engineers, example issue, please unassign yourself when you finish review
    • Occurs every 2 weeks, to avoid taking too much of the team’s focus each week.
    • Goals:
      • Ensure everyone on the team weighs in on the priorities.
      • Advance tech improvements or tech debt issues.
      • Flag issues that should be given higher importance.
      • Identify issues that are no longer needed or should be de-prioritized.
    • How to Participate:
      1. Review the current priorities in Rolling Backlog
      2. Weigh in: Add/Change the following as needed (including for new issues you want to push):
        1. Status: Planning breakdown: Should be on our radar, within the next 2-3 milestones or so
        2. Status: Ready for development: Ideally should be done this milestone
        3. Label: workflow::scheduling: Immediate priority, should be picked up next (or at least should be discussed this week)
      3. Comment & tag EM + PM if you change any of the above with reasoning
    • Notes:
      1. Don’t spend time deep investigating any issue at this point, just high level overview of the priorities is enough
      2. Comment in the relevant issue itself or in the rolling backlog issue if your comment is more relevant there
      3. Link to references to specific GitLab resources to improve discoverability.
  3. EM + PM weekly sync call: Focus on the label workflow::scheduling, read team comments, confirm ranking, make trade-offs, and pick target deliverables for the next 1-2 weeks.

    • Meeting should be scheduled on the shared team calendar and recorded; we will also use zoom transcript so team can have transparency on the reasoning and arguments behind changing an issue priority or order and add it to the planning issue.
    • Once every month this call will be used to create a milestone planning issue that can be subject to change with the next refinement.
    • EM is responsible for assigning the agreed on & updated deliverables.
    • Output: Update the milestone planning issue weekly + EM to assign updated priority issues
      • Once a month, before the start of the milestone, the discussion will span a bigger number of tickets in preparation for creating a new milestone planning issue

How to Participate (for non-team members)

If you want to bring an issue to the attention of the team, please create an issue. If no issue exists yet, then reach out on #s_ai-clients-questions.

Monthly Planning

  • Purpose: Define and scope what we’ll deliver in the current milestone
    • Plan monthly to shape product priorities, but revisit weekly to stay adaptive to fast-changing AI requirements, quality focus, and urgent user needs
  • Format: 2 stage process described in the “Flow” section below
  • Cadence: Every month + possible weekly updates
  • Output:
Expand for more details

Milestone Planning Issues

We use Milestone Planning Issues to define our goals for the current/upcoming milestone. The PM and EM are responsible for aligning on the goals. The planning issues are created automatically every month.


Flow

  1. Fill Initial milestone planning issue
    • PM drives the goals of the milestone, in alignment with EM
    • All the output of the previous issues refinement is taken into consideration
    • Should be done before the milestone starts
  2. Weekly updates after the weekly issues refinement
    • EM + PM update the milestone planning issue, if needed, reflecting latest changes, that could include for example:
      • Urgent bugs that came up
      • Needing to adopt another AI engineering team work into the IDEs
      • Flagged tech debt
    • EM aligns with the team to assign Deliverable & Stretch labels and ensure issues status, weight & milestone are assigned reflecting the latest priorities
      • Possibly in weekly 1:1 or async

Team Sync Meetings

We have a sync meeting once per week. This is a collaborative meeting across the Developer Clients group.

  • Recordings are uploaded to the Editor Extensions Category playlist on GitLab Unfiltered.
  • The timing of the call alternates every week between APAC/AMER & EMEA/AMER so everyone in different timezones can join sync conveniently at least every other call, and everyone can contribute async as well every week.
  • Weekly Sync Meeting Agenda, agenda is open, everyone in the team is invited to bring relevant topics to align on.

Weekly Async Updates

Team members post weekly async updates on the in progress issues using the Dev Check-in (editor-extensions) comment template.

Issues’ Labels

Check AI Clients labeling guidance

Some extra labels we use:

Label Description
Deliverable Committed items for the milestone / must-ship work.
Stretch Next items on the priority list, added as optimistic goals for the milestone

Issues’ Weight

We use three weights to give a rough estimate of the issue’s complexity:

  • 1 - day or two of effort
  • 2 - week of effort
  • 3 - week and a half of effort

Notes:

  1. Everything with a base weight above 3 should be a spike that will result in one or more issues with estimated weight.
  2. These are estimates for someone familiar with the codebase/system; you can add extra weight 1 or 2 to the base weight if you are new to the team/codebase/system.
  3. Weights are assigned in the planning flow.

Cross-Group Ownership and Boundaries

Editor extensions systems host features and modules owned by different groups.

The Ownership and Boundaries page provides clarity and a clear expectation between all parties who author/maintain features in our systems.



Duo CLI
We are building an intelligent command-line interface that brings GitLab Duo's AI capabilities directly to developers' terminals, enhancing productivity through natural language interactions with GitLab's DevSecOps platform.
JetBrains
The JetBrains functional team owns and maintains the GitLab plugin for JetBrains IDEs, bringing GitLab's core features and AI capabilities directly into JetBrains-based developer workflows.
VS Code
The VS Code functional team owns and maintains the GitLab Workflow extension for Visual Studio Code and the Web IDE, bringing GitLab's core features and AI capabilities directly into VS Code-based developer workflows.