Created
March 10, 2026 18:22
-
-
Save LaurMo/f323fce1147044f5bf6109fff4695c9e to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| # Mobile Agentic Research Plan | |
| ## Executive Summary | |
| GitHub Mobile is entering a moment of significant opportunity. As Copilot and agents begin to participate more actively in the software development lifecycle, mobile can evolve from a passive companion app into a *control surface for agentic work*. | |
| Early brainstorms and research signals suggest that developers do not want to deeply author workflows on mobile. Instead, they want to *monitor progress, resolve blockers, and delegate work to agents* while away from their desktop. | |
| This research effort will help us validate where mobile can create the most leverage for developers. The goal is to identify the moments where mobile increases *momentum, awareness, and trust in automated systems*, while maintaining fast access to core GitHub workflows like pull requests and issues. | |
| Insights from this research will inform the evolution of: | |
| - Home | |
| - Mission Control | |
| - Notifications | |
| - Copilot surfaces | |
| - Agent interaction models | |
| The outcome will guide how GitHub Mobile supports a *new developer workflow where agents handle increasing portions of work while humans monitor and steer progress across devices.* | |
| --- | |
| ## Objective | |
| Understand how GitHub Mobile should evolve to support an *agentic developer workflow* while maintaining fast access to core GitHub functionality. | |
| Mobile should act as a *lightweight control surface for the software development lifecycle*, allowing developers to: | |
| - monitor active work | |
| - quickly unblock workflows | |
| - delegate tasks to agents | |
| - stay informed without returning to their laptop | |
| This research will help identify where mobile creates the most value within an *AI-assisted development environment.* | |
| --- | |
| ## Key Research Questions | |
| ### 1. Where Mobile Fits in the Developer Workflow | |
| Validate when developers naturally reach for mobile and what tasks feel appropriate on a phone. | |
| Questions we want to answer: | |
| - When do developers check GitHub on mobile? | |
| - What tasks feel valuable in *under 30 seconds*? | |
| - What workflows feel too complex or risky on mobile? | |
| Working hypothesis: | |
| Mobile is primarily used for *triage, awareness, and quick interventions*, not deep authoring. | |
| --- | |
| ### 2. What Drives Repeat Mobile Engagement | |
| Identify the triggers that cause developers to open the GitHub mobile app. | |
| Potential high-value triggers include: | |
| - CI failures | |
| - PR review updates | |
| - agent status changes | |
| - incident alerts | |
| - repository activity summaries | |
| Understanding these moments will shape *Home, notifications, and Copilot entry points.* | |
| --- | |
| ### 3. What Agent Workflows Users Will Delegate | |
| Explore when developers are comfortable letting agents run autonomously. | |
| Key questions include: | |
| - When does automation feel helpful versus risky? | |
| - What guardrails increase trust in agent behavior? | |
| - What alerts or approvals are needed when agents run unsupervised? | |
| Insights here will inform how we design *agent visibility, escalation paths, and intervention controls* across mobile surfaces. | |
| --- | |
| ### 4. What Mobile Should Avoid | |
| Just as important as identifying opportunities is understanding the boundaries of mobile. | |
| Research should help identify workflows that create friction on mobile such as: | |
| - reading large diffs | |
| - writing long prompts | |
| - managing complex project structures | |
| - navigating dense technical context | |
| Understanding these boundaries ensures mobile focuses on *high-leverage moments rather than replicating desktop workflows.* | |
| --- | |
| ## Target Demographics | |
| To ensure we capture a range of behaviors and needs, we will recruit participants across several developer archetypes. | |
| ### Heavy GitHub Operators | |
| Developers who spend a large portion of their day managing repositories, pull requests, and CI pipelines. | |
| These users are most likely to adopt *agent workflows and mobile delegation patterns*. | |
| Typical characteristics: | |
| - multiple active repositories | |
| - frequent pull request reviews | |
| - CI monitoring responsibilities | |
| - heavy GitHub daily usage | |
| --- | |
| ### OSS Maintainers | |
| Open source maintainers who frequently manage issues, review community contributions, and triage activity across repositories. | |
| Mobile workflows are often important for *triage and coordination across distributed contributors.* | |
| Typical characteristics: | |
| - public repositories with active contributors | |
| - high volume issue management | |
| - asynchronous collaboration patterns | |
| --- | |
| ### Engineering Leaders and Staff Engineers | |
| Developers responsible for project direction, repository health, and incident response. | |
| Mobile supports *situational awareness and decision making* rather than hands-on coding. | |
| Typical characteristics: | |
| - oversight of multiple teams or services | |
| - involvement in incident response | |
| - monitoring CI and deployment pipelines | |
| --- | |
| ## Research Methods | |
| ### Workflow Interviews | |
| Conduct interviews to understand how developers currently use GitHub on mobile. | |
| Focus areas include: | |
| - when they open the app | |
| - what they hope to accomplish | |
| - what slows them down | |
| --- | |
| ### Mobile Diary Study | |
| Participants record moments when they use GitHub on mobile throughout the day. | |
| This helps uncover: | |
| - natural usage triggers | |
| - context switching patterns | |
| - real-world workflow interruptions | |
| --- | |
| ### Prototype Testing | |
| Test upcoming mobile concepts including: | |
| - Actionable Home | |
| - Chat-first workflows | |
| - Mission Control | |
| - Agent steering experiences | |
| Key measure: *time to action.* | |
| --- | |
| ### Notification Concept Testing | |
| Evaluate actionable notifications that allow users to: | |
| - fix CI issues | |
| - respond to agent prompts | |
| - unblock pull requests | |
| - resolve merge conflicts | |
| Notifications may become the *primary entry point for mobile engagement.* | |
| --- | |
| ## Success Metrics | |
| We will evaluate mobile concepts using the following metrics. | |
| *Time to Action* | |
| How quickly users can complete high-value workflows. | |
| *Path Length* | |
| Number of taps required to complete common actions. | |
| *Findability Rate* | |
| Percentage of times users navigate directly to the correct location without backtracking. | |
| *Agent Engagement* | |
| Frequency of initiating or interacting with agent workflows. | |
| --- | |
| ## Strategic Opportunity | |
| GitHub Mobile should not attempt to replicate the desktop experience. | |
| Instead, it should specialize in: | |
| - *momentum* | |
| - *delegation* | |
| - *situational awareness* | |
| In an agentic development world: | |
| Desktop remains the primary *creation surface*. | |
| Mobile becomes the *control layer for orchestrating agent work.* | |
| If successful, GitHub Mobile can become the easiest way for developers to *monitor and steer automated work across the software development lifecycle.* |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment