> 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.
* 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.
I didn't want to get into this in the piece but i think you're right that the IDE is another vector of activity to pay attention to. A few notes:
- IDE layer in software dev has been largely unmonetized (Jetbrains is a notable exception). Version control has proven far more strategic. Lots of reasons for this (open source commoditized IDEs with free offerings in emacs, vim, vscode; also version control made more sense as a nexus for collaboration). Maybe AI assistance tightly integrated into the IDE changes the dynamics.
- One thing that I don't get into here but which is sort of implied at the end. Natural language as a programmign language has all kind of funky implications. Very reductionist but: if you pull on this thread, you might come to the conclusion that task management itself is a sort of very high-level programming language with agents as a sort of compiler. So when I say that the future of task management might not look like task management, i'm sort of pointing at the idea that maybe developers would benefit from a new interface for architecting, planning, and writing software.
Interesting that you frame this from the perspective of task management. Your last paragraph hints at this but I'm not sure we have the right UX for orchestrating coding agents. I imagine we'll have different levels of abstraction: from Cursor at an IC level to Devin at a product team level, etc ...
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.
I didn't want to get into this in the piece but i think you're right that the IDE is another vector of activity to pay attention to. A few notes:
- IDE layer in software dev has been largely unmonetized (Jetbrains is a notable exception). Version control has proven far more strategic. Lots of reasons for this (open source commoditized IDEs with free offerings in emacs, vim, vscode; also version control made more sense as a nexus for collaboration). Maybe AI assistance tightly integrated into the IDE changes the dynamics.
- One thing that I don't get into here but which is sort of implied at the end. Natural language as a programmign language has all kind of funky implications. Very reductionist but: if you pull on this thread, you might come to the conclusion that task management itself is a sort of very high-level programming language with agents as a sort of compiler. So when I say that the future of task management might not look like task management, i'm sort of pointing at the idea that maybe developers would benefit from a new interface for architecting, planning, and writing software.
Interesting that you frame this from the perspective of task management. Your last paragraph hints at this but I'm not sure we have the right UX for orchestrating coding agents. I imagine we'll have different levels of abstraction: from Cursor at an IC level to Devin at a product team level, etc ...
I liked Erik's take here on an AI engineer as a potential convergence of different layers of abstraction: https://erikschluntz.com/software/2024/07/30/code-with-ai.html
Thanks for sharing!