That hasn't been our experience using it in-house! It's not perfect, but not every software engineering task is some galaxy-brain architectural shit. Sometimes, you have to lay down some bricks. And sometimes, to lay down bricks, you need to touch more than one tiny patch of code.
Having something round up the likely areas of the codebase that needs touching feels magical. It doesn't always succeed! But it feels pretty magical to get that boost when you're new to some part of a codebase (which, real talk, code I wrote > 1 month ago, I must page back into memory).
Making it easy for me to progressively add context for the model is an accurate analogue for how I think as a developer when tackling a task. I have to build a mental model of how things work. And then a plan for how I'm going to change it.
Maybe for the kinds of tasks you usually tackle, it won't have value. But the amount of context it's attempting to bring to bear on whatever task you give it is categorically more — and better — than any other tool I've seen. I have seen (and been the author of) spaghetti. Could I make CW generate spaghetti? Surely. That's why it's a tool for developers, not a substitute for developers.
A part of building great products is allowing your engineers to focus on things that really matter. But sometimes you need to change copy, add small features, from my experience with some of these tools, it is incredible. A PM can just create a repo issue, and the bots will go away with high accuracy and quality (if your codebase is setup well), and submit a PR.
This level of velocity for teams cannot be understated.
I'm sure we'll share some of the strategies we used here in upcoming talks. It's, uh, "nontrivial". And it's not just "what text do you stick in the prompt".
When video terminals first came out, everyone started out using line editors even though line editors make no sense when you can display arbitrary buffer. It took a while until editors changed to be "screen native". But they did change, meaningfully.
When GUIs first came out, editors were just "terminal editors in a window". Took a while for the modern concept of an IDE to happen, with hovers, red squigglies, sidebars, jump to definition. All of that was possible on the first day of the GUI editor! But it took a while to figure out what everyone wanted it to be.
I think we're at a similar inflection point. Yeah, everyone today (myself included) is comfortable in the environment we know. VS Code is lovely. And AI (plus realtime multiplayer) is not a display technology. But I think it's a material technology shift in the same vein as those two moments in history. I would not bet that the next thirty years is going to continue look like today's VS Code. I don't know to say what it WILL look like — we have to keep prototyping to find out.
I mostly agree with all of your points. But IMHO, if (and that's a big if nowadays, with modern web and mobile dev) text editing is the core task of the app your'e using as your IDE, then all the graphics are just redundant.
All the highlighting, hovers / etc can be done via much simpler graphics that is memory and CPU efficient.
As a dev, I would like to IDE developers to invest in core functionality, rather than a fancy GUI.
Take the electron IDE for example. It embeds the chrome runtime which is a total waste, given that i just want to edit some text files.
The leading coefficient of these tools successfully getting you to/near the goal is all about clearly articulating the domain and the job to be done
Ergo, it's pretty important to craft experiences that make their core mechanic about that. And that's how Copilot Workspace was designed. The LLM generating the code is in some ways the least interesting part of CW. The effort to understand how the code works, which files must be touched, how to make coordinated changes across the codebase — that's the real challenge tackled here.
But there is so much context that the LLM has no access to. Implicit assumptions in the system, undocumented workflows, hard edge cases, acceptable bugs and workarounds, Peter principle boundaries, etc... All these trade-offs need someone that understands the entire business domain, the imperfect users, the system' implementation and invariants, the company's politics and so much more. I have never encountered a single programmer, no matter intelligence and seniority, that could be onboarded on a project simply by looking at the code.
How many students / people early in career would benefit from having something to help them explore ideas?
How many don't have the advantages I had, of a four-year university, with professors and TAs and peers to help me stumble through something tricky?
How many have questions they feel embarrassed to ask their peers and mentors because they might make them look stupid?
Don't give up. This is a generational opportunity to lift up new developers. It's not perfect (nothing is). But if we sweat hard enough to make it good, then it is our chance to make a dent in the "why are there not more ______ people in tech" problem.
_People_ are getting outsized value from AI in the ways they apply it. Photographs come from the photographer, not the camera.