I think the near-future of AI assistance in software development will look something like this:
Companies employ coding agents. Coding agents are different from copilots. A copilot provides live feedback in the context of a user’s IDE. A coding agent completes discrete tasks.
Coding agents have a comprehensive understanding of your technical resources. They know about your codebase, infrastructure, design assets, documentation etc… They also have access to their own secure execution environments that they use for running tests. Like any good employee, they are confident in the quality of their work before they submit it for review.
Coding agents are deeply integrated into apps that make up nearly every phase of the development lifecycle. They translate design updates into code; they appear in task management apps as candidates for new work; they respond immediately to bug reports with near-immediate pull requests…
The primary bottleneck to their productivity will be task clarity. Because of this, so much of the scaffolding of software development will turn towards making tasks comprehensible to coding agents.
Copilot has Issues
In November, Github announced that they would bring code automation to Github Issues.
With Copilot Workspace (as it is officially named), users will be able to solicit AI assistance for any of the tasks they’ve recorded in Github Issues. When summoned, Copilot will generate a “plan” that users can review and edit. If users like the approach, they can direct Copilot to do the work. It’s not quite a coding agent since the human is still in the loop. But it’s close.
Even without being fully autonomous, Copilot Workspace teases a new paradigm of task management.
In the past, this category has centered on human coordination: break out work into tasks, distribute them to members on your team etc… But the dynamics change when we start treating AI as a labor source. Suddenly, the value of a task management app goes from coordination to something more strategically vital: actual automation of work.
In the new paradigm, apps will compete in terms of how much automation they can facilitate. It’s hard to imagine customers sticking with their existing task management solution if alternatives (like Copilot Workspace) can reliably automate some portion of work.
My view is that Copilot Workspace reflects the new shape of task management apps for dev teams. One aspect has to do with keeping track of planned work. The other has to do with incorporating coding agents that can actually complete discrete tasks.
Copilot Workspace natively integrates both of these pieces. Issues lets users record work they need done, while Copilot is the agent layer that has a hand (one day an autonomous one) in completing that work.
Just because Github has their own agent-integrated task management system doesn’t mean they won’t pursue a platform strategy. It’s easy to imagine Copilot as an agent plugin for any task management system. In fact, I’d expect that lots of apps in the developer lifecycle will eventually integrate with Copilot plugins to facilitate code automation.1
One question is whether Copilot will have any competitive advantage over possible agent alternatives. Copilot will likely come to know quite a bit about your team’s resources. Perhaps, the friction involved in giving Copilot access to your documentation, infrastructure, design system etc… represents a kind of switching cost: teams might be reluctant to go through the same onboarding process with an alternative coding agent.
Even if the agent layer were to totally commoditize from a product perspective, that would still probably be favorable to Github. They have numerous default advantages, e.g. brand, distribution, default access to your codebase etc… that make them the likely winner in this category.
The biggest risk to Github is that an alternative agent provider turns out to be straight up better. In that scenario, Github may end up finding that the roads they paved, in getting the ecosystem aligned around agent plugins, may end up working against them.
How does this forecast bear on companies like Linear and other task management apps?
Github Issues represents a bigger competitive threat than Linear and others probably ever anticipated. But as long as Github pursues a platform strategy, I assume they’ll be unbothered by Github’s moves in the space. (On reflection, they’ll probably be able to charge for bot users…).
Their biggest risk is probably that a new entrant emerges with a completely new approach to task management. What do eng teams need in a task orchestration system that helps them get the most out of their AI colleagues? The answer might be significantly different than just making coding agents available targets for task assignment. It might not even look like task management.
If you’re building something in this space, especially if it feels a bit radical, I’d love to hear from you. You can reach me at peter@upfront.com.
Interesting questions, outside scope of this current post, linger around the nature of those integrations. The simplest form of integration for Github is for users to authorize 3p apps to send instructions to the Copilot on their team. But integration dynamics might be more complex than they immediately seem. To the extent that the best user experience calls for Copilot to actually participate in 3p apps as if it were a real user, we might need a standard protocol that governs Copilot interactions in 3p apps.
Excellent post.
> My view is that Copilot Workspace reflects the new shape of task management apps for dev teams. One aspect has to do with keeping track of planned work.
I’m curious if this ends up transferring a larger/different workload to product owners in the long run, in terms of orchestrating dev work, now done by AI. Or perhaps the product team also gets automated here.
Great piece. Couple reflections:
* The automated coding of tasks (agents) feels like the right next step from the current augmented coding experience that copilot delivers. I feel good about placing a bet on this trend, whether it's in software engineering or in other industries.
* It's important to think about the review process when this paradigm comes online. Reviewing a body of code is significantly more taxing than "hinting through" the code as copilot does, especially if you're a good engineer and write comments before your next block of code (like me 😇). There's something to changing from author to stitcher that personally makes me feel more comfortable.
* It'd be so hard for me to place a bet here. Github has everything going for it as you mention, most importantly the focus and drive. I think Cursor might be an interesting signal to watch here.
PS - I think there's a typo in the "Github Issues..." paragraph - think you mean Linear down below.