Six research artifacts, built with a team of five researchers, mapping what AI means for developer roles, the DevOps loop, and GitLab’s product strategy over the next several years.
Context & Contributions
GitLab’s design team was sprinting on a bold new vision for the product, and that kind of speculative, future-facing work needed to stay grounded in real research rather than just conviction and instinct. Futurecasting 2026 was our team’s answer: six linked artifacts, moving from framework to evidence to competitive landscape to workflow to interaction design to concrete implications, meant to give the design team (and the rest of GitLab) a shared, evidence-backed picture of where things are heading.
This was a true team effort with shared leadership. I worked alongside four other researchers across most of the series, and I solo-authored the closing synthesis piece.
PROJECT DETAILS
ROLE: RESEARCHER, SHARED TEAM LEADERSHIP (SOLO ON THE CLOSING SYNTHESIS)
PROJECT TYPE: SPECULATIVE / FUTURES RESEARCH SERIES
TEAM MEMBERS: 5
DURATION: Q1 FY26
Problem
Nobody had put together a coherent, evidence-based picture of how AI was likely to reshape software development roles, workflows, and competitive dynamics over the next few years. Without that, ambitious product and design bets risked being built on assumption rather than research.
Hypothesis
We believed that if we built a deliberate sequence of artifacts, each one testing or extending the last, we could give GitLab’s design and product teams something more durable than a single trend report: a framework, tested against expert opinion and a competitive landscape, then extended into concrete workflow and interaction implications, then closed out with specific, sourced recommendations. In lieu of this we were concerned that future design directions ran the risk of becoming untethered from data and signals we were getting from the real world.
Methods & Process
Understanding
We started with a framework, not a study: a three-role operating model we called Builders, Governors, and Layers, describing how software delivery roles are reorganizing as AI takes on more execution. Builders create and implement, Governors own accountability and judgment calls, and Layers are the AI and platform infrastructure that mediates between them. That framework became the spine the rest of the series tested against, rather than something we derived after the fact.
Refining
We ran 7 expert interviews with academics and industry professionals, structured specifically to test whether the three-role framework held up against independent opinion. It did, largely, the interviews validated the split and sharpened its boundaries, while also surfacing governance and accountability anxieties that kept recurring through the rest of the series. We mapped the interviews across all 7 STEEPLE dimensions (social, technological, economic, environmental, political/regulatory, legal, ethical) to see where our coverage was strong and where it wasn’t, finding thin coverage particularly in environmental and legal signal.
From there we built The AI-Augmented DevOps Loop, an interactive map of 39 AI capabilities and competing vendors across Ideate, Create, Release, and Oversee, tagging every capability by which role it primarily serves. That surfaced one of the framework’s more useful findings on its own: the vast majority of AI tooling on the market targets Builders, leaving Governors systematically underserved. We used that gap directly to shape Speculative Future SDLC Workflows, which took the loop’s findings and asked where human judgment remains genuinely irreducible even in a highly automated future, landing on five judgment moments: intent setting, value prioritization, ethical review, crisis response, and stakeholder accountability.
The SDLC work in turn raised a question none of the earlier artifacts had answered: not just where AI acts, but how it should interact with people when it does. That became Agent Modalities, an evaluation of 27 hypotheses about how people will actually work with agentic AI, across interaction patterns like chat, workspaces, nudges, whispers, and summons. We scored each hypothesis against the evidence: 3 came back well-supported, 12 somewhat supported, 4 directly contradicted by what we found, and 8 landed as mixed, genuinely dependent on organizational or market conditions design can’t resolve on its own.
Delivering
I closed the series out by writing “What This Means for GitLab,” synthesizing design and product implications across all five earlier artifacts, with every implication linked back to the specific piece of research it came from rather than presented as a bare assertion.
Findings & Results
The series produced some sharp, quotable findings on their own: the developer role is fragmenting into three distinct functions rather than one, agentic AI needs genuinely different interaction modes depending on context and trust level, every stage of the DevOps loop is already contested by AI-native competitors, five human judgment moments remain irreducible even in a highly automated future, and the transition itself is a design problem in its own right, not something that resolves on its own once the right features ship.
More broadly, this work gave GitLab’s design team a research-grounded foundation while they sprinted on a bold, forward-looking redesign of the product. Rather than a single trend report handed off and forgotten, the series stayed live and connected. Each artifact’s findings fed the next, and the closing synthesis kept tying speculative design work back to the specific evidence behind it.
Leave a Reply